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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 20 Jan 2006 17:17:19 -0500

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:[email-masked]] 
> Sent: Friday, January 20, 2006 2:40 PM
> To: [email-masked]
> Cc: Bernie Volz (volz); [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Jan 2006 20:38:51 -0700

> document. Or do we feel that is naturally obvious.)

Generally speaking, if you state something clearly and explicitly in an RFC, 
there is a *chance* that all implementors will understand what you meant.   
If you don't state that thing in an RFC, there is a *chance* that a few 
implementors will understand what you meant or ask you.   So of the two 
options, I think being explicit is better.

> relayed messages). 

No, there's no such assumption.

> This would be useful in both directions, since if so 

That seems balky.   I like your first suggestion better.   In general I think 
it might be challenging to completely specify the behaviour you're suggesting 
here.

I hate to say it, given where we are in the process, but it might be better to 
require that a relay-forward option in a DHCPv6 packet that is itself being 
authenticated must always indicate whether or not the message being relayed 
was authenticated.  This would have to be done via a new option we haven't 
talked about yet.

I don't know if this is necessary, though - perhaps it's enough to simply 
explain the problem in the security considerations section and let the 
administrator impose a solution locally, which I think is basically what 
you're saying here.