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 protected] Cc: [EMAIL PROTECTED] 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 protected] https://www1.ietf.org/mailman/listinfo/sidr
_______________________________________________ Sidr mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sidr
