Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

"Templin, Fred L" <> Fri, 24 March 2017 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52BDD129548; Fri, 24 Mar 2017 10:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uLXHR2fyjsXN; Fri, 24 Mar 2017 10:25:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F25712949A; Fri, 24 Mar 2017 10:25:05 -0700 (PDT)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v2OHP4jS043768; Fri, 24 Mar 2017 10:25:04 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v2OHOvGW043562 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 24 Mar 2017 10:24:58 -0700
Received: from (2002:8988:eede::8988:eede) by (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 24 Mar 2017 10:24:57 -0700
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Fri, 24 Mar 2017 10:24:56 -0700
From: "Templin, Fred L" <>
To: Tomek Mrugalski <>, dhcwg <>
CC: draft-ietf-dhc-sedhcpv6 authors <>
Thread-Topic: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
Thread-Index: AQHSmBEZNN0XaqjWoEec2cWUphDKn6GkVjeg
Date: Fri, 24 Mar 2017 17:24:56 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Mar 2017 17:25:08 -0000

Hi Tomek,

With apologies for the delayed response, see below:

> -----Original Message-----
> From: dhcwg [] On Behalf Of Tomek Mrugalski
> Sent: Wednesday, March 08, 2017 5:37 AM
> To: dhcwg <>
> Cc: draft-ietf-dhc-sedhcpv6 authors <>
> Subject: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
> Hi,
> draft-ietf-dhc-sedhcpv6-21 describes a mechanism for using public key
> cryptography to provide end-to-end security between DHCPv6 clients and
> servers. The mechanism provides encryption in all cases, and can be used
> for authentication based on pre-sharing of authorized certificates. This
> draft has started in 2013, but the whole DHCPv6 security saga is much
> longer and begins in 2008. This draft was submitted to IESG in mid-2015.
> The guidance received was clear that  substantial changes are needed. As
> a result, "encrypt everywhere, authenticate if you can" approach was used.
> Authors believe this draft to be ready for working group last call.
> Please send your substantial comments to the mailing list and express
> your opinion whether this draft is ready for publication. Feel free to
> send nitpicks and minor corrections to the authors directly. This is a
> complex draft, so the chairs believe 3 weeks WGLC is in order. Please
> send your comments no later than March 29th. Bernie and I will determine
> consensus and will discuss during Chicago meeting as needed.
> To initiate the discussion, I have two related questions. The chairs
> would love to hear your opinions on those.
> 1. The "encrypt everywhere" paradigm means that in deployments that do
> snooping on relay will break down. To solve this problem, we need a
> assignment notification mechanism, similar to the one described in
> draft-ietf-dhc-dhcpv6-agentopt-delegate-04. That draft expired many
> years ago. This matter was discussed in Seoul and the minutes describe
> the conclusion as:
>   The discussion gravitated towards not resurrecting until the sedhcpv6
>   I-D progresses further. We will reevaluate this once sedhcpv6 is done.
> Do you want the WG to resurrect agentopt-delegate a) now, b) when
> sedhcpv6 is sent to IESG or c) when sedhcpv6 is published as RFC? d) we
> need a completely new draft and I'm volunteering to work on it.

a) now. What would be the reason for any delay?

If there is any assistance I could give to the effort I would be willing
to help.

Thanks - Fred

> 2. One of the authors suggested that this protocol is quite complex and
> having a feedback from an implementation (or ideally two interoperating)
> would be very important and would likely result in some changes to the
> draft. It's probably too late for Chicago, but we can organize a
> sedhcpv6 hackathon in Prague. Two likely implementations would be WIDE
> and Kea, as those two are open source and have an old version of the
> draft partially implemented. Do you think such a hackathon would be
> useful? Are you willing to participate?
> Title: Secure DHCPv6
> Authors: L. Li, S. Jiang, Y.Cui, T.Jinmei, T.Lemon, D.Zhang
> Filename: draft-ietf-dhc-sedhcpv6-21
> Pages: 31
> Date: 2017-02-21
> Link:
> Responses by March 29th are appreciated.
> Thanks,
> Bernie and Tomek
> _______________________________________________
> dhcwg mailing list