Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Feb 2014 08:33:49 -0500

On Jan 31, 2014, at 10:40 AM, Brian Haberman <[email-masked]> wrote:
>     I have done my AD Evaluation of draft-ietf-dhc-dhcpv6-unknown-msg
> (since Ted is listed as a co-author).  I only have a few points of
> discussion on this document before we move it along in the publication
> process.  I am by no means a DHCP expert, so let me know if I have gone
> off in the weeds...
> 
> 1. I would like to see a little more clarity in the purpose of this
> document.  It does a good job clarifying what a relay agent should do
> with existing messages, but I think it would be useful to spell out that
> is document is also dictating how future documents that define new DHCP
> messages should specify relay behavior.

This is a good suggestion (actually, these are all good suggestions!).   I think the right solution to this is twofold.   First, the following change should be made at the end of 4.1 (this also addresses your point 2):

OLD:
   In the case that a new type of message is sent by the server to a
   relay agent but the relay agent does not recognize it, the message is
   put into a Relay-forward message and sent to the server.
NEW:
   New DHCP message types may be defined in future that are intended to
   convey information from DHCP servers to relay agents.   Relay agents
   that do not implement these messages will not recognize that such
   messages are intended for them.   A relay agent that implements this
   specification will necessarily forward such messages to the DHCP
   servers to which it is configured to relay client messages.

   At this time, no messages of this variety have been specified.
   If such a message is specified in the future, the specification could
   include text something like the following:

      DHCP servers that send this new message type MAY, when they
      receive a relayed message of this type, mark the relay agent to
      which the message was sent as not implementing messages of this
      type.   In this case, the DHCP server MAY implement a strategy
      of probing the relay agent occasionally to see if it has been
      updated.

   However, this is not strictly necessary, since DHCP does not provide
   a signaling message for rejecting unexpected message types, and
   therefore DHCP servers are not expected to respond to such messages.

   Documents specifying new message types should use different types for
   communicating *to* relay agents than are used for communicating *from*
   relay agents, so that no confusion can occur where a message sent to
   a relay agent is sent back to the DHCP server, which then tries to
   process it as if it came from a relay agent.

In addition to this change, I'd propose the following change to the abstract:

OLD:
   DHCPv6 is not specific about handling messages with unknown types.
   This memo describes the problems and defines how a DHCPv6 server,
   client or relay agent should behave when receiving unknown DHCPv6
   messages.  This document updates RFC3315.

NEW:
   DHCPv6 is not specific about handling messages with unknown types.
   This memo describes the problems and defines how a DHCPv6 server,
   client or relay agent should behave when receiving unknown DHCPv6
   messages.  This document also provides advice for authors of future
   documents defining new messages sent from DHCP servers to DHCP relay
   agents, and should be read by potential authors of such documents.
   This document updates RFC3315.

> 2. In section 4.1, the text talks about targeting a message based on its
> message type.  To me, that suggests that a relay must know about all
> DHCP message types.  I thought (feel free to correct me) that relay
> agents were mostly stateless and would forward all messages not
> addressed to them to the configured DHCP server.  This assumes that all
> Relay-Reply messages are addressed to the relay directly.

That is the general effect of 4.1, but I hope the text above makes clearer what the issues are, both to you and to other future readers of the document.

> 3. After having an exchange with Ralph Droms, I want to ask about
> messages from servers to clients.  If those messages are *not* in a
> Relay-Reply message, but are received by a relay, should those messages
> be dropped?  If a server->client message is forwarded to a server by the
> relay, should it be dropped by the server?

If this happens, it's an implementation bug: the DHCP server is not in conformance with RFC3315.   I therefore think that we don't need to address it, although it would certainly break things if an implementation were to erroneously do that.   I think such an implementation would never make it to the field, because it simply wouldn't work.

> 4. Is there a need to specifically discuss the behavior of single
> devices that have both a relay agent and a client running at the same time?

Hm.   We generally treat these as two separate implementations that happen to be running on the same hardware.   Also I think usually it's a client and a server, not a relay agent and a server.   We could add text addressing this, but I don't really see this coming up in practice.   There isn't similar text in RFC3315, for instance, and we haven't seen evidence of implementors getting this wrong.

> 5. Also from Ralph... Could section 5 simply be written as "A client or
> server MUST silently discard any received DHCPv6 message with an unknown
> message type."?

