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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 24 August 2016 16:23 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 3CB5B12D104 for <dhcwg@ietfa.amsl.com>; Wed, 24 Aug 2016 09:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pbOXUCfaYswM for <dhcwg@ietfa.amsl.com>; Wed, 24 Aug 2016 09:23:24 -0700 (PDT)
Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 784D812D096 for <dhcwg@ietf.org>; Wed, 24 Aug 2016 09:23:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u7OGNNwo045492; Wed, 24 Aug 2016 09:23:23 -0700
Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u7OGNDYm045255 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 24 Aug 2016 09:23:14 -0700
Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 24 Aug 2016 09:23:13 -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; Wed, 24 Aug 2016 09:23:13 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
Thread-Index: AdHz4kyO7hzDfzYnSfqWBjHhBsGHFqBFt3GAoEOccRC/eUedAP/8S5WA//aij8CAFPU5gP//AD5QoEYx64D//16xcKA73swQwHdAwFuA7cV/AIHbDQ2Ag7aBK1A=
Date: Wed, 24 Aug 2016 16:23:13 +0000
Message-ID: <091180442e44490ba451874d1543f814@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> <CAJ3w4NdjgVxvnvuaWjGM=qtOe0qUq4N96fVXsbNrf=YkhiABbQ@mail.gmail.com> <2f45b99b50f84b1280e92ad824e39e26@XCH15-05-05.nw.nos.boeing.com> <9E9A9543-ECB0-4D99-A00F-1AAD813B6522@fugue.com>
In-Reply-To: <9E9A9543-ECB0-4D99-A00F-1AAD813B6522@fugue.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: multipart/alternative; boundary="_000_091180442e44490ba451874d1543f814XCH150505nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/voBHlMSXJgSgsnOUjCvS_eiSVXU>
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
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: Wed, 24 Aug 2016 16:23:27 -0000

Hi Ted,


Ø  Can you cite some evidence to show that AERO will be a common use case for DHCPv6?

I have published a proof-of-concept implementation, and we will soon be
publishing a more production-oriented implementation. AERO is being
mentioned in many different working groups, and cuts across many use
cases – corporate mobile device users and aeronautical communications
to name two.


Ø  As for the AERO encryption problem, I assume it’s that you want some data that’s

Ø  in the encrypted part of the packet.

The relay needs to see the IA_PD option that the server returns to
the client in a Reply message.


Ø  The solution is to send that data in the relay agent portion of the packet,

Ø  since presumably it’s the relay agent that’s going to consume it.

Can the server include the IA_PD option in-the-clear in the relay agent
portion of the packet?


Ø  This is a problem that needs to be solved anyway in order for secure DHCPv6

Ø  to work in general.   If we were to solve that problem, would it address your concern?

I think possibly so. If the server can feed the relay the IA_PD option then
all is well. In fact, I think this same issue would apply in any other prefix
delegation use case where the relay needs to inspect the IA_PD so it
can inject routing information into the routing system.

Am I understanding correctly?

Thanks – Fred

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Wednesday, August 24, 2016 8:24 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: <dhcwg@ietf.org> <dhcwg@ietf.org>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

Can you cite some evidence to show that AERO will be a common use case for DHCPv6?

As for the AERO encryption problem, I assume it’s that you want some data that’s in the encrypted part of the packet.   The solution is to send that data in the relay agent portion of the packet, since presumably it’s the relay agent that’s going to consume it.

This is a problem that needs to be solved anyway in order for secure DHCPv6 to work in general.   If we were to solve that problem, would it address your concern?

On Aug 24, 2016, at 11:03 AM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:

I have presented a use case (AERO) that needs DHCPv6 authentication but
not encryption, and I have stated that encryption will be incompatible with
my use case. Bernie mentioned another use case that will be incompatible.

As far as I can tell, AERO will be one of the most important use cases for
DHCPv6, and also as far as I can tell secdhcpv6 could easily be relaxed to
satisfy the need. So, drawing a hard line like this is essentially blocking an
important use case for no good reason. Is that really what people want?

Thanks – Fred
fred.l.templin@boeing.com<mailto:fred.l.templin@boeing.com>

From: Lishan Li [mailto:lilishan48@gmail.com]
Sent: Tuesday, August 23, 2016 8:40 PM
To: Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>
Cc: Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>; <dhcwg@ietf.org<mailto:dhcwg@ietf.org>> <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>; Francis Dupont <Francis.Dupont@fdupont.fr<mailto:Francis.Dupont@fdupont.fr>>; 神明達哉 <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

Hi, Fred,

In the Applicability part of secure DHCPv6, it is stated that: secure DHCPv6 is applicable in any environment where physical security on the link is not assured and attacks on DHCPv6 are a concern.
In addition, after the discussion in Yokohama, we have reached a consensus that: Given the focus on pervasive monitoring, all encrypting is the correct direction.


Best Regards,
Lishan

2016-08-24 5:55 GMT+08:00 Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>>:
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.

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

- Bernie (from iPhone)

> On Aug 23, 2016, at 1:15 PM, Templin, Fred L <Fred.L.Templin@boeing.com<mailto: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<mailto:fred.l.templin@boeing.com>
>
>> -----Original Message-----
>> From: Bernie Volz (volz) [mailto:volz@cisco.com<mailto:volz@cisco.com>]
>> Sent: Friday, August 19, 2016 6:38 AM
>> To: 神明達哉 <jinmei@wide.ad.jp<mailto:jinmei@wide.ad.jp>>; Templin, Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>>
>> Cc: <dhcwg@ietf.org<mailto:dhcwg@ietf.org>> <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>; Francis Dupont <Francis.Dupont@fdupont.fr<mailto: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> [mailto: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<mailto:Fred.L.Templin@boeing.com>>
>> Cc: <dhcwg@ietf.org<mailto:dhcwg@ietf.org>> <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>; Francis Dupont <Francis.Dupont@fdupont.fr<mailto:Francis.Dupont@fdupont.fr>>; Bernie Volz (volz) <volz@cisco.com<mailto: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<mailto: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

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
https://www.ietf.org/mailman/listinfo/dhcwg