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

There's also the assumption that a relay-agent, that will relay the
message using IPsec, doesn't relay a relayed message except if received
from an IPsec secured relay (since the relays down the chain and the
server can't know which earlier hops were secured or not - except the
last). A relay-agent only relay's a client message and an IPsec secured
relay message? (There isn't anything that I found that explicitly states
this in RFC 3315, so perhaps something to consider as we advance the
document. Or do we feel that is naturally obvious.)

Regarding your other point:

> 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.

Isn't there inherently an assumption that a relay know whether it should
only be a first hop relay and thus ONLY relay client traffic (and not
relayed messages). This would be useful in both directions, since if so
configured, the relay would never want to relay a RELAY-REPLY either. (I
guess servers could also be told the maximum hops expected and drop
messages that have more than the maximum hops.)

- Bernie

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] 
> Sent: Friday, January 20, 2006 2:40 PM
> To: dhcwg@ietf.org
> Cc: Bernie Volz (volz); iesg@ietf.org
> Subject: 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