On Sun, Mar 10, 2013 at 2:05 PM, Christopher Morrow <[email protected]> wrote: > On Sun, 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? > > 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.
oops, unfinished thought: "your message provides at least 1 bit of clarification" would you be interested in providing stephen with some text for the threats doc about this? -chris >> -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
