Subject: Comments on draft-jinmei-ipv6-rfc2462bis-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Wed, 12 Nov 2003 12:00:45 -0800

The section "5.4.5 When Duplicate Address Detection Fails" currently
says:

   A tentative address that is determined to be a duplicate as described
   above, MUST NOT be assigned to an interface and the node SHOULD log a
   system management error.  If the address is a link-local address
   formed from an interface identifier, the interface SHOULD be
   disabled.

The part about disabling the interface enables a DOS attack: wait for a
target to come on line and send a DAD packet, reply with a deliberate
collision, and poof the target is disconnected from the network. 

Proposed resolution: write "MAY be disabled" instead.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Nov 2003 22:14:07 +0200 (EET)

> collision, and poof the target is disconnected from the network. 

Unless you haven't noted from SEND work, if you have access to the local
link, you can do pretty much everything anyway, so this is really not big 
news.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 13 Nov 2003 05:26:52 +0900 (JST)

> link, you can do pretty much everything anyway, so this is really not big 

	agree completely.  if you allow enemy to be on-link you are dead.
	my suggestion is to leave it SHOULD.

itojun

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2003 12:40:50 -0800

> 	my suggestion is to leave it SHOULD.

you didnt justify why. makes no sense on an unprotected network.

Vijay

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 13 Nov 2003 05:47:05 +0900

>you didnt justify why. makes no sense on an unprotected network.

	i did.  you did not quote my previous line.

>>	my suggestion is to leave it SHOULD.

	this is just like physical security; if you allow people to enter
	computer room, security mechanisms are pertty moot as bad guys can use
	sledge hammer to break the computer.

itojun

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2003 12:59:33 -0800

> 	sledge hammer to break the computer.

it still does not make sense. even the IETF WLAN network is
unprotected. somebody could easily screw up your network
interface by replying to your DAD NS solicitation.

you are just making it simple for somebody to disable your
interface by leaving it as SHOULD.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Nov 2003 13:03:14 -0800

Vijay

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Nov 2003 21:32:35 -0600

> Proposed resolution: write "MAY be disabled" instead.

Um, I'd suggest that this by itself isn't really all that helpful. It
might help to add some more explanatary text together with
recommendations on what to do. E.g.,

 - should an implementation just configure the address and use it
   anyway? (I doubt this, as this implies we should just punt on DAD)

 - Assume there is a DOS attack, wait a while, and try again? (hoping
   the bad guy goes away in the meantime)

 - generate a new IID and try again? And if so, are there
   recommendations on what kind of ID? And if there is a  DOS attack
   in progress, why would  trying *any* address result in success?

 - Try generating a new address, but use exponential backoff in
   delaying after each failed attempt?

 - something else? (or some combination of the above?)

Thomas