Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08

At Fri, 22 Jun 2007 09:05:36 -0400,
"Hemant Singh (shemant)" <shemant@cisco.com> wrote:

> Thanks for the quick review of section 5 in our new I-D.  Your reading
> of section 5 is correct - we have proposed both new and old
> implementations to always perform DAD for any unicast address. You are
> also correct that the gross change we have proposed over 2462bis is that
> old implementations MUST also not skip DAD. We stress about old
> implementations because if older implementations that are already
> deployed continue to be deployed for say, the next 5-10 years, that's
> not good. A software upgrade to older implementation is certainly
> possible.
> 
> We have given a solid reason for our case - it's presented in Section 2,
> bullet 4 of our I-D. Please see if our reasoning is solid enough to
> convince IETF.

I've also read that part (copied below to be very specific), but I
doubt it convinces the opponents of forcing DAD in all cases.  First,
it is not clear which "security problem" this bullet tries to
indicate.  Also, if Host1 is assumed to be the attacker that mounts
traffic hijacking and/or DoS against Host2, forcing Host2 to perform
DAD doesn't help because Host1 can get the same result by simply
ignoring the DAD-NS from Host1.

Meanwhile, 2462bis has just entered the AUTH48 state.  From what I've
seen so far, I don't see the need for delaying the publication of the
document due to this issue (and I'm going to complete this work just
with a few minor editorial fixes).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

   4.  The host MUST issue NS(DAD)s for all of its acquired unicast
       addresses except when the host interface has
       DupAddrDetectTransmits variable set to zero.  Section 5.4 of RFC
       2462 [ADDRCONF] erroneously relaxes this requirement and suffers
       from a security problem as illustrated by the following example:

          Host1 uses EUI-64 to configure a Link Local Address (LLA)
          using MAC1 and manually configures a Global Unicast Address
          (GUA) that is equal to an address configured using EUI-64 and
          MAC2.  Host1 completes an NS(DAD) for both its LLA and GUA.
          Then, Host2 uses EUI-64 to configure both a LLA and a GUA
          using MAC2.  Host2 completes an NS(DAD) for the LLA and does
          not send an NS(DAD) for its GUA in compliance with RFC 2462
          [ADDRCONF].  Now Host1 and Host2 have the same GUA on the same
          link.

       Therefore, this exception in section 5.4 of RFC 2462 [ADDRCONF]
       MUST be ignored.  Note that draft-ietf-ipv6-rfc2462bis-08
       [ADDRCONFbis] refers to an extensibility concern with new
       implementations and states in section 5.4:

          "Whereas this document does not invalidate such
          implementations, this kind of 'optimization' is NOT
          RECOMMENDED, and new implementations MUST NOT do that
          optimization."

       However, the security problem mentioned in this document
       invalidates even currently existing implementations.  The
       "Changes to draft-ietf-ipv6-rfc2462bis-08" section in this
       document describes the corresponding changes to
       draft-ietf-ipv6-rfc2462bis-08 [ADDRCONFbis].

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------