Re: [dhcwg] IESG Discusses/Comments on draft-ietf-dhc-dhcpv6-subid-00.txt

On Friday 20 January 2006 10:13, Bernie Volz (volz) wrote:
> This option is NOT used by clients. It is used between relay agents and
> servers only. Thus, there is no issue regarding roaming (unless of
> course the relay agents and servers are in different administrative
> domains, but in this case there is likely some agreement between these
> domains and the relay would likely only forward the information to the
> appropriate server(s)).

Just to be clear, there are two different kinds of DHCPv6 packets - a naked 
packet from a client, and a relay packet from or two a relay agent, which 
encapsulates a naked packet from the client.   This option can only appear in 
the relay agent portion of the packet.   You guys have all read RFC3315, but 
memories fade, so I thought it might be worth pointing this out.

It _is_ possible for a DHCP client to construct a relay packet and send it to 
a relay.  That relay might forward the packet to the server.   Likewise, a 
client can construct a relay packet and send it directly to the server 
(although getting a response back would be problematic).   DHCPv6 allows 
multiple relay encapsulation, so there's no denying that it's possible to 
spoof an ID using the mechanism described here.

In practice, though, there are problems with this.   The likely result of this 
would be an error - the client would not get a valid configuration, and would 
not be able to use the network.   The worst that might happen is that if a 
client successfully perpetrated this attack, another client might experience 
a denial of service because the DHCP server might not be willing to hand out 
additional IP addresses to the same remote ID.

This still wouldn't be a problem if the DHCP server is managing the client's 
address space, because any attempt to exhaust a /48 would simply overwhelm 
the server, which you can do without using the remote ID option.   It would 
be a problem with prefix delegations, though, since presumably the ISP isn't 
going to assign an unlimited number of /48's to every subscriber.

However, protecting the remote ID by making it secret isn't necessary.   The 
DHCPv6 protocol defines a shared secret-based authentication mechanism, and 
furthermore it's possible for the relay agent and server to do IPsec, and to 
use IPsec to prove that the remote ID was inserted by the relay agent, not a 
client.

So I think the fix for this is to mention in the security considerations 
section that DHCPv6 servers and relay agents SHOULD use shared-secret-based 
authentication in cases where this option is used, and that in particular 
DHCPv6 servers SHOULD ignore the contents of this option if these contents 
have not been verified using shared-secret-based authentication or some other 
kind of secure authentication.

This still leaves open a possible hole if the DHCPv6 client sends a 
relay-forward packet to the DHCPv6 relay agent, but the DHCPv6 relay agent 
doesn't insert its own remote ID option.   However, in this case the server 
is not expecting a remote ID option, so I think this is okay.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg