Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt

From: [email-masked]
Date: Wed, 29 Sep 2010 02:30:04 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title           : Relay-Supplied DHCP Options
	Author(s)       : T. Lemon, W. Wu
	Filename        : draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt
	Pages           : 7
	Date            : 2010-09-29

This document describes a general mechanism whereby a DHCPv6 relay
agent can provide options to a DHCPv6 server that the DHCPv6 server
can then provide to the DHCPv6 client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Qin Wu <[email-masked]>
Date: Wed, 29 Sep 2010 17:42:04 +0800

Hi, folsk:
The new version of draft-ietf-dhc-dhcpv6-relay-supplied-options-02 is available at:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt
We have addressed all your comments in the new 02 draft version that I
just posted. Please have a look at the new version to see whether you
agree with the changes.

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 29, 2010 5:30 PM
Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------------

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

---

From: Andre Kostur <[email-masked]>
Date: Wed, 29 Sep 2010 10:42:46 -0700

Reading over this draft it seems to me that it wants to strictly define which options are "RSOO-enabled" (section 4), then allow the admin to add more options to the list (section 6), and then still have a list of options that won't be considered anyway (last paragraph of section 6).  I think that just having a list of options on the server side that it is willing to reflect to the client would cover off all of the cases.  The server would (presumably) have some default list of what are acceptable RSOO options (perhaps defaulting to empty), and the admin can add whichever options they so choose as per documentation of whichever relay they were using.  I think this "opt-in" method of choosing RSOO is better than having to supply a list of RSOO options, and then a list of options to suppress.

More in section 6: it seems to acknowledge the possibility of a message which may have passed through multiple relays, each with the potential to add their own RSOO options, but does not make mention as to which order to process them in, or to even move that decision off as a policy decision on the server.

I also think that the second half of section 5 is superfluous.  That simply describes relay agent behaviour  that already has been defined in RFC 3315.

For section 7: This section talks about authenticating between a trusted relay and the server.  What about a case where an attacker interposes a relay between the client and the first trusted relay?  You could end up with client -> untrusted relay (which adds certain RSOO) -> trusted relay -> server.  At this point the server now has RSOOs which may be used to compose the client response, which the server signs, and then sends back through the same path.  Perhaps the server would need a list of which RSOOs it is willing to reflect from particular relays?  In this case the server wouldn't be willing to reflect any of the RSOOs supplied by the untrusted relay, but should the trusted relay wish to add RSOOs it could.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Sep 2010 11:07:22 -0700

> Reading over this draft it seems to me that it wants to strictly define which options are "RSOO-enabled" (section 4), then allow the admin to add more options to the list (section 6), and then stil…

Originally we decided not to enumerate a list of excluded options because it would be difficult to come up with a list.   Then we thought to add a configuration mechanism to exclude options.   This raised some objections, so the latest plan was to simply exclude all options that aren't explicitly defined as being included (the RSOO-enabled) solution.

Having done that, the point of the configuration option is simply to allow the list of RSOO-enabled options to be modified by the administrator in the event that a new RSOO-enabled option is defined and deployed, but the DHCP server predates the definition of that option, and thus doesn't list it.

The language in the draft may need some tweaking to remove obsolete language--from your description it sounds like I missed some.   But that's the intent--the intent is not to have the list of RSOO-enabled options vary on a site-by-site basis.

> More in section 6: it seems to acknowledge the possibility of a message which may have passed through multiple relays, each with the potential to add their own RSOO options, but does not make menti…

D'oh, sorry.   Somebody pointed this out in the previous version of the draft, and we forgot to address it.

> I also think that the second half of section 5 is superfluous.  That simply describes relay agent behaviour  that already has been defined in RFC 3315.

Agreed.

> For section 7: This section talks about authenticating between a trusted relay and the server.  What about a case where an attacker interposes a relay between the client and the first trusted relay…

In the case where an attacker interposes a relay between a trusted relay and the server, the relay will presumably still be there when the reply comes back.   That being the case, the relay can simply modify the packet to add the option it wants to add, rather than offering the option to the server to add.

If the message from the server is not signed, there's nothing to stop this happening. If the message *is* signed, then indeed the rogue relay agent would have a new opportunity to inject any RSOO-enabled option it wanted into the response going to the client, and that response would bear the server's signature and thus would validate.   

In this situation, the site administrator would do well to make sure that traffic between the relay and the server was signed, and to either skip relay options that weren't signed, or else drop messages containing such options.

