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

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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] 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
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg