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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Oct 2010 09:03:48 -0500

The language in the draft is rather restrictive as it may be easy for
future option definitions to "forget" to indicate that they are
RSOO-enabled. It might be more appropriate to require future options to
indicate they are RSOO-disabled?

In either case, it seems as if a list of options would be required
(either those that are RSOO-enabled or RSOO-disabled) for the options
that IANA has assigned to date?

My concern was that we need to be sure that a certain class of options
are NEVER included in these RSOO options. The problem is describing that
class of options.

Be nice if we could just same something like ...

"The Relay Agent and DHCP server MUST NOT include options that are meant
to be processed and constructed by the DHCP server in its course of
processing to assign client specific resources (such as the IA_NA,
IA_TA, IA_PD, AUTH, FQDN, etc. options). In general, allowed options are
those that contain basic configuration parameters that do not usually
resources that are specific to a single client."

Perhaps someone has better wording to suggest.

We could certainly generate a list of the prohibited options defined
today.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Oct 2010 10:57:04 -0700

> indicate they are RSOO-disabled?

It seems unlikely that a draft with a mistake like this would mAke it all the way through the review process without the mistake being corrected. Do you really think that's likely? 

> that IANA has assigned to date?

This means that nearly every option specification written by this working group will need to label the option as not appropriate for RSOO. This seems much more prone to error than the current proposal.
 
> are NEVER included in these RSOO options. The problem is describing that

Sure, but the easiest way to describe at class is by making it default to everything, and require exceptions.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Oct 2010 13:21:33 -0500

I guess the 'default' for options comes down to which we expect to be
more common in the future and which if the document forgets to mention
it does more harm? And which reduces problems with older implementations
that may not know about certain options. Also, by "harm" here it only
does harm if configured in the relay and the server makes use of them in
what it delivers to the client ... a server should have a capability to
configure either the options allowed or disallowed.

I'm thinking you're thinking that there are few options that would be
RSOO-enabled? I would have expected most options that are not client to
server data or client resource assigning would be RSOO-enabled (which is
thus a larger list in the future based on the more commonly defined new
options).

As I think it will be required for the document, can we get a list of
the options that are RSOO-enabled (or those that are RSOO-disabled)?

Here's my quick pass based on the IANA registered options (I didn't go
looking up each option to assure I was correct about how it is used so
I'm CERTAIN this list has errors) ...

Disabled	1	OPTION_CLIENTID	[RFC3315]
Disabled	2	OPTION_SERVERID	[RFC3315]
Disabled	3	OPTION_IA_NA	[RFC3315]
Disabled	4	OPTION_IA_TA	[RFC3315]
Disabled	5	OPTION_IAADDR	[RFC3315]
Disabled	6	OPTION_ORO	[RFC3315]
Disabled	7	OPTION_PREFERENCE	[RFC3315]
Disabled	8	OPTION_ELAPSED_TIME	[RFC3315]
Disabled	9	OPTION_RELAY_MSG	[RFC3315]
(Disabled)	10	Unassigned	
Disabled	11	OPTION_AUTH	[RFC3315]
Disabled	12	OPTION_UNICAST	[RFC3315]
Disabled	13	OPTION_STATUS_CODE	[RFC3315]
Disabled	14	OPTION_RAPID_COMMIT	[RFC3315]
Disabled	15	OPTION_USER_CLASS	[RFC3315]
??		16	OPTION_VENDOR_CLASS	[RFC3315]
??		17	OPTION_VENDOR_OPTS	[RFC3315]
Disabled	18	OPTION_INTERFACE_ID	[RFC3315]
Disabled	19	OPTION_RECONF_MSG	[RFC3315]
Disabled	20	OPTION_RECONF_ACCEPT	[RFC3315]
Enabled	21	SIP Servers Domain Name List	[RFC3319]
Enabled	22	SIP Servers IPv6 Address List	[RFC3319]
Enabled	23	DNS Recursive Name Server Option	[RFC3646]
Enabled	24	Domain Search List option	[RFC3646]
Disabled	25	OPTION_IA_PD	[RFC3633]
Disabled	26	OPTION_IAPREFIX	[RFC3633]
Enabled	27	OPTION_NIS_SERVERS	[RFC3898]
Enabled	28	OPTION_NISP_SERVERS	[RFC3898]
Enabled	29	OPTION_NIS_DOMAIN_NAME	[RFC3898]
Enabled	30	OPTION_NISP_DOMAIN_NAME	[RFC3898]
Enabled	31	OPTION_SNTP_SERVERS	[RFC4075]
Enabled?	32	OPTION_INFORMATION_REFRESH_TIME	[RFC4242]
Enabled	33	OPTION_BCMCS_SERVER_D	[RFC4280]
Enabled	34	OPTION_BCMCS_SERVER_A	[RFC4280]
		35	Unassigned	
