Danny and Sandy, It seems to me that the question of whether an intermediate AS monkeying with ORIGIN is an "attack" or not depends on what one understands the correct and intended operation of ORIGIN to be. The problem is, as you've rightly said, ORIGIN's (ahem) original purpose was obsolete almost as soon as it was introduced, and since then we have decades of uncoordinated operational (ab)use of ORIGIN. I'm not aware of any broad consensus on best practice for the current use of ORIGIN, and I'm sure there's no standard for it, other than what the BGP standard says which is as previously noted, effectively obsolete.
If I parse Danny's email right, he's saying that he wishes he could rely on ORIGIN to be untouched by intermediate ASes, so that he can use it to "impact path selection" by them. I presume that he's not actually relying on this, though, since the facts on the ground (as he points out) are that various intermediate ASes do adjust the value of ORIGIN. I'm not aware of any of the operators who do adjust ORIGIN in their networks having spoken up (though I may easily have overlooked some). If correct, I suspect this is simply because they're not following SIDR. However, I don't interpret this silence as meaning that all operators agree that ORIGIN should be immutable once launched. So, we have the following schools of thought on ORIGIN: - It's an interdomain policy knob to be used solely by the originator. - Or, it may be used as an intradomain policy knob by a transit AS. It's tempting, though futile, to say "a plague on both your houses!", because the standard doesn't say it's either of those things. It does say it "SHOULD NOT be changed by any other speaker", which offers some support for Danny's point of view. But really, spec-lawyers can't convincingly support either approach, since the spec doesn't frame ORIGIN as a policy tool at all. For my own part, I think twiddling ORIGIN at any point on the path is an abomination and I wish it had never become practice. However, as with so many things about BGP, it's an abomination that HAS become practice, and I think we would be well-advised to be careful in trying to stuff this little genie back into its bottle. All that said, I guess I prefer Sandy's option (2) -- given there's an identified issue, why not write it down, if only to avoid recapitulating quite so much of this conversation in the future? (And for the sake of this discussion I assume characterizing it as a "threat" uses "threat" as a term of art and not a value judgement -- see my first paragraph above regarding "attack".) --John On Mar 10, 2013, at 12:00 PM, Danny McPherson <[email protected]> wrote: > On 2013-03-08 11:10, Murphy, Sandra wrote: >> In reviewing the discussions about the threat document, the wg >> eventual consensus wrt one topic was not clear to the chairs. >> >> The ORIGIN attribute was mentioned by some as having the potential to >> be used out-of-spec to influence routing through the neighbor (and >> their neighbors, etc.). >> >> One response was that there is no way to verify the authenticity of >> the ORIGIN's original value, so the origin AS could mis-use this >> attribute no matter what we do. > > The origin AS sets the value of the attribute to whatever THEY desire -- the > concern was that upstream ASes can manipulate this to launch "traffic > attraction attacks". This happens today with some of our transit providers, > and we'd like the option to be able to mitigate that attack if we're going to > put a bunch of stuff in place to secure inter-domain routing on the Internet. > >> Also, a later discussion pointed out that the original need for the >> ORIGN attribute had long since been OBE, > > Many origin ASes set the value to various upstreams intentionally today to > impact path selection in upstream ASes, so it is very much in use today, even > if not for the originally envisaged application. > >> but that ISPs had re-purposed >> the attribute for influencing traffic. Several operators mentioned >> that ISPs find it useful to modify this attribute and spoke against >> protecting the integrity (ie preventing the modification). > > Right, that want to be able to exploit traffic attraction attack vectors, > whereas, as an origin AS I'd like to have the capability to prevent that. > >> The current draft does not mention the ORIGIN attribute as a threat. >> >> Is that the right outcome? > > No. > >> That is, was the desired outcome: >> >> (1) yes, we know it is a threat but we know we can't & don't want to >> protect it, so might as well leave it out. (current state). why do >> make-work. > > It's not make-work, it is a clear threat - you say yourself in the question. > It needs to be reflected in the threats draft and accommodated in subsequent > requirements and solutions work. We should not keep it out of the threat > draft simply because the solution does not currently accommodate it (we've > done lots of that already). > >> (2) we should mention it as a threat but then mention the bits about >> can't authenticate the original value and don't want to protect the >> integrity (ie want to permit modification). > > It's a threat, we don't need to have a solution here, we're talking about the > threats draft. It should lead to a requirement and then the solution can be > developed. > >> If there's no interest in changing, the threats draft stands as it is >> on this point. > > How many times do I need to defend this operational feedback before it's > considered and accommodate in the threats draft? > > -danny > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