Yes, I think this is a good edit.   Qi, do you have time to do these edits?

---

From: Qi Sun <[email-masked]>
Date: Sun, 2 Feb 2014 22:52:55 +0800

Dear Brian & Ted,

Thank you so much for your evaluation/suggestions! I think the comments/changes are very helpful to make the text clearer. 

I will do the updates asap. Thank you again!

//Sorry for late response because of the Chinese Spring Festival. 

Best Regards,
Qi

On 2014-2-2, at 下午9:33, Ted Lemon wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Feb 2014 09:57:42 -0500

> //Sorry for late response because of the Chinese Spring Festival. 

You responded about an hour after my message, so I think you are blameless.   Happy New Year!

---

From: Tomek Mrugalski <[email-masked]>
Date: Sun, 02 Feb 2014 17:07:50 +0100

On 02.02.2014 14:33, Ted Lemon wrote:
> Yes, I think this is a good edit.
I would extend the text a bit with "The server or client MAY log the
fact.". Silently dropping a message that is typically network setup
problem may hide problems and make their debugging harder.

If you configured your relay to send message X, but your server is not
capable of understanding it, then why did you configure your relay to
send it in the first place? Also, if your network has clients that send
message Y and your server does not know what to do with it, perhaps its
time upgrade your server? Or forbid those particular clients if that new
behavior is not welcome in a given network.

On the other hand, some people may afraid that their server could be
spammed with messages of bogus type and filling in syslog with useless
junk. Given those two arguments, MAY seems like a good compromise for
the logging.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Feb 2014 10:12:22 -0500

> problem may hide problems and make their debugging harder.

The "silent" in "silently drop" conventionally means "drop without sending any response," not "drop without making any record that you dropped it."   Silently dropped messages are often either logged or recorded in statistics counters, and I'm pretty sure RFC 3315 recommends this practice and explains that that's what "silently drop" means.   Hm, actually no, neither 3315 nor 2131 explains, but they do use the term in this way.   I know I've seen it documented somewhere... :}

Anyway, it certainly could be clarified, but I don't think it's strictly necessary, given that it's not clarified in 3315.   Maybe you could just add it to the terminology section in 3315-bis?

---

From: Brian Haberman <[email-masked]>
Date: Mon, 03 Feb 2014 09:17:12 -0500

>    servers to which it is configured to relay client messages.

Hmm... The text above talks about messages from servers to relays.
Would these messages be coming from servers *not* identified in the
relay's configuration?  That is, do you envision relays seeing messages
from servers that the relay is not configured to use for received client
messages?  If not, shouldn't the guidance be that relays should silently
drop them?  If they can receive messages from servers they don't know
about, the relays will forward these messages to *other* servers and
they should drop them.

>    process it as if it came from a relay agent.

Almost sounds like DHCP needs a capabilities negotiation between servers
and relays. :)

>    This document updates RFC3315.

Ok.

> That is the general effect of 4.1, but I hope the text above makes clearer what the issues are, both to you and to other future readers of the document.

Once my follow-up question is answered, I will have a better grasp on
the clarity.

> If this happens, it's an implementation bug: the DHCP server is not in conformance with RFC3315.   I therefore think that we don't need to address it, although it would certainly break things if an…

Ok.

> Hm.   We generally treat these as two separate implementations that happen to be running on the same hardware.   Also I think usually it's a client and a server, not a relay agent and a server.   W…

If the pairing of a client and relay agent is not expected, this may not
be an issue.

Regards,
Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 09:48:15 -0500

> about, the relays will forward these messages to *other* servers and

Yes, I had a bit of a think about that when replying to your review yesterday, and thought about it some more just now.   I don't think we can address that here—we don't know what these messages will look like, or even if they will be defined, so trying to anticipate their security implications is a bit futile.   I think the language I proposed is adequate for the time being, and does the right thing in the case of unknown messages.   E.g., a server implemented according to the existing spec would not do a bad thing with such a message, because it wouldn't recognize it, and the document defining that message ought to specify how the server should handle it in the case you've described.

> Almost sounds like DHCP needs a capabilities negotiation between servers

Perish the thought.  :)

> If the pairing of a client and relay agent is not expected, this may not

It's certainly a plausible configuration—I've even proposed something like this in homenet.   But I think that the way this would work would again be something that could be documented in the spec describing how it works.   And homenet doesn't seem very interested in solving the problem this way anyway.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 03 Feb 2014 09:52:17 -0500

