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
