Subject: Re: [dhcwg] draft-forte-dhc-passive-dad-02

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jun 2006 10:46:54 -0700 (PDT)

Some questions about the proposal:

1. How does the client know that passive DAD is in operation so that it 
can avoid doing DAD? 
2. What if the DHCP server does not keep state in stable storage (like 
most home gateways), and reboots?  Couldn't the server still assign the 
same address to another host? 
3. What happens if a DHCP server learns of a conflict after it has 
assigned an address?

It seems that without #1, the protocol would only work in special 
situations (e.g. handsets configured for use on a particular network known 
to support pDAD). 

---------------------------------------------------------------------------
Dear all,

We have submitted the new version of the pDAD draft. You can find it here:
http://www.ietf.org/internet-drafts/draft-forte-dhc-passive-dad-02.txt

Some adjustments have been included in the IPv6 part, as discussed on the 
mailing list.
We are looking forward to comments and feedback.

Regards,
-Andrea

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 28 Jun 2006 11:57:43 -0700

> 1. How does the client know that passive DAD is in operation so that it 

Does it have to avoid doing DAD, or can it merely elide the check to
after binding to the address (if there is either an indication or a
presumption that pDAD is in use)?

Substantially, and at least for the forseeable future, I see pDAD as
a mechanism to help sysadmins keep control of their networks, and reduce
collisions for systems that do not perform DAD.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Andrea G Forte <[email-masked]>
Date: Wed, 28 Jun 2006 16:00:52 -0400

Please read inline.

> 1. How does the client know that passive DAD is in operation so that it 
I am assuming here you are referring to IPv6 since DAD is performed by 
the server in IPv4. We have not looked in detail at IPv6 issues as our 
draft is mainly about IPv4. I am not an IPv6 expert, however it seems 
that without defining any other extension or option, the client would 
not have any mean to know if pDAD is available or not.

> same address to another host? 
In this case we can have different approaches. One is, we choose a not 
too long expiration time for all the entries in the AUC table. This 
would reduce the vulnerability interval during which the DHCP server 
would not have such information after a reboot. Another option would be 
to define a message sent by the DHCP server to the AUC that would force 
the expiration (and immediate refresh) of all the entries in the AUC 
table. Another option could be to have the DHCP server ask the AUC to 
send the information again.
> 3. What happens if a DHCP server learns of a conflict after it has 
This can happen for example when the DHCP server assigns a legitimate 
(i.e. not used) IP address to a client and someone else, later on, 
decides to manually configure that same address. In this case we have a 
duplicate address situation. One of the things that we could do is to 
use a FORCERENEW message (rfc 3203) to trigger a renew of the IP address 
for the legitimate client. At the same time we could "block" that node 
at the switch and redirect it to a default web-page saying 
"Unauthorized" for example.

 From our paper:
"By using pDAD, the DHCP server has also much more control over the 
network. For example, the DHCP server could configure packet flow rules 
in the egress router that perform some actions to block the IP addresses 
that have been illegally acquired by some malicious MNs. Furthermore, 
some form of intrusion detection could also be implemented."
 
-Andrea

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jun 2006 13:20:48 -0700 (PDT)

> I am assuming here you are referring to IPv6 since DAD is performed by the
> server in IPv4. 

A number of DHCP clients also perform DAD in IPv4 (MacOS X, Windows, etc.)

Also, not all DHCP servers perform DAD. 

So, I'm not clear this is completely a server issue.

---

From: Andrea G Forte <[email-masked]>
Date: Wed, 28 Jun 2006 17:39:01 -0400

Actually, that is true, although I do not understand why there is this 
redundancy.
Probably a new option should be defined to tell the client if it needs 
to perform DAD or not. Something simple like:

 Code   Len  Value
+-----+-----+-----+
|  xx |  1  | 0/1 |
+-----+-----+-----+

this would also help in the case in which the server is already 
performing the normal DAD (without any pDAD).
Suggestions are welcome.

-Andrea

---

From: Andrea G Forte <[email-masked]>
Date: Wed, 28 Jun 2006 17:38:53 -0400

> presumption that pDAD is in use)?
This is a good point. I guess you could follow either approach. Is there 
a reason to prefer one rather than the other?

-Andrea

> ------------------------------------------------------------------------
>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 28 Jun 2006 16:53:06 -0700

> a reason to prefer one rather than the other?

Doing DAD before binding is not a bet.  You're dead sure, to the extent
you reasonably can be, there isn't a collision.

Eliding DAD after binding is hedging a bet: you're betting the server
is likely to know about conflicts beforehand.

So having an indication (or presumption) of wether the server is
involved in pDAD might be a consideration in choosing one of those
two.

---

From: Andrea G Forte <[email-masked]>
Date: Thu, 29 Jun 2006 15:15:57 -0400

Yes. I was actually looking at it in the other direction. Assuming that 
you have pDAD, either one of the two would work. Perhaps the second one 
(DAD after binding) would take care of those less common cases where 
there could be some vulnerability window right after a server reboots 
and before the AUC re-sends the information to the server.

-Andrea