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
