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 detections). 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! Jack