Wed, Oct 24, 2012 at 10:53:58AM -0600, Shane Amante: > Danny, > > On Oct 24, 2012, at 9:11 AM, Danny McPherson <da...@tcb.net> wrote: > > On Oct 23, 2012, at 6:03 PM, Shane Amante wrote: > > > >> I suspect John is referring to the operational practice employed by some > >> networks, right now, whereby they overwrite ORIGIN during receipt of an > >> UPDATE into their network to 'normalize' ORIGIN to a consistent value. > > > > Ironically, if "normalize[ing] ORIGIN to a consistent value" at an upstream > > AS results in a change to the ORIGIN code for a given path, you've _created > > INconsistent ORIGIN codes for the prefix in the routing system. I suppose > > I understand why this might be desirable for a transit network provider, > > but as an edge AS I'd prefer to not have intermediate networks changing the > > values I set. > > Fair enough. In my defense :-), RFC 4271 does state that ORIGIN code "SHOULD > NOT" be changed by any other speaker > <http://tools.ietf.org/html/rfc4271#section-5.1.1>. Fortunately, it doesn't > say: "MUST NOT". :-) > > Perhaps a better question should be: is ORIGIN code still required, > particularly from a BGP path selection perspective, in today's networks? I > would say "no". (If you wanted to know the 'source' of a BGP route, there > are already a plethora of BGP communities to help operators narrow this down > ... but, this is more for convenience of troubleshooting, it doesn't need to > be in path selection). > > IOW, instead of "securing" ORIGIN, maybe folks should be looking at > deprecating it? IMO, this would have likely been a far more productive use > of time than the deprecation of AS_SET's, (the latter of which I still > maintain was a bad idea, done primarily for convenience w/out adequate > consideration of it's _long-term_ usefulness).
its used as a "TE" knob, whether danny likes it or not. given the lack of TE knobs, a lot of hatred should be expected if its taken away (deprecated or "secured"). > > >> This is especially valuable in cases where one network, A, is multi-homed > >> to an adjacent network, B, and network A may not be announcing a > >> consistent set of BGP path attributes associated with a set of IP prefixes > >> at all locations. Ultimately, this practice allows network B to > >> consistently skip over ORIGIN and, instead, evaluate more well-understood > >> BGP Path Selection criteria like MED's, IGP metric, etc. > >> across the full set of "common" BGP routes, (i.e.: those with the same > >> AS_PATH, LOCAL_PREF, etc.), learned across all exit points to network B. > > > > I'm pretty sure MEDs and "IGP metric" are far more ambiguous and broken in > > practice than ORIGIN code (e.g., [1]), especially when comparing across > > paths learned from different adjacent ASes. > > FWIW, I wasn't actually referring to to MED or IGP metric comparison across > different AS_PATHs, rather MED or IGP metric comparison across same AS_PATHs. > > Regardless, your point is valid that comparison of MED's, even just across > the same AS_PATH, is oftentimes fraught with operational > headaches/brokenness. However, in defense of MED's :-), I believe that the > root cause problem here is, most likely, an inability (or, worse, > unwillingness) for the network sending MED's to continually fine-tune not > only the MED value(s), but at the same time (just as importantly) to > __intelligently__, (i.e.: only when necessary), deaggregate [very] large > prefixes in order that more relevant MED values can be targeted at those more > specifics resulting in better 'signals' toward upstream networks. Then > again, we might agree to disagree on this. :) > > > To the larger point of going back to actual requirements for this work, then > why hasn't there been discussion in the requirements or threats documents > about 'securing': > - ORIGIN > - NEXT_HOP: third-party NEXT_HOP at IXP's anyone? > BTW, I would note that the above would be an extremely clever way to divert > traffic through a bad guy's network that would be completely invisible within > the AS_PATH, (but could show up in traceroutes). w00t! > - MED's > - BGP communities: which are quite commonly used to manipulate an upstream's > BGP path selection algorithm (i.e.: raise/lower LOCAL_PREF) and/or _scope_ > the announcement toward adjacent ASN's/routers, (i.e.: no-export, > no-advertise, being the two standards-based ones)? > > ... not even a mention of being "out-of-scope" and for what reason(s), even > though draft-ietf-sidr-bgpsec-reqs-05 states: "As noted in the threat model, > [I-D.ietf-sidr-bgpsec-threats], this work is limited to threats to the BGP > protocol." > > Then again, there still isn't a serious acknowledgement that 'route leaks' > are, in fact, a much more serious "threat to the BGP protocol", than > manipulation of most of those BGP attributes even though the route-leaks > problem has been crisply defined in 1.5 pages: > http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01 > ... with further elaboration in this and associated drafts: > http://tools.ietf.org/html/draft-dickson-sidr-route-leak-def-03 > > <sigh> > > -shane > > > > > -danny > > > > > > [1] > > <http://www.nanog.org/meetings/nanog29/abstracts.php?pt=Njk2Jm5hbm9nMjk=&nm=nanog29> > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
