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

[Lishan Li <[e-mail]>]

2016-12-21 5:29 GMT+08:00 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.
>
[LS2]: Thanks a lot for your guidance. Will add the reference of RFC4034
and RFC6840 for this issue.

>
>
>
>
> 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?
>
[LS2]: It really misses some text. Will add some text to illustrate it
clearly.

>
>
> 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).
>
[LS2]: Got it. Will delete this part.

> 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:
>
>
> Best Regards,
Lishan