Geoff,
Personally, I'm happy to have multiple signatures on a ROA. However, I
think that multiple signatures is not the only way that we can provide
guidence in all envisaged situations.
Sandy had previously posted the following list of possible solutions:
(1) create multiple singly signed ROAs, say for two /20's, and let the
recipient interpret whether you meant to authorize the origination of
the /19 as well.
(2) mandate that all sources (all CAs) MUST produce an aggregate cert
when there are aggregatable certs
(3) tell prefix holders whose source is not willing to sign an aggregate
cert that they are just out of luck in originating the aggregate, maybe
just until the next prefix renewal period, maybe forever.
(4) allow a prefix holder whose source is not willing to sign an
aggregate to sign an aggregate ROA with multiple signatures.
There seems to be consensus that (1) is not a workable solution. Some
people (including myself) like option (4), but others feel that
implementing multiple signatures would introduce needless complexity.
However, if the cases we are discussing are truly rare, then a
combination of (2) and (3) may also be reasonable. Our documents could
specify that a CA MUST produce an aggregate cert whenever possible and
that a prefix holder needs to have an aggregate cert in order to
advertise an aggregate prefix (otherwise, the prefix holder can only
advertise the longer [non-aggregate] prefixes).
- Matt Lepinski :->
Geoff Huston wrote:
Matt Lepinski wrote:
Therefore, I was wondering if there was consensus that the ROA format
should be changed to allow multiple signatures? Or if the working
group felt there was a better approach for matching ROAs against the
NLRI in a BGP Update?
If we are going to allow two signatures on a ROA, I'd like to begin
revising the ROA format draft at some point next week so that we have
time to go through two versions of the ROA draft (if needed) before
the next IETF meeting. Therefore, if you do not believe that allowing
multiple signatures on a ROA is a good approach, please let me know
before August 8.
*wg chair hat off*
I've been reviewing the WG consideration of this topic so far
<http://www1.ietf.org/mail-archive/web/sidr/current/index.html>
From the thread of WG email so far on this topic it appears evident
that no better approach for matching ROAs against the NLRI in a BGP
update has been proposed in the case that the NLRI encompasses a span
of addresses that are certified by multiple certificates.
The thread of conversation appears to be the view on the one hand that
such a situation is sufficiently unlikely that it should not be
encompassed in a ROA format specification, and on the other hand the
view has been that a standard interoperable specification should cover
all eventualities and leave nothing to creativity of individual
implementors and that multiple signatures on a ROA should be allowed.
I don't believe that anyone has argued that this case would be one
that would be commonly encountered. Equally, I have not seen a case
made that this could _never_ happen under _any_ circumstances.
The question I ask myself is should a standard specification provide
guidance to implementors and users of the tool that covers all
envisaged situations or should it only cover the cases that are most
likely to occur and leave the remainder unspecified?
My preference is the former approach, namely that a standard should be
useful for interoperation in all envisaged use cases. Given the lack
of workable alternatives here I remain of the view that the ROA
specification should include this case, with the implication that a
'standard' ROA within this specification may contain multiple signatures.
Geoff
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
