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@elan.net> To: ÍõÄÈ <wn@ndsc.com.cn> Cc: nanog@merit.edu, sidr@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@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@elan.net