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

["Templin, Fred L" <[e-mail]>]

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:[e-mail]]
Sent: Thursday, August 25, 2016 11:14 AM
To: Templin, Fred L <[e-mail]>
Cc: Bernie Volz (volz) <[e-mail]>; dhcwg <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
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
[e-mail]<mailto:[e-mail]>

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

Please explain what else the relay needs to know.

- Bernie (from iPhone)

On Aug 25, 2016, at 9:34 AM, Templin, Fred L <[e-mail]<mailto:[e-mail]>> wrote:
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
[e-mail]<mailto:[e-mail]>

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

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

Thanks - Fred

From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Wednesday, August 24, 2016 12:46 PM
To: Templin, Fred L <[e-mail]<mailto:[e-mail]>>
Cc: Ralph Droms (rdroms) <[e-mail]<mailto:[e-mail]>>; Ted Lemon <[e-mail]<mailto:[e-mail]>>; dhcwg <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:
draft-draft-droms-dhc-dhcpv6-agentopt-delegate-00.txt