At Fri, 22 Jun 2007 09:05:36 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] 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 --------------------------------------------------------------------