Subject: Last Call: 'Optimistic Duplicate Address Detection for IPv6' to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 02 May 2005 14:16:25 -0400

The IESG has received a request from the IP Version 6 Working Group to 
consider the following document:

- 'Optimistic Duplicate Address Detection for IPv6 '
   <draft-ietf-ipv6-optimistic-dad-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-05-16.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-05.txt

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 25 May 2005 12:38:40 -0400

I've reviewed this document and on the whole think it's fine for PS.

But I do have one general concern. This document requires that an
implementation do what in practice, I think might be "difficult" for
some implementations. While that is OK at one level, I fear that some
implementors will do most of this spec, but not all of it. I wonder if
that would be a good outcome.

For example:

>    * (modifies 7.2.2)  When a node has a unicast packet to send from an
>         Optimistic Address to a neighbor, but does not know the
>         neighbor's link-layer address, it MUST NOT perform Address
>         Resolution. It SHOULD forward the packet to a default router on
>         the link in the hope that the packet will be redirected.
>         Otherwise it SHOULD buffer the packet until DAD is complete.

will implementations really bother with this? Or will they be tempted
to skip this because it is "too hard" for a particular implementation?

>    * Nodes implementing Optimistic DAD SHOULD additionally implement
>         Secure Neighbor Discovery [SEND].

