(Intentionally separating the thread since this is irrelevant to the
main focus of completing 2462bis)
At Tue, 10 Jul 2007 07:43:34 -0400,
James Carlson <[EMAIL PROTECTED]> wrote:
> > On the other hand, I'd point out the same argument could apply to the
> > "two-hour" rule adopted in RFC2462 and kept in 2462bis. The consensus
> > at that time (IIRC) was that even though we knew it's an on-link only
> > attack the forced shut-down of an available global addresses was
> > serious enough to mitigate within the protocol specification. And
> > since an unsolicited NA is a very rare event, I'd suspect it's more
> > likely an attack than an actual duplicate that happens to have been
> > undetected.
>
> The two-hour rule has always struck me as more of a robustness issue
> than anything else.
I'm not sure if you are indicating by "robustness" that it's not an
issue of DoS, but the fact is that the two-hour rule was indeed
introduced as a counter-measure of a DoS attack (I guess you knew
that, but just in case...).
> The point I was making was that a denial of service attack against NDP
> is not just feasible, but trivial, and that bringing up DoS as a
> reason to ignore assumed-incorrect advertisements doesn't seem like a
> productive way to frame the argument.
I admit whether discarding the NA may be a debatable behavior (with or
without logging the event), but I don't think discussing this in the
context of DoS, referring to the two-hour rule, is unproductive. An
attacker can easily make the Solaris node shut down an address by
sending two attacking NAs. The attacker can also mount the same
attack on any other nodes in the link by first pinging them to collect
the addresses and then performing the attack with the forged NAs.
We could still argue that such an attack is "trivial" and discussion
based on the "trivial" attack is not productive. But if so, we should
also revisit the two hour rule, too. As long as we keep that rule, it
makes more sense to me to consider a counter measure for the same
level of security threats.
To avoid wasting our time further, however..., I personally think this
particular case isn't worth further debates. As I repeatedly noted,
we don't see unsolicited NAs very often in the first place, whether it
would indicate a duplicate address or an attack. We can safely leave
it to implementations without a fear of disruption in practice. So,
I'll stop here on this matter until, someday, we need to discuss how
to address undetected duplicates in general.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
