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 protected]
https://www1.ietf.org/mailman/listinfo/sidr