It was the intent of the text in section seven to indicate that this should be done.   I think that's what the third paragraph in section 7 says to do.  It sounds like you came away with a different impression from reading the text, though--would you say that we should make it more explicit, or change the SHOULD to a MUST, or something like that?

---

From: Andre Kostur <[email-masked]>
Date: Wed, 29 Sep 2010 12:06:16 -0700

> In the case where an attacker interposes a relay between a trusted relay and the server, the relay will presumably still be there when the reply comes back.   That being the case, the relay can sim…

I was suggesting that the attacker was interposing a relay between the client and the trusted relay, not between the trusted relay and the server.

> If the message from the server is not signed, there's nothing to stop this happening. If the message *is* signed, then indeed the rogue relay agent would have a new opportunity to inject any RSOO-e…

Yep, the draft acknowledges that if the message isn't signed from the server, then the malicious relay can add whatever it wants.

Section 7 seems to cover the case of client + relay + server pretty well.  In this scenario, section 7 outlines that you need to secure your relay -> server communication otherwise a malicious relay could inject RSOOs which the server would sign.   When you add in the additional complication that each relay along the path could add RSOOs, you could end up with an untrusted relay sending a message to the trusted relay, which then sends it to the server.  The server would validate that the source of the received message is the trusted relay and thus would process the message.  It would pick up both sets of RSOOs (assuming that the trusted relay also added some RSOOs) and compose the client response and sign it. 

Perhaps this hole could be covered off with some text around if the admin is configuring the system such that the server is authenticating the relay, that the admin would also have to configure the relay to authenticate any further downstream relays as well for the same reasons (and/or reject any untrusted relays).

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Sep 2010 14:08:21 -0700

> I was suggesting that the attacker was interposing a relay between the client and the trusted relay, not between the trusted relay and the server.

Sorry, that's what I meant to say.
> Perhaps this hole could be covered off with some text around if the admin is configuring the system such that the server is authenticating the relay, that the admin would also have to configure the…

The expectation is that the DHCP server will authenticate the relay, not the next relay up the chain.   That being the case, if any relay agent encapsulation is not authenticated, the server ought either to ignore that encapsulation, or else ignore the RSOO in that encapsulation, if any, or simply discard the packet.   The fact that we're still talking about this suggests that we should add some more text to say that explicitly.   :')

Based on your lack of comment on the other parts of my response, should I assume that you are satisfied with those aspects of the response?

---

From: Andre Kostur <[email-masked]>
Date: Wed, 29 Sep 2010 14:28:46 -0700

> The expectation is that the DHCP server will authenticate the relay, not the next relay up the chain.   That being the case, if any relay agent encapsulation is not authenticated, the server ought…

Your wording seems to lead to some confusion. "The expectation is that the DHCP server will authenticate the relay, not the next relay up the chain.".  We're talking about multiple relays in the picture.  Which relay does "the relay" refer to?   Or perhaps did you mean to say "all relays" instead of "the relay"?

> Based on your lack of comment on the other parts of my response, should I assume that you are satisfied with those aspects of the response?

I guess the part I'm not sold on is where the DHCP server would have to have 4 lists of options to deal with: the default list of RSSO options that were known at the time the service was built, any RSSO options that the admin chooses to add (presumably as they were unknown at the time the service was built), the list of options that the admin does not want to respect, and the list of options that was determined to never reflect.   Granted, the service merges these lists together eventually, but there's two lists that the admin has control over.   I'm suggesting that this only be one list which the admin lists which options he chooses to enable.

---

From: Qin Wu <[email-masked]>
Date: Thu, 30 Sep 2010 10:50:02 +0800

[Qin]: Yeah, if we need to take multiple relays into consideration, we have to address two typical cases from security perspective:
case a.  client ->trusted relay->rogue relay->server 
case b.   client-> rogue relay->trusted relay->server
for case a, it can be easily addressed by securing trusted relay and the server communciation using signing.
for case b, rogue relay may inject one RSOO into the message sent to trusted relay. if the trust 
relay don't authenticate the message from rogue relay and just forward the message to the server. the server 
may pick up the RSOO injected by rogue  and extract the option in this RSOO and send to the client. I think
we need to prevent this happen.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Sep 2010 20:52:23 -0700

> we need to prevent this happen.

Yup, Andre is right about how to solve this.  I will add some text to the document to address this case.