Re: [dhcwg] draft-miles-dhc-forcerenew-key-00

["MILES DAVID" <[e-mail]>]

Hi Bernie,


Thanks for the quick review. Comments inline:


1. We already have 0-length data options in DHCPv4 (see
http://www.ietf.org/rfc/rfc4039.txt), so not sure what the value of
using a 1-byte data option is for the Forcerenew Key Protocol Capability
Option.

>> Understood. This was part of the original proposal and I admit we
glossed over this particular detail. A zero-len option would be fine.

2. Why not use the same techniques as used for DHCPv6 ...

DISCOVER includes Forcerenew Key Protocol Capability Option.
OFFER includes Forcerenew Key Protocol Capability Option.
REQUEST includes Forcerenew Key Protocol Capability Option.
ACK includes Forcerenew Key Protocol Capability Option & Auth Option
(with key).

This avoids the need to send back the AUTH option in the OFFER (and the
need for Type of 0).

>> Will update this in -01. 

3. I don't understand why the following is needed:

   The client would indicate that it supports the functionality by
   inserting an Parameter Request List option (option 55, [RFC2131])
   containing option <TBD> in the DHCP Discover message.

The client has provided the option and if the server supports it, it
MUST send it back (if adopt #2 above). This is a "core" protocol option
so I see little value to also include it in the PRL.-

>> Will remove this line.

4. While perhaps it doesn't matter much because it is easy to snoop
packets via promiscous mode anyway, but I wonder whether something needs
to be said about the BROADCAST ACK which contains the key (in DHCPv6,
messages to the client are always unicast)? Certainly something should
be said about it in the Security Considerations?


>> Ill add a section describing the problem when the broadcast bit is
set. Thanks again!