Geoff,
On the issue of canonicalization -- To the best of my knowledge no one
has put forward a use-case, on this mailing list or at the Dublin
meeting, in which efficient comparison of ROAs is necessary. Therefore,
the only reason to define some sort of 'canonicalization' is to simplify
comparison between the addresses in a ROA and an EE cert. It is possible
that requiring prefixes to be lexiographically sorted makes it easier
for relying parties to compare a ROA with its coresponding EE
certificate [at the cost of slightly more work for the relying party].
Therefore, I have a weak preference for requiring ROA prefixes to be
lexiographically sorted. However, I have a strong preference for
finishing the document, so I'm willing to go along with Geoff's proposal
(i.e. No canonical ordering).
While we're on the topic of comparing ROA prefixes to those in EE
certificates: Currently, the ROA format draft specifies an exact match
between the prefixes in a ROA and the prefixes in the EE cert, and this
text is a bit ambigous as written (for which I am to blame). As was
pointed out at IETF 72 we have the following issue:
One might reasonably create a ROA containing 10.0/16 and 10.1/16.
However, RFC 3779 specifies that if one were to create an EE cert
covering these addresses that the IP address extension would contain the
single prefix 10.0/15.
So if by "exact match" we mean a simple bit-wise comparison, then
10.0/16 and 10.1/16 cannot be present in the same ROA (they would need
to be split into two separate ROAs, which is clearly inefficient) and if
by "exact match" we mean 'logically the same set of addresses' then it's
not clear what the "exact match" requirement is buying us.
At IETF 72, George Michaelson suggested that the proper requirement is
that each prefix in the ROA is a logical subset of a prefix in the EE
certificate. This is at least as easy to implement as testing whether
the ROA and EE cert contain the same 'logical set of addresses' and
nicely resolves the issue of needing to break apart authorizations into
a (potentially) large number of ROAs.
- Matt Lepinski
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
* Should the ROA format permit multiple EE certs?
- If an ISP has two CA certs from different CAs for adjacent
addresses where the ISP wishes to advertise the aggregate,
that this cannot be expressed in a ROA.
- Is this something that the specification should address?
- There was no clear outcome from the discussion, and further
consideration of the matter is required by the WG.
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.
b) a ROA BE ALLOWED to use multiple signatures
This would use the CMS option of multiple EE certs to describe those
aggregate prefixes that are not certified within a single validation
path. This is a situation akin to proxy aggregation, where a route
object is being constructed from multiple components and the
associated ROA therefore contains a route object that cannot be
described in a single EE certificate.
The draft would need to specify that:
- all EE certificates are to be included
- all signatures MUST validate for the CMS object to be considered valid
- the union of the address prefixes in the EE certificates MUST
encompass the prefixes specified in the ROA.
In favor of this approach I note that RFC 3852 and RFC4853 permit
multiple signatures and EE certs in CMS, so the basic format of the
ROA is not altered.
The comment has been raised that this is an unlikely situation and
there is no need to make the specification more complex for unlikely
cases. In response I would argue that the specification should be
complete and provide appropriate guidance to implementors for all
situations where interoperability is required, and this case,
although not common, has visible in the routing table already and
will likely be visible in the routing table in future. Given that
this does not define a new signature standard for CMS, nor a major
change in the logic of ROA processing I do not see that this adds any
undue complexity to implementations and has the benefit of covering
the full range of anticipated use cases for ROAs in their application
to signing route origination.
Are there any comments from other folk on this proposed form of
resolution?
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
