[dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt

[Francis Dupont <[e-mail]>]

Timestamps are not enough for the anti-replay protection and
are difficult to implement for clients without a good long term
real time clock, so I propose:
 - to introduce a nonce option which will be processed as an extension
  of the transaction ID (so there are already 3 octets)
 - to put the timestamp in its own option (so it can be omitted)
 - to document a way for an unsynchronized node to get a good time value,
  for instance sending an Information-Request or a Solicit without
  rapid-commit asking for a timestamp option in the ORO
I propose to require the timestamp option in all messages changing the
state (e.g., request, renew, etc) and everything from agents.
I don't propose to make nonces mandatory but there is no good reason
to not use them as soon as they are supported.
A still open problem is what to do with clock mismatch between agents
but this has in fact only an impact on optimization (multicast to
more than one agent) so IMHO we can live with it.

The second point is about (X.509 public key) certificates. They are useless
without the trust anchor, the whole chain, CRLs, etc. And if we want
to use self-signed certificates they bring nothing compared to raw
public keys. And I don't talk about profiles (even SeND had to be
completed by RFC 6494). So I really suggest to drop the certificate
option and to use the key option to identify the public key.

The last point is compatibility with SeND (RFC 3971). Today in red and
black (:-) environments it is possible to secure the Neighbor Discovery
but not DHCP. I propose to fix this using the secure DHCPv6 for
the protection of DHCP and the SeND section 6 Authorization Delegation
Discovery for the "certificate part".

Regards

[e-mail]