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

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Aug 2007 05:59:54 -0400

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

>>>>> "Sandy" == Sandy Murphy <[email-masked]> writes:
    Sandy> I believe that there was another wrinkle to the issue.
    Sandy> (Since I was the one who raised it, I know what I *meant*,
    Sandy> although others might have heard differently.)

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

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

  I think that it would be exceedingly rare. 
  For it to occur, the two sources would have to have received
allocations from a parent RIR that were not powers of two.  Even if
source A had been allocated:
	A: 10.10/16	and had delegated 10.10.240.0/20
	B: 10.11/16	and had delegated 10.11.0.0/20

  no aggregatable /19 would be posssible. yes, a range from 10.10.240.0
to 10.11.15.255 exists, but it wouldn't aggregate.

  The case where additional address space is allocated (as Sandy
mentions, from the same RIR) seems simpler to me. 
  You give a reason why the RIR couldn't just issue the /19 certificate
at that point: 

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

  But, if the validity times are significantly different such that one
prefix is going to change prior to the certificates expiring, should the
ISP really even be advertising the aggregate?

- -- 
]            Bear: "Me, I'm just the shape of a bear."          |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 1 Aug 2007 17:27:43 -0400

At 5:59 AM -0400 8/1/07, Michael Richardson wrote:
>...

The allocation certs may have validity intervals that overlap for a 
number of months so why not advertise the aggregate for that time 
interval? The ROA would have to have a validity interval that does 
not exceed that of the cert(s) used to verify it, but that could 
still be a usefully long interval.

There is no sense that the resource holder will loose the allocation 
when it expires.  Typically the allocation is renewed. However, if 
the issuer (an RIR, NIR or LIR) wants to keep its life simple and 
drive cert lifetimes off of its allocation management database, then 
it may not be willing to issue a single cert covering the two 
allocations, hence the motivation cited by Geoff and Sandy for this 
added complexity for ROAs.

Steve

---

From: Geoff Huston <[email-masked]>
Date: Thu, 02 Aug 2007 09:31:07 +1000

*Working group chair hat _off_*

Stephen Kent wrote:
> interval? The ROA would have to have a validity interval that does not 
> exceed that of the cert(s) used to verify it, but that could still be a 
> usefully long interval.
> 
> when it expires.  Typically the allocation is renewed. However, if the 
> issuer (an RIR, NIR or LIR) wants to keep its life simple and drive cert 
> lifetimes off of its allocation management database, then it may not be 
> willing to issue a single cert covering the two allocations, hence the 
> motivation cited by Geoff and Sandy for this added complexity for ROAs.
> 

It is not only validity dates that motivated my comment to support 
multiple signings of a ROA - if one looked into the old B and C space 
and follow the various trails of movement of some of these address 
blocks then there may well be situations where there are adjacent 
aggregateable prefixes that have different validation paths and hence 
cannot be aggregated into a single certificate that covers the aggregate 
prefix. If you want to have a ROA that covers the prefix and does not 
ential the replying party making guessing games as to intent (ugh!) then 
having multiple signings over the ROA makes sense to me as a capability 
in the ROA specification.

Geoff