Geoff Huston wrote:
> WG-Chair hat hurled into the corner for this posting....
>
> I note that there are two residual open issues in the ROA draft that
> should be resolved. From the minutes of IETF 72 it was reported that
> from this draft:
>
>
> o Open issues:
> * Should a canonical format for IP addresses in ROAs be
> specified?
> - What does equivalence of ROA mean if there is no canonical
> format?
> - Should we mandate canonical format to make comparison as
> easy as possible?
> - Is a useful canonical format feasible, and is the transform
> to any such format of benefit to the ROA creator or ROA
> relying party?
> - How do we apply the validation test of a precise match
> between the resources in the EE cert and the prefixes in
> the ROA, as described in step 3 of the draft
> - Further consideration of this topic is required by the WG
>
(see below, please)
>
> I'd like to propose a resolution to these issues by proposing that:
>
> a) NO canonical ROA format be specified.
>
> The reason for this is that origination validation is reliant on the
> presence of a valid ROA that matches the prefix. The presence of
> additional ROAs, valid or invalid, that also match the prefix does not
> alter the reliance that can be given to the route object once one
> valid ROA is detected. Therefore, as long as a relying party can use
> as a lookup key a given prefix and retrieve all ROAs that match the
> prefix then the validation operation can be undertaken. Comparison of
> 2 or more ROAs for equivalence is not necessary. in order to allow
> this document to proceed I propose that NO text be added regarding a
> description of a canonical ordering of prefixes in a ROA.
>
(See below)
> Are there any comments from other folk on this proposed form of
> resolution?
I hope it isn't too late to voice an opinion on ROA prefix and
prefix-range semantics, and how those may better be represented with a
slight change in the ROA fields needed to achieve that degree of subtlety.
I believe that this may in fact inform a canonical format and sort
order, for facilitating comparisons between ROAs and for matching
prefixes against ROAs.
Here's the gist of the issue - there are two things represented in the
ROA which a prefix must match.
One is, the "range" of the ROA, i.e. the CIDR block within which the
matching prefix must fall.
The second is the "size" of prefixes that the ROA is valid for, i.e. the
range of valid prefix-lengths that a matching prefix's prefix-length
must fall within.
As it currently stands, an ROA has an implicit, rather than explicit,
lower value for the range of prefix-lengths, which equals the
prefix-length of the CIDR block that the ROA describes.
I believe that there may be situations where the "semantics" of the ROA
as it stands, would require multiple ROAs (where "multiple" could
conceivably be any power of 2!!), to accurately represent a desired ROA
assignment set.
And, that a more "flexible" ROA with *explicit* lower value for range of
prefix-lengths, would be all that is required to permit expressing such
ROA sets.
Rather than having:
IP_address / length le maxLength (length <= maxLength <=
address-family-max-length)
this would be
IP_address / length ge minLength le maxLength (length <= minLength
<= maxLength <= address-family-max-length)
One example I've seen discussed (not sure of the context, either in ROA
format discussions, or in multiple-signature context), is 10.0/16 and
10.1/16.
In this new syntax, this would be represented as "10.0/15 ge 16 le 16".
A prefix/length would match an ROA, iff prefix is covered by ROA
(ip_address/length) AND minLength <= length <= maxLength.
Sort order would be:
prefix (ascending)
length (descending)
minLength (descending)
maxLength (descending)
Search order semantics would be (and could be extended to tree-based
searching):
key_prefix >= prefix
key_prefix < prefix + 2^(addr-family-max-length - length)
key_length >= minLength
key_length <= maxLength
(NB - with this sort order and search order, the presence of "moot" ROAs
who are entirely covered by another ROA (subnet of the prefix, range
entirely within the other's range), won't break the matching process.)
I don't think this change drastically affects the ROA, and in most cases
I would expect length == minLength to be the case.
However, in the few instances where it doesn't hold true, this would be
a saving grace, and valuable enough (IMHO) to warrant discussion.
Brian Dickson
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
