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

Lishan Li <lilishan48@gmail.com> Wed, 21 December 2016 07:44 UTC

Return-Path: <lilishan48@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDD61294A2 for <dhcwg@ietfa.amsl.com>; Tue, 20 Dec 2016 23:44:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElcIVEWXDm0U for <dhcwg@ietfa.amsl.com>; Tue, 20 Dec 2016 23:44:47 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91E471294D1 for <dhcwg@ietf.org>; Tue, 20 Dec 2016 23:44:47 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id w33so198788113qtc.3 for <dhcwg@ietf.org>; Tue, 20 Dec 2016 23:44:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lFRRpfRHzVxKwMCwkw7mjvELpFyqocbbzh8Tae2K14s=; b=NjIOhZl2frCBkBQjtVpUQYGQLvyr2o49bfgS4KtrfJbLzijvpvKTXkE9i6V9TQPb6M 4yhAb0ZXM1UjaYd/KaMjBPIawz5dKQlkA3xobb3wiE7y4PDur/ElYNs/eYUMgkKq3xEW n9biVZxBGRrEsWWpx6mPWW0+BAm9qNgpt3vPhTvJI/B7gbh+GxuTYD+tRubTSVztEXk3 tF3Dv3TYg5hcthh5xV6Zv1aphKeYwCnOOj1M/g3mZH8KxcZH2Spx33flvgPVYTcGApEq /wE48xw4NY/Lw/aVcba1yP6AIIjjFWFCKKiJCetFTGwGGC3ataSEnsXmLA3FBauja8OC xPzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lFRRpfRHzVxKwMCwkw7mjvELpFyqocbbzh8Tae2K14s=; b=YP5i73E1WEtI/B5H2ivbpBngWU6/dT4VWitRBLJcJk9eyZKVOeMYFIWU6soRdVkval imQ2sfHpFkGphfyy6nTckIIdhDGm6asGqfBcj+ijRNP+b0eothklSJfyfqTVg0+Uv7gs AFCxAi1vuh+n7ObKNbSsnnnBcGoLlqlMn1vv0stWVKbfN9ui8e74Mcl0BmCMBjX/tqOo 6VXFxY8soTYxcg7OjOa1NGujkXxeLfL0036vvgiCvLWrkWpP2URU8bmkmtm9Y56Tn/gD 64VhSEWYySts4GWM+WUfrd81R75WQoh4+GJ0aWXUhG/vFOa3ULtt3O1tqCrm14XSwjMN bKbQ==
X-Gm-Message-State: AIkVDXJnJLWA0c2BZBpDLkMoVwNAjV5GsoBIugRMoSe/L2a6Oi1nnICepfH9GU8An4MAMYT9NqMAL+Ck770pZg==
X-Received: by 10.200.45.75 with SMTP id o11mr3694569qta.254.1482306286771; Tue, 20 Dec 2016 23:44:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.36.211 with HTTP; Tue, 20 Dec 2016 23:44:46 -0800 (PST)
In-Reply-To: <51d8e6bf623f4a639eb4af7e1881511c@XCH-ALN-003.cisco.com>
References: <148092498114.3294.14134801279747342720.idtracker@ietfa.amsl.com> <CAJ3w4NfufMn9yzACowX728Cxxn4Rdci5pXAwVYB3d2fKDtNF2Q@mail.gmail.com> <352fe8719ab34fd3ad7b0af2e7127bb8@XCH-ALN-003.cisco.com> <CAJ3w4NfR8jLkRAHnQ072cnO5hJUxvhm+n=gSFx9ooQQyNVqb8Q@mail.gmail.com> <51d8e6bf623f4a639eb4af7e1881511c@XCH-ALN-003.cisco.com>
From: Lishan Li <lilishan48@gmail.com>
Date: Wed, 21 Dec 2016 15:44:46 +0800
Message-ID: <CAJ3w4Ne-T0LiEcTpa_YvEwq6rmVkucVOKP9H4v9qtNVEBp7wAQ@mail.gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Content-Type: multipart/alternative; boundary=001a1142b174abe650054426533f
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/d-930tgt4q047dQKD7DxFhpV9Ro>
Cc: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-18.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2016 07:44:49 -0000

2016-12-21 5:29 GMT+08:00 Bernie Volz (volz) <volz@cisco.com>;:

> 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