Subject: [dhcwg] Review of draft-ietf-dhc-sedhcpv6-13

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Jul 2016 19:04:35 +0000

Hi:

Thanks for your continued efforts on this draft.

Here are some comments from my reading of draft-ietf-dhc-sedhcpv6-13 (while reading it in preparation for Berlin IETF). I just now had some time to write them up.

Section 1:

   o  encryption between the DHCPv6 client and the DHCPv6 server in
      order to protect the DHCPv6 from pervasive monitoring.

"the DHCPv6" is a bit odd here. Perhaps better to say to "product the DHCPv6 communication"?

Section 4, 2nd paragraph:

Perhaps mention that the bis document removes this support from the protocol specification?

Section 5.2, 3rd bullet - "Timestamp is one of the possible implementation choices." (Choice -> choices)

Section 5.3, 1st paragraph:

-          Algorithm is misspelled.

-          Last sentence is odd: "The same client and server SHOULD use the various algorithm in a single communication session." Not sure what you mean (client and server use the same algorithm in a single session)?

Section 5.4, 1st paragraph:
I think "can be applied for secure DHCPv6 deployment" should be "can be applied to secure DHCPv6 deployments"?

And, in last paragraph, "issues with PKI deployment [to] be addressed"? Add "to".

Section 6

-          2nd paragraph, "except [the] ORO option" (add "the").

-          Note: We may want to discuss whether the other options related to requesting the certificate option should or should not be in the ORO (i.e., signature). I don't have a problem either way but we should probably be consistent with whatever we end up in 3315bis about which options should be in the ORO and which should not.

-          Is the "If the hash algorithm field is zero, the signature algorithm and hash algorithm are not separated" clear enough? I'm not exactly sure myself what this means exactly.

-          "The message transaction-id is used as the identifier" ... what exactly does this mean? Do future Encrypted-Query message (and hence Encrypted-Response) use this same transaction-id? Or how is this used?

-          On storage of the increasing-number option, I would expect that the client (and server)  must keep track of this on a per server (per client) basis? So, a client perhaps should keep a record of this "forever", but how should servers manage this? When can they forget this information (when all leases have expired)? Or do they need to keep this for a period?

-          This is perhaps an issue for section 9.1.3, but I would think a 64-bit value would be better for the Increasing Number option? And, should this be modulo 2^32 (or 2^64) check to see if the current number if "higher" than the previous? Otherwise, what happens if the number wraps around?

-          For sentence at end of paragraph on page 9, "If contained number is lower than the stored number on the server, the server MUST drop the DHCPv6 message". This section is all about client behavior, so should this server processing be in elsewhere (or was this supposed to say client, not server)? Perhaps the how each (client or server) handles this increasing number option can be more generic and moved to a separate section (perhaps with the option definition)? You could then say client (or server) does increasing number check as documented in section 9.1.3?

-          While not wrong, saying "for the following network parameters configuration" is a bit odd. How about just "for the remainder of the client/server interaction"? (Or just drop it - i.e., client selects ONE).

-          On page 10, top paragraph ... changing "Server Identifier option MUST be contained" to "MUST be included"? Contained may confuse people to imply encapsulation of some kind? And, "to avoid the extra decryption for the DHCPv6 servers not for it" to "to avoid the need for other servers receiving the message to attempt to decrypt it"?

-          On page 10, 2nd paragraph. It is a bit odd for the server to send an ORO to the client. While the server can do that in a Reconfigure, it is not generally expected in a Reply. We should consider this carefully and it may be better to have the server send back a specific option (Client Certificate Request or something like that)?

-          On page 10, 3rd paragraph. See earlier about transaction-id and how this is used.

Section 9.1.2

-          Perhaps more should be said as to how signature of message is created (signature field set to all 0's when generating and validating)?

-          I think note about Authentication option in 3315 could be dropped (given that 3315bis has removed that)? There might be a question as to whether to "update" RFC 3315bis to say that if seDHCPv6 is used, the Reconfigure Key Authentication Protocol SHOULD or SHOULD NOT (?) be used. Perhaps there is also some work needed to define how Reconfigure is sent when seDHCPv6 is being used? After all, it would be nice to make use of this to secure it better.

Section 9.1.3

-          I think using OPTION_INCREASING_NUM[BER] would be better (add underscore is most important). This will use more consistent naming with current options.

-          Again see earlier for comments regarding:

o   Number of bits (consider 64)

o   How to compare (modulo 2^32 or 2^64 comparison to allow for rollover). See TCP RFC (793) section 3.3.

Section 9.2

-          See earlier about my comments about transaction-id and what this means and how it is used for this message as I think it is a bit more involved than normal?

-          Options field - I think "or" is wrong here and you want and (Server Identifier Option AND Encrypted-message)? This might be too simple a rewrite as it MUST contain the Encrypted-message option and MUST contain the Server Identifier if the message in the Encrypted-message option has a Server Identifier option - when sent from Client).

Section 9.3:

-          Would changing "IncreasingNumFail" status to "ReplayDetected" be more meaningful?

Other items:

-          As mentioned for 9.1.2, adding something about how server/client deal with Reconfigure would be useful.

-          Clarifying whether Rebind can use seDHCPv6 or not would be good? And how this is done (or not done)? It might be that when using this, one is stuck with Renew or having to return to Solicit instead of using Rebind?

-          "Coffee room" might be changed to "coffee shop"?

-          DHPCv6 is used in at least one place (instead of DHCPv6).

And finally ... the text in the -12 (or was it -11) was more descriptive as to how the client especially should behave. While I think that was probably over specified, it now seems that perhaps it is a bit under specified (section 6)?

---

From: Lishan Li <[email-masked]>
Date: Thu, 28 Jul 2016 16:35:34 +0800

Dear Bernie,

Thanks a lot for your throughout review and comments. For the details,
please see inline (start with LS).

Best Regards,
Lishan

2016-07-26 3:04 GMT+08:00 Bernie Volz (volz) <[email-masked]>:
>
> -          Note: We may want to discuss whether the other options related
> to requesting the certificate option should or should not be in the ORO
> (i.e., signature). I don’t have a problem either way but we should probably
> be consistent with whatever we end up in 3315bis about which options should
> be in the ORO and which should not.
>
[LS]: I have discussed this issue with Jinmei. We think that if the
certificate option is contained, then the signature and Increasing-Num are
also contained. So there is no need to contain the code of signature option
and Increasing-Num option in ORO.
But according to 3315-bits, "Other top-level Options MUST appear in the
Option Request option or the will not be sent by the server". The code of
signature option and Increasing-Num should be contained in the ORO.
Looking forward to your further comments.

> -          Is the “If the hash algorithm field is zero, the signature
> algorithm and hash algorithm are not separated” clear enough? I’m not
> exactly sure myself what this means exactly.
>
[LS]: How about the following sentences:
“If the hash algorithm is zero, then the case indicates that used hash
algorithm is decided by the corresponding signature algorithm".
Sorry for my not clear expression. Ted have modified the contents of
section 1 - section 5. He will modify the remaining sections if he has free
time.

> -          “The message transaction-id is used as the identifier” … what
> exactly does this mean? Do future Encrypted-Query message (and hence
> Encrypted-Response) use this same transaction-id? Or how is this used?
>
[LS]: Yes, we think the Encrypted-Query and Encrypted-Response message will
use the same transaction-id.
Because the client may have multiple public/private key pairs, the
transaction-id is used as identifier for the client's private key to
decrypt the message. In addition, the transaction-id is also used as
identifier for the server's public key to encrypt the message.

> -          On storage of the increasing-number option, I would expect
> that the client (and server)  must keep track of this on a per server (per
> client) basis? So, a client perhaps should keep a record of this “forever”,
> but how should servers manage this? When can they forget this information
> (when all leases have expired)? Or do they need to keep this for a period?
>
[LS]: In our document, the server first sends the Increasing-Num option to
the client. So I think that the server should keep a record of this
"forever". When the transaction between the client and server is finished,
the client can forget the information.

> -          This is perhaps an issue for section 9.1.3, but I would think
> a 64-bit value would be better for the Increasing Number option? And,
> should this be modulo 2^32 (or 2^64) check to see if the current number if
> “higher” than the previous? Otherwise, what happens if the number wraps
> around?
>
[LS]: If the server keeps a record of the increasing number, I also think
64-bit value would be better. And module 2^64 check is also needed. Thanks
for your valuable comments.

