Subject: [Sidr] new ROA format

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Apr 2007 10:43:47 -0400

Folks,

In response to the discussion on the list, and at the meeting, I want 
to suggest a new format for ROAs, which addresses some of the issues 
that have been discussed.

First, I note that the original format reused much of the RFC 3779 
format for representing address space.  However, on further 
reflection, we should probably use a smaller subset of that format, 
just the part that represents address prefixes, not address ranges. I 
say that because we will be using the content of a ROA to generate 
route filters or in a similar fashion, and BGP advertises only 
prefixes, not the arbitrary ranges that 3779 can express.  Making a 
change just to accommodate prefixes (vs. ranges) we get some 
simplification of the format:

       RouteOriginAttestation ::= SEQUENCE {
         version [0] INTEGER DEFAULT 0,
         asID   ASID,
         ipAddrBlocks ROAIPAddrBlocks }

       ASID ::= INTEGER
    
       ROAIPAddrBlocks ::= SEQUENCE of ROAIPAddressFamily
    
       ROAIPAddressFamily ::= SEQUENCE {
         addressFamily OCTET STRING (SIZE (2..3)),
         addresses SEQUENCE OF IPAddress }
       -- Only two address families are allowed: IPv4 and IPv6
    
       IPAddress ::= BIT STRING

Note that this is just a subset of the 3779 ASN.1, so it retains the 
advantage of reusing that syntax, and that should make comparison 
against the cert used to verify a ROA easier than if we adopt a 
different syntax. It allows multiple prefixes to be associated with 
one AS in each ROA.

Additionally, there were suggestions about what controls we should 
make available to a ROA signer, to express the semantics of the ROA. 
The simplest one, other than my ill-conceived exact match suggestion, 
was a proposal by Geoff for a flag to say exact match vs. inclusion. 
There was also a suggestion from Curtis to allow for a mask length 
range, e.g., prefix/len1 [-len2].  Larry enumerated 4 prefix range 
operators taken from RPSL, which support even more expressiveness.

It is important to note that the ASCII syntax used in the latter two 
suggestions above is not directly compatible with the ASN.1 used in 
3779. That prefix syntax is binary, and RFC 3779 has defined a 
canonical representation for it already (something we do for most 
digitally signed objects). So we would need to employ a different 
encoding to represent any of these more sophisticated prefix 
expression options, if we still want to keep the syntax in the ROA 
easy to match against the 3779 extension in the cert.

Another observation is that an address space holder can generate 
multiple ROAs to express constraints that might not be expressible 
via a single ROA if we adopt less expressive prefix range  controls. 
Of course we have to balance complexity of such controls against the 
repository bloat that could arise if one had to generate lots of ROAs.

So, I'd like to ask the WG what level of expressiveness do we believe 
is required in ROAs? For example, what has the experience been using 
the RPSL range operators, e.g., do we see IRR entries that use all 
four of the ones Larry cited, or do most entries use only a subset, 
and if so, which subset? Can we get by with just a flag indicating 
whether a ROA confers authorization to advertise exactly the prefix 
contained in it, or the prefix and all more specifics?

Since the RIRs and others are already developing code to deal with 
ROAs, it is important that we make progress on selecting format 
sooner, rather than later :-) .

Steve

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: Russ White <[email-masked]>
Date: Tue, 10 Apr 2007 18:27:42 -0400

> different syntax. It allows multiple prefixes to be associated with one
> AS in each ROA.

I would much prefer to see the prefix/length format in the ROA, just
from the operational usefulness and human readability perspectives....

> Additionally, there were suggestions about what controls we should make
> available to a ROA signer, to express the semantics of the ROA. The
> simplest one, other than my ill-conceived exact match suggestion, was a
> proposal by Geoff for a flag to say exact match vs. inclusion. 

I would really like to see this suggestion incorporated.

> There was
> also a suggestion from Curtis to allow for a mask length range, e.g.,
> prefix/len1 [-len2].  Larry enumerated 4 prefix range operators taken
> from RPSL, which support even more expressiveness.

I'm ambivalent on this one. Either way is fine with me.

:-)

Russ