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

[Ted Lemon <[e-mail]>]

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 <[e-mail]> 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
> [e-mail] <mailto:[e-mail]>
>  
> From: Lishan Li [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Tuesday, August 23, 2016 8:40 PM
> To: Bernie Volz (volz) <[e-mail] <mailto:[e-mail]>>
> Cc: Templin, Fred L <[e-mail] <mailto:[e-mail]>>; <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>>; Francis Dupont <[e-mail] <mailto:[e-mail]>>; 神明達哉 <[e-mail] <mailto:[e-mail]>>
> 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) <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
> >
> >> -----Original Message-----
> >> From: Bernie Volz (volz) [mailto:[e-mail] <mailto:[e-mail]>]
> >> Sent: Friday, August 19, 2016 6:38 AM
> >> To: 神明達哉 <[e-mail] <mailto:[e-mail]>>; Templin, Fred L <[e-mail] <mailto:[e-mail]>>
> >> Cc: <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>>; Francis Dupont <[e-mail] <mailto:[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 <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]> [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of ????
> >> Sent: Thursday, August 18, 2016 6:54 PM
> >> To: Templin, Fred L <[e-mail] <mailto:[e-mail]>>
> >> Cc: <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>>; Francis Dupont <[e-mail] <mailto:[e-mail]>>; Bernie Volz (volz) <[e-mail] <mailto:[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] <mailto:[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
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>
>  
> _______________________________________________
> dhcwg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>