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

["Bernie Volz (volz)" <volz at cisco.com>]

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