Subject: [dhcwg] Should the DHC working group work on draft-lemon-dhcpv6-relay-supplied-options?

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Apr 2010 16:45:26 -0700

I'm asking for review of a short (three-page) draft I submitted during IETF 77 to address a problem that was raised as a result of my review of a draft that the Mobile IPv6 working group did a couple of years ago -- draft-ietf-mip6-hiopt.   The draft was in the RFC editor queue when I found the problem, so this is kind of a last-minute thing, but the problem was significant.

The problem is that the hiopt draft introduces an option that relay agents can send that the server will then turn around and send back to the client.   This seems like a useful capability, but the hiopt draft does it in a very application-specific way rather than coming up with a solution that could be generalized for use in other DHCP relay agent options.

So I wrote up a draft describing how to do it in a more general way.   I mentioned it in the meeting at IETF, and there seemed to be consensus that we should adopt it as a working group item, so this is my call for adoption.   If you are in favor of adoption, please say so.   If you are against, please say why.

The draft is at:

	http://tools.ietf.org/html/draft-lemon-dhcpv6-relay-supplied-options-00

The hiopt draft is at:

	http://tools.ietf.org/html/draft-ietf-mip6-hiopt-17

The hiopt draft has been sitting in the RFC editor queue since 2008 with this bug in it, and if we don't do something about it quickly, I think there's going to be a justifiably high degree of pressure to just publish it as is, so I'd really appreciate it if people could take a look at it.

I apologize for taking so long to issue this call for adoption--things have been busy, and it took Ralph reminding me of the stalled hiopt draft to trigger this request.

---

From: Frank Xia <[email-masked]>
Date: Fri, 23 Apr 2010 09:48:55 -0500

Hi Ted

Yes, we should take on this work.

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
Sent: Thursday, April 22, 2010 6:45 PM
To: [email-masked] Group
Subject: [dhcwg] Should the DHC working group work
ondraft-lemon-dhcpv6-relay-supplied-options?

I'm asking for review of a short (three-page) draft I submitted during IETF
77 to address a problem that was raised as a result of my review of a draft
that the Mobile IPv6 working group did a couple of years ago --
draft-ietf-mip6-hiopt.   The draft was in the RFC editor queue when I found
the problem, so this is kind of ae last-minute thing, but the problem was
significant.

The problem is that the hiopt draft introduces an option that relay agents
can send that the server will then turn around and send back to the client.
This seems like a useful capability, but the hiopt draft does it in a very
application-specific way rather than coming up with a solution that could be
generalized for use in other DHCP relay agent options.

So I wrote up a draft describing how to do it in a more general way.   I
mentioned it in the meeting at IETF, and there seemed to be consensus that
we should adopt it as a working group item, so this is my call for adoption.
If you are in favor of adoption, please say so.   If you are against, please
say why.

The draft is at:

The hiopt draft is at:

The hiopt draft has been sitting in the RFC editor queue since 2008 with
this bug in it, and if we don't do something about it quickly, I think
there's going to be a justifiably high degree of pressure to just publish it
as is, so I'd really appreciate it if people could take a look at it.

I apologize for taking so long to issue this call for adoption--things have
been busy, and it took Ralph reminding me of the stalled hiopt draft to
trigger this request.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 Apr 2010 16:13:34 -0500

Ted:

I'm fine with this being adopted as a WG item.

In terms of the review, I have some relatively minor comments:

- Section "3. Encoding" ... be nice if a more standard option definition
diagram were used (as in RFC 3315 and other RFCs and current drafts).

- Section "4. DHCP Relay Agent Behavior" ... why include the statement:

   Relay agents MUST NOT
   modify the contents of any message before forwarding it to the DHCP
   client.

What is meant by "any message"? My recommendation is to drop this
sentence. Perhaps this is because of text in the draft-ietf-mip6-hiopt
draft? But I don't think we want to change/clarify anything specific to
RFC 3315 here and thus I think this is a bad statement to have in this
draft.

- Section "5. DHCP Server Behavior"

I could see that a server could have several different kinds of policies
here:

