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

[Sean Shuo Shen <sshen at huawei.com>]

Hi, Bernie,

As we have said several times, it is certainly doable if the signature
option is somewhere in the middle and still protect message contents after
itself. It is only design choice, actually, either last or in the middle is
acceptable for us. We can change it if there is no other people insist last
should be mandated.

Many thanks for your valuable comments! Best regards,

Sean & Sheng

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz at cisco.com]
> Sent: Monday, July 14, 2008 10:16 PM
> To: Sean Shuo Shen; kre at munnari.OZ.AU
> Cc: Mark Stapp (mjs); Sheng Jiang; dhcwg at ietf.org
> Subject: RE: [dhcwg] A new draft of draft-jiang-dhc-secure-dhcpv6 is
submitted.
> Comments are welcome!
> 
> If you reworked section 5.2 of the draft as follows you'd solve the
> option ordering issue:
> 
>        Signature       A variable-length field containing a digital
>                        signature. The signature value is computed with
>                        the hash algorithm and the signature algorithm,
>                        as described in HA-id and SA-id. The signature
>                        constructed by using the sender's private key
>                        over the following sequence of octets:
> 
>                        1. The 128-bit CGA Message Type tag value for
>                        Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090
>                        0665 d2e0 02c2. (The tag value has been
>                        generated randomly by the editor of this
>                        specification.)
> 
>                        2. The 128-bit Source Address field from the IP
>                        header.
> 
>                        3. The 128-bit Destination Address field from
>                        the IP header.
> 
>                        4. The entire DHCPv6 message with the Signature
>                        field of this option set to all zero's.
> 
> If may even be better to have it read:
> 
>                        1. The entire DHCPv6 message with the Signature
>                        field of this option set to all zero's.
> 
>                        2. The 128-bit CGA Message Type tag value for
>                        Secure DHCPv6, 0x81be a1eb 0021 ce7e caa9 4090
>                        0665 d2e0 02c2. (The tag value has been
>                        generated randomly by the editor of this
>                        specification.)
> 
>                        3. The 128-bit Source Address field from the IP
>                        header.
> 
>                        4. The 128-bit Destination Address field from
>                        the IP header.
> 
> The reason is that it is often easier to (temporarily) add data at the
> end of the message than to have allocated sufficient space BEFORE it
> (and at least KRE wants to avoid having to use multiple buffer fragments
> to hash over).
> 
> Also, I'm not sure what benefit the "reserved" field in the option has
> (other than making the diagram easier to draw) and I'd suggest removing
> it unless you have a good argument for keeping it. I think it is there
> in RFC 3971 for the simple reason that there is attempt to align IPv6
> header fields so that routers and the like have quicker access to them.
> As the DHCPv6 message has no such alignment requirements and the start
> of an option can be on any byte boundry, there is no benefit to having
> this field to "align" the buffer.
> 
> - Bernie


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