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

[Ted Lemon <[e-mail]>]

On Apr 3, 2013, at 2:04 PM, "Bernie Volz (volz)" <[e-mail]>
 wrote:
> 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.

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:
> 
>   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.

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.