Tatuya,
The gist of your new paragraph is fine by me. However, you have un-fixed
what I clearly defined in the past for behavior. The match statement has
to apply to tentative address as well as an assigned address. Here is a
suggestion for change in bullet 1:
1. If the target address is tentative, the tentative address is not
unique.
changes to
1. If the target address matches a tentative address on the receiving
interface,
the tentative address is not unique.
There is a distinct case where the receiving interface gets an NA where
target address in NA does not match any tentative address on the
interface.
Further, in an email you said:
You said:
"I intended, for example, that implementations should not affect their
neighbor caches as a result of processing the NA "as described in
[RFC4861=2461bis]". I thought a naive implementation may be confused by
the received NA and modify the link-layer address information of its own
address (realized as a special type of neighbor cache)."
Even if a bad link-layer address gets into the ND cache of the receiving
node, the node have NUD kick in within 30-50 seconds and issue a mcast
NS to resolve the destination IPv6 address that will result in the bad
address to be replaced.
Hemant
-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 10, 2007 11:18 AM
To: James Carlson
Cc: [email protected]
Subject: Re: Revisit: one remaining corner case in DAD
(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
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
