Subject: [Sidr] Multiple Signatures on a ROA

From: Matt Lepinski <[email-masked]>
Date: Tue, 31 Jul 2007 10:53:44 -0400

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 31 Jul 2007 12:00:13 -0400

Matt,

The discussion in SIDR addressed a different, more limited problem. 
The question was what if an ISP receives two, adjacent allocations 
from the SAME source at different times, and the source refuses to 
issue one cert for both allocations, because they have different 
validity periods. That was the motivation cited by Geoff Houston in 
the meeting.

The possibility of two adjacent allocations coming from different 
sources is much, much smaller, but it would be covered by the same 
mechanism, i.e., one that allows multiple signatures on a ROA, each 
linked to a different EE cert.

Steve

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 31 Jul 2007 12:27:46 -0400

Steve,

Thanks, I did indeed have the wrong example from the Sidr meeting.

- Matt L. :->

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 31 Jul 2007 12:12:11 -0400 (EDT)

>to issue an advertisement for the aggregate /19 prefix.

I believe that there was another wrinkle to the issue.  (Since I was
the one who raised it, I know what I *meant*, although others might have
heard differently.)

The issue is that some RIRs, when allocating a prefix, will reserve a
matching adjacent prefix for future requests, so that the two
allocations are aggregatable.  This helps limit routing table bloat.
Note the difference: this is a *single* source allocating multiple
aggregatable allocations.  And I believe that it happens frequently,
by deliberate process.  

(Actually, I'm having trouble visualizing allocations from *multiple*
sources that are aggregatable - perhaps this only happens when ranges
rather than prefixes are involved?  I'm lazy and I don't want to do
the math - if you have an example of *prefixes* allocated from
multiple sources that were aggregatable, could you describe it?)

An aggregated cert from a single source does not run afoul of the
encompassing rules of 3779 and the res-certs draft, since it is from a
single source.  But the architecture notes that an RIR (or a source
further down the allocation chain) might not always want to create a
cert for the aggregate, as the validity times of the two longer prefix
allocations might be different.  Hence the need for multiple certs,
and the choice between either interpreting the validity of a BGP UPDATE
based on multiple (singly signed) ROAs or multiply signed ROAs.

I believe that multiply signed ROAs are a direct indication of the
intent of the prefix holder, while interpreting UPDATEs based on
multiple singly signed ROAs is trying to derive the intent of the
prefix holder.

I am in favor of multiple signatures on the ROAs.

--Sandy

---

From: Stephen Kent <[email-masked]>
Date: Tue, 31 Jul 2007 16:04:10 -0400

At 9:11 AM -1000 7/31/07, Randy Bush wrote:
>>  validity periods.
>and we agreed many moons ago that the issuer would not play silly games
>with validity periods.
>
>for once, can we see if we can do the simple thing and not look for how
>complex we can make it by pushing functionally useless corner cases?
>
>randy

Randy,

I'd rather have just one signature on a ROA, to make life as simple 
as possible.

But, I also was "sensitized" to the notion of not imposing undue 
restrictions on how a registry operates.

So, if a registry drives cert issuance based on its allocation 
database, and if that database treats two allocations as having 
different lifetimes, based on when they were made, when fees are 
assessed, etc.,  I don't know how to reconcile both sets of goals.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Wed, 01 Aug 2007 06:11:15 +1000

Matt Lepinski wrote:
> should be changed to allow multiple signatures? 

Like Sandy, I support this change to the ROA format. I can envisage 
situations where a holder's address space is certified in a number of 
certificates, yet the join of this address space describes a single 
advertised prefix. In this case there is no way in the currently 
described ROA format that the ROA can be formed.

Geoff

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 31 Jul 2007 16:58:38 -0400 (EDT)

>I believe that there was another wrinkle to the issue.
>...

I did not put in here the obligatory message that these statements
were made strictly as a member of the wg, not as a wg chair pronouncement.
My opinion on this matter should matter no more or less than any
other wg member.

--Sandy

---

From: Geoff Huston <[email-masked]>
Date: Wed, 01 Aug 2007 07:30:07 +1000

> My opinion on this matter should matter no more or less than any

ditto for my comment as well!

   Geoff

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 31 Jul 2007 17:34:06 -0400 (EDT)

Obligatory statement: The following opinions are stated strictly as a
member of the wg, not as a wg chair pronouncement.  My opinion on this
matter should matter no more or less than that of any other wg member.

Right now, prefix holders who have been allocated multiple
aggregatable prefixes can originate an advertisement for the
aggregate.

I imagine that we (sidr) would want the architecture to premit the
authorization of such an aggregate advertisement - no one wants to
give up current features.

The choices seem to be:

(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.  

   (IMHO, I don't care for the recipient reading the mind of the
   prefix holder - the wg must choose a common interpretation to make this
   work, and if the common choice is wrong for some prefix holder,
   there's no way for that prefix holder to recover.)

(2) mandate that all sources (all CAs) MUST produce an aggregate cert
when there are aggregatable certs.  

   (IMHO, mandating a CA activity like this is out of character for PKIs, 
   but there's always a first time...)

(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.  

   (IMHO, this would not be a popular option.)

(4) allow a prefix holder whose source is not willing to sign an
aggregate to sign an aggregate ROA with multiple signatures.

   (IMHO, this does add a bit of complication to the ROA validation 
   algorithm, but for the computers not the humans - and that's what 
   computers are good for.)

It could be that the chosen interpretation in (1) is so very seldom
wrong, that we can decide that this is a good engineering choice and
go with that.  But I dislike the idea of going to some large effort to
strongly assert an authorization that won't be exactly followed by the
recipients.

--Sandy