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

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Aug 2016 15:10:10 +0000

Should RFC3315(bis) cite 'draft-ietf-dhc-secdhcpv6? If so, the following
comments should be addressed:

> 20) Section 19, this whole Section needs to either import
>     'draft-ietf-dhc-sedhcpv6' or simply say that a new DHCP
>     authentication mechanism will be specified in a future
>     document.
> 
> 21) Section 20.11 again should mention 'draft-ietf-dhc-sedhcpv6'
>     or simply say that a new DHCP authentication mechanism will
>     be specified in a future document.
> 
> 22) Section 21, same comment as for 20) and 21) above.

Thanks - Fred
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Aug 2016 21:19:52 +0200

In your previous mail you wrote:

>  Should RFC3315(bis) cite 'draft-ietf-dhc-secdhcpv6?

=> IMHO it should not and in particular it should not be referenced
as a replacement for authentication according to the new direction
taken by secdhcpv6 (i.e., encryption vs authentication).

Regards

[email-masked]

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 12 Aug 2016 19:38:29 +0000

I second this ... mostly because:

1. It is still very much a work in progress.
2. Several previous attempts at this had to be rebooted; while we hope that isn't the case this time around ...
3. This is the base standard and extensions to it will always exist.

Note: We only reference two drafts, prefix-length-hints and topo-conf. Topo-conf will be an RFC well before this one (it is at RFC-editor). And, we still need to finalize what we do re: prefix-length-hints in this document (see Ticket #114 - https://trac.tools.ietf.org/group/dhcpv6bis/ticket/114).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: Friday, August 12, 2016 3:20 PM
To: Templin, Fred L <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

>  Should RFC3315(bis) cite 'draft-ietf-dhc-secdhcpv6?

=> IMHO it should not and in particular it should not be referenced as a replacement for authentication according to the new direction taken by secdhcpv6 (i.e., encryption vs authentication).

Regards

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 12 Aug 2016 23:22:30 +0000

Hi, OK to remain silent on this but:

> => IMHO it should not and in particular it should not be referenced as a replacement for authentication according to the new direction

this part has me worried. My use case is a large multi-access link that is secured
via physical and/or link-layer security. But, the link is still vulnerable to "insider
attacks" where a rogue node might try to fool the DHCPv6 server into giving it
configuration information pertaining to a victim node. So, I was counting on
secdhcpv6 to provide a means for the server to authenticate each client.
Has something changed?

Thanks - Fred

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Friday, August 12, 2016 12:38 PM
> To: Francis Dupont <[email-masked]>; Templin, Fred L <[email-masked]>
> Subject: RE: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
> 
> Note: We only reference two drafts, prefix-length-hints and topo-conf. Topo-conf will be an RFC well before this one (it is at RFC-
> editor). And, we still need to finalize what we do re: prefix-length-hints in this document (see Ticket #114 -
> https://trac.tools.ietf.org/group/dhcpv6bis/ticket/114).
> 
> - Bernie
> 
> => IMHO it should not and in particular it should not be referenced as a replacement for authentication according to the new direction

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 12 Aug 2016 23:58:08 +0000

I'd suggest you read the latest sedhcpv6 draft - https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6. My understanding is that a client can present a certificate to the server.

If you have comments on it, please do send them along. We are looking for additional comments on this document.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, August 12, 2016 7:23 PM
To: Bernie Volz (volz) <[email-masked]>; Francis Dupont <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: RE: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

Hi, OK to remain silent on this but:

> => IMHO it should not and in particular it should not be referenced as 
> a replacement for authentication according to the new direction taken by secdhcpv6 (i.e., encryption vs authentication).

this part has me worried. My use case is a large multi-access link that is secured via physical and/or link-layer security. But, the link is still vulnerable to "insider attacks" where a rogue node might try to fool the DHCPv6 server into giving it configuration information pertaining to a victim node. So, I was counting on
secdhcpv6 to provide a means for the server to authenticate each client.
Has something changed?

Thanks - Fred

> Note: We only reference two drafts, prefix-length-hints and topo-conf. 
> Topo-conf will be an RFC well before this one (it is at RFC- editor). 
> And, we still need to finalize what we do re: prefix-length-hints in this document (see Ticket #114 - https://trac.tools.ietf.org/group/dhcpv6bis/ticket/114).
> 
> - Bernie
> 
> => IMHO it should not and in particular it should not be referenced as 
> a replacement for authentication according to the new direction taken by secdhcpv6 (i.e., encryption vs authentication).
> 
> Regards
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Aug 2016 15:32:56 +0000

OK, I will have a look.

Thanks - Fred

> Sent: Friday, August 12, 2016 4:58 PM
> To: Templin, Fred L <[email-masked]>; Francis Dupont <[email-masked]>
> this part has me worried. My use case is a large multi-access link that is secured via physical and/or link-layer security. But, the link is
> still vulnerable to "insider attacks" where a rogue node might try to fool the DHCPv6 server into giving it configuration information
> pertaining to a victim node. So, I was counting on
> > And, we still need to finalize what we do re: prefix-length-hints in this document (see Ticket #114 -

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Aug 2016 21:35:34 +0000

Hi Bernie,

I glanced through the document, and my first impression is that it has become
overkill for what I need. For my needs, there is already link-layer security and
so I do not need encryption between the client and server. But, the link is
very large and may be vulnerable to an insider attack in which the attacker
impersonates a legitimate client in an attempt to steal the legitimate client's
service. So, all I need is some way for the client to authenticate itself to the
server assuming that the client and server have manually configured
public/private keys and certificates before the client is put into service.

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.

Thanks - Fred

> From: dhcwg [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Monday, August 15, 2016 8:33 AM
> > I'd suggest you read the latest sedhcpv6 draft - https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6. My understanding is that a
> client
> > can present a certificate to the server.
> >

---

From: 神明達哉 <[email-masked]>
Date: Wed, 17 Aug 2016 17:25:43 -0700

At Tue, 16 Aug 2016 21:35:34 +0000,
"Templin, Fred L" <[email-masked]> wrote:

> so I do not need encryption between the client and server.
[...]
> include a simple "authentication only" mode of operation.

The currently described approach is based on a WG consensus made at
the Yokohama IETF last November.  So you'll need a stronger argument
than "it's overkill for me" if you want to change that.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Aug 2016 22:42:38 +0000

Thanks - Fred

> From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
> Sent: Wednesday, August 17, 2016 5:26 PM
> Cc: Bernie Volz (volz) <[email-masked]>; Francis Dupont <[email-masked]>; <[email-masked]> <[email-masked]>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 18 Aug 2016 15:54:03 -0700

At Thu, 18 Aug 2016 22:42:38 +0000,

> > 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 19 Aug 2016 13:37:32 +0000

> 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: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, August 18, 2016 6:54 PM
To: Templin, Fred L <[email-masked]>
Cc: <[email-masked]> <[email-masked]>; Francis Dupont <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Aug 2016 20:15:24 +0000

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

> Sent: Friday, August 19, 2016 6:38 AM
> To: 神明達哉 <[email-masked]>; Templin, Fred L <[email-masked]>
> Cc: <[email-masked]> <[email-masked]>; Francis Dupont <[email-masked]>
> 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).
> 
> 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
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 23 Aug 2016 21:55:44 +0000

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 <[email-masked]> wrote:
> 
> Hi Bernie,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Aug 2016 22:49:41 +0000

Hi Bernie,

> Sent: Tuesday, August 23, 2016 2:56 PM
> Cc: 神明達哉 <[email-masked]>; <[email-masked]> <[email-masked]>; Francis Dupont <[email-masked]>

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

---

From: Lishan Li <[email-masked]>
Date: Wed, 24 Aug 2016 11:39:44 +0800

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) <[email-masked]>:

> 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.
>
> >> Note that encryption will cause significant issues for DOCSIS and
> likely other deployments where the relay currently snoops the traffic.
> >
> >> 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).
> >>
> >> 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
> >>
> >> Cc: <[email-masked]> <[email-masked]>; Francis Dupont <
> [email-masked]>; Bernie Volz (volz) <[email-masked]>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Aug 2016 15:03:00 +0000

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

From: Lishan Li [mailto:[email-masked]]
Sent: Tuesday, August 23, 2016 8:40 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Templin, Fred L <[email-masked]>; <[email-masked]> <[email-masked]>; Francis Dupont <[email-masked]>; 神明達哉 <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>>:
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.

- Bernie (from iPhone)

> On Aug 23, 2016, at 1:15 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Bernie,
>
> [email-masked]<mailto:[email-masked]>
>
>> From: Bernie Volz (volz) [mailto:[email-masked]<mailto:[email-masked]>]
>> To: 神明達哉 <[email-masked]<mailto:[email-masked]>>; Templin, Fred L <[email-masked]<mailto:[email-masked]>>
>> Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; Francis Dupont <[email-masked]<mailto:[email-masked]>>
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ????
>> To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>
>> Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; Francis Dupont <[email-masked]<mailto:[email-masked]>>; Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
>> "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
>>

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Aug 2016 11:23:33 -0400

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 <[email-masked]> wrote:
> 
> [email-masked] <mailto:[email-masked]>
>  
> From: Lishan Li [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>
> Cc: Templin, Fred L <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>; Francis Dupont <[email-masked] <mailto:[email-masked]>>; 神明達哉 <[email-masked] <mailto:[email-masked]>>
> 2016-08-24 5:55 GMT+08:00 Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>:
> > On Aug 23, 2016, at 1:15 PM, Templin, Fred L <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi Bernie,
> >
> > [email-masked] <mailto:[email-masked]>
> >
> >> From: Bernie Volz (volz) [mailto:[email-masked] <mailto:[email-masked]>]
> >> To: 神明達哉 <[email-masked] <mailto:[email-masked]>>; Templin, Fred L <[email-masked] <mailto:[email-masked]>>
> >> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>; Francis Dupont <[email-masked] <mailto:[email-masked]>>
> >> 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>
> >> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of ????
> >> To: Templin, Fred L <[email-masked] <mailto:[email-masked]>>
> >> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>; Francis Dupont <[email-masked] <mailto:[email-masked]>>; Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>
> >> "Templin, Fred L" <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dhcwg <https://www.ietf.org/mailman/listinfo/dhcwg>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Aug 2016 16:23:13 +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:[email-masked]]
Sent: Wednesday, August 24, 2016 8:24 AM
To: Templin, Fred L <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

On Aug 24, 2016, at 11:03 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Thanks – Fred

From: Lishan Li [mailto:[email-masked]]
Sent: Tuesday, August 23, 2016 8:40 PM
To: Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Cc: Templin, Fred L <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; Francis Dupont <[email-masked]<mailto:[email-masked]>>; 神明達哉 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

Hi, Fred,

Best Regards,
Lishan

- Bernie (from iPhone)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Aug 2016 12:28:20 -0400

> Am I understanding correctly?

Yes. This is the exact use model we need to address. Ralph Droms did some
work on it a few years ago but it never got off the ground. The work needs
to happen.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Aug 2016 16:33:07 +0000

Ø  Yes. This is the exact use model we need to address. Ralph Droms did some work

Ø  on it a few years ago but it never got off the ground. The work needs to happen.

So, there is no way to do it today based on published standards – there would
need to be a new standard developed? Or, can we use some existing mechanism?

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 9:28 AM
To: Templin, Fred L <[email-masked]>
Cc: dhcwg <[email-masked]>
Subject: RE: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

> Am I understanding correctly?

Yes. This is the exact use model we need to address. Ralph Droms did some work on it a few years ago but it never got off the ground. The work needs to happen.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 24 Aug 2016 13:04:47 -0400

> need to be a new standard developed? Or, can we use some existing mechanism?

You can do it with a vendor option right now, but yes, to do it in a standard way would require a standard.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 24 Aug 2016 17:14:56 +0000

> On Aug 24, 2016, at 12:28 PM 8/24/16, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 24, 2016 12:23 PM, "Templin, Fred L" <[email-masked] <mailto:[email-masked]>> wrote:
> 

If I recall correctly, this is the I-D: draft-draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt

...which expired back in 2005.  The dhc WG discussed the idea and we ran into concerns that out-of-order packet delivery or delivery through different relay agents might cause the state in the relay agent to be out-of-sync with the state of the assigned addresses or prefixes.  While we tried to engineer solutions to those issues into this mechanism, I call that we conclude the proper solution is for some other mechanism (e.g., today, an SDN controller) to inject the right information into the routers or routing protocol.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Aug 2016 18:26:23 +0000

Hi Ralph,

?  ...which expired back in 2005.  The dhc WG discussed the idea and we ran into

?  concerns that out-of-order packet delivery or delivery through different relay

?  agents might cause the state in the relay agent to be out-of-sync with the state

?  of the assigned addresses or prefixes.  While we tried to engineer solutions to

?  those issues into this mechanism, I call that we conclude the proper solution is

?  for some other mechanism (e.g., today, an SDN controller) to inject the right

?  information into the routers or routing protocol.

I vaguely remember this. I seem to recall that we also felt that relay agents could
glean prefix information by examining the options in the server's Reply message
to the client without needing to include any options in the relay message. That is
exactly what AERO does, and I assume also what other DHCPv6 prefix delegation
use cases do. But, if secdhcpv6 encrypts the Reply message then the prefix
information can no longer be gleaned.

?  If I recall correctly, this is the I-D: draft-draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt

If we could resurrect this draft, it would satisfy my needs. What do you think?

Thanks - Fred

From: Ralph Droms (rdroms) [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 10:15 AM
To: Ted Lemon <[email-masked]>
Cc: Templin, Fred L <[email-masked]>; dhcwg <[email-masked]>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

On Aug 24, 2016, at 12:28 PM 8/24/16, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 24 Aug 2016 19:46:07 +0000

Note that latest version of that draft is https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-04.

Also, 03 used the https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-srsn-option-02 draft to address out of order issues. Don't recall why 04 removed this and whether there were other issues still unresolved - though I think there were.

Sadly there is no change log to indicate changes made in each rev, so we will need to review the email dialog and meeting minutes around the time of these drafts to determine open issues & how to move forward. I think interest died because cable (cmts) just started to snoop the client packets. This actually doesn't resolve out of order issues, though I think those have not caused any known problems. So while in theory they could be, in practice they are not.

- Bernie (from iPhone)

On Aug 24, 2016, at 11:26 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

draft-draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Aug 2016 19:50:45 +0000

Can we dust this off and insert it back into the process?

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 12:46 PM
To: Templin, Fred L <[email-masked]>
Cc: Ralph Droms (rdroms) <[email-masked]>; Ted Lemon <[email-masked]>; dhcwg <[email-masked]>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2016 14:33:57 +0000

Hi, on further consideration RAAN options alone are not sufficient for my
needs. For my needs, the relay has to be able to inspect the contents of
both the client's messages to the server and the server's messages to
the client. And, it is about more than just IA_NA and IA_PD.

The use case is VPN clients connecting in to a secured home network then
using DHCPv6 to obtain prefixes and/or addresses. So, the client comes in
across a secured link where there is no concern for eavesdropping, but
the client still needs to prove to the server that it is authorized to receive
the requested addresses/prefixes.

In that case, when we can say that the link is secured against eavesdropping,
then there is a use case for authentication-only DHCPv6 security.

Thanks - Fred

From: dhcwg [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Wednesday, August 24, 2016 12:51 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: dhcwg <[email-masked]>; Ted Lemon <[email-masked]>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

Thanks - Fred

Cc: Ralph Droms (rdroms) <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>; dhcwg <[email-masked]<mailto:[email-masked]>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 25 Aug 2016 16:40:35 +0000

Please explain what else the relay needs to know.

- Bernie (from iPhone)

On Aug 25, 2016, at 9:34 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

Thanks - Fred

Cc: dhcwg <[email-masked]<mailto:[email-masked]>>; Ted Lemon <[email-masked]<mailto:[email-masked]>>

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2016 18:08:34 +0000

Hi Bernie,

VPN clients may need to configure their virtual interfaces over multiple
underlying physical interfaces (e.g., WiFi, Cellular, SATCOM, etc.) - each
with its own IP address. The relay then sees the client as a single network
layer entity with multiple link-layer addresses. So, the client needs to
have some way to tell the relay about its preferences for each of the
underlying interfaces. The client does this by including an option with the
preference values that the relay then needs to snoop in-the-clear,
i.e., and not encrypted.

Thanks - Fred

Sent: Thursday, August 25, 2016 9:41 AM

- Bernie (from iPhone)

Thanks - Fred

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Aug 2016 14:13:51 -0400

Fred, if we allow a non-encrypted mode, that will be the only mode that is
universally implemented.   That is why the consensus was to only define a
standard for the encrypted mode.   You are asking us to compromise rather
drastically on that for the benefit of your protocol, which as far as I
know has no real-world deployments that require interop, and is not on
track to become a standard.

I don't mean to say that what you want doesn't matter, but neither is it
the case that you have said anything to justify overturning the working
group consensus on this.   So instead, the right thing to do is to figure
out a way to get what you want without requiring the working group to
change its consensus.

If what you want is for the client to be able to communicate preferences to
the relay, something similar to the relay-supplied options option would do
the trick, only sent from the client rather than the relay.

On Thu, Aug 25, 2016 at 2:08 PM, Templin, Fred L <[email-masked]>
wrote:

> underlying physical interfaces (e.g., WiFi, Cellular, SATCOM, etc.) – each
>
> *From:* Bernie Volz (volz) [mailto:[email-masked]]
> *Sent:* Thursday, August 25, 2016 9:41 AM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* dhcwg <[email-masked]>; Ted Lemon <[email-masked]>
> *Subject:* Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
>
>
>
> On Aug 25, 2016, at 9:34 AM, Templin, Fred L <[email-masked]>
> wrote:
>
> both the client’s messages to the server and the server’s messages to
>
> *From:* dhcwg [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Templin, Fred L
> *Sent:* Wednesday, August 24, 2016 12:51 PM
> *To:* Bernie Volz (volz) <[email-masked]>
> *Cc:* dhcwg <[email-masked]>; Ted Lemon <[email-masked]>
> *Subject:* Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
>
>
>
> *From:* Bernie Volz (volz) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, August 24, 2016 12:46 PM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* Ralph Droms (rdroms) <[email-masked]>; Ted Lemon <[email-masked]>;
> dhcwg <[email-masked]>
> *Subject:* Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
>
>
>
> Note that latest version of that draft is https://tools.ietf.org/
> html/draft-ietf-dhc-dhcpv6-agentopt-delegate-04.
>
>
>
> Also, 03 used the https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-
> srsn-option-02 draft to address out of order issues. Don't recall why 04
> removed this and whether there were other issues still unresolved - though
> I think there were.
>
>
>
> Sadly there is no change log to indicate changes made in each rev, so we
> will need to review the email dialog and meeting minutes around the time of
> these drafts to determine open issues & how to move forward. I think
> interest died because cable (cmts) just started to snoop the client
> packets. This actually doesn't resolve out of order issues, though I think
> those have not caused any known problems. So while in theory they could be,
> in practice they are not.
>
> - Bernie (from iPhone)
>
>
> On Aug 24, 2016, at 11:26 AM, Templin, Fred L <[email-masked]>
> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2016 19:53:24 +0000

Hi Ted,

Thanks for the outside-the-box thinking on this. But, maybe this can be even easier
than what you are suggesting. I don’t want the relay to receive the client’s information
directly from the client – I want for the server to first authenticate the client’s message
and then loop the client information back to the relay. That way, the relay knows that
it can trust the information since the server has already authenticated it.

So, is there a way for the relay to include an ORO or something like that to convince
the server to loop the client-supplied option back in the Relay-Reply message to
the relay?

If yes, then that piece of the puzzle is solved. But, that still leaves us with resurrecting
RAAN and how we would go about doing that?

Thanks - Fred

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, August 25, 2016 11:14 AM
To: Templin, Fred L <[email-masked]>
Cc: Bernie Volz (volz) <[email-masked]>; dhcwg <[email-masked]>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

Fred, if we allow a non-encrypted mode, that will be the only mode that is universally implemented.   That is why the consensus was to only define a standard for the encrypted mode.   You are asking us to compromise rather drastically on that for the benefit of your protocol, which as far as I know has no real-world deployments that require interop, and is not on track to become a standard.

I don't mean to say that what you want doesn't matter, but neither is it the case that you have said anything to justify overturning the working group consensus on this.   So instead, the right thing to do is to figure out a way to get what you want without requiring the working group to change its consensus.

If what you want is for the client to be able to communicate preferences to the relay, something similar to the relay-supplied options option would do the trick, only sent from the client rather than the relay.

On Thu, Aug 25, 2016 at 2:08 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernie,

Thanks – Fred

- Bernie (from iPhone)

Thanks – Fred

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Aug 2016 15:56:25 -0400

> the server to loop the client-supplied option back in the Relay-Reply message to

We don’t currently specify this behavior, but it could certainly be added as an extension.   Privacy implications would have to be considered, of course, but presumably anything the relay needs to know isn’t private in the context of the relay agent, and of course you can use IPsec to protect the communication between the server and the relay.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2016 20:02:02 +0000

Hi Ted,

Where would we add this as an extension – rfc3315(bis)?

Thanks - Fred

Sent: Thursday, August 25, 2016 12:56 PM

On Aug 25, 2016, at 3:53 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
So, is there a way for the relay to include an ORO or something like that to convince
the server to loop the client-supplied option back in the Relay-Reply message to
the relay?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Aug 2016 16:06:31 -0400

> Where would we add this as an extension – rfc3315(bis)?

No, just define a new DHCP spec that says how to do what you need.