Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 3 Apr 2013 18:04:27 +0000

While I think it is appropriate for the WG to adopt this document, I do have comments on the draft itself.

The draft really should focus on the relay agent issue (what should a relay agent do with unknown message types). I would leave the client and server issues out of it as these are already pretty clear and I don't think there is any value in clarifying it. Sure, if some client or server has an if then else list or case statement where the last "else" or the "default" case was a particular message, they might mis-process that message but that is a client or server implementation issue and not an interoperability issue.

For that reason, I also think the document should be retitled to be something like "Relay Agent Handling of Unknown DHCPv6 Message Types"?

This document (I believe) intends to update RFC 3315, but does not indicate that in the header. This might be something to debate, but I would think it may want to make some explicit changes to RFC 3315. For example, RFC 3315 section 20.1 states:

   When a relay agent receives a
   valid message to be relayed, it constructs a new Relay-forward
   message.  

So what was meant by 'valid' message? Here, I suspect you want to clarify this and perhaps state everything but a Relay-Reply (at least at the present time, future documents might change this if there are messages intended for the Relay -- such as the new message proposed by draft-scskf-dhc-dhcpv4-over-dhcpv6). That in itself may create a slightly odd situation.

I also wonder whether security considerations may allow a knob on the relay to specify whether it MAY 'restrict' the packets it forwards (mini 'firewall').

Some other nits:
- Section 2, "...in RFC 3315 about [the case that] what a relay". "The case that" can be removed.
- Section 3, "leverage the information" ... what information? 
- Section 5, "attacker can interference ... inject fake" ... attacker can interfere ... by injecting? Note also that the client and server attacks for invalid message type code packets already exists for "on-link" attacks too.
- Section 5, "yet no known vulnerabilities exist". I'm not sure it is a good idea to claim this; perhaps best to just drop those words.
- The document makes use of 2119 keywords yet does not indicate so.
- All RFC 3315 usages should likely be to the reference.

You may also want to discuss with Ted Lemon as to whether he should be an author as it may slightly complicate getting this document through the full IETF process.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, April 03, 2013 1:26 PM
To: dhcwg
Subject: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00

Hi all,
This draft is a side effect of the DHCPv4-over-DHCPv6 discussions during last IETF meeting. We were somewhat surprised to note that RFC3315 does not clarify how the relays should handle message types that they do not recognize. This draft clarifies that unknown messages should be relayed as usual.

Authors requested adoption call on
draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being initiated to confirm whether there is WG consensus to adopt this work as DHC WG draft. Please state whether or not you're in favor of the adoption by replying to this mail.
If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-04-17.

Regards,
Bernie & Tomek

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Apr 2013 21:12:23 +0000

> The draft really should focus on the relay agent issue (what should a relay agent do with unknown message types). I would leave the client and server issues out of it as these are already pretty cl…

I don't really agree with this.   I do agree with your analysis of how servers and clients are likely implemented; every eval loop I've seen looks pretty much like what you described.   However, RFC3315 does not explicitly say that servers or clients should drop messages that they don't recognize, and while as you say, this probably does little harm, it's certainly an omission that ought to be corrected, and this seems like a convenient document to use to correct it.

> For that reason, I also think the document should be retitled to be something like "Relay Agent Handling of Unknown DHCPv6 Message Types"?

And hence I disagree with this proposed change. :)

> This document (I believe) intends to update RFC 3315, but does not indicate that in the header.

Good catch.

> This might be something to debate, but I would think it may want to make some explicit changes to RFC 3315. For example, RFC 3315 section 20.1 states:
> 

This is a really good point.

> I also wonder whether security considerations may allow a knob on the relay to specify whether it MAY 'restrict' the packets it forwards (mini 'firewall').

An additional paragraph in Security Considerations that says this might help:

Nothing in this update should be construed to mean that relay agents may not be administratively configurable to drop messages on the basis of the message type, for security reasons (e.g., in a firewall).   The sole purpose of requiring relay agents to relay unknown messages is to ensure that when legitimate new messages are defined in the protocol, relay agents, even if they were manufactured prior to the definition of these new messages, will, by default, succeed in relaying such messages.

> You may also want to discuss with Ted Lemon as to whether he should be an author as it may slightly complicate getting this document through the full IETF process.

Actually in this case I really am a co-author—Qi and Yong kindly agreed to help me to write the document, but as you may recall I was the one who originally proposed writing it.   It's a pretty simple document, so I think it's okay if Brian gets stuck being the responsible AD for it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 3 Apr 2013 21:45:46 +0000

On extending beyond relays, OK.
On authorship, yes I do recall you had been the one to suggest this draft - just figured worth a comment to confirm.

> The sole purpose of requiring relay agents to relay unknown messages is to ensure that when legitimate new messages are defined in the protocol, relay agents, even if they were manufactured prior to the definition of these new messages, will, by default, succeed in relaying such messages.

I think this would be useful to mention in the draft.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2013 5:12 PM
To: Bernie Volz (volz)
Cc: Tomek Mrugalski; dhcwg
Subject: Re: [dhcwg] Adoption call on draft-csl-dhc-dhcpv6-unknown-msg-3315update-00

