[Sidr] Re: S-BGP and IP prefix aggregation

Fri Dec 2 09:46:40 UTC 2005

I'm reposting my email reply that did not make it to nanog (it made it fine
to ietf list though as did Tony's reply to my email that went to both sidr
and to nanog). I suspect nanog maybe using special filtering rules
[aka amavisd] that did not non-ascii characters in "To" field (that is 
the only thing I can think of that in how that post was different from 
others) - I can't think of a good reason to have this filtering rule though...

---------- Forwarded message ----------
Date: Fri, 2 Dec 2005 00:22:44 -0800 (PST)
From: "william(at)elan.net" <william at elan.net>
To: ÍõÄÈ <wn at ndsc.com.cn>
Cc: nanog at merit.edu, sidr at ietf.org
Subject: [Sidr] Re: S-BGP and IP prefix aggregation

[I'm cross-posting this to SIDR BOF (future SIDR WG) list as that seems
  to be the most appropriate forum to discuss this issue]

On Fri, 2 Dec 2005, <wn at ndsc.com.cn> wrote:

> I have a question about S-BGP. When IP prefix is aggregated, and a S-BGP 
> speaker receives a route announcement with the aggregated ip prefix,
> 
> how does it verify the authority of the AS to announce the IP prefix. The 
> aggregated IP prefix should have not address attestation.

With rare exceptions almost all aggregation happens by ISP that has been
allocated larger block and which it sub-allocated to its customers (or decided 
to break of and announce subparts from multiple datacenters), so in this case 
ISP (ASN) would obviously be able to provide a permission [sign cert] to 
announce that larger block.

There are however some rare exceptions, for example I know of ip block
in legacy class-c space that UUNET is announcing as /16 aggregate but
where it actually consists of a number of smaller ip blocks assigned (direct 
assignment from RIR) to several different organizations.

I always assumed myself that those running SIDR aware routers in such cases
would not be doing aggregation - i.e. no aggregation if each ip block in the 
aggregate has permission for announcement from different entity.

An alternative for sbgp design could be that aggregating ASN would create 
special self-signing cert for such aggregate block and that cert would have 
special attribute(s) indicating list of all sub-blocks and reference
to all certs that "make" this aggregate block. Then verifying router
in such a case would go through and verify each one of those sub-block
certs (and those sub-block certs would have to be such that they give 
permission for announcing the block from that sub-block owner to aggregating 
ASN).

-- 
William Leibzon
Elan Networks
william at elan.net