Enabled	36	OPTION_GEOCONF_CIVIC	[RFC4776]
Disabled	37	OPTION_REMOTE_ID	[RFC4649]
Disabled	38	OPTION_SUBSCRIBER_ID	[RFC4580]
Disabled	39	OPTION_CLIENT_FQDN	[RFC4704]
Enabled	40	OPTION_PANA_AGENT	[RFC5192]
Enabled	41	OPTION_NEW_POSIX_TIMEZONE	[RFC4833]
Enabled	42	OPTION_NEW_TZDB_TIMEZONE	[RFC4833]
Disabled	43	OPTION_ERO	[RFC4994]
Disabled	44	OPTION_LQ_QUERY	[RFC5007]
Disabled	45	OPTION_CLIENT_DATA	[RFC5007]
Disabled	46	OPTION_CLT_TIME	[RFC5007]
Disabled	47	OPTION_LQ_RELAY_DATA	[RFC5007]
Disabled	48	OPTION_LQ_CLIENT_LINK	[RFC5007]
Enabled	49	OPTION_MIP6_HNINF	[RFC-ietf-mip6-hiopt-17]
Enabled	50	OPTION_MIP6_RELAY	[RFC-ietf-mip6-hiopt-17]
Enabled	51	OPTION_V6_LOST	[RFC5223]
Enabled	52	OPTION_CAPWAP_AC_V6	[RFC5417]
Disabled	53	OPTION_RELAY_ID	[RFC5460]
Enabled	54	OPTION-IPv6_Address-MoS	[RFC5678]
Enabled	55	OPTION-IPv6_FQDN-MoS	[RFC5678]
Enabled	56	OPTION_NTP_SERVER	[RFC5908]
Enabled	57	OPTION_V6_ACCESS_DOMAIN	[RFC5986]
Enabled	58	OPTION_SIP_UA_CS_LIST
[RFC-lawrence-sipforum-user-agent-config-03]
Disabled	59	OPT_BOOTFILE_URL	[RFC5970]
Disabled	60	OPT_BOOTFILE_PARAM	[RFC5970]
Disabled	61	OPTION_CLIENT_ARCH_TYPE	[RFC5970]
Disabled	62	OPTION_NII	[RFC5970]

Newer options are much more likely (IMHO) be enabled because they are
non-core protocol, configuration options. Obviously options that
communicate client data (client to server) are always disabled.

But, it really isn't a big deal either way ... as whichever way we go
there will be potential issues. I guess I'm on the side of saying if you
trust your relays, why not trust them and hence err on the side of
allowing new options rather than requiring servers to be reconfigured
when new options are needed.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, October 01, 2010 1:57 PM
To: Bernie Volz (volz)
Cc: Andre Kostur; Qin Wu; [email-masked]
Subject: Re: [dhcwg]
I-DAction:draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt

> indicate they are RSOO-disabled?

It seems unlikely that a draft with a mistake like this would mAke it
all the way through the review process without the mistake being
corrected. Do you really think that's likely? 

> that IANA has assigned to date?

This means that nearly every option specification written by this
working group will need to label the option as not appropriate for RSOO.
This seems much more prone to error than the current proposal.
 
> are NEVER included in these RSOO options. The problem is describing
that

Sure, but the easiest way to describe at class is by making it default
to everything, and require exceptions.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Oct 2010 11:34:08 -0700

> communicate client data (client to server) are always disabled.

Okay, now I understand why you think we need a list.  You think this option is for something other than what it is intended for. The goal of this option is to prove a communications path for options specifically designed to be conveyed from the relay agent to the client.  It is emphatically NOT to provide a general mechanism whereby the relay agent can provide arbitrary configuration information for the client. 

Do you actually think it ought to be a more general mechanism, or were you just assuming that was how it was intended to be used?   Do you think the abstract or the introduction leads the reader to think it is intended for that purpose?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Oct 2010 14:53:57 -0500

While the document does provide one example in the introduction:

                              For example, the DHCP client may need to
   learn the EAP local domain name [I.D-ietf-hokey-ldn-discovery] for
   use in EAP re-authentication [RFC5296], which is known to the relay
   agent but not the server.

But it is otherwise indicates nothing about what this means for existing
options that IANA has already defined.

If this is specifically NOT intended to be used for any existing
options, why doesn't the document state this clearly?

Wouldn't is be best to add to the IANA considerations section something
like:

   IANA is requested to set up a new DHCPv6 registry for options allowed
   to be supplied by relays. That registry is defined to be empty
   (excepting any current or future documents that define options to be
   added to this registry). ... add more about how registry is managed
