Subject: Re: [Sidr] Multiple Signatures on a ROA

From: "Schliesser, Benson" <[email-masked]>
Date: Tue, 31 Jul 2007 10:07:46 -0500

Matt-

Leaving aside the question of multiple signatures, I'm doubtful of your example.

How often does this situation arise in practise? The odds of receiving adjacent allocations from different sources seems like it would be fairly low, in which case this is a non-issue.

(Perhaps somebody knows better than me? Could an analysis of route registries, global BGP table, etc provide some stats?)

-Benson

------Original Message------
From: Matt Lepinski
To: [email-masked]
Cc: [email-masked]
Sent: Jul 31, 2007 10:53
Subject: [Sidr] Multiple Signatures on a ROA

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-masked]
https://www1.ietf.org/mailman/listinfo/sidr

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr