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

From: "Christian Huitema" <[email-masked]>
Date: Wed, 12 Nov 2003 13:33:44 -0800

> > It is true that a bad guy on-link can do a lot of harm, some of
which
> > can be alleviated by SEND. However, most of other attacks require a
> > constant stream of packets, and increase the risk that the attack
will
> > be detected and traced. The recommendation to turn off the interface
> > amplifies the powers of this bad guy: they can kick someone off the
> > network with a single packet. In short, just because someone broke
in,
> > there is no reason to hand her a sledge hammer.
> 
> 	but then, if we change it to MAY, what is the point in running
DAD
> 	process?  if you do not disable interface (or the address on the
> 	interface) the owner of the same address will get confused,
> 	peers of the address get confused, you will do bad things to the
> 	original owner of the address.

Disabling the address is OK, as you can always configure a new one.

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

---

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

One more point:

One of the original motivations for disabling an interface if DAD
fails for the LL address is that if you are running DAD on a LL
address generated using the EUI-64 format, in the absence of a DOS
attack, if DAD fails, that really means duplicate ethernet addresses
are in use. In this case, the device is hosed and configuring another
address won't result in a usable network. In fact, it probably makes
things worse by creating problems that harder to diagnose than just
shutting down the interface. The user will see a partially working
network where some things work, and other things won't.

BTW, some of the above text might be worth putting into 2462bis as
background information.

Thomas

---

From: [email-masked]
Date: Thu, 13 Nov 2003 06:01:30 +0200

Thomas,

> BTW, some of the above text might be worth putting into 2462bis as

Understood about the original intention, but this may not be the case.

2462 currently says:

   Note that interface identifiers will typically be 64-bits
   long and based on EUI-64 identifiers as described in [ADDR-ARCH].

This may not always be the case. See 3GPP, for example.  Also,
I remember that the MIP folks wanted to be able to use a random
number in place of the EUI-64 in case the DAD failed.  

My question, is the original quote above still a valid assumption?
If so, what does 'typically' mean?

John

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 12 Nov 2003 20:14:36 -0800

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

No, we clarified later that the implementation should disable the
address.
 
>  - Assume there is a DOS attack, wait a while, and try again? (hoping
>    the bad guy goes away in the meantime)

I would not specify that..

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

Yes. The implementation may very well have access to several EUI-64, and
may try an alternative. Or, it may try to use a random address. The
persistence of DAD collision would indicate with quasi certainty a DOS
attack. Forcing the attacker to repeat the attack increases the chances
of detection.

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

That is a variation of the above. It may be useful in some cases, e.g.
when turning of the interface briefly saves energy.

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

Maybe. There is no limit to creativity.

-- Christian Huitema

---

From: "Chirayu Patel" <[email-masked]>
Date: Thu, 13 Nov 2003 23:03:34 +0530

On Thu, 13 Nov 2003 20:03:59 +0900 (JST), "Jun-ichiro itojun Hagino"
<[email-masked]> said:
>       so proposed change: the last part should be changed to "the
>       interface address SHOULD be disabled".  (add "address")
>
> 5.4.5.  When Duplicate Address Detection Fails
>
>    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.

Hi itojun,

Replacing interface with address will not be enough. I have attempted to
rephrase the paragraph with my comments in brackets.

    A tentative address that is determined to be a duplicate as
    described above, MUST NOT be assigned to the interface on which DAD
    has failed (this allows for the address to be assigned to other
    interfaces) and the node SHOULD log a system management error.
    Moreover, the address SHOULD (or MUST?) be disabled. If the address
    is a link-local address formed from an interface identifier, the
    complete set of addresses formed with the same interface identifier
    SHOULD (or MUST?) be disabled.

CP