On Sun, Mar 10, 2013 at 12:00 PM, Danny McPherson <da...@tcb.net> 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?
I think the question was a survey sort of question: 'Should this be in the threats doc? Is the intent to come back and say: "Yes, origin changes along the path for many reasons, we want to protect against this." (ie: origin changes are a threat) OR "Yes, origin changes along the path, we actually want to keep this feature available.' There were at least 2 people talking about origin, one from either side I think... so clarification would be good. > -danny > > > > _______________________________________________ > 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