> -          For sentence at end of paragraph on page 9, “If contained
> number is lower than the stored number on the server, the server MUST drop
> the DHCPv6 message”. This section is all about client behavior, so should
> this server processing be in elsewhere (or was this supposed to say client,
> not server)? Perhaps the how each (client or server) handles this
> increasing number option can be more generic and moved to a separate
> section (perhaps with the option definition)? You could then say client (or
> server) does increasing number check as documented in section 9.1.3?
>
[LS]: Thanks! Will adopt your suggestion.

> -          On page 10, 2nd paragraph. It is a bit odd for the server to
> send an ORO to the client. While the server can do that in a Reconfigure,
> it is not generally expected in a Reply. We should consider this carefully
> and it may be better to have the server send back a specific option (Client
> Certificate Request or something like that)?
>
[LS]: Stephen suggested us that client authentication should be optional.
So I think that it is better to indicate whether client authentication is
needed in Reply message.
So you mean that we define a new option to specify the request of client
certificate option?
How about the following process method: The server does not specify the
request of client's certificate. And all the clients sends certificates to
the server. If client authentication is necessary, then the server check
it. If client authentication is not necessary, then the server drops the
receiving certificate information.

> -          On page 10, 3rd paragraph. See earlier about transaction-id
[LS]: Please see earlier reply.

> Section 9.1.2
>
> -          Perhaps more should be said as to how signature of message is
> created (signature field set to all 0’s when generating and validating)?
>
[LS]: For the format of encrypted message format,  we have added reference
of RFC5652 which defines the creation method of signature and other content
of encrypted message.

> -          I think note about Authentication option in 3315 could be
> dropped (given that 3315bis has removed that)? There might be a question as
> to whether to “update” RFC 3315bis to say that if seDHCPv6 is used, the
> Reconfigure Key Authentication Protocol SHOULD or SHOULD NOT (?) be used.
> Perhaps there is also some work needed to define how Reconfigure is sent
> when seDHCPv6 is being used? After all, it would be nice to make use of
> this to secure it better.
>
[LS]: In this document, we states that "Authentication option SHOULD NOT be
used if secure DHCPv6 is applied."  The statement that How Reconfigure
should be used needs to be added.

> Section 9.1.3
>
> -          I think using OPTION_INCREASING_NUM[BER] would be better (add
> underscore is most important). This will use more consistent naming with
> current options.
>
[LS]: Agree. Will adopt your suggestion.

> o   How to compare (modulo 2^32 or 2^64 comparison to allow for
> rollover). See TCP RFC (793) section 3.3.
>
[LS]: Thanks a lot for the given reference. Will modify the check method
according to the reference.

> Section 9.2
>
> -          See earlier about my comments about transaction-id and what
> this means and how it is used for this message as I think it is a bit more
> involved than normal?
>
> -          Options field – I think “or” is wrong here and you want and
> (Server Identifier Option AND Encrypted-message)? This might be too simple
> a rewrite as it MUST contain the Encrypted-message option and MUST contain
> the Server Identifier if the message in the Encrypted-message option has a
> Server Identifier option – when sent from Client).
>
[LS]: Will modify it.

>  Other items:
>
> -          As mentioned for 9.1.2, adding something about how
> server/client deal with Reconfigure would be useful.
>
[LS]: Will add it.

> -          Clarifying whether Rebind can use seDHCPv6 or not would be
> good? And how this is done (or not done)? It might be that when using this,
> one is stuck with Renew or having to return to Solicit instead of using
> Rebind?
>
[LS]: Whether return to Solicit or Rebind message, the returned message can
only be decrypted with the selected server(s). So the change to RFC3315 is
that solicit and rebind messages can only be sent to the selected server.

> And finally … the text in the -12 (or was it -11) was more descriptive as
> to how the client especially should behave. While I think that was probably
> over specified, it now seems that perhaps it is a bit under specified
> (section 6)?
>
[LS]: Sorry for my not clear expression. Other author will modify it.
Thanks again.

Best Regards,
Lishan