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

From: "Hemant Singh \(shemant\)" <[email-masked]>
Date: Thu, 21 Jun 2007 12:31:58 -0400

Folks,
 
Here is the Abstract of our I-D that helps explain why we wrote this
I-D.  
 
   RFC 2461 [ND] describes host data forwarding and address resolution.
   However, nine years after the ND protocol became an RFC, IPv6 hosts
   still do not fully comply with RFC 2461 [ND].  In particular, hosts
   incorrectly implement on- vs. off-link data forwarding.  This
   document clarifies host behavior and associated router behavior to
   define explicitly address resolution and data forwarding models.  The
   set of new requirements beyond what has been specified in RFC 2461
   [ND] and RFC 2462 [ADDRCONF] is restricted to corrections and
   clarifications deemed necessary to facilitate correct implementation.

Please see section 5 of our I-D for a proposed change to 2462bis-08 - we
hear this I-D is 
in Editor's queue and any changes to it must be given ASAP.
 
We have tested and developed host and routers stacks for IPv6 at Cisco. 
We'd like to be put this I-D on the agenda for the July 2007 IETF
meeting. 
 
Thanks.
 
Kind Regards.
 
Hemant
 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 21 Jun 2007 19:35:46 +0300

Le jeudi 21 juin 2007, Hemant Singh (shemant) a écrit :
> Please see section 5 of our I-D for a proposed change to 2462bis-08 -
> we hear this I-D is

Could you please use US-ASCII rather than UTF-16 for you I-D, as is 
customary here?

Thanks in advance.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Hemant Singh \(shemant\)" <[email-masked]>
Date: Thu, 21 Jun 2007 12:38:41 -0400

Will do, thanks for this tip. I will send out another copy soon.

Hemant 

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 12:36 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes suggested to 2462bis-08

Le jeudi 21 juin 2007, Hemant Singh (shemant) a écrit :
> we hear this I-D is in Editor's queue and any changes to it must be 
> given ASAP.

Could you please use US-ASCII rather than UTF-16 for you I-D, as is customary here?

Thanks in advance.

--
Rémi Denis-Courmont
http://www.remlab.net/

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 22 Jun 2007 11:40:07 +0900

At Thu, 21 Jun 2007 12:31:58 -0400,

> in Editor's queue and any changes to it must be given ASAP.

(with the document editor hat of 2462bis on)

From a quick look at Section 5 (and that section only), the key point
of the proposed change is:

  skipping DAD is NOT RECOMMENDED, and new implementations MUST NOT do
  it (but existing ones still performing the optimization will not be
  accused of non-conformance)

to 

  skipping DAD is completely prohibited, and all new/old
  implementations MUST always perform DAD for any address.

Is that correct?

If so, I suspect it's too controversial to merge in 2462bis at this
stage.  This part was indeed a result of very heated discussions, and
even though (I believe) we all knew that simply prohibiting it without
exception was a cleaner resolution, we failed to reach a clear
consensus on it; hence the current text as a sort of compromise.

If your new draft could now perfectly convince those who opposed to
prohibiting the DAD optimization before 2462bis goes to the AUTH48
state, I, for one, would be happy to include it to the final version
of 2462bis.  But I cannot be that optimistic.

In any event, I don't think changing the phrase matters much; we
already clearly state new implementations MUST NOT skip DAD, so the
change only affects existing implementations.  I suspect a certain
amount of existing implementations that skip DAD as specified in
RFC2462 will still keep the current behavior whatever the new 2462bis
RFC specifies.  But they'll eventually be replaced with new
implementations, which, if conforming to 2462bis, won't perform DAD
skipping.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Hemant Singh \(shemant\)" <[email-masked]>
Date: Fri, 22 Jun 2007 09:05:36 -0400

Hi Tatuya,

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.

Thanks.

Hemant

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 10:40 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]; Wes Beebee (wbeebee); Ralph
Droms (rdroms)
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changes suggested to 2462bis-08

