Subject: [dhcwg] Request for Review on draft-ietf​-dhc-dhcpv​4-over-ipv​6-01

From: Peng Wu <[email-masked]>
Date: Thu, 22 Mar 2012 23:33:55 +0800

Hi WG,

I would like to request for more reviews on the DHCPv4 over IPv6
draft, and thank Tomek, Francis and the earlier reviewers for their
valuable inputs.

This draft describes a mechanism of allocating IPv4 addresses to
devices in IPv6 networks, for the usage of providing residual IPv4
service. The draft is motivated from IPv4-over-IPv6 tunneling
mechanisms in the Softwire WG. With the development of tunneling
mechanisms which require this DHCP feature (e.g., Public 4over6,
Lightweight 4over6, SD-NAT), we authors very much hope to improve the
draft, move forward it and possibly meet the timeline. We would really
appreciate it if you can provide your valuable comments.

Here is the link to the draft:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-01

Thanks!

----
Peng Wu

---

From: Alper Yegin <[email-masked]>
Date: Tue, 27 Mar 2012 18:06:34 +0300

Not that this draft is the source of this issue , but it certainly highlights the following:

RFC 3118 is not used. Sending security parameters over DHCP needs consideration.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Mar 2012 15:19:57 +0000

> RFC 3118 is not used. Sending security parameters over DHCP needs consideration.

Yes, we have pretty much given up on providing information like this in DHCP.   It doesn't make any sense to do so, because DHCP does not operate in controlled administrative domains.   Even if you authenticate the DHCP server, you still can't trust it to tell you what PKI server to talk to.

---

From: Cui Yang <[email-masked]>
Date: Wed, 28 Mar 2012 15:47:05 +0000

Hi, Ted and Alper,

Thanks for your reviews and comments.

The proposed DHCP option is aimed to help set up the security mechanism, i.e., carrying IP addresses of PKI server, etc. 
But the option itself does not need to be protected, or in other words, the security does not necessarily rely on the DHCP option.

The current usage of vendor-specific solution (option 43) for this problem is quite restricted, because of the usual limitations of requiring the client and server to understand these vendor-specific extensions. It is desired that security configuration has a new standardized option, since most parameters are common across most clients and servers.

Thanks,
Yang
________________________________________
发件人: Ted Lemon [[email-masked]]
发送时间: 2012年3月27日 23:19
到: Alper Yegin; dhc WG
主题: Re: [dhcwg] draft-bi-dhc-sec-option

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Mar 2012 16:30:50 +0000

> But the option itself does not need to be protected, or in other words, the security does not necessarily rely on the DHCP option.

So if a rogue DHCP server provides a PKI server address, the client will be able to tell that it is not a legitimate server without revealing sensitive information to it?

---

From: Cui Yang <[email-masked]>
Date: Wed, 28 Mar 2012 17:29:24 +0000

Yes, the client could find out that the PKI server it is talking with is not a valid one in this case, after running a mutual authentication.
A proof of possession method in X.509 [RFC4210,4211] could be used to avoid revealing the sensitive information.

BR,
Yang
________________________________________
发件人: Ted Lemon [[email-masked]]
发送时间: 2012年3月29日 0:30
到: Cui Yang; Alper Yegin; dhc WG
主题: RE: [dhcwg] draft-bi-dhc-sec-option