Subject: [dhcwg] Comments on draft-jiang-dhc-secure-dhcpv6

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Nov 2009 11:03:38 +0900

Two things.   First, in the working group meeting you said that you decided not to use the existing authentication framework so as to leave the client the choice of using your protocol or using the existing auth protocols as documented in RFC3315.   This reason doesn't make sense to me: if the client wants to do the regular auth protocol, it can indicate this in its transmission to the server.   So I think it would be better to use the existing authentication framework as defined in RFC3315 for this CGA-based authentication solution.

Second, DHCPv6 clients are _required_ to use their link-local IP address when transmitting messages.   This means that the CGA address that will be used to authenticate the message from the client will have to be a link-local address.   Does CGA work with link-local addresses?  The draft doesn't mention this point, and I think it's very important to bring it up.   It would be wrong to solve the problem by eliminating or relaxing the restriction that the client use its link-local address for communication - that was a very deliberate choice.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 17 Nov 2009 17:48:32 +0800

Hi, Ted,

Our reply for your early message dhcwg had been flitered by the dhc mail
list for some reason. Resend it. Reply in lines.

Best regards,

Sheng & Sean

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Thursday, November 12, 2009 10:04 AM
> To: [email-masked]
> Subject: [dhcwg] Comments on draft-jiang-dhc-secure-dhcpv6
> 
> Two things.   First, in the working group meeting you said 
> that you decided not to use the existing authentication 
> framework so as to leave the client the choice of using your 
> protocol or using the existing auth protocols as documented 
> in RFC3315.   This reason doesn't make sense to me: if the 
> client wants to do the regular auth protocol, it can indicate 
> this in its transmission to the server.   So I think it would 
> be better to use the existing authentication framework as 
> defined in RFC3315 for this CGA-based authentication solution.

The CGA solution and auth option solution are quite different either in
concept or in functions. It's possible for a sender to use both the already
defined auth protocol and cga option signature in a dhcpv6 message 
so that receiver can check what he can or prefer for validation. If 
cga-parameters&signatures and auth data were both carried by auth
options, then just one can be used because dhcpv6 just allow one 
auth option. It's not surprising that auth option will be used for a long
time even forever and signature probably is not the only existing choice.
If a sender has both public key or authentication key and want to use 
both, he don't what to send multiple dhcpv6 messages using different
protections. Based on policy, a receiver may choose to only verify auth
option if he think it's enough and fast processing, or choose to verify
CGA address and signature for address authentication and better 
security. 
 
> Second, DHCPv6 clients are _required_ to use their link-local 
> IP address when transmitting messages.   This means that the 
> CGA address that will be used to authenticate the message 
> from the client will have to be a link-local address.   Does 
> CGA work with link-local addresses?  The draft doesn't 
> mention this point, and I think it's very important to bring 
> it up.   It would be wrong to solve the problem by 
> eliminating or relaxing the restriction that the client use 
> its link-local address for communication - that was a very 
> deliberate choice.

Yes, CGA can be link-local addresses (section 7.2 of rfc3972).

Best regards,

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