At the Sidr meeting at IETF 69, the following issue was raised in
regards to matching ROAs with NLRI in a BGP update.
Consider an ISP that receives an allocation of a /20 prefix from source
A, and an allocation of an adajecnt /20 prefix from source B, but wants
to issue an advertisement for the aggregate /19 prefix.
Note that since the allocations are received from different sources, the
ISP will have one certificate for each alloation and the certificates
will have different validation paths. Therefore, the ISP cannot create a
single end-entity certificate the encompasses the entire /19 prefix
(i.e. any certificate encompassing the entire /19 prefix would fail
validation according to RFC 3779 rules). This means that under the
current one-to-one correspondence between ROAs and end-entity
certificates, the ISP would have to create 2 separate ROAs, one for each
of the /20 prefixes.
Similarly, one can imagine a scenario where an ISP receives adjacent
allocations from three sources and wants to announce an aggregate prefix
(e.g. the ISP receives a /19, a /20 and a second /20 and wants to
announce a /18). This would currently require issuing three separate ROAs.
Thus, if we continue to mandate a one-to-one correspondence between ROAs
and end-entity certificates, we place the burden on the recipient of a
BGP Update to determine if there is any collection of valid ROAs that
could be aggregated to form the NLRI in the Update message. That is,
upon receiving an advertisement for a /18 prefix originated by AS 123,
one must example all of the ROAs containing AS 123 and determine if any
subset of them can be aggregated to form the /18 prefix in question. No
one in the room at the Sidr meeting indicated that they believed this
was a good idea.
An alternative approach is to break the one-to-one correspondence
between ROAs and end-entity certificates by allowing two signatures on a
single ROA. Returning to our original example, the ISP would now create
two end-entity certificates, one containing the /20 prefix from source A
and the other containing the /20 prefix from source B. The ISP would
then issue a single ROA for the aggregate /19 prefix and attach two
signatures, one that could be verified using the first end-entity
certificate and one that could be verified using the second end-entity
certificate. Several people in the room at the Sidr meeting indicated
that they believed this was a good idea.
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.
Thanks,
- Matt Lepinski :->
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
