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
- [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-18.txt internet-drafts
- Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-1… Lishan Li
- Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-1… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-1… Lishan Li
- Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-1… Bernie Volz (volz)
- Re: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-1… Lishan Li