1. To accept only certain RSOO options (rather than all or nothing).
This is more useful as there may be cases where an option should not be
supplied even when there is no "internal candidate". Perhaps this can be
reworded to say that a server MUST provide a means to discard either all
RSOO options or limit those options it will use contained in an RSOO
option. This also avoids problems for the relay injecting options that
the server knows nothing about and hence has no "internal candidate". I
also wonder whether there might be a need to have a list of options that
should NEVER be used from a received RSOO (such as Rapid Commit, Auth,
Server Unicast?, IA_*, IAADDR/IAPREFIX, ...) -- though this might be
painful to maintain.

This probably even argues for a REQUIREMENT to configure the DHCP server
with options from a RSOO that it will allow (or at least NOT allow).

Though I guess we could all just agree that that is overkill as the
relays and servers are usually under the same administrative domain.

2. Even if we do a simple ON/OFF setting, the server's default likely
should be OFF (to ignore RSOO).

3. To use a RSOO supplied option in certain cases even when it has an
"internal candidate". But, I guess the "SHOULD" in the text regarding
this processing allows for this.

- Section "6. Security Considerations"

   However, it is still possible in
   some configurations for a rogue DHCP server to supply additional
   options to the DHCP client.

Did you mean rogue DHCP relay? Based on the 2 paragraphs that follow,
that makes the most sense?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ted Lemon
Sent: Thursday, April 22, 2010 7:45 PM
To: [email-masked] Group
Subject: [dhcwg] Should the DHC working group work
ondraft-lemon-dhcpv6-relay-supplied-options?

I'm asking for review of a short (three-page) draft I submitted during
IETF 77 to address a problem that was raised as a result of my review of
a draft that the Mobile IPv6 working group did a couple of years ago --
draft-ietf-mip6-hiopt.   The draft was in the RFC editor queue when I
found the problem, so this is kind of a last-minute thing, but the
problem was significant.

The problem is that the hiopt draft introduces an option that relay
agents can send that the server will then turn around and send back to
the client.   This seems like a useful capability, but the hiopt draft
does it in a very application-specific way rather than coming up with a
solution that could be generalized for use in other DHCP relay agent
options.

So I wrote up a draft describing how to do it in a more general way.   I
mentioned it in the meeting at IETF, and there seemed to be consensus
that we should adopt it as a working group item, so this is my call for
adoption.   If you are in favor of adoption, please say so.   If you are
against, please say why.

The draft is at:

The hiopt draft is at:

The hiopt draft has been sitting in the RFC editor queue since 2008 with
this bug in it, and if we don't do something about it quickly, I think
there's going to be a justifiably high degree of pressure to just
publish it as is, so I'd really appreciate it if people could take a
look at it.

I apologize for taking so long to issue this call for adoption--things
have been busy, and it took Ralph reminding me of the stalled hiopt
draft to trigger this request.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Apr 2010 14:29:32 -0700

Bernie, excellent comments, as usual!

I think it might be worth specifying a list of options that the relay agent should never send, and that the server should always ignore when processing RS options.   Even though we can't anticipate future options, I think you're right to be concerned about relays providing options that it would be an error for the DHCP server to forward, whether due to misfeasance or malfeasance.

I got some private comments from a co-Nominite who has yet to weigh in publicly, and based on your comments and his, I'll update the draft.   I'll wait a few days before publishing a new version though in case there are more comments.

Thanks for the quick response!

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 24 Apr 2010 09:31:22 +0700

> Yes, we should take on this work.

+1

> Of
> IETF
> found
> agents
> that
> publish it
> have

---

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 24 Apr 2010 10:27:05 -0700 (PDT)

+1 for adoption of the draft as WG draft.

----- Original Message ----
> From: Ted Lemon <[email-masked]>
> To: "[email-masked] Group" <[email-masked]>
> Sent: Thu, April 22, 2010 6:45:26 PM
> Subject: [dhcwg] Should the DHC working group work on draft-lemon-dhcpv6-relay-supplied-options?
> 
> I'm asking for review of a short (three-page) draft I submitted during IETF 77 
> to address a problem that was raised as a result of my review of a draft that 
> the Mobile IPv6 working group did a couple of years ago -- 
> the problem, so this is kind of a last-minute thing, but the problem was 
> significant.

The problem is that the hiopt draft introduces an option 
> that relay agents can send that the server will then turn around and send back 
> to the client.   This seems like a useful capability, but the hiopt draft 
> does it in a very application-specific way rather than coming up with a solution 
> that could be generalized for use in other DHCP relay agent options.

