North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
[Sidr] Re: S-BGP and IP prefix aggregation
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" <[email protected]>
To: ÍõÄÈ <[email protected]>
Cc: [email protected], [email protected]
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, <[email protected]> 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,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).