Good catch.

> You may also want to discuss with Ted Lemon as to whether he should be an author as it may slightly complicate getting this document through the full IETF process.

Actually in this case I really am a co-author-Qi and Yong kindly agreed to help me to write the document, but as you may recall I was the one who originally proposed writing it.   It's a pretty simple document, so I think it's okay if Brian gets stuck being the responsible AD for it.

---

From: Qi Sun <[email-masked]>
Date: Mon, 8 Apr 2013 13:23:53 +0800

Dear Bernie,

Thank you for your thorough review of the draft. Please see inline :)

Best Regards,
Qi

> indicate that in the header.

[Qi] Yes, the draft is meant to update RFC 3315 about the handling of
unknown messages. We will make it clear in Abstract & Introduction parts.

> This might be something to debate, but I would think it may want to make
> some explicit changes to RFC 3315. For example, RFC 3315 section 20.1
> states:
>
> So what was meant by 'valid' message? Here, I suspect you want to clarify
> this and perhaps state everything but a Relay-Reply (at least at the
> present time, future documents might change this if there are messages
> intended for the Relay -- such as the new message proposed by
> draft-scskf-dhc-dhcpv4-over-dhcpv6). That in itself may create a slightly
> odd situation.
>

[Qi] We will try to make the changes to RFC 3315 more specific and address
these related issues.

> - Section 3, "leverage the information" ... what information?

[Qi] We use the word "information" intends to say a relay agent is able to
tell that the Relay-reply message is for uplink while the Relay-forward and
other messages are for downlink. Maybe we need more efforts to make it
clearer.

> - Section 5, "attacker can interference ... inject fake" ... attacker can
> interfere ... by injecting? Note also that the client and server attacks
> for invalid message type code packets already exists for "on-link" attacks
> too.
>

[Qi] What we would like to express is that an attacker can interfere the
DHCP process by constructing a packet with an unknown message type code
(considering the relay agent will relay unknown message).

> - Section 5, "yet no known vulnerabilities exist". I'm not sure it is a
> good idea to claim this; perhaps best to just drop those words.
>

[Qi] We would remove those words.

> - All RFC 3315 usages should likely be to the reference.
[Qi] We will make modifications accordingly.

> Subject: [dhcwg] Adoption call on
> draft-csl-dhc-dhcpv6-unknown-msg-3315update-00
>
> Hi all,
> This draft is a side effect of the DHCPv4-over-DHCPv6 discussions during
> last IETF meeting. We were somewhat surprised to note that RFC3315 does not
> clarify how the relays should handle message types that they do not
> recognize. This draft clarifies that unknown messages should be relayed as
> usual.
>
> draft-csl-dhc-dhcpv6-unknown-msg-3315update-00. This call is being
> initiated to confirm whether there is WG consensus to adopt this work as
> DHC WG draft. Please state whether or not you're in favor of the adoption
> by replying to this mail.
> If you are not in favor, please also state your objections in your
> response. This adoption call will complete on 2013-04-17.
>
> Regards,
> Bernie & Tomek
>
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 08 Apr 2013 18:52:43 +0200

> While I think it is appropriate for the WG to adopt this document, I do have comments on the draft itself.
This is a small, but important draft. By clarifying that relays must
forward unknown messages it provides forward compatibility with any
future extensions that define new message types. We know that there's
one around the corner already, but there may be more ahead.

It is very useful. I do support adoption of this draft. This is
definitely something DHC WG should work on. Fortunately, there's not
much work left to be done.

Minor comment: I would add in section 3.2 "regardless of the message
type in Relay Message option".

Tomek

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 15 Apr 2013 09:45:29 +0000

I do support the adoption of this draft. Useful work. However, I do think this draft should go further to include both unknown message and unknown OPTIONS.

Best regards,

Sheng

>Sent: Tuesday, April 09, 2013 12:53 AM
>To: dhcwg
>Subject: Re: [dhcwg] Adoption call on

---

From: Qiong <[email-masked]>
Date: Wed, 17 Apr 2013 16:55:16 +0800

Hi all,

I'm in favor of adoption this work.

Best wishes
Qiong

On Mon, Apr 15, 2013 at 5:45 PM, Sheng Jiang <[email-masked]> wrote:

> I do support the adoption of this draft. Useful work. However, I do think
> this draft should go further to include both unknown message and unknown
> OPTIONS.
>
> Best regards,
>
> Sheng
>
> >> While I think it is appropriate for the WG to adopt this document, I do
> have
> >comments on the draft itself.

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Apr 2013 13:03:30 +0000

As an author, I guess it goes without saying that I support adoption, but I'll say so anyway to make the chairs' job easier in terms of determining consensus.

---

From: Andre Kostur <[email-masked]>
Date: Wed, 17 Apr 2013 09:18:31 -0700

I support adoption.

--
Andre Kostur

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 18 Apr 2013 08:07:01 -0700

> I support adoption.
<chair hat off>I also support this work.

It is short, but very useful clarification. It will make any future
extensions easier to deploy.