>From a quick look at Section 5 (and that section only), the key point of
the proposed change is:

to 

Is that correct?

If so, I suspect it's too controversial to merge in 2462bis at this
stage.  This part was indeed a result of very heated discussions, and
even though (I believe) we all knew that simply prohibiting it without
exception was a cleaner resolution, we failed to reach a clear consensus
on it; hence the current text as a sort of compromise.

If your new draft could now perfectly convince those who opposed to
prohibiting the DAD optimization before 2462bis goes to the AUTH48
state, I, for one, would be happy to include it to the final version of
2462bis.  But I cannot be that optimistic.

In any event, I don't think changing the phrase matters much; we already
clearly state new implementations MUST NOT skip DAD, so the change only
affects existing implementations.  I suspect a certain amount of
existing implementations that skip DAD as specified in
RFC2462 will still keep the current behavior whatever the new 2462bis
RFC specifies.  But they'll eventually be replaced with new
implementations, which, if conforming to 2462bis, won't perform DAD
skipping.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba
Corp.
					[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2007 16:09:00 +0200

Hemant,

Your logic escapes me. Old implementations are *old*
and will continue to do whatever their code does.
No words in 2462bis or 2462ter or anywhere can change
that. I think your proposal is a no-op.

     Brian

---

From: "Hemant Singh \(shemant\)" <[email-masked]>
Date: Fri, 22 Jun 2007 10:23:51 -0400

Hi Brian,

IETF can only make recommendations to implementers, they cannot force
implementers to implement anything.  However, IETF is the authority on
whether an implementation is compliant with an IETF specification.  By
making our proposed change to 2462bis, we are saying that old
implementations are no longer compliant with the new 2462bis I-D.  If an
old implementation wishes to comply with the new 2462bis, then the
software needs to be upgraded (by eliminating the "grandfathering"
clause).  This provides incentive for software upgrades to prevent the
security problem found in our I-D.  

Hemant

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, June 22, 2007 10:09 AM
To: Hemant Singh (shemant)
Cc: JINMEI Tatuya / ????; [email-masked]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent

Hemant,

Your logic escapes me. Old implementations are *old* and will continue
to do whatever their code does.
No words in 2462bis or 2462ter or anywhere can change that. I think your
proposal is a no-op.

     Brian

> also correct that the gross change we have proposed over 2462bis is 
> that old implementations MUST also not skip DAD. We stress about old 
> 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

> Cc: [email-masked]; [email-masked]; Wes Beebee (wbeebee); 
> Ralph Droms (rdroms)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2007 16:38:29 +0200

You don't seem to understand my point. Formal compliance is
irrelevant. The IETF isn't in the business of compliance,
conformance, or commenting on commercial products. What is
out there as running code is history and words in RFCs
will not change it.

     Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 22 Jun 2007 09:25:13 -0700

On Jun 22, 2007, at 7:38 AM, Brian E Carpenter wrote:
> What is out there as running code is history and words in RFCs will  
> not change it.

I think his point is that a new IPv6 implementation has just been  
released into the market and is not operating very well. Forget the  
compliance language; what he's saying is that the various IPv6  
implementations around don't run in his lab as well as advertised -  
the running code doesn't run all that well - and he has some  
suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc.

How about we keep this on the technical content of what he has to  
say? Do you believe, and do others believe, that the problems he  
describes are real? If not, how would you suggest he look at it in  
order to see things your way? If so, do you and others believe that  
the behavior he suggests will address the issues?

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2007 08:38:18 +0200

On 2007-06-22 18:25, Fred Baker wrote:
> implementations around don't run in his lab as well as advertised - the 
> running code doesn't run all that well - and he has some suggestions for 
> Vista Service Pack 1, MacOSX Leopard, Linux, etc.
> 
> How about we keep this on the technical content of what he has to say? 
> Do you believe, and do others believe, that the problems he describes 
> are real? 

Absolutely. I just don't think that delaying 2From [email-masked] Mon Jun 25 03:17:33 2007
Date: Mon, 25 Jun 2007 08:38:18 +0200
From: Brian E Carpenter <[email-masked]>
To: Fred Baker <[email-masked]>
Cc: [email-masked], JINMEI Tatuya / ???? <[email-masked]>
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changes
 suggested to 2462bis-08

On 2007-06-22 18:25, Fred Baker wrote:
> implementations around don't run in his lab as well as advertised - the 
> running code doesn't run all that well - and he has some suggestions for 
> Vista Service Pack 1, MacOSX Leopard, Linux, etc.
> 
> How about we keep this on the technical content of what he has to say? 
> Do you believe, and do others believe, that the problems he describes 
> are real? 

Absolutely. I just don't think that delaying 2462bis has any value.

   Brian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 25 Jun 2007 17:58:39 +0900

At Fri, 22 Jun 2007 09:05:36 -0400,

> bullet 4 of our I-D. Please see if our reasoning is solid enough to

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

   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].

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 25 Jun 2007 18:05:22 +0900

At Fri, 22 Jun 2007 09:25:13 -0700,

> suggestions for Vista Service Pack 1, MacOSX Leopard, Linux, etc.

Is that true?  I've confirmed that both MacOSX(Tiger) and Linux
(Fedora Core 6, kernel 2.6.18) perform DAD on both link-local and
global addresses (generated from the same Mac address).  I also know
all BSD variants behave the same way.  I don't know about Vista, but
in my understand the vast majority of existing implementations
actually perform DAD without an exception.

					JINMEI, Tatuya

---

From: "Hemant Singh \(shemant\)" <[email-masked]>
Date: Mon, 25 Jun 2007 10:45:35 -0400

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."

Tatuya also needs to explain how ignoring DAD from a host is a valid
implementation of the 2462 standards.  Our scenario is perfectly legal
within the specification.  Also, note that Host1 sends out the
unchallenged DAD, so routers will assume everything is OK and send their
traffic to Host1 and not Host2.

2. Delay of 2462bis I-D - we'll work with you to close issues ASAP. 

To also reply to another email where Tatuya said:

"I've confirmed that both MacOSX(Tiger) and Linux (Fedora Core 6, kernel
2.6.18) perform DAD on both link-local and global addresses (generated
from the same Mac address).  I also know all BSD variants behave the
same way.  I don't know about Vista, but in my understand the vast
majority of existing implementations actually perform DAD without an
exception."

Well, if stacks do not skip DAD, then there should be no problem with
tightening up the language as we've proposed. 

Further, these hosts are not the only implementations out there. What
about IPv6 cable modem bridges or DSL IPv6 bridges which implement an
IPv6 host? These modems are deployed in a Service Provider deployment
that is very strict on compliance with standards. 

- Hemant and Wes

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 2:38 AM
To: Fred Baker (fred)
Cc: Hemant Singh (shemant); [email-masked]; JINMEI Tatuya / ????
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent

   Brian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Jun 2007 00:28:25 +0900

At Mon, 25 Jun 2007 10:45:35 -0400,

> doesn't help because Host1 can get the same result by simply ignoring

Yeah, there was a typo.  It should actually be:

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 Host2.
(i.e., replace the final "Host1" with "Host2")

> 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.

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").

> 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.

But I in fact didn't mean all stacks don't skip DAD.  I simply
interpreted the following part

> > what he's saying is that the various IPv6 

as indicating MacOSX or Linux do skip DAD and tried to point out it's
not true.

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 25 Jun 2007 16:16:29 -0400

Hi Tatuya,

Please see in line below with "<hs>". 

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 11:28 AM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; Fred Baker (fred); [email-masked]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent

> 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:
> 
> ignoring the DAD-NS from Host1."

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. 

<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.

> 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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Jun 2007 11:08:19 +0900

At Mon, 25 Jun 2007 16:16:29 -0400,

> have gone to Host2, goes to Host1 instead - why is this not a security

I, for one, would not call it a "security" problem; it's an accident.
As an "accident", the problem described in your draft is just
another form of a weird situation that 2462bis already explains.  And
since the possibility of the accident didn't fully convince the
opponents when we discussed 2462bis, I don't think this new draft can
now do it.

> <hs> Do you acknowledge the problem we describe above?

As an accident, yes.  And I'm now more confident that it's not
significant enough to delay the publication of 2462bis.

Without the editor hat on:

> Since we realize

Before seeking the place to put the changes, the draft first needs to
convince others about the changes.  If it goes successfully, the new
document will be published as a separate RFC (I understand it's a time
consuming process, but in my understanding standardization at the IETF
works that way).

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Jun 2007 10:10:19 -0400

Tatuya,

OK, it's alright to say an accident, but this accident caused the
security problem because we still think if Host1 is receiving traffic
that was meant to go to Host2, it's a security problem. 

You also described the other security problem case where you said, Host1
is not compliant to IPv6 standards and deliberately malicious and we
granted you the fact that Host1 being a rouge can decide to ignore the
NS(DAD) from Host2. But even in this case the rtr will be able to detect
the problem if our proposed solution is applied - the solution being
Host2 will not skip DAD for GUA.

See my response in earlier email in quotes below:

"<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."

Here is the summary of what stands as of today.

Problem1: Host1 is not a rogue - it has already been acknowledged in
this mailer that this is a real problem that is not detected.
Solution1: What we propose in our I-D will fix this problem. We have
explained in an earlier email how.

Problem2: Host1 is a rogue - you have acknowledged this is a problem.
Solution2: The same solution from 1 is applied here. Host2 MUST NOT skip
DAD. Even when Host1 is a rogue and will ignore DAD from Host2 for GUA, 
           the Ipv6 rtr picks up the dup and logs an error message. 

Problem1 is a worse problem than problem2 because the attack can be
mounted by an IPv6 novice, and is not detected.

Let's focus on the problems at hand and solutions - forget delay of
2462bis I-D or what have you. Why are we referring to text in 2462bis as
an admittance that accident cases can exist when we have a solution for
such cases?

Thanks,

Hemant & Wes

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 10:08 PM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; Fred Baker (fred); [email-masked]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent

At Mon, 25 Jun 2007 16:16:29 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> <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?

I, for one, would not call it a "security" problem; it's an accident.
As an "accident", the problem described in your draft is just another
form of a weird situation that 2462bis already explains.  And since the
possibility of the accident didn't fully convince the opponents when we
discussed 2462bis, I don't think this new draft can now do it.

Without the editor hat on:

> 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.

					JINMEI, Tatuya

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 26 Jun 2007 23:16:00 +0900 (JST)

> Host2 will not skip DAD for GUA.

	i fail to understand why this is a new problem for you.  the problem
	exists with ARP, and the only solution for the operator would be to
	pin down MAC address caches on the ethernet switch (L2 solution), or
	deploy secure neighbor discovery (L3 solution, which is very difficult,
	RFC3971 sizes 123Kbytes!).  why do you think we have to solve it with
	DAD change, which is not a perfect solution and incompatible with the
	deployed codebase?

itojun@code then spec

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Jun 2007 10:30:23 -0400

Why is solving the problems with a DAD change not a perfect solution ?
The problems are serious enough for deployed codebase to change. It's
not like we are asking to replace IPv6 hardware. It's a software change
for deployed code base. Anyhow, Tatuya has already said most hosts he
has tested with do not skip DAD. We have also tested hosts that do not
skip DAD. So what codebase and what specific hosts/nodes are you talking
about ?

Thanks.

Hemant

-----Original Message-----
From: Jun-ichiro itojun Hagino [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2007 10:16 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked];
[email-masked]; Fred Baker (fred)
Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent
changessuggested to 2462bis-08

> You also described the other security problem case where you said, 
> Host1 is not compliant to IPv6 standards and deliberately malicious 
> and we granted you the fact that Host1 being a rouge can decide to 
> ignore the
> NS(DAD) from Host2. But even in this case the rtr will be able to 
> detect the problem if our proposed solution is applied - the solution 
> being

	i fail to understand why this is a new problem for you.  the
problem
	exists with ARP, and the only solution for the operator would be
to
	pin down MAC address caches on the ethernet switch (L2
solution), or
	deploy secure neighbor discovery (L3 solution, which is very
difficult,
	RFC3971 sizes 123Kbytes!).  why do you think we have to solve it
with
	DAD change, which is not a perfect solution and incompatible
with the
	deployed codebase?

itojun@code then spec

---

From: Markku Savela <[email-masked]>
Date: Tue, 26 Jun 2007 17:39:22 +0300

Related to this topic, long time ago when the choices of

a) DAD only on link local, and not on other addresses derived
from the same id (legal on original RFC)

b) do DAD indivially on each address

were discussed, I preferred (a) (and still do), and proposed an
additional logic on hosts using (a):

- if they see DAD probe on any address using the ID part of the
  assigned link local address, the host would reply as if the probed
  address was configured ("defend ID patch").

That solves the case where one tries to manually configure global
address to some other host using the same ID part. The attempt will
fail as DAD collision. It does not solve merging of two local links
into one, but nothing solves that mess anyway, if there are multiple
users of same ID and addresses.

I still question the sanity of "do DAD on all addresses" approach:

- when router advertises a list of global prefixes, *each* and *every*
  node will now send DAD on each address at same time => instant DAD
  storm. And a host can have mulpiple id's in use...

- now, if we talk about rogue hosts, one could do continous stream of
  RA's with 40 random prefixes, and see how the hosts behave...

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 26 Jun 2007 23:41:52 +0900

At Tue, 26 Jun 2007 10:10:19 -0400,

> an admittance that accident cases can exist when we have a solution for

I'm afraid I'm now a little confused, so please let me be sure about
one thing first: are you still requiring us to incorporate your
proposed change in the coming 2462bis RFC?  Or are you now starting a
discussion as a separate thread from the publication of 2462bis?

					JINMEI, Tatuya

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 26 Jun 2007 23:45:32 +0900 (JST)

> skip DAD. So what codebase and what specific hosts/nodes are you talking

	i'm very sorry, i think i did not do the homework hard enough.

	i reread the whole thread and i think your abstract on the i-d is
	a bit misleading.  from the word "new requirement" i read that (i guess
	between the line) there are code changes to the deployed codebase which
	implements DAD correctly.  the fact is that you are proposing changes
	to make DAD a MUST instead of SHOULD (from section 5 of your draft).

	jinmei (who is KAME colleague of mine as you know) is very careful guy
	and he cares about other careless implementations which skips DAD :-)

	i do not care about careless implementations unlike jinmei, however,
	i still think that your security model with "DAD is a MUST" is not
	perfect.

	yes, which DAD being MUST it would be a better world order.  however,
	because this is based on the assumption that all of the implementations
	would follow the RFC to secure the link, a clever attacker would get
	a freely-available IPv6 implementation, "#if 0" the portion which does
	DAD and steal traffic anyway (or implement something on BPF writes or
	raw IPv6 sockets).

	so, as i said, the only solution is either to pin-down MAC address
	cache (L2) or do some cryptographic dance (L3).  L3 stuff still require
	every node to cooperate, i think the only solution is in L2.
	CISCO can sell a lot of L2 devices with the feature :-P

itojun

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Jun 2007 10:58:42 -0400

We originally wanted to make changes to 2462bis I-D, but since it's in
AUTH state, that may not be possible anymore.

If you want, we can let 2462bis I-D not make our proposed change, but
our security case and solution needs to be addressed in an I-D to
highlight the problem with older implementations that can skip DAD. It
would be preferable if the security problem and its solution is
presented in 2462bis, but if that's not possible, then we'll discuss it
in our I-D.

We have other issues we want to address in our I-D, and we don't want to
have this issue prevent other issues from being discussed.

- Hemant and Wes

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]] 
Sent: Tuesday, June 26, 2007 10:42 AM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; Fred Baker (fred); [email-masked]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent

At Tue, 26 Jun 2007 10:10:19 -0400,
"Hemant Singh (shemant)" <[email-masked]> wrote:

> 2462bis I-D or what have you. Why are we referring to text in 2462bis 
> as an admittance that accident cases can exist when we have a solution

> for such cases?

I'm afraid I'm now a little confused, so please let me be sure about one
thing first: are you still requiring us to incorporate your proposed
change in the coming 2462bis RFC?  Or are you now starting a discussion
as a separate thread from the publication of 2462bis?

					JINMEI, Tatuya

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 26 Jun 2007 15:51:53 -0400

IETF IPv6 Folks,

The focus of discussion has been with regards to one proposed change to
2462bis, because of its impending release status.  However, this is not
the primary focus of our I-D.  The primary focus is clearing up
misconceptions related to data forwarding and address resolution with
respect to on-link determination.  We have found host bugs that have
matched areas of 2461 and 2462 that are not clear, concise, and
explicit.

- Hemant and Wes 

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Tuesday, June 26, 2007 10:59 AM
To: JINMEI Tatuya / ????
Cc: [email-masked]; Brian E Carpenter; Fred Baker (fred)
Subject: RE: draft-wbeebee-nd-implementation-pitfalls-00 with urgent

- Hemant and Wes

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:[email-masked]]
Sent: Tuesday, June 26, 2007 10:42 AM
To: Hemant Singh (shemant)
Cc: Brian E Carpenter; Fred Baker (fred); [email-masked]
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Wed, 27 Jun 2007 14:27:37 -0400

One bug that may or may not be common is to make assumptions about  
the prefixes on a link based on addresses assigned to an interface.   
I can imagine (and I believe we've actually made a real sighting of  
this scenario) that an IPv6 implementor might extrapolate IPv4  
conventions and extract the /64 prefix from an assigned address  
(either SLAAC, DHCP or manual config), and add a route to the host  
table indicating that the prefix is on-link, regardless of whether  
the prefix is advertised as "on-link" in an RA.

This bug is an example of the issues addressed by section 2 of draft- 
wbeebee-nd-implementation-pitfalls.

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 28 Jun 2007 14:14:57 +0900

At Wed, 27 Jun 2007 14:27:37 -0400,

> the prefix is advertised as "on-link" in an RA.

FWIW, *BSDs do not have this "bug".

- the L and A bits of the RA prefix information option are clearly
  separated.  That is, creating an IPv6 address from a prefix
  information option (with A bit on) doesn't make the kernel consider
  the prefix on-link unless the L bit is also on.
- the WIDE-DHCPv6 client configures an IPv6 address with the prefix
  length of 128.  So, an IPv6 address created via DHCPv6 doesn't
  impose the incorrect assumption of on-link'ness either.

If the system administrator manually configures an IPv6 address with a
prefix length smaller than 128, the kernel will assume that the
corresponding prefix is on-link.  But I believe this should be
reasonable.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Jun 2007 10:26:19 -0400

On Jun 28, 2007, at Jun 28, 2007,1:14 AM, JINMEI Tatuya / 神明達哉  
wrote:

> [...]

I see where draft-wbeebee-nd-implementation-pitfalls also mentions  
manual configuration as a special case:

    2.  The RA and ICMPv6 Redirects from the default router are the only
        sources of information for on-link determination.  DHCPv6 or any
        other configuration on the host MUST NOT be used for on-link
        determination.  Manual configuration of a host introduces its  
own
        set of security considerations and is beyond the scope of this
        document.

Is there some reason to believe the information about on-link  
prefixes should be implicitly overridden in the case of manual  
address assignment?  I can understand explicitly overriding  
information from RAs by manually configuring the on-link information  
as a separate step from manual address assignment.  But it seems to  
me that assuming the prefix from a manually configured address is on- 
link might cause unexpected loss of connectivity if the prefix does  
require off-link delivery through the router.

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 29 Jun 2007 10:55:47 -0400

Please see in line below with "<hs>" 

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, June 29, 2007 10:26 AM
To: JINMEI Tatuya / ????
Cc: IETF Mailing List IPv6; Wes Beebee (wbeebee); Hemant Singh (shemant)
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08

> 					[email-masked]

I see where draft-wbeebee-nd-implementation-pitfalls also mentions manual configuration as a special case:

        determination.  Manual configuration of a host introduces its own

Is there some reason to believe the information about on-link prefixes should be implicitly overridden in the case of manual address assignment?  I can understand explicitly overriding information from RAs by manually configuring the on-link information as a separate step from manual address assignment.  But it seems to me that assuming the prefix from a manually configured address is on- link might cause unexpected loss of connectivity if the prefix does require off-link delivery through the router.

<hs> If the host has been manually configured for IPv6 address where the host was also configured for prefix and prefix length, then what's on-link for this host can be determined by host. But what if manual configuration configured an IPv6 address and maybe, also the prefix, but forgot to configure prefix length. Then this manual configuration has no means to determine what's on-link for a destination based on the data from manual configuration. I have host not assuming a default prefix length yet. The RA has been explicitly ignored. So not this host has no choice but to send non-link-local traffic to the default router. Specifying manual configuration behavior and its interaction with RA is a can of worms that will take time to clear up.

Hemant

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Jun 2007 12:06:21 -0400

Hemant - does RFC 2461 allow a host to ignore the PIOs in RAs?

Stig - you wrote "At least as a sysadmin/user I would find it  
confusing if the prefix length I configured would not be used for on- 
link determination. I think it's more bad than good to try to  
separate the two. I'm happy the way it currently is on the systems  
I've seen."  I can understand that it should be possible to manually  
configure on-link prefix information.  I question whether that  
configuration should be conceptually tied with address assignment  
because of the design of IPv6, or do we mix address assignment with  
prefix information because that's the way it was done in IPv4?

Looking back to the definition of DHCPv6 - we received a lot of input  
that DHCPv6 should *not* include information about default routers  
and on-link prefixes, because that information comes from RAs.  That  
argument made sense to me at the time; makes sense to me in the case  
of manual address assignment, too...

- Ralph

On Jun 29, 2007, at Jun 29, 2007,11:53 AM, Stig Venaas wrote:

> Hemant Singh (shemant) wrote:
>> information from RAs by manually configuring the on-link  
>> information as a separate step from manual address assignment.   
>> But it seems to me that assuming the prefix from a manually  
>> configured address is on- link might cause unexpected loss of  
>> connectivity if the prefix does require off-link delivery through  
>> the router.
>
> At least as a sysadmin/user I would find it confusing if the prefix
> length I configured would not be used for on-link determination.
>
> I think it's more bad than good to try to separate the two. I'm
> happy the way it currently is on the systems I've seen.
>
>>
>> <hs> If the host has been manually configured for IPv6 address  
>> where the host was also configured for prefix and prefix length,  
>> then what's on-link for this host can be determined by host. But  
>> what if manual configuration configured an IPv6 address and maybe,  
>> also the prefix, but forgot to configure prefix length. Then this  
>> manual configuration has no means to determine what's on-link for  
>> a destination based on the data from manual configuration. I have  
>> host not assuming a default prefix length yet. The RA has been  
>> explicitly ignored. So not this host has no choice but to send non- 
>> link-local traffic to the default router. Specifying manual  
>> configuration behavior and its interaction with RA is a can of  
>> worms that will take time to clear up.
>
> Can you manually configure prefix on a host without also specifying
> prefix length?
>
> Stig
>
>>
>> Hemant
>>
>> - Ralph
>>
>>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 29 Jun 2007 17:53:45 +0200

