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

["Bernie Volz (volz)" <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> 
>> -----Original Message-----
>> From: Bernie Volz (volz) [mailto:[e-mail]]
>> Sent: Friday, August 19, 2016 6:38 AM
>> To: 神明達哉 <[e-mail]>; Templin, Fred L <[e-mail]>
>> Cc: <[e-mail]> <[e-mail]>; Francis Dupont <[e-mail]>
>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of ????
>> Sent: Thursday, August 18, 2016 6:54 PM
>> To: Templin, Fred L <[e-mail]>
>> Cc: <[e-mail]> <[e-mail]>; Francis Dupont <[e-mail]>; Bernie Volz (volz) <[e-mail]>
>> Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
>> 
>> At Thu, 18 Aug 2016 22:42:38 +0000,
>> "Templin, Fred L" <[e-mail]> 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