...

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, October 01, 2010 2:34 PM
To: Bernie Volz (volz)
Cc: Andre Kostur; Qin Wu; [email-masked]
Subject: Re: [dhcwg]

> communicate client data (client to server) are always disabled.

Okay, now I understand why you think we need a list.  You think this
option is for something other than what it is intended for. The goal of
this option is to prove a communications path for options specifically
designed to be conveyed from the relay agent to the client.  It is
emphatically NOT to provide a general mechanism whereby the relay agent
can provide arbitrary configuration information for the client. 

Do you actually think it ought to be a more general mechanism, or were
you just assuming that was how it was intended to be used?   Do you
think the abstract or the introduction leads the reader to think it is
intended for that purpose?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Oct 2010 15:09:51 -0500

> options, why doesn't the document state this clearly?

I thought it had been stated clearly--that's why I was surprised by your interpretation.

The IANA registry is an interesting idea.   It seems a little bit outside of the bailiwick of the IANA, but I admit I don't read IANA registries very often, so I may be missing something.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Oct 2010 15:39:06 -0500

> I thought it had been stated clearly--that's why I was surprised by
your interpretation.

I could easily see some of the options where a relay might be configured
with local policy that it wants to override ... for example, if I want
to use a specific domain search list or a set of (internal) DNS servers,
these seem like valid uses of this capability? Sure, I might be able to
have the DHCP server administrator configure these for the networks
serviced by the relay, but that might be in a different administrative
domain and not something they'd want to keep managing.

Of course, this might require bending the rules a bit:

   If the server receives an RSOO and is configured to accept it, it
   SHOULD add any options that appear in the RSOO for which it has no
   internal candidate to the list of options that are candidates to send
   to the DHCP client.  The server SHOULD discard any options that
   appear in the RSOO for which it already has one or more candidates.
   If the server receives more than one RSOO, it SHOULD not foward
   multiple versions of the same option from different RSOOs to the DHCP
   client.

So you'd have to get the DHCP administrator to unconfigure these items
for the networks serviced by the relay.

But, apparently that usage is outside the bounds of this draft ... 

If this is just about the EAP stuff, why not have an EAP specific Relay
Option that communicates this rather than a very general purpose
mechanism?? Avoids a lot of these issues and questions?

BTW: The above text from the draft brings up an old issue ... if relay
chaining is in use, and multiple relays in the chain include RSOO, what
is the default order for processing these multiple RSOOs (a DHCP server
could always allow for policy to override). This was never clarified
with respect to the link-address field in the Relay-Forw's in 3315
(though there likely closest relay to the client out makes sense because
the link-address closest to the client is likely the correct one).

As a nit, if you stick with the general purpose option, the use of
"suboptions" is a bit confusing in 3. Encoding. I'd recommend you follow
the convention in RFC 3315 (such as 22.4 and 22.5) and use
"RSOO-options" instead of "suboptions".

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, October 01, 2010 4:10 PM
To: Bernie Volz (volz)
Cc: Andre Kostur; Qin Wu; [email-masked]
Subject: Re: [dhcwg]

> options, why doesn't the document state this clearly?

I thought it had been stated clearly--that's why I was surprised by your
interpretation.

The IANA registry is an interesting idea.   It seems a little bit
outside of the bailiwick of the IANA, but I admit I don't read IANA
registries very often, so I may be missing something.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Oct 2010 14:20:09 -0400

On Oct 1, 2010, at 4:39 PM, Bernie Volz (volz) wrote:
> these seem like valid uses of this capability?

Essentially what you are saying is that it might be worthwhile in some cases to configure the DHCP server by storing configuration on individual routers toward the edge of the network.   By comparison, the application we have in mind is for a situation where the router has acquired information about the client during the layer two authentication/authorization process that it wants to share with the client.   This mechanism provides a communications path to the client that solves the problem nicely.   So it's really quite a different situation.

Does what you are talking about make sense?   I guess so--I can see how you might run a network that way.   But it's a very different application.   And nobody does it that way now, nor does anybody expect to.   Furthermore, we haven't thought through the security implications, and I think they are significant.   It's because of the security implications that I want to keep this draft as small and targeted as possible.   The mere *possibility* that this might be useful in the case you describe is not (IMHO) a good enough reason to open such a large attack surface.   If you have a real use case, that's a different thing, but you haven't given us any indication that you do.

> for the networks serviced by the relay.

Camel.   Tent.   Nose.   The extra opening up of attack surface that you're suggesting is precisely why I don't want us to do this.   In order for this to be useful in the way you are proposing, I think it necessarily has to have relay agent authentication.

> mechanism?? Avoids a lot of these issues and questions?

