Hi Tatuya, Please see in line below with "<hs>".
-----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 11:28 AM To: Hemant Singh (shemant) Cc: Brian E Carpenter; Fred Baker (fred); [email protected] Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08 At Mon, 25 Jun 2007 10:45:35 -0400, "Hemant Singh (shemant)" <[EMAIL PROTECTED]> wrote: > Let us summarize the discussion that has taken place so far and issues > closed. > > 1. Technical content - Brian has agreed below that the problem we > describe is real and we are saying our recommendation to change > 2462bis I-D does fix this problem. Tatuya still has some issues with > our problem, but we think till he fixes some typos in his email we > cannot reply to him. This is what was sent from Tatuya that we think > is text with typos: > > "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." Yeah, there was a typo. It should actually be: First, it is not clear which "security problem" this bullet tries to indicate. <hs> The problem we refer to is the fact that Host1 and Host2 have the same GUA on the same link! This is an obvious problem because Host1 is able to get an authoritative (because Host1 issued an unchallenged DAD for GUA) GUA that is also later assigned to Host2. Note that Host1 does not need an incorrectly implemented or hacked up IPv6 stack to reach this problem scenario - the problem arises with a fully compliant IPv6 host stack on Host1 and Host2 using only the interface exported to an end user. If Host2 was NOT allowed to skip DAD, then Host2 will issue a NS(DAD) for GUA and Host1 being a compliant host would reply with an NA saying "I have this GUA". The net result is that traffic that should have gone to Host2, goes to Host1 instead - why is this not a security problem? 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 Host2. (i.e., replace the final "Host1" with "Host2") <hs> The second problem case, when Host1 is a rogue and not compliant with IPv6 standards, sure Host1 can ignore the DAD-NS from Host2 but the IPv6 router on the link MAY catch this duplicate since the router has also seen this NS(DAD). We envision that the router logs an error message. Again, in our previous case above, if Host2 had skipped NS(DAD) then the router would not catch this problem. > Tatuya also needs to explain how ignoring DAD from a host is a valid > implementation of the 2462 standards. Why should I? I interpreted the bullet as describing Host1 was an attacker, so it would do anything (whether it's valid or not wrt standards) to make the attack succeed. <hs> OK, now that we read your reply with the typo fixed, we agree with you here. It's because Host1 is a rogue, this host will ignore the NS(DAD) from Host2 for GUA. In any event, the main point is that it's not clear (to me) which "security problem" this draft tries to explain (and how the change in the specification helps solve or mitigate the "problem"). > Well, if stacks do not skip DAD, then there should be no problem with > tightening up the language as we've proposed. I'd rather say that *if* stacks do not skip DAD, then there should be no problem with leaving the current text as is (remember new implementations won't skip DAD, so leaving the text won't cause a problem in the future either). And if so, I'd rather keep it since I don't see any value in modifying text that has been fully reviewed and does not actually have any problem. <hs> Do you acknowledge the problem we describe above? Since we realize that 2462bis I-D is in AUTH48 state, a change like this may require IETF-wide review and that would further delay 2462bis becoming an RFC. But then where do we put changes like ours? Our I-D is at the beginning of the process, so it may be an appropriate place for this and any further changes if they can't make it into 2462bis. A note to the IPv6 WG chairs. Please add our I-D to the agenda for the July IETF meeting. Thanks, Hemant and Wes -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
