Anyone notice strange announcements for

Jack Bates jbates at
Wed Jan 14 01:11:55 UTC 2009

Sandy Murphy wrote:
> The sidr wg is working on protection of the origination of the
> route - so the origin AS in the AS_PATH is known to be authorized
> to originate routes to the prefix.
> That's not full AS_PATH protection.  sidr is not doing full AS_PATH protection.
> Yet.

I always considered AS_PATH protection to be a waste of time. It does 
what it does, and has minor tweaking capabilities which I hope Randy 
will show are mostly pointless (ie, please quit doing this because it 
won't actually work as you want).

heh. Someone should have added "modifying AS_PATH might confuse those 
people attempting to route IP traffic on the Internet."

Similar to RFC 1930:

    There are few security concerns regarding the selection of ASes.

    AS number to owner mappings are public knowledge (in WHOIS), and
    attempting to change that would serve only to confuse those people
    attempting to route IP traffic on the Internet.

I also like this statement from same RFC:

ASX knows how to reach a prefix called NET1.  It does not matter
    whether NET1 belongs to ASX or to some other AS which exchanges
    routing information with ASX, either directly or indirectly; we just
    assume that ASX knows how to direct packets towards NET1.  Likewise
    ASY knows how to reach NET2.

ie, We care about the AS we are peered with and all beyond it doesn't 
really matter (exception being the use of ASN in AS_PATH for loop 

They wouldn't have even bothered assigning ASNs except to insure 
uniqueness when it comes to detecting routing loops in AS_PATH  and for 
insuring two AS's that suddenly peer are unique. It is important that an 
ASN be unique, or loop detection on an AS_PATH would cause a possible 
lack of reachability (if 2 seperate AS's use the same ASN). That being 
said, the person advertising a route can change the AS_PATH to effect 
the reachability of their network in a variety of ways (most common is 
prepending their own ASN, least common is probably path truncating and 
use of atomic_aggregator).

The real quirk is, given that an AS by definition has its own routing 
policy and announces it to peers, is path poisoning part of that AS's 
policy in order to not allow some routes via certain peers to be 
accepted by another AS to traffic engineer. Is not the point of BGP to 
define a routing policy?

And just because this RFC cracks me up, one last quote:

However, if the criteria applied above are adhered to,
    then there is no immediate danger of AS space exhaustion. It is
    expected that IDRP will be deployed before this becomes an issue.
    IDRP does not have a fixed limit on the size of an RDI.

Let's switch already! ISIS and IDRP for life!


More information about the NANOG mailing list