Re: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is submitted. Comments are welcome!

[Ted Lemon <Ted.Lemon at nominum.com>]

> However, there is a good practical reason.   That is, we know how this
> will be implemented, the signature can't be added until all the other
> options for the message are in place (at least, known), and the natural
> way to do things is to put each option into the packet as it is needed.
> That is, when generating the packet the last option added is always
> going
> to be the signature, and it is hard to imagine an implementation where
> that won't mean the signature will be the last option in the packet
> (and yes, I mean the original packet, ignoring anything that later
> encapsulates it.)

This simply isn't true.   The way I have always envisioned writing this code (which, I admit, I have never written) is to represent the option internally as zeroes, and then call the routine that constructs the packet.   Then compute the actual checksum.   Then stuff it in where the option was stored in the packet, wherever that was.   So for me, requiring the option to be at the end would require additional code.

> But consider the receiver (the client).   It has to be able to deal
> with
> any legal packet.   That's fine, it is possible to write code that will
> allow the signature to be in the middle somewhere (or at the
> beginning),
> but when will that code ever get tested?   It is natural to optimise
> for
> the common case

Actually, it wouldn't be natural to optimize this case, because there's no way to optimize it.   You can't traverse the options backwards.   So it's no easier to find the option at the end of the packet than in the middle.   The obvious optimization for both the server and client is to put the option at the beginning.

> The end result of this kind of thing is a "well known implementors
> rule"
> that the sig option must be last, or various clients fail in obscure
> ways,
> without that rule being ever written anywhere, leaving it as a surprise
> for
> new implementors.   In situations like this, it is often wiser to
> simply
> accept that life is is as it is, and make "last" be mandatory, so
> clients
> can simply discard any packet where the sig isn't last as being
> malformed,
> and there's no code to deal with this to rot.

This is exactly backwards.   We want broken clients to fail early and often.   Otherwise they never get fixed.   The best place for the server to put the option is in the middle of the packet, where neither the assumption that it's at the beginning, nor the assumption that it's at the end, will work.

> Also note, sig (auth) options are not (and never can be) treated like
> any
> general option, they always need to be treated specially, the way
> they're
> implemented is just different than general options - they always need
> to be
> calculated last at the sender, and should generally be checked first
> (after
> only basic packet format) at the receiver to avoid processing options
> from a
> forged packet.   That is, there's no need to worry about needing
> special
> case code in servers/clients for this, because of the order
> requirement, as
> special case code for auth options is going to be needed anyway.

This is also untrue.   You want to use the regular packet construction code to place the option in the packet; otherwise you are putting in a special code path that will never get tested, because nobody actually uses DHCP authentication.   So you want as little of the DHCP authentication code as possible to be special-cased.   In every DHCP project I've ever worked on, there are primitives for "get option X" and "add this option to the list of options to put in the packet."   There are no primitives for "get the last option" or "put this at the end."

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg