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

[Lishan Li <[e-mail]>]

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) <[e-mail]>:
>
> -          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
> and how this is used.
>
[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.

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