Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 23 August 2016 22:49 UTC

Return-Path: <Fred.L.Templin@boeing.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 90A7C12DBF4 for <dhcwg@ietfa.amsl.com>; Tue, 23 Aug 2016 15:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 yz7lAQ7ZLSRX for <dhcwg@ietfa.amsl.com>; Tue, 23 Aug 2016 15:49:51 -0700 (PDT)
Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37C612DBF6 for <dhcwg@ietf.org>; Tue, 23 Aug 2016 15:49:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7NMnmda053640; Tue, 23 Aug 2016 15:49:48 -0700
Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7NMnfpL053239 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 23 Aug 2016 15:49:41 -0700
Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 15:49:40 -0700
Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 23 Aug 2016 15:49:41 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Bernie Volz (volz)" <volz@cisco.com>
Thread-Topic: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
Thread-Index: AdHz4kyO7hzDfzYnSfqWBjHhBsGHFqBFt3GAoEOccRC/eUedAP/8S5WA//aij8CAFPU5gP//AD5QoEYx64D//16xcKA73swQwHcrkACA7r9rwA==
Date: Tue, 23 Aug 2016 22:49:41 +0000
Message-ID: <c89946cef81345b8bfe6c99ac4660dfb@XCH15-05-05.nw.nos.boeing.com>
References: <92dcf2e0cf08452caa5861f7258ea6c5@XCH15-05-05.nw.nos.boeing.com> <201608121919.u7CJJqcS056876@givry.fdupont.fr> <c5303eef3c124228825f32a40f229107@XCH-ALN-003.cisco.com> <ccaff4d4cb5c4eefb05eee0660c2611c@XCH15-05-05.nw.nos.boeing.com> <f46aa91e4cfb41b29dd2d8186f5959f8@XCH-ALN-003.cisco.com> <ba1c8ff573d7466b8c437373e05f1023@XCH15-05-05.nw.nos.boeing.com> <b65e1dd66b634240b3ca164b2c04c20a@XCH15-05-05.nw.nos.boeing.com> <CAJE_bqfb5sxOpkTEXkwZXckKBWof7U1-W6EFzCHk7ijnMjpMMA@mail.gmail.com> <5ec83aaf4e76497aa4b4d465483bdcf5@XCH15-05-05.nw.nos.boeing.com> <CAJE_bqeKqEgLVC2ZZyUCjsrPP5_suRJ8en2NC+g13Q5PyQL1iw@mail.gmail.com> <30c9413c4662476096ef087ac88f6314@XCH-ALN-003.cisco.com>, <dc9d2c300d574732a12f7f366f6223c0@XCH15-05-11.nw.nos.boeing.com> <3A5F0B79-8C76-4E82-97E9-FA63657DE6C3@cisco.com>
In-Reply-To: <3A5F0B79-8C76-4E82-97E9-FA63657DE6C3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.137.12.6]
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/L5aSE3bCyZqgKqKjZsSCcxzQmy4>
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, Francis Dupont <Francis.Dupont@fdupont.fr>, 神明達哉 <jinmei@wide.ad.jp>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
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: Tue, 23 Aug 2016 22:49:53 -0000

Hi Bernie,

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Tuesday, August 23, 2016 2:56 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> Cc: 神明達哉 <jinmei@wide.ad.jp>; <dhcwg@ietf.org> <dhcwg@ietf.org>; Francis Dupont <Francis.Dupont@fdupont.fr>
> Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
> 
> My point is that we will need to develop a solution for this (i.e. something like the referenced draft); not that this should change
> sedhcpv6 work.

We don't need multiple secure DHCPv6 drafts - we only need for this one to
provide a bit of flexibility.

> Given the focus on pervasive monitoring, encrypting is the correct direction.

If the link-layer already provides security, then only authorized parties will be
admitted onto the link. But, if the link is large, then DHCPv6 itself will need to
provide authentication in order to defeat insider attacks.

In that case, pervasive monitoring of DHCPv6 configuration parameters is not
a problem. The problem being addressed is theft of service by an adversarial
insider. And, again, the secure DHCPv6 spec will address this issue if it is
relaxed to allow an "authentication only" profile.

Thanks - Fred
fred.l.templin@boeing.com

> - Bernie (from iPhone)
> 
> > On Aug 23, 2016, at 1:15 PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Hi Bernie,
> >
> >> Note that encryption will cause significant issues for DOCSIS and likely other deployments where the relay currently snoops the
> traffic.
> >
> > This is exactly the case for AERO, i.e., the relay snoops the traffic which
> > must be available in the clear.
> >
> > So, authentication-only is what is needed. And, it does not need to have
> > anything added to the spec - only a relaxation of what is already there.
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> >> -----Original Message-----
> >> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> >> Sent: Friday, August 19, 2016 6:38 AM
> >> To: 神明達哉 <jinmei@wide.ad.jp>; Templin, Fred L <Fred.L.Templin@boeing.com>
> >> Cc: <dhcwg@ietf.org> <dhcwg@ietf.org>; Francis Dupont <Francis.Dupont@fdupont.fr>
> >> Subject: RE: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
> >>
> >>> so not very convincing to overturn a wg consensus on always enabling encryption
> >>
> >> Agreed. We held discussions with others (Randy Busy, etc.) and are under the belief that what is there is in the right direction. This
> is
> >> an overall solution to the DHCP security solution and tries to address FULL security (as the traffic is encrypted - so it addresses
> privacy).
> >>
> >> I'm not sure if encryption harms anything in  your environment; so what harm is there to use it?
> >>
> >> Note that encryption will cause significant issues for DOCSIS and likely other deployments where the relay currently snoops the
> traffic.
> >> So, we'll need to address how to handle that (either dust of the https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-
> delegate
> >> work or come up with something else). Until something else is in place, those environments just can't make use of this capability.
> >>
> >> - Bernie
> >>
> >> -----Original Message-----
> >> From: jinmei.tatuya@gmail.com [mailto:jinmei.tatuya@gmail.com] On Behalf Of ????
> >> Sent: Thursday, August 18, 2016 6:54 PM
> >> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> >> Cc: <dhcwg@ietf.org> <dhcwg@ietf.org>; Francis Dupont <Francis.Dupont@fdupont.fr>; Bernie Volz (volz) <volz@cisco.com>
> >> Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
> >>
> >> At Thu, 18 Aug 2016 22:42:38 +0000,
> >> "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:
> >>
> >>> Hi, I already made a stronger case as follows:
> >>>
> >>>> I think what that means in terms of this draft is that for some use cases all
> >>>> that is needed is for the client to include a Signature option in its DHCPv6
> >>>> messages to the server. The client does not need to include a Certificate
> >>>> option nor any encryption options. So, I would like it if the draft could
> >>>> include a simple "authentication only" mode of operation.
> >>
> >> To me, it just looks like "in some cases encryption may not be needed"
> >> and not so different from "it's overkilling for me", so not very
> >> convincing to overturn a wg consensus on always enabling encryption.
> >> But it's ultimately up to the wg.
> >>
> >> --
> >> JINMEI, Tatuya