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