The reason for having a generic mechanism is that there's another draft that's actually in the IETF publication queue that also depends on this sort of functionality, and that indeed defined a one-off solution.   Each such one-off solution requires special-case code in the DHCP server.   Hence, it makes sense to define a general mechanism for solving problems of this kind.

> the link-address closest to the client is likely the correct one).

Yeah, I added a bunch of text for this to the relay encapsulation for DHCPv4 draft.   I haven't reread RFC3315 to see how it compares.

> "RSOO-options" instead of "suboptions".

Good point, thanks!

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 4 Oct 2010 23:23:06 -0500

OK ...

I would like to see (though it is your call as to whether I will as they
wording may be tricky):

1. Improved description of the usage model for options that could be
considered RSOO options. The abstract, introduction and protocol summary
could be clearer that RSOO options should only be used for cases where
the relay has acquired information that needs to be delivered to the
client that the server would otherwise not be able to know. It is not a
mechanism for the relay to provide configuration that the server would
normally be configured with.

2. Please work in some text to be very clear that existing options are
all RSOO-disabled. It wasn't that clear to me that this was the case
(though I do fully agree that as the document says "Unless specifically
called out as an RSOO-enabled option, no DHCP option should appear in an
RSOO."

I think requesting an IANA registry for these is also a good idea as it
assures that there is one place we can go to see what the list of
RSOO-enabled options are, rather than having to look through various
RFCs? If IANA is unwilling to do this, then we can take it out.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, October 04, 2010 2:20 PM
To: Bernie Volz (volz)
Cc: Andre Kostur; Qin Wu; [email-masked]
Subject: Re: [dhcwg]

> these seem like valid uses of this capability?

Essentially what you are saying is that it might be worthwhile in some
cases to configure the DHCP server by storing configuration on
individual routers toward the edge of the network.   By comparison, the
application we have in mind is for a situation where the router has
acquired information about the client during the layer two
authentication/authorization process that it wants to share with the
client.   This mechanism provides a communications path to the client
that solves the problem nicely.   So it's really quite a different
situation.

Does what you are talking about make sense?   I guess so--I can see how
you might run a network that way.   But it's a very different
application.   And nobody does it that way now, nor does anybody expect
to.   Furthermore, we haven't thought through the security implications,
and I think they are significant.   It's because of the security
implications that I want to keep this draft as small and targeted as
possible.   The mere *possibility* that this might be useful in the case
you describe is not (IMHO) a good enough reason to open such a large
attack surface.   If you have a real use case, that's a different thing,
but you haven't given us any indication that you do.

> for the networks serviced by the relay.

Camel.   Tent.   Nose.   The extra opening up of attack surface that
you're suggesting is precisely why I don't want us to do this.   In
order for this to be useful in the way you are proposing, I think it
necessarily has to have relay agent authentication.

> mechanism?? Avoids a lot of these issues and questions?

The reason for having a generic mechanism is that there's another draft
that's actually in the IETF publication queue that also depends on this
sort of functionality, and that indeed defined a one-off solution.
Each such one-off solution requires special-case code in the DHCP
server.   Hence, it makes sense to define a general mechanism for
solving problems of this kind.

> the link-address closest to the client is likely the correct one).

Yeah, I added a bunch of text for this to the relay encapsulation for
DHCPv4 draft.   I haven't reread RFC3315 to see how it compares.

Good point, thanks!

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Oct 2010 07:19:19 -0700

> I would like to see (though it is your call as to whether I will as they

[...]

Okay, thanks!   I will issue a new draft with changes to address what you've asked for.   I think you're right about the IANA--the worst that can happen is that they make us take out that requirement.   :)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Oct 2010 20:43:32 -0700

I've issued a new version of the RSOO draft.   This addresses comments made by Bernie Volz and Andre Kostur.

In particular, I've tried to make it clearer that this is a specific solution for specific and restricted protocol needs, and not a general mechanism for conveying arbitrary DHCP options from the DHCP relay through the DHCP server to the DHCP client.   I've added an IANA registry that lists current options that are enabled for use in the RSOO (pending IANA's willingness to implement this list, of course).

Andre had commented that implications for relay agent authentication were not clear.   I actually took out all that text--I don't think it's needed.   Instead, I added text suggesting that relay agents should be configurable to drop Relay-Forward messages that contain the RSOO.   In this way, a network administrator could configure edge routers to drop packets containing RSOOs, which would prevent relay agents outside of the trusted portion of the network from overriding RSOOs provided by relay agents on the trusted portion of the network.

I also removed some extraneous language from the spec based on Andre's comment that I was proposing that the server maintain four lists of options that would have to be dropped.

I think the Security Considerations section is quite a bit tighter now, but would appreciate further comment.