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

[Sheng Jiang <[e-mail]>]

Hi, Francis,

Please see replies in lines.

>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)

We could apply this to next version.

> - 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

This has to be a separated document. It remains out of scope for this document. In most of cases, it is ok to assume a node have a time which has less 5-min time drift. A brand new node without any knowledge of time is an edge case.

>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.

It's reasonable.

>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.

Actually, certificate would be very useful for server to authorize the client. It is much less useful on a client, who have not been allowed to connect on line. In such case, certificate can be used with LoF, which is equal usage as 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".

Could you be more clear how this may work? I am not sure I fully understand your proposal. So far, SeDHCPv6 has no compatibility issues with SeND, because they are two solutions independent from each other. We don't want to introduce any dependency between them, which would make the deployment much more complicated.

Best regards,

Sheng

>Regards
>
>[e-mail]
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg