[dhcwg] Comments on draft-jinmei-dhc-dhcpv6-clarify-auth-00

Jinmei-san,

here are my first comments on the I-D. My overall impression of the I-D
is very good, it seems to include all the issues raised on the DHC-ML.
All comments I have are mostly minor things like language and typos, not
essential problems with the contents.

I like the comment that you make in para 2.1 about not having a real
"session" in stateless which is essentially a contradiction to
"stateless" on one hand but on the other hand one obviously needs to
strictly separate sessions that concern content transmitted via DHCP and
sessions that concern the transmission itself. I think that your
proposed rephrasing of Section 21.4.4.4 incorporates that nicely.

I paragraph 4. you write:

"A reasonable interpretation of the phrase is probably as follows: a
DHCPv6 message is called unauthenticated when it fails the validation
test described in Section 21.4.2, it does not contain an authentication
option, or when it includes an authentication option but does not have
authentication information when necessary."

I would propose a minor rephrasing to clear the language up a little (if
I understand the above paragraph correctly, the following rewording
should work):

"A reasonable interpretation of the phrase is as follows: a DHCPv6
message is called unauthenticated if it fails the validation test
described in Section 21.4.2, if it does not contain an authentication
option, or if it includes an authentication option without the necessary
authentication information."

I also like para 5.1. very much, especially the choice of highlighted
keywords is very good. I second the idea of proposing a default policy
of discarding non-authenticated messages.

Minor typos:

para 2.:
	-It should also be noted that [RFC3315] does not define how the
         server should do when it receives
        +It should also be noted that [RFC3315] does not define what the
         server should do when it receives

para 3.:
	-3.  What If Reply Is Detected
	+3.  What If Replay Is Detected

para 5.:
	-Apparently this contradicts with the requirement in Section
         21.4.2.
	+Apparently this contradicts the requirement in Section 21.4.2.

para 5.1.:
	-Accepting an non-authenticated
	+Accepting a non-authenticated

Thank you for writing this I-D up, it summarises important DHCP
authentication issues raised on the ML very well and gives the reader a
good idea where there're gaps in the standard and where clarifications
should be made. Additionally I think that this I-D is a good basis for
any future BCP document regarding DHCPv6 deployments where
authentication mechanisms are used.

Cheers,
Christian

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg