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