Stig

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 29 Jun 2007 12:52:53 -0400

Stig,

Wrt to this question you raised:

"Can you manually configure prefix on a host without also specifying prefix length?"

See text below snipped from http://www.microsoft.com/technet/community/columns/cableguy/cg0506.mspx#EMB about Manual configuration for Windows Vista for IPv6. Text snipped from this URL shows that if an IPv6 address has been added via the CLI, prefix length is optional to be configured. Also, as I said before, I not too fond of a host assuming a default of 64 as this CLI help shows.

------------------ begin snip-------------------------------

Configuring IPv6 With the Netsh.exe Tool
In the same way as IPv6 for Windows XP, you can configure IPv6 addresses and other configuration parameters at the command line using commands in the netsh interface ipv6 context.

Configuring Addresses
To configure IPv6 addresses, you can use the netsh interface ipv6 add address command with the following syntax:

netsh interface ipv6 add address [interface=]Interface_Name_or_Index [address=]IPv6_Address[/Prefix_Length] [[type=]unicast|anycast] [[validlifetime=]Time|infinite] [preferredlifetime=]Time|infinite] [[store=]active|persistent]

* interface The connection or adapter's name or interface index.
 
* address The IPv6 address to add, [optionally followed by the subnet prefix length] (default of 64).

------------------------ end snip -------------------------------------------------------------------------------------
 
Hemant 

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 11:54 AM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); JINMEI Tatuya / ????; IETF Mailing List IPv6
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08

Hemant Singh (shemant) wrote:
>> If the system administrator manually configures an IPv6 address with 
>> a prefix length smaller than 128, the kernel will assume that the 

At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on-link determination.

I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen.

> <hs> If the host has been manually configured for IPv6 address where the host was also configured for prefix and prefix length, then what's on-link for this host can be determined by host. But what…

Can you manually configure prefix on a host without also specifying prefix length?

Stig

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 29 Jun 2007 13:02:27 -0400

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, June 29, 2007 12:06 PM
To: Stig Venaas
Cc: Hemant Singh (shemant); JINMEI Tatuya / ????; IETF Mailing List IPv6
Subject: Re: draft-wbeebee-nd-implementation-pitfalls-00 with urgent changessuggested to 2462bis-08

<hs> Not that I know of.

Stig - you wrote "At least as a sysadmin/user I would find it confusing if the prefix length I configured would not be used for on- link determination. I think it's more bad than good to try to separate the two. I'm happy the way it currently is on the systems I've seen."  I can understand that it should be possible to manually configure on-link prefix information.  I question whether that configuration should be conceptually tied with address assignment because of the design of IPv6, or do we mix address assignment with prefix information because that's the way it was done in IPv4?

Looking back to the definition of DHCPv6 - we received a lot of input that DHCPv6 should *not* include information about default routers and on-link prefixes, because that information comes from RAs.  That argument made sense to me at the time; makes sense to me in the case of manual address assignment, too...

<hs> Sure thing. But how does a sys admin who is configuring IPv6 manually on a host know what has RA sent to the host to match setting on the host with the RA? Is it the same admin who also has access to the IPv6 default router for this host in which case the admin know how has ND and RA been configured on the router.  Even if admin knows how is RA configured on router, the admin can fat-finger the default prefix and prefix length during manual configuration. Or of admin doesn't have access to the router's config, the admin has to sniff RA in the network and see what PIO has been sent etc. This seems like a process prone to errors.

Hemant

- Ralph