This seems like gratuitous recommendation. This either requires
justification, or removal. (I'd think the latter.)

>    Tentative Address - an address for which a node has not yet completed
>         DAD is regarded as Tentative: a single Neighbor Solicitation for
>         this address or a single Neighbor Advertisement defending this
>         address will cause the node to deconfigure the address and cease
>         using it.
> 
>    Deprecated Address - an address which should not be used if an
>         alternative is available.
> 

Wouldn't it be better to just use the same definitions as appears in 2462?

Editorial/minor:

>    Optimistic Address - an address which is available for use despite
>         DAD not being fully complete.  This memo places restrictions on
>         the use of Optimistic Addresses.
> 

s/which/that/

>    Standard Node - A Standard Node is one which is compliant with RFCs
>         2461 and 2462.
>

s/standard/conventional/? (nodes implementing this spec will be
"standard" too)

>    * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation
>         for an Optimistic Address from the unspecified address.  This NS
>         indicates that the address is a duplicate, and it MUST be
>         deconfigured as per the behaviour specified in RFC2462 for
>         Tentative addresses.

Suggested reword of second sentence::

     Receipt of such an NS indicates that the address is ...

>    The ON will immediately send out a Neighbor Solicitation to determine
>    if its new address is already in use.

s/new/optimistic/

>    router behaviour, eg: that the router includes SLLAOs in RAs, and

s/eg:/e.g.,/

---

From: Greg Daley <[email-masked]>
Date: Thu, 26 May 2005 10:12:03 +1000

Hi Thomas.

> to skip this because it is "too hard" for a particular implementation?

I guess that the forwarding to the router may be difficult as also may
the buffering of the packets (which I guess actually may be part
of the existing tentative address specification).

Neither is actually as important as the first instruction
(the MUST NOT).

What's actually critical here is that NS's aren't sent to multicast
addresses.   They contain SLLAOs which will overwrite a peer's NCE
destructively.

So my question is: Is your problem mainly with the SHOULDs or the
MUST NOT?

Greg

---

From: Thomas Narten <[email-masked]>
Date: Wed, 25 May 2005 21:03:46 -0400

> > that would be a good outcome.

BTW, what I meant to say above was more like:

  This document requires that an implementation do things that may
  logically (if you follow the conceptual sending model) be hard to
  do, because the information needed to do something may not be
  available at that point in the algorithm (implementation). I.e., one
  ends up having to have access to the ND cache info while doing steps
  that (previously) were logically completely separate from the ND
  cache.  I wonder if in practice, these might be "difficult" for some
  implementations.

> Neither is actually as important as the first instruction

If you only do the MUST NOT, but not the SHOULDs, what is the point of
implementing the spec? You are allowing an upper layer to use a
tentative address, yet packets from that address presumably won't be
sent until (the normal) DAD has completed, in which case, you've paid
the price  of the normal DAD delay... Right?

> So my question is: Is your problem mainly with the SHOULDs or the

Am I understanding correctly that not implementing the SHOULD
effectively negates the benefits of implementing the spec?

Well, maybe it depends also on what one expects the first packets to
be that a node sends. I.e., if they are for non-neighbors (i.e.,
off-link) and would go through the router, then that traffic would get
sent immediately. But it appears that at least when sending to
neighbors, not implementing the SHOULDs results in no reduction in
delay.

Thomas

---

From: Greg Daley <[email-masked]>
Date: Thu, 26 May 2005 12:38:11 +1000

Hi Thomas,

Thomas Narten wrote:
[cut]
>   cache.  I wonder if in practice, these might be "difficult" for some

I guess that's a fair comment.  There's more required knowledge in order
to control operations within the NC.

Nick may have more comments implementation though.

[cut]
> the price  of the normal DAD delay... Right?

Yes, full DAD delay is incurred in that case (for on-link destinations).

As you mentioned below off-link destinations are a different case,
but I guess in scope.  A lot of the interest was being driven
through path restoration mechanisms like MIPv6, SCTP, etc.

> effectively negates the benefits of implementing the spec?

It reduces the applicability to only off-link destinations available
through a discoverable router.

Do you think that the draft needs a statement about the effect of
not implementing the 'send to router' mechanism?

> neighbors, not implementing the SHOULDs results in no reduction in

Since the implicit goal of Opti-DAD was not to create long-lasting state
on neighbours, I guess the idea of delaying was seen as preferable in
this case to destruction of existing NCEs.  I guess that delay reduction
was the main reason for having these ideas as SHOULDs.

If there was a way of explicitly removing peer NCEs created during the
optimistic period, then it would be good to be able to send multicast
NS's, instead of forwarding to a router (or delaying).

This may be difficult in practice too though (more difficult than
forwarding to a router??).

Greg.

P.S.

Here's an example of the type of mechanism which may offer an
alternative and only needs to check the optimistic state from the
NCE during ND operations (rather than during packet delivery).
It's a lot more work than 'send to the router', though.

I'd guess one way to address resolution is to send multicast
NS's to neighbours, but to not reply to unicast/PROBE NS's
sent from these neighbours until the end of the optimistic period.

The NS created STALE entry transits immediately to DELAY upon
unicast NA transmission back to the Optimistic Node.
The DELAY of 5 seconds could potentially push the probe back until
the node was either finished being optimistic, or discovered
that it was a duplicate address.  In the duplicate case, there would
be about 14 seconds of delay and probing before the NCEs were deleted,
along with any queued data (about 9 seconds of which would be lost?).

It would require further data (and perhaps upper layer timeout) to
reinitialize the NCE to the original owner's MAC address.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 26 May 2005 08:58:42 -0700

Thomas,

>   cache.  I wonder if in practice, these might be "difficult" for some

To be more specific, if I understand your concern correctly, the problem is
that the host is required by this to send packets to the router at a time
when it does not have the router's link address?

            jak

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 May 2005 13:08:39 -0400

> when it does not have the router's link address?

Somewhat different. From an implementation perspective, one needs
access to information (e.g., whether the router's link-layer address
is in the cache) at a place in the implementation where that
information is not necessarily readily availbale.

But, looking back over the document again, I think I've convinced
myself that this may not be a big issue after all.

However, thinking and rereading leads me to two more thoughts:

In off-list mail:

Jari Arkko <[email-masked]> writes:

> >    * Optimistic DAD SHOULD NOT be used to configure addresses unless the
> >         probability of collision is exceedingly small.

> I find it very hard to implement this. More guidance would be
> needed. Did you mean "... SHOULD NOT when addresses have
> been configured manually"?

I tend to agree.

Actually, I wonder if what is needed is more of an applicability
statement saying what types of addresses it is appropriate to use this
procedure for, and where not. For example, can optimistic DAD be used
for the LL address?  It took me some thinking to decide whether it
could or not. The answer I believe is yes, but that is not immediately
obvious, I would assert.

But this all depends on having the link-layer address of a router in
the cache (as had been discussed already).

The second thought I have is that the security considerations section
needs some more text, something along the following lines:

  Optimistic DAD takes steps to ensure that if another node is already
  using an address, the proper link-layer address in existing Neighbor
  Cache Entries is not replaced with the link-layer address of the
  Optimistic node. However, there are still scenarios where incorrect
  entries may be created, if only temporarily.  For example, if a
  router (while forwarding a packet) sends out a Neighbor Solicitation
  for an address, the optimistic node may respond first, and if the
  router has no pre-existing link-layer address for that IP address,
  it will accept the response and (incorrectly) forward any queued
  packets to the optimistic node. The optimistic node may then respond
  in an incorrect manner (e.g., sending a TCP RST in response to an
  unknown TCP connection). Such transient conditions should be
  short-lived, in most cases.

  Likewise, an Optimistic node can still inject IP packets into the
  Internet that will in effect be "spoofed" packets appearing to come
  from the legitimate node. In some cases, those packets may lead to
  errors or other operational problems, though one would expect that
  upper layer protocols would generally treat such packets robustly,
  in the same way they must treat old and other duplicate packets.

Thomas

---

From: "James Kempf" <[email-masked]>
Date: Thu, 26 May 2005 10:50:51 -0700

Thomas,

> myself that this may not be a big issue after all.

OK.

> the cache (as had been discussed already).

Well, this brings up the reason why I asked for clarification.

In the DNA WG, we've been discussing how to handle the address state machine
when a host moves from one wireless AP to another, potentially with both APs
on the same IP link or not (the host doesn't know a priori from L2 info
after movement). There's nothing currently in the DNA DT draft on the topic
because we just got to discussing it when the draft was almost complete but
it is on the list of issues.

One way to handle this is for the host to classify the link local address as
"Optimistic" then use that as the source address of  a DNA RS that is
multicast to All_Routers_Multicast. The RS is used to test whether the host
has moved, if the RA comes back "yes, you are on the same IP link", then no
additional configuration is necessary, if it comes back "no, you are on a
different IP link" there's configuration information (prefixes, whether
address configuration is stateful or not, etc.).

