Re: [dhcwg] light review of draft-ietf-dhc-sedhcpv6 and helpful suggestion
Lishan Li <lilishan48@gmail.com> Thu, 20 April 2017 14:22 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 41DDA127241 for <dhcwg@ietfa.amsl.com>; Thu, 20 Apr 2017 07:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 1LITU2JpMPHA for <dhcwg@ietfa.amsl.com>; Thu, 20 Apr 2017 07:22:19 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 8A166127342 for <dhcwg@ietf.org>; Thu, 20 Apr 2017 07:22:19 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id m36so46204615qtb.0 for <dhcwg@ietf.org>; Thu, 20 Apr 2017 07:22:19 -0700 (PDT)
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=V+Fq0eVa1rmp1Pu4aWTcOBDScqgo5d9ByFd83tSSbqs=; b=StZ40jnGyC74nfhQW9hF2ZcIcMIog2PeK5rKeH/TZVnVZXjlhi4Q+R68AYfSD/yCIg DQb2vQ2IfKh3s+b9kylau4kW3B7p/U9qy3zK5jIPa71fVDmHb0OucV/zoit/QwqB3cmS mKDQciPjkGrBXN1YVTb8hstbodXR9kzPFb2J9Mc45qpc08+m/swWF82EPlXM8GWlOTRX yIpeJ0D7NiWpaXL3SyXyWystCLz3A9Ps06XqpK4c4XzToy0qoAeneH+pBWLR6BGLnlWH P2IqhPa5DsadGX8bvGnhly46gR6NjXeKVrnv3LZfxwDv7euXtLdYNK+9gsWFqT0I/oRF ZG0A==
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=V+Fq0eVa1rmp1Pu4aWTcOBDScqgo5d9ByFd83tSSbqs=; b=tKwaQiKKfyBfRsqLTbvF0dguBixcKLB/J8EpF8eJc2cLdBmgjYZDPGi6X64PFUScj8 6DT0W0U0SHs/34QnOE4nzdvYSBCQIUPNsG/s0GZnhcho/J2MTjI3Mz0bJsdxVInfyfoz pfOi1uWSmZIdvvrA+koVsUsWQMkxbGw63EJ+iOxQxz1Gl/MajVfJSwk7UHuaEcNX8orb YGKkPr+AEZYonWA3blv0yG4KPVHqOzt6mzNuuEFViW4KRdUShF7gHai1QD7SlnLtIPIz jEl+B7NwfCK5N2nKeG4lH2XuB9EKfWhPp6ElK/yUMHC/IZM+577GUjSMoYpJMzk54+Wh NzMg==
X-Gm-Message-State: AN3rC/4eSIhJyMIIi3PRoFM4a+vtUBdXXxLmoB1DwEtiwfHxgT/BPQx5 odF85/nBirUdIXEQ7HUj5Wr7gx1W3Q==
X-Received: by 10.237.34.22 with SMTP id n22mr8009278qtc.164.1492698138651; Thu, 20 Apr 2017 07:22:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.58.71 with HTTP; Thu, 20 Apr 2017 07:22:18 -0700 (PDT)
In-Reply-To: <CAHbuEH7ymFOtU7HBz3FgsrBQmwaxFwm8gU=b3xye1-T0SiOGxw@mail.gmail.com>
References: <CAHbuEH7ymFOtU7HBz3FgsrBQmwaxFwm8gU=b3xye1-T0SiOGxw@mail.gmail.com>
From: Lishan Li <lilishan48@gmail.com>
Date: Thu, 20 Apr 2017 22:22:18 +0800
Message-ID: <CAJ3w4Ne0WGFO_PU0wtEH5hWPt_U9oh+3gdYK_C5+m5epVoEe9w@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="001a113e49b84fb1d8054d99de1b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/7gHmv5P5qZrxlf7ev37JpvWBlTo>
Subject: Re: [dhcwg] light review of draft-ietf-dhc-sedhcpv6 and helpful suggestion
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 20 Apr 2017 14:22:21 -0000
Hi, Kathleen, Thanks a lot for your valuable comments on the draft. Please see inline. Best Regards, Lishan 2017-04-18 4:43 GMT+08:00 Kathleen Moriarty <kathleen.moriarty.ietf@gmail. com>: > Dear authors, > > I just skimmed the draft triggered by another review and noticed the > deployment concerns in the WGLC summary sent to the list. think I can > help here with the remaining issues on making it easier to deploy. > > First, I'm really glad to see this work. Thanks for all of your > efforts on it! Second, I know this is late in the process, but I > think more text on opportunistic security for IPsec is worth > documenting to overcome implementation hurdles and address the coffee > shop use cases. I didn't see a reference to: > > https://tools.ietf.org/html/rfc7619 > > and am thinking the authors/WG might not be aware of this work. > Additionally, it should be noted that there are several Linux > implementations for IPsec with NULL authentication (OS). Paul > Woulters is a author on the mentioned RFC and did implement this with > IPsec for RedHat. > [LS]: In the before, we are just aware of the work of RFC7435 and not aware of RFC7619. For the reference of RFC7619, I have one question and want to get your guidance. RFC7619 proposes the NULL authentication method for IPsec. If we add the reference of RFC7619 for coffee shop scenario, then IPsec is used to protect the security of DHCPv6? Right? However, our document defines the secure DHCPv6 mechanism, not using the IPsec mechanism. If the IPsec mechanism is used, then the client and Relay, Relay and Relay, Relay and server need to establish the IPsec communication. And for our document, we just want to protect the information between the client and server, so secure DHCPv6 is suited. As opportunistic security for IPsec, our document proposes opportunistic security for DHCPv6. For the coffee shop, then the client and server can start the NULL authentication mode, which is easy to deployed. Could you please help check whether my understanding correct? Looking forward to your further comments. > > Michael Richardson is an author on the draft: > https://tools.ietf.org/html/draft-richardson-ipsec-opportunistic-17 > > documenting the OS IPsec implementation for the Linux FreeS/WAN project. > > I think it would be beneficial to see text that has OS as mandatory to > implement (MTI) and upgradeable to authenticated IPsec when practical. > Ideally, they would both be MTI, not mandatory to use (MTU) at least > for the authenticated since that is too hard. But MTI on > opportunistic would be a great next step that could be deployed. If > we were able to get DCHPv6 supporting this option in code with OS, > then people could turn it on. As you point out in the draft, > enterprise and other managed scenarios could use an option with > authentication if implemented. I think the MTI versus MTU could have > been more clear in this draft and the relay one that just went through > the IESG review. > > The current OS text leaves me, the reader, thinking it won't be > implemented as it's not pointing to a practical implementable RFC. I > am copying Michael and Paul (mentioned above) as one of them might be > willing to help with text. I think this will greatly assist with the > deployability of session encryption. [LS]: So, in our document, we need to states that: Opportunistic security is mandatory to implement, not just say that opportunistic security can be used for secure DHCPv6 deployment. Could you please help check whether my understanding correct? Thanks again, Lishan
- [dhcwg] light review of draft-ietf-dhc-sedhcpv6 a… Kathleen Moriarty
- Re: [dhcwg] light review of draft-ietf-dhc-sedhcp… Michael Richardson
- Re: [dhcwg] light review of draft-ietf-dhc-sedhcp… Lishan Li