On 2/3/14 9:48 AM, Ted Lemon wrote:
>> Would these messages be coming from servers *not* identified in
>> the relay's configuration?  That is, do you envision relays seeing
>> messages from servers that the relay is not configured to use for
>> received client messages?  If not, shouldn't the guidance be that
>> relays should silently drop them?  If they can receive messages
>> from servers they don't know about, the relays will forward these
>> messages to *other* servers and they should drop them.
> 
> Yes, I had a bit of a think about that when replying to your review
> yesterday, and thought about it some more just now.   I don't think
> we can address that here—we don't know what these messages will look
> like, or even if they will be defined, so trying to anticipate their
> security implications is a bit futile.   I think the language I
> proposed is adequate for the time being, and does the right thing in
> the case of unknown messages.   E.g., a server implemented according
> to the existing spec would not do a bad thing with such a message,
> because it wouldn't recognize it, and the document defining that
> message ought to specify how the server should handle it in the case
> you've described.

Ok.

> 
>> Almost sounds like DHCP needs a capabilities negotiation between
>> servers and relays. :)
> 
> Perish the thought.  :)

Duly noted.

> 
>> If the pairing of a client and relay agent is not expected, this
>> may not be an issue.
> 
> It's certainly a plausible configuration—I've even proposed something
> like this in homenet.   But I think that the way this would work
> would again be something that could be documented in the spec
> describing how it works.   And homenet doesn't seem very interested
> in solving the problem this way anyway.
> 

Ok. Just wanted to check.

When a new version pops out, I will review it and start IETF LC.

Regards,
Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 09:52:36 -0500

> When a new version pops out, I will review it and start IETF LC.

Thanks!

---

From: Ralph Droms <[email-masked]>
Date: Mon, 3 Feb 2014 10:03:05 -0500

>   This document updates RFC3315.

This proposed text generally looks ok.  I see the conversation has picked up a few messages later in the thread, so I'll jump ahead to that discussion in another response.

> That is the general effect of 4.1, but I hope the text above makes clearer what the issues are, both to you and to other future readers of the document.

OK.

> If this happens, it's an implementation bug: the DHCP server is not in conformance with RFC3315.   I therefore think that we don't need to address it, although it would certainly break things if an…

Looking ahead to 4, seems to me we should consider the case in which a client and relay agent are multiplexing inbound DHCPv6 messages on the same port.

> Hm.   We generally treat these as two separate implementations that happen to be running on the same hardware.   Also I think usually it's a client and a server, not a relay agent and a server.   W…

I'm imagining a scenario in which a device is doing DHCP-PD and has a DHCPv6 client for local configuration.  Don't underestimate implementors; jsut because they haven't gotten it wrong in the past doesn't mean we shouldn't consider the case.

I'm assuming this entire document will be absorbed into RFC3315bis at some point?  Idle thought - is it worth publishing this document now when it will likely be superseded by RFC3315bis?

---

From: Ralph Droms <[email-masked]>
Date: Mon, 3 Feb 2014 10:06:31 -0500

On Feb 3, 2014, at 9:48 AM 2/3/14, Ted Lemon <[email-masked]> wrote:

> Yes, I had a bit of a think about that when replying to your review yesterday, and thought about it some more just now.   I don't think we can address that here—we don't know what these messages will look like, or even if they will be defined, so trying to anticipate their security implications is a bit futile.

I don't think we can count on the relay agent explciitly knowing all of the servers for which it is configured. The default configuration for a realy agent is to forward messages to a multicast address.

>   I think the language I proposed is adequate for the time being, and does the right thing in the case of unknown messages.   E.g., a server implemented according to the existing spec would not do a bad thing with such a message, because it wouldn't recognize it, and the document defining that message ought to specify how the server should handle it in the case you've described.
> 

We'll get on that as soon as we finish a HA server-server protocol.

>> If the pairing of a client and relay agent is not expected, this may not

Perhaps I'm insufficiently caffeinated this AM, but I don't understand "pairing of a client and relay agent"...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 10:24:12 -0500

> I'm imagining a scenario in which a device is doing DHCP-PD and has a DHCPv6 client for local configuration.  Don't underestimate implementors; jsut because they haven't gotten it wrong in the past…