In this case, there is no need for the router's link address because the
host is sending the RS to an address that goes to the router anyway. And, if
the host can't use "Optimistic", it would have to DAD the link address,
potentially on every AP movement.

In addition, if the host *has* moved to a new IP link, the DNA RA will
provide the host with the router's link address, so it therefore potentially
is able to autoconfigure a new unicast global address on the new link, and,
putting it in "Optimistic" state, start using it for traffic by sending the
traffic directly to the router while the address is being confirmed.

In this case, the ability to use "Optimistic" greatly reduces handover
latency, and there doesn't seem to be an issue with routing through the
router because the RA provides the link address.

Do you see any issues with this that I might have missed?

>   short-lived, in most cases.

OK.

>   in the same way they must treat old and other duplicate packets.

It is true that an Optimistic attacker can do this, but, really, can't any
IPv6 node do it? An attacking node doesn't have to do DAD, it could simply
come on the link and start sending packets to the Internet with whatever
address it wants. It might not get anything back, of course, since any
response will get sent to the legitimate owner of the address.

            jak

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 May 2005 13:57:31 -0400

> Well, this brings up the reason why I asked for clarification.

I need to spend some time getting back up to speed with DNA, as that
work is complimentary piece of this puzzle. Let me defer responding to
your point until later.

> response will get sent to the legitimate owner of the address.

I think the key difference is that nodes running optimistic DAD may
end up spoofing traffic, even though they are following the spec and
are "good" nodes. I.e, there is no ill-intent, as is the case with
attacking nodes.

So we may end up seeing such events even in cases where there are no
"attackers". 

Thomas

---

From: "James Kempf" <[email-masked]>
Date: Thu, 26 May 2005 11:22:19 -0700

> So we may end up seeing such events even in cases where there are no

Yes, that makes sense. oDAD is really depending on the low probability of a
clash. If the node is out of luck, it will of course look like spoofed
traffic. Might make sense to add something like that, maybe:

       Optimistic DAD assumes a low probability of an address clash.
       If this assumption fails, an Optimistic node can still inject IP
       packets into the Internet ...

            jak

---

From: Greg Daley <[email-masked]>
Date: Fri, 27 May 2005 10:48:38 +1000

Hi James,

James Kempf wrote:
[cut]
> it is on the list of issues.
[dna context cut]
> Do you see any issues with this that I might have missed?

DNA has been considering DAD issues informally for a long time,
even though there's no text in the current proposal (oDAD was once
a potential charter item for the group).  I think it is now
believed necessary to use Optimistic DAD with a link-local
address while testing whether reconfiguration is needed.

The main issues with using Optimistic DAD for DNA seem to be as follows:

1 There's a requirement to include the SLLAO into the RA for DNA
   routers, otherwise the DNA host incurs full DAD delay before
   resolving the router address.  It may be able to detect link
   change though...

