Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-18.txt

["Bernie Volz (volz)" <[e-mail]>]

Hi:

I dropped the CC of the original messages I’m replying to as it was extremely large and required mailing list administrator action. For those that want to review that, see https://www.ietf.org/mail-archive/web/dhcwg/current/msg17817.html.

Here’s a few comments with respect to your comments on my comments! Thanks again for all your effort on this document!

For General comment:

[LS]: According to RFC 4034, for the same problem, it define the key tag calculation algorithm

BV2> Referencing RFC 4034 (Appendix B) would be a good way to resolve this. Though it may be worth checking the RFCs that update this one to see if there’s anything changed in those - Updated by: 4470, 6014, 6840, 6944.

RFC 6840:
5.5<https://tools.ietf.org/html/rfc6840#section-5.5>.  Key Tag Calculation
   Appendix B.1 of [RFC4034]<https://tools.ietf.org/html/rfc4034#appendix-B.1> incorrectly defines the Key Tag field
   calculation for algorithm 1.  It correctly says that the Key Tag is
   the most significant 16 of the least significant 24 bits of the
   public key modulus.  However, [RFC4034<https://tools.ietf.org/html/rfc4034>] then goes on to incorrectly
   say that this is fourth-to-last and third-to-last octets of the
   public key modulus.  It is, in fact, the third-to-last and second-to-
   last octets.


For section 5.2:
BV> Also, given that the WG is working on Failover Protocol in parallel, how would seDHCPv6 work with Failover? And should we consider anything related to this. One possibility is that the failover partners could exchange some information (so we might have to define a new failover option eventually). But then my comment above about the Server Identifier may cause other issues? It may just be that once a client picks one of the failover partners, it will have to stick with that partner or return to the server discovery phase? But that would be too bad. (I had thought about whether the failover partners should share a Server Identifier, but that likely complicates other cases so not sure it is best.) Perhaps when the failover partners exchange the above mentioned information, that could include the Server Identifier which would allow them to be used.
[LS]: Sorry for not reviewing the draft. Will review it and reply to you later.

BV2> This is just something that happens when two drafts that might impact each other are being worked on at the same time. While great if you want to think about, it was more to raise the issue so that we give it some thought (it may be appropriate for those working on failover to work with you on this). I just wanted to bring out the issue so we would think about it before it was too late.
For section 6:
[LS]: The reply message is the first message that contains the increasing-number option. So, the
client does not verify it, but record the value of the locally stored increasing number as the value of it.

BV2> That sounds appropriate. Did I just misunderstand this in my reading or was this missing text?

For section 8:
   Relay agent is RECOMMENDED to cache server announcements to form the
   list of the available DHCPv6 server certs.  If the relay agent
BV> NO! I do not think this is a wise idea at all. Please remove this! Relays should not do this!
[LS]: In the before, Ted suggested us to add this part. What is the caused problem? Looking forward to your guidance.

I don’t think this is a good idea. Let the servers handle these Information-Requests. Having the relay’s respond on behalf of servers isn’t a good idea and also can’t work as the XID of the Information-Request messages will be different and hence unless the relay can encrypt on the server’s behalf, how could this work? (I assume that the signature is calculated over the entire message, which includes the XID field).
In 10.1.3 you write:
   The Signature option allows a signature that is signed by the private
   key to be attached to a DHCPv6 message.  The Signature option could
   be in any place within the DHCPv6 message while it is logically
   created after the entire DHCPv6 header and options.  It protects the
   entire DHCPv6 header and options, including itself.  The format of
   the Signature option is described as follows:

Happy Holidays!

-          Bernie