Right, but if they are that creative, it's unlikely we will be able to stop them.

> I'm assuming this entire document will be absorbed into RFC3315bis at some point?  Idle thought - is it worth publishing this document now when it will likely be superseded by RFC3315bis?

Yes, the working group considered that question, and decided to publish.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 03 Feb 2014 10:30:54 -0500

Hi Ralph,

> Perhaps I'm insufficiently caffeinated this AM, but I don't understand "pairing of a client and relay agent"...

I meant having a client and relay agent functioning in the same box.

Brian

---

From: Ralph Droms <[email-masked]>
Date: Mon, 3 Feb 2014 10:35:24 -0500

>> in solving the problem this way anyway.

I have a less laissez-faire view, here, which is that we ought to disallow explicitly the deployment of a client and relay agent on the same device, with a recommendation that a specification for such a deployment needs to be written if the use case is realized.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Feb 2014 10:38:04 -0500

> I have a less laissez-faire view, here, which is that we ought to disallow explicitly the deployment of a client and relay agent on the same device, with a recommendation that a specification for s…

That sounds like the opposite of a laissez-faire view.   The only problem with this proposal is that there's no reason to think that anyone who needs to would read it.   This sounds like more of a thing to do in 3315bis.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 03 Feb 2014 10:41:30 -0500

On 2/3/14 10:38 AM, Ted Lemon wrote:
>> I have a less laissez-faire view, here, which is that we ought to
>> disallow explicitly the deployment of a client and relay agent on
>> the same device, with a recommendation that a specification for
>> such a deployment needs to be written if the use case is realized.
> 
> That sounds like the opposite of a laissez-faire view.   The only

Umm... He said "less laissez-faire". :) He's not wielding Thor's hammer
though.

> problem with this proposal is that there's no reason to think that
> anyone who needs to would read it.   This sounds like more of a thing
> to do in 3315bis.
> 

I would be fine with that guidance being in 3315bis., but recall that I
am also not a DHCP expert.

Regards,
Brian

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 3 Feb 2014 22:10:36 +0000

>I'm assuming this entire document will be absorbed into
>RFC3315bis at some point?  Idle thought - is it worth
>publishing this document now when it will likely be
>superseded by RFC3315bis?

Yes, that is the DHCPv6bis team's expectation as well.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Monday, February 03, 2014 10:03 AM
To: Lemon Ted; Haberman Brian
Cc: [email-masked] WG; [email-masked]
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

On Feb 2, 2014, at 8:33 AM 2/2/14, Ted Lemon <[email-masked]> wrote:

>> discussion on this document before we move it along in the 
>> publication process.  I am by no means a DHCP expert, so let me know 
>> if I have gone off in the weeds...
>> 
>> with existing messages, but I think it would be useful to spell out 
>> that is document is also dictating how future documents that define 
>> new DHCP messages should specify relay behavior.
> 

> 
>> 2. In section 4.1, the text talks about targeting a message based on 
>> its message type.  To me, that suggests that a relay must know about 
>> all DHCP message types.  I thought (feel free to correct me) that 
>> relay agents were mostly stateless and would forward all messages not 
>> addressed to them to the configured DHCP server.  This assumes that 
>> all Relay-Reply messages are addressed to the relay directly.
> 

OK.

>> Relay-Reply message, but are received by a relay, should those 
>> messages be dropped?  If a server->client message is forwarded to a 
>> server by the relay, should it be dropped by the server?
> 

> 
>> 5. Also from Ralph... Could section 5 simply be written as "A client 
>> or server MUST silently discard any received DHCPv6 message with an 
>> unknown message type."?
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 3 Feb 2014 22:18:04 +0000

Sorry, just to be clear - this draft should be published; then it will be incorporated into RFC3315bis.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Monday, February 03, 2014 5:11 PM
To: Ralph Droms; Lemon Ted; Haberman Brian
Cc: [email-masked] WG; [email-masked]
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

>I'm assuming this entire document will be absorbed into RFC3315bis at 
>some point?  Idle thought - is it worth publishing this document now 
>when it will likely be superseded by RFC3315bis?

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Monday, February 03, 2014 10:03 AM
To: Lemon Ted; Haberman Brian
Cc: [email-masked] WG; [email-masked]
Subject: Re: [dhcwg] AD Evaluation: draft-ietf-dhc-dhcpv6-unknown-msg

OK.