--- On Tue, 1/13/09, Patrick W. Gilmore <patr...@ianai.net> wrote: > > AS_PATH != identity, and I would not recommend loading > the latter onto the former. > > We disagree. When I am researching something, I frequently > look at ASNs in the path to figure out not just where but > who controls the path.
Oh, I certainly think that there is a loose coupling there, and the relationship is highly valuable from a troubleshooting point of view. However, I would counsel anyone investigating AS_Path relationships to remember that do not completely characterize the relationship between any two organizations, let alone the multipolar relationships between all organizations. It's a good first-cut, but it doesn't have the level of authority that you're implying. I'm not aware of any ASNs being trademarked... > >> Personally, I would be upset if someone injected > a route > >> with my ASN in the AS_PATH without my permission. > > > > Why? Is this a theoretical "because it's > ugly" complaint, or is there a reason why manipulating > this particular BGP attribute in this particular way is so > bad? Organizations do filtering and routing manipulation > all over the place. Is there something worse about doing it > this way than others? > > Filtering and other manipulation happened on your router, > prepending my ASN is putting that information into every > router. That seems to be a serious qualitative difference > to me. Do you disagree? This is qualitatively similar to an ASN announcing de-aggregated routes - it may be nice if they don't, and you don't have to accept them, but are they permitted? > > > This thread has been interesting & educational. So > many people seem to be happy to explain why they should be > allowed to use globally unique identifiers they do not own > in ways which were not intended, then explain to the people > who do own those identifiers how they should react, which > alarms should go off, and even which priority the alarms > should have. > > As I have repeated probably hundreds of times: Your > network, your decision. I have yet to hear a credible > argument against that stance. What you do _inside_ your > network is _your_ decision. When it leaves your network, > however, things change. Exactly! Provider RB announces $WEIRD. A bunch of providers receive alarms about the existence of $WEIRD, and they treated this as $IMPORTANT. The bunch of providers who treated this as $IMPORTANT are informing all of us about their monitoring thresholds and their responses to this threshold being met. Their networks, their decisions. It should be pointed out that pre-provisioned AS_Path filters and prefix-lists would actually be effective at defeating this and preventing someone who is actually malicious from using this technique. This is an excellent argument for implementing SIDR... > > Announcing an ASN which is not yours to eBGP peers means it > is leaving your network, which means it is not just your > business. Doing so and then telling the ASN owner that they > should not worry about it afterwards - and in fact arguing > when the owner repeatedly tells you this caused them > problems - does not seem to be the proper course of action. Understood, but if this is viewed as problematic, there is a very simple solution: don't allow a BGP customer (or peer!) to prepend someone else's ASN. > > > I mentioned earlier in the thread if Cogent prepending > Sprint's ASN to Verio, people would react differently. > Randy said tools can be used for good or bad, obviously > implying he's the good guy. He is not the good guy. He > used someone else's resources without their permission > and without even notifying them, costing them time & > effort. Randy doesn't get to decide if the ASN owner > should have alerted or investigated or whatever, and > neither do any of you unless it is your ASN. > > How can anyone seriously argue the ASN owner is somehow > wrong and keep a straight face? How can anyone else who > actually runs a network not see that as ridiculous? Are any providers going to implement ^ASN filtering as a result of this experiment? This could turn out to be a very inexpensive lesson, which is far preferable to more expensive lessons... David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com