2 Non SEND addresses can be stolen by fake DAD defences upon the
   host entering DNA (for example cell change within a link).
   This is not a new attack, but an extension of its applicability.

3 RS's cannot contain an SLLAO in Optimistic DAD.  This either
   causes a multicast response, or an additional address resolution
   by the router toward the host.

The first issue cannot be controlled by DNA hosts (since they
may visit networks where compliant 2461 routers don't include the
option.  It may be worth describing in one of the documents
(DNA for hosts ??).  Including SLLAO in RAs should be mentioned in
DNA for routers (I'll check that it is).

The second issue needs a few words in the DNA for hosts document,
and should probably mention how SEND can be used to defend against it.
(I'll check that this is there).

The third issue remains problematic for DNA hosts in that in
some circumstances there will be 2461 routers which won't unicast
respond to an RS without SLLAO.  This will induce (further) delay.

What would really help things along would be a Tentative Source
Link-Layer Address Option, which could be used to create a STALE
NCE on the router, iff there's no existing NCE with a different MAC
address.

The existing DNA DT proposal (not a WG document) in DNA requires use of
such options, but refers to a separate draft (I'm one of the TSLLAO
authors).  If the DNA WG needs the option, perhaps it would be better to 
look at that option in IPv6 WG though, because of its DAD expertise.

Greg

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 31 May 2005 12:49:41 +1000

> I've reviewed this document and on the whole think it's fine for PS.

Thanks.  Sorry it's taken a little while for me to get back to you, 
I had a couple of other things on.  It looks like the IESG assessment
has been pretty positive, though.

[talking here about sect 2.3 / sect 3.2 rule 4.]

> effectively negates the benefits of implementing the spec?

Partly.

Optimistic DAD is very much a compromise.  It's trying to be 
backwards compatible with normal routers and hosts, and it's
trying not to be too slow, unsafe or complicated.  If we could 
have started again with a clean slate, we could have come
up with something much nicer.  But it wouldn't have worked
with existing IPv6 infrastructure ...

The problem being that we've only got half of the NS/NA mechanism
available, because of the problem with sending LL address options
and overriding NC entries.

> sent immediately.

In a lot of cases, a mobile node won't care who is on its local
net ... it's trying to quickly hand over from one net to another
so it can keep on talking to someone on a third net, far away.
So long as the new router broadcasts its LL address, OptiDAD works
fine in this case.

> But it appears that at least when sending to

That's true.  The reasons why I left it a SHOULD:

a) it's not always necessary.  Not all applications will care about
	talking to neighbours quickly.  Those that don't have no 
	need of this mechanism.

b) it's not always sufficient.  The router only SHOULD behave that
	way in a redirect.  It might not, in which case we're back
	to waiting 1000ms anyway.

c) it may be a pain to implement, and I'd rather that implementors
	have something implementable, rather than just doing the
	bits they need to do for their application and silently
	dropping the rest.

Okay, so no points for dogma with that last one.  But recognizing
that this is a compromise solution, an alternative to just 
"set dad_transmits to zero", it seems okay to me.

(the rest of the comments which came out of the IESG review seem
pretty simple to address, to me.  I think this means I need to 
start firing up -06 ... sadly, it seems unlikely that I'll be able
to get funding to attend Paris, so it'll have to keep bouncing 
around in email ...)

-----Nick

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 31 May 2005 13:01:46 +1000

Hi James, sorry it's taken me a while to get back to you on this.

> Do you see any issues with this that I might have missed?

Nope, that's pretty much exactly the case that OptiDAD was 
designed for.

> response will get sent to the legitimate owner of the address.

Yeah, there's an assumption that "good" nodes greatly outnumber
"evil" nodes, so the potential harm from "good" nodes occasionally
spoofing packets is much more than the everpresent potential evil.

Optimistic Nodes won't 'steal' traffic ... they don't get into the
router's NC, so the router never misdirects traffic to them.  They
can send out packets from an address being used by an existing node,
and (in the case of a MIPv6 Binding Update, for example) this can
cause great wads of traffic to arrive at the existing node, but
there's pretty good odds that those packets will just get dropped
at their destination anyway.  And the existing node is obliged to
correct the optimistic node's error within 1000ms anyway.

This is where the statistical argument comes in.  Address collision
(very unlikely) multiplied by the probability of an accidentally
spoofed packet actually upsetting anything (very unlikely) equals ...

-----Nick