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

From: [email-masked]
Date: Fri, 17 Sep 2010 21:30:02 -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-01.txt
	Pages           : 6
	Date            : 2010-09-17

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-01.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: Sat, 18 Sep 2010 12:40:11 +0800

Hi, 
I just submitted the revision for relay supplied options draft. 
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/
For Diff, refer to
http://tools.ietf.org/rfcdiff?url1=draft-ietf-dhc-dhcpv6-relay-supplied-options-00&difftype=--html&submit=Go%21&url2=draft-ietf-dhc-dhcpv6-relay-supplied-options-01
no content change.

Let us know if there are any remaining comments.

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, September 18, 2010 12:30 PM
Subject: I-D Action:draft-ietf-dhc-dhcpv6-relay-supplied-options-01.txt

> implementation to automatically retrieve the ASCII version of the

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

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Sep 2010 13:10:52 -0700

> Let us know if there are any remaining comments.

This document received substantial support when it came up at the meeting in Anaheim, and no dissent.   There's immediate demand for it.   So I'd like to do a last call now.   Please read the document.   It's quite short--shouldn't take more than ten minutes to read:

In order to advance the document, we need a few careful readers, so in addition to yeas and nays, please indicate that you've actually read the document carefully before responding to this last call.   At this point we've had three reviews, but not all from experienced DHCwg people, so I'd really like to hear from some old-timers.

Based on the guidelines for last calls, I will count up the results of this last call after 22:00 UTC on October 8, 2010.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 19 Sep 2010 14:06:14 +0700

The diagram in section 3 is arguably incomplete; suggest using the same
style as in RFC 3315 (e.g., Section 22.2).  It might also be helpful to IANA
id the desired option ID (maybe "OPTION_RSOO) was specified, rather than the
generic "TBD", both here and in the IANA Considerations section.

In section 5, it would be nice to supply a reference for "IA option".

Can more than one RSOO appear in a given Relay-Forward message?  If so, what
should the server do if it receives a Relay-Forward message containing
multiple RSOOs themselves containing contradictory sub-options and the
server has no candidates of its own?

---

From: Stephen Jacob <[email-masked]>
Date: Mon, 20 Sep 2010 09:41:30 -0700

On Sat, Sep 18, 2010 at 01:10:52PM -0700, Ted Lemon wrote:
> This document received substantial support when it came up at the
> meeting in Anaheim, and no dissent.   There's immediate demand for
> it.   So I'd like to do a last call now.   Please read the
> document.   It's quite short--shouldn't take more than ten minutes
> to read:
> 
> In order to advance the document, we need a few careful readers,
> so in addition to yeas and nays, please indicate that you've
> actually read the document carefully before responding to this last
> call.   At this point we've had three reviews, but not all from
> experienced DHCwg people, so I'd really like to hear from some
> old-timers.
> 
> Based on the guidelines for last calls, I will count up the results
> of this last call after 22:00 UTC on October 8, 2010.

Ted,

I'm not sure I really fit the bill of old-timer since I've not been
a particularly active WG participant over a long period of time, but
I have a little experiene with DHCP as you know. :-)

To start with:  +1

I have read the draft carefully, and my only question is related to
the assertions about what configuration knobs a compliant DHCP server
has.  I'm not sure I can recall other drafts/RFCs specifying admin
configurability as a part of draft/RFC compliance before.

Specifically, it specifies:

  - "A DHCP server that implements this spec must have a user-
    configurable setting which determines whether or not it accepts
    a Relay-Supplied Options option."

    (Actually, perhaps this should say "administrator-configurable"?)

  - "The list of options that will be discarded SHOULD be configurable
    by the administrator."

Both of these proposed configuration elements seem like good ideas.
I'm just not certain if one is meant to dictate configuration
elements in a protocol document?

This isn't exactly an objection.  It's really more of a question.
If the answer is "this sort of thing is considered absolutely fine
in an IETF spec", I have no problem with them.  Honestly, I think
they would probably save implementors some needless iteration with
their customers.

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Stephen Jacob <[email-masked]>
Date: Mon, 20 Sep 2010 09:54:38 -0700

> generic "TBD", both here and in the IANA Considerations section.

When you say it is arguably incomplete, do you mean because it doesn't
specify "variable length", or just the stylistic aspect of the sub-options
not being a block spanning multiple lines, or something else?

w.r.t. specifying "variable length", it seems 22.4, 22.5 and 22.6 (and
probably others) do not bother to say "variable length" for similar
encodings of lists of options, so I would not consider that to be
a necessity.

I like the suggestion of using "OPTION_RSOO".

> server has no candidates of its own?  

That is a very good question.  It's probably better to provide an
indication as to what implementors SHOULD do as opposed to just
leaving it up in the air for everybody to decide separately.

I would suggest closest relay (to the client) wins.

Regards,
Stephen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Sep 2010 10:23:49 -0700

>    (Actually, perhaps this should say "administrator-configurable"?)

Indeed, it SHOULD say MUST, as well.   :')
> elements in a protocol document?

Yup, it's actually pretty common.   The motivation for doing it here is that I don't think that DHCP servers should, by default, accept relay-supplied options.   So if we say that, then by definition we're requiring that the server be configurable to support them; otherwise the code to support them couldn't be turned on.   So here we're just making it explicit.

In the latter case, it's not as clear-cut, but it seems to me that administrators might want to have a default-exclude model for relay-supplied options, Just In Case.  This language makes that easy for the administrator to do.   Essentially, both of these configuration requirements are security measures.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 21 Sep 2010 08:20:10 +0700

> not being a block spanning multiple lines, or something else?

I mean the not even the lengths of the fixed-length fields are illustrated,
nor specified anywhere else in the document.  I think that it would be
clearer, more precise and more consistent with the existing document set to
use the same format as RFC 3315.

> encodings of lists of options, so I would not consider that to be

Since I never mentioned "variable length" or 22.4, 22.5 and 22.6, please
consider your straw man suitably pummeled if not incinerated ;-).

...

---

From: Qin Wu <[email-masked]>
Date: Tue, 21 Sep 2010 10:27:12 +0800

> server has no candidates of its own?  

[Qin]: Good question. 
In such case, we have two choices.
(1).Do we allow the server restrain multiple RSOOs to be included in Relay-Forward and deems such options inappropriate to forward?
(2) Or just foward all the sub-options in the multiple RSOOs to the client?

In my opinion, it depends on what kind of suboptions you are talking about?
If the suboption is one list option or group option which could include a list of the same kind of information,
e.g., the Domain Search List option is included in multiple RSOOs as suboption, what the server needs to do is to extract the information from all the Domain Search List options in the RSOOs
and merge the information list into one Domain Search List option and sent this option to the client. In such case, it seems additional server behavior is required.

If the suboption is not list option or group option, the server will confuse on which suboption it should extract from multiple RSOOs. One possible way to resolve this is the server deems multiple RSOOs as inappropriated options to forward.

Any other proposal or suggestion?

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

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 21 Sep 2010 10:18:03 +0700

Ted Lemon [mailto://[email-masked]] writes:

> Yup, it's actually pretty common.   The motivation for doing it here is
> that I don't think that DHCP servers should, by default, accept relay-
> supplied options.   So if we say that, then by definition we're
> requiring that the server be configurable to support them; otherwise the
> code to support them couldn't be turned on.   So here we're just making
> it explicit.
> 
> In the latter case, it's not as clear-cut, but it seems to me that
> administrators might want to have a default-exclude model for relay-
> supplied options, Just In Case.  This language makes that easy for the
> administrator to do.   Essentially, both of these configuration
> requirements are security measures.

That being the case, and the second being only a "SHOULD", would it be a
good idea to note in Section 6 the bad things that could happen if the
"SHOULD" is ignored? 

Also, Section 6 says

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

   Note, however, that this attack is only useful if the DHCP server is
   using the DHCPv6 authentication mechanism; in the absence of DHCPv6
   authentication, the relay agent could more easily forge a message to
   the client, rather than using this mechanism to cause the server to
   produce a message containing forged information.

Shouldn't it instead say 

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

   Note, however, that this attack is only useful if the DHCP client is
                                                              ^^^^^^
   using the DHCPv6 authentication mechanism; in the absence of DHCPv6
   authentication, the relay agent could more easily forge a message to
   the client, rather than using this mechanism to cause the server to
   produce a message containing forged information.

?

---

From: Qin Wu <[email-masked]>
Date: Tue, 28 Sep 2010 17:33:10 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "'Ted Lemon'" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 21, 2010 11:18 AM
Subject: Re: [dhcwg] Last call: draft-ietf-dhc-dhcpv6-relay-supplied-options

>   produce a message containing forged information.
[Qin]: No, I think what it said here is DHCP server is using DHCPv6 authentication mechanism
to authenticate a message from Relay Agent who might be an attacker.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 28 Sep 2010 08:46:42 -0700

> good idea to note in Section 6 the bad things that could happen if the

We do.   Apparently not clearly enough?   :'}

>   produce a message containing forged information.

No.   The packet that needs protection in this case is the one flowing from the DHCP server to the DHCP client, not the one flowing from the DHCP client to the DHCP server.   The point is that if this packet is not signed by the DHCP server, the relay agent can simply modify the packet in transit to add new options to it, rather than going to the trouble of planting a cuckoo's egg in the message it sends to the DHCP server.

I can see that this is unclear in the text, so we'll have to update it.