Re: [sidr] origin attribute

[heasley <[e-mail]>]

Wed, Oct 24, 2012 at 10:53:58AM -0600, Shane Amante:
> Danny,
> 
> On Oct 24, 2012, at 9:11 AM, Danny McPherson <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr