JINMEI Tatuya / 神明達哉 writes:
> At Mon, 9 Jul 2007 16:04:39 -0400,
> James Carlson <[EMAIL PROTECTED]> wrote:
> > As a result, what I've done in the Solaris implementation is to
> > 'defend' the address once -- by sending out my own advertisement in
> > reply to the received one -- but setting a flag. If I see another
> > duplicate advertisement within some period of time (~10), then shut
> > the address down.
>
> I'm not sure if we are talking about the same thing, so please let me
> check. Are you saying "if a Solaris node happens to receive an NA
> targeting an address assigned on the receiving interface, the node
> will 'respond' to the NA with another NA (probably sent to ff02::1)
> targeting the same address"?
Yes. Obviously, since it's a potential feedback loop, it has
substantial safeguards on it, as I described above. If we find we're
arguing, then the address is torn down. (And, no, there's
intentionally no knob that allows the system to be "infinitely
persistent," though some users felt that was somehow necessary for
systems classed as "important servers.")
> In any case, I'd not disagree with trying to handle an address
> duplicate that has not been detected in the initial DAD as a general
> topic. But I'd say it's basically beyond the scope of 2462bis.
Calling additional behavior here "beyond the scope" of the amended RFC
is fine by me. The only part I'd disagree with is roping off the
ability to do such things by stating that implementations "MUST"
discard such messages.
> reliability. Note also that this particular case (receiving an NA
> targeting one of the receiver's own addresses) is a very minor case
> among such undetected duplicates since an unsolicited NA is sent only
> in very limited cases; if we were to do that within this spec, we'd
Yep; understood.
> What we've actually been discussing in this thread is how to fix a
> clear error in the 2462bis (and RFC2462/1971) text: it talked about
> "how to handle a *solicitation*" in the "Receiving Neighbor
> Advertisement" section. It was an unfortunate side effect that we hit
> the minor, yet pretty substantial, issue of undetected duplicates
> while trying to resolve the seemingly editorial error.
I think everyone essentially read "advertisement" (or just "packet")
here instead of "solicitation," without additional implications of
what gets discarded, as it was fairly obvious what was meant.
> 2. If the target address matches a unicast address assigned to the
> receiving interface, it would possibly indicate that the
> address is a duplicate but it has not been detected by the
> Duplicate Address Detection procedure (recall that Duplicate
> Address Detection is not completely reliable). How to handle
> such a case is beyond the scope of this document, but care
> should be taken so that the advertisement will not affect the
> normal Neighbor Discovery [RFC4861] processing.
This seems better to me, as it clarifies the scope, though I'm
somewhat unclear on what the last clause actually implies.
How should an implementor actually take care here? Are you perhaps
referring to the possibility of endless NA battles between a pair of
misconfigured systems? Or something else?
I might have worded it something like this:
How to handle such a case is beyond the scope of this
document, but implementations that take any action other than
discarding the message MUST take measures to avoid an infinite
series of advertisements triggered by reception of such
messages.
Or just:
How to handle such a case is beyond the scope of this
document, and implementations MAY log and discard such
messages.
> 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.
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.
Instead, the issue is determining what happens to _all_ of the systems
observing these messages on the wire.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