So I 
> wrote up a draft describing how to do it in a more general way.   I 
> mentioned it in the meeting at IETF, and there seemed to be consensus that we 
> should adopt it as a working group item, so this is my call for adoption.  
> If you are in favor of adoption, please say so.   If you are against, 
> please say why.

> http://tools.ietf.org/html/draft-lemon-dhcpv6-relay-supplied-options-00

The 
> hiopt draft is at:

> http://tools.ietf.org/html/draft-ietf-mip6-hiopt-17

The hiopt draft has 
> been sitting in the RFC editor queue since 2008 with this bug in it, and if we 
> don't do something about it quickly, I think there's going to be a justifiably 
> high degree of pressure to just publish it as is, so I'd really appreciate it if 
> people could take a look at it.

I apologize for taking so long to issue 
> this call for adoption--things have been busy, and it took Ralph reminding me of 
> the stalled hiopt draft to trigger this 
> request.

dhcwg mailing 
> list

> href="mailto:[email-masked]">[email-masked]

> href="https://www.ietf.org/mailman/listinfo/dhcwg" target=_blank

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 28 Apr 2010 11:00:51 +0300

Ted,

Your I-D defines a single relay agent option that can encapsulate all types
of other purpose-specific options, including MIP6 ones. That makes sense.

But please see RFC 4014 again. It does address this problem space in its own
way, and you are introducing another way. What am I missing?

Also:
 
   For this reason, DHCP servers in environments where a rogue relay
   could interject itself into the packet flow SHOULD authenticate the
   relay agent as described in section 21.1 of DHCPv6 [RFC3315].

In theory, this deserves a SHALL.
I practice, this deserves a "SHALL authenticate .... unless equivalent
security is provided by the lower-layers."
(Note that this is really what's happening with the client-server DHCP
messaging in today's deployed networks).

Alper

> Sent: Friday, April 23, 2010 2:45 AM
> To: [email-masked] Group
> IETF 77 to address a problem that was raised as a result of my review
> of a draft that the Mobile IPv6 working group did a couple of years ago
> -- draft-ietf-mip6-hiopt.   The draft was in the RFC editor queue when
> I found the problem, so this is kind of a last-minute thing, but the
> problem was significant.
> 
> So I wrote up a draft describing how to do it in a more general way.
> I mentioned it in the meeting at IETF, and there seemed to be consensus
> adoption.   If you are in favor of adoption, please say so.   If you
> are against, please say why.
> 
> The draft is at:
> 
> The hiopt draft has been sitting in the RFC editor queue since 2008
> with this bug in it, and if we don't do something about it quickly, I
> think there's going to be a justifiably high degree of pressure to just

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Apr 2010 12:45:30 -0400

> way, and you are introducing another way. What am I missing?

From RFC4014:

6. DHCP Client Behavior Relay agent options are exchanged only between relay agents and the DHCP server, so DHCP clients are never aware of their use.

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Apr 2010 15:18:03 -0400 (EDT)

Ted,
 
Exact same behavior also applies to your I-D.
 
DHCP client does not know if the content of an option it received was originally
sent from the DHCP relay to the DHCP server, or if the DHCP server pulled it
from its own database.

On April 28, 2010 at 4:45 PM Ted Lemon <[email-masked]> wrote:

> 6. DHCP Client Behavior Relay agent options are exchanged only between relay
> agents and the DHCP server, so DHCP clients are never aware of their use.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Apr 2010 15:31:29 -0400

On Apr 28, 2010, at 3:18 PM, [email-masked] wrote:
> DHCP client does not know if the content of an option it received was originally sent from the DHCP relay to the DHCP server, or if the DHCP server pulled it from its own database.

Okay, how about this quotation from the RFC:

5.  DHCP Server Behavior

   When the DHCP server receives a message from a relay agent containing
   a RADIUS Attributes suboption, it extracts the contents of the
   suboption and uses that information in selecting configuration
   parameters for the client.  If the relay agent relays RADIUS
   attributes not included in the table in Section 4, the DHCP server
   SHOULD ignore them.  If the DHCP server uses attributes not specified
   here, it might result in side effects not anticipated in the existing
   RADIUS specifications.
This is entirely consistent with existing practice, and fundamentally different from what hiopt does.   It's been standard practice for years to use the information in the relay agent information option to make choices about how to configure the client.   If you can figure out a way to make hiopt work that way, then there's no need for this new draft.   But currently, as I read it, hiopt provides information for the server to send back to the client, not information for the server to use in determining the client's configuration.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 28 Apr 2010 22:58:34 +0300

5.  DHCP Server Behavior

 

This is entirely consistent with existing practice, and fundamentally
different from what hiopt does.   It's been standard practice for years to
use the information in the relay agent information option to make choices
about how to configure the client.   If you can figure out a way to make
hiopt work that way, then there's no need for this new draft.   But
currently, as I read it, hiopt provides information for the server to send
back to the client, not information for the server to use in determining the
client's configuration.

Alper> OK, I see the difference. I'm not sure why this difference matter,
semantically. Whether the DHCP server is using the values as they are, or
using them as index to some other values. Btw, the Session-Timeout in RFC
4014 probably does not follow that semantic. 

Alper> Anyways, I think your concern is having too many options and you want
to cobble them up under one. Having such hierarchy is OK.

Alper> Finally. I think your I-D deserves a note that explains the
difference between what it does and what RFC 4014 does, especially some
guidelines for selecting between these two different types of schemes for
the future authors. 

 

From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2010 10:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] Should the DHC working group work on
draft-lemon-dhcpv6-relay-supplied-options?

DHCP client does not know if the content of an option it received was
originally sent from the DHCP relay to the DHCP server, or if the DHCP
server pulled it from its own database.

5.  DHCP Server Behavior

This is entirely consistent with existing practice, and fundamentally
different from what hiopt does.   It's been standard practice for years to
use the information in the relay agent information option to make choices
about how to configure the client.   If you can figure out a way to make
hiopt work that way, then there's no need for this new draft.   But
currently, as I read it, hiopt provides information for the server to send
back to the client, not information for the server to use in determining the
client's configuration.

---

From: <[email-masked]>
Date: Wed, 28 Apr 2010 22:04:14 +0200

Just seeking a clarification here from this thread:

On 4/28/10 2:31 PM, "ext Ted Lemon" <[email-masked]> wrote:

>> originally sent from the DHCP relay to the DHCP server, or if the DHCP server
>> pulled it from its own database.
> 
> different from what hiopt does.   It's been standard practice for years to use
> the information in the relay agent information option to make choices about
> how to configure the client.   If you can figure out a way to make hiopt work
> that way, then there's no need for this new draft.   But currently, as I read
> it, hiopt provides information for the server to send back to the client, not
> information for the server to use in determining the client's configuration.

So I understand the intent of what is being proposed in HiOpt and the view
that it can be achieved with what is specified in RFC4014.
I am just wondering if there is any need to send information that is
available at the relayagent to the DHCP server which helps it in determining
the clients configuration. Just wondering why the DHCP server should care to
know the client config.

-Raj

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Apr 2010 16:50:42 -0400

> the clients configuration. Just wondering why the DHCP server should care to

Yes, existing practice is that the DHCP server uses information about the client to choose how to configure the client.   So it is in fact necessary for the server to have that information, and that's why we have the relay agent information option.   This capability is widely used by broadband providers.

Reasons why include:

- An ISP doesn't want to give the client an IP address if they haven't paid their bill
- An ISP needs to know what circuit the client is using in order to choose their IP address
- A wholesale ISP need to use the client's circuit ID to look them up in a database to figure out who their retail ISP is.

Etc.

---

From: <[email-masked]>
Date: Wed, 28 Apr 2010 22:55:12 +0200

Okay. Thanks. 
I would support the WG taking on draft-lemon-dhcpv6-relay-supplied-options
I-D.

-Raj

On 4/28/10 3:50 PM, "ext Ted Lemon" <[email-masked]> wrote:

> Yes, existing practice is that the DHCP server uses information about the
> client to choose how to configure the client.   So it is in fact necessary for
> the server to have that information, and that's why we have the relay agent
> information option.   This capability is widely used by broadband providers.
> 
> Reasons why include:
> 
> - A wholesale ISP need to use the client's circuit ID to look them up in a
> database to figure out who their retail ISP is.
> 
> Etc.
>