Subject: Re: [Dhcpv6bis] [dhcwg] seDHCPv6 update and next steps ...

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 24 Jul 2017 21:32:39 +0000

Hi Ted:

Ok, thanks for that update. You might not need to follow up further … I think it may just depend on what happens with 3315bis when we get it to the IESG.

I think the main issue will be to figure out what text to add/change in the 3315bis document for the -10 (i.e., the version we plan to publish shortly and hopefully send on).

I was planning on taking a first stab at that but if anyone else has cycles (I likely won’t this week) …

I did copy the existing section 22 and 23 into https://docs.google.com/document/d/1sIH0vbaM26zEuOlneTFSB_0TOK56pZKVLlA1R-KelLQ/edit?usp=sharing (removed RFC formatting so it is just text, but still does include hyperlinks). In first paragraph, I did remove the 2nd sentence since we don’t want to mention sedhcpv6 but made no other changes yet.

The analysis that Francis did might help (attached), but he didn’t address whether the server’s response contained anything that could be “sensitive” (probably not). And snooping of that might be more difficult in many situations (since it is unicast, and often switches only send those packets to a single port).

I also wonder if we should have sub-sections to discuss general issues and different types of networks (enterprise vs coffee shop)? Or somehow break up the section a bit? We also don’t mention the SAVI work and perhaps one or more of those RFCs could also be useful to reference?

-          Bernie

From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, July 24, 2017 3:36 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]; 神明達哉 <[email-masked]>; Lishan Li <[email-masked]>; Tomek Mrugalski <[email-masked]>
Subject: Re: [dhcwg] seDHCPv6 update and next steps ...

On Jul 19, 2017, at 4:27 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
We can certainly follow up with her on that, but I think it is the pervasive monitoring …

I did follow up with her.   As far as I was able to gather from talking to her, she does not have a clear use case either, and she hadn't realized that 802.1x+relay security gets us security in the enterprise environment, so she was quite mollified by that.

I'm going to have a chat with her next time I'm in Boston and see if we can get some clarity on this.

Subject: Re: Next steps for sedhcpv6
From: Francis Dupont <[email-masked]>
To: Kathleen Moriarty <[email-masked]>
Cc: "Bernie Volz (volz)" <[email-masked]>, Timothy Carlin <[email-masked]>, Tomek Mrugalski <[email-masked]>, draft-ietf-dhc-sedhcpv6 authors <[email-masked]>, "Templin, Fred L" <[email-masked]>, Suresh Krishnan <[email-masked]>
Date: Thu, 20 Jul 2017 15:12:16 +0000

Here I put a (not so) short analysis of opportunistic encryption with
(or versus) DHCPv6.

First the use case is the so called "coffee shop" one. There is a network
(likely WiFi) providing an Internet access to persons (customers) in
the radio range.
 The goal is to provide privacy, i.e., the use of the DHCPv6 protocol
to get a global IPv6 address assigned do not reveal something interesting
to a passive attacker (eavesdropper).

Implications of the use of DHCPv6 on privacy were well studied in RFC
7824 and an anonymity profile defined in RFC 7844. Typically the client
should not try to update the DNS (BTW there is no reason to update
the DNS in this use case so this is just to complete the analysis) and
the identity information is available only in the DUID which can be based on:
 - the MAC address (note as this option is required for stable DUID
  without stable storage most client implementations support this option,
  i.e. there is nothing special to do for the user)
 - an UUID so 128 random bits
The client DUID is opaque for the server: the only constraint is the
same DUID must not be used by 2 clients at the same time. This is
fulfilled by the MAC address (if 2 clients use the same MAC address on
the same link the problem is greater than DHCPv6) and the DUID (anyway
there are only 2^64 addresses available per link :-).

So IMHO even without specific care the DHCPv6 protocol in this use case
does not need to be protected against eavesdroppers so dedicated
oportunistic encryption is useless.

Now look at around.

DHCPv4 is like DHCPv6 but from its long history it didn't got a very
good design. For instance it embeds the MAC address making hidding it
inside the protocol itself harder (i.e. it can require specific setup).
 Anyway the 2 RFC about privacy and anonymity apply to both DHCPv4 and
DHCPv6 so there is no unknown or untrackable problem here.

To assign IPv6 addresses one can use the SLAAC mechanism, i.e., the
Neighbor Discovery (note there is a secure version of it named SeND
in RFC 3971 but it is only about authentication and a bit of
authorization). The choice between SLAAC or DHCPv6 for address
assignment and for other common paramaeters (e.g. DNS server addresses)
is at the choice of the network manager.

On the opportunistic side DHCPv6 uses multicast to discover the agent
(relay or server) on the link and may get an address in one (rapid
commit) or two exchanges (one exchange : a query from client to agent,
and a response from agent to client. The query is sent from a link-local
address to a multicast one).
 This is not supported by any standard key-exchange protocol so IMHO
by opportunistic encryption something like IPsec is referred to.

So if IPsec is used to provide the opportunistic encryption this means
the client picks a self signed or raw key (anything else will be both
too complex with no benefit and vulnerable to active attacks as IKEv2
chose to protect the responder identity against active attacks) and
runs IKEv2 with an agent which was discovered using a to-be-defined
mean.
 It can work but IKEv2 offers by the Configuration Payload (RFC 7296
section 3.15) address assignment so I can clearly claim if there is
a possibility to get IPsec deployed in the coffee shop use case
then there is no reason to not get rid of DHCP at the same time.

Note if the use case is changed to include prefix delegation
the trade-offs are pretty different. A delegated router
(i.e. a prefix delegation client) has already an address with
a large enough scope to be able to communicate directly with
the DHCP server. So it can embed a relay and apply the DHCPv6
security mechanism between relays and servers which is BTW IPsec.
(I proposed the embedded relay idea for mobile delegated routers
in RFC 6276.)

In conclusion I claim there is no clear use case to justifying to
invest resources into a work about dedicated (to DHCPv6 privacy
protection) opportunistic encryption.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Jul 2017 20:59:53 +0200

In your previous mail you wrote:
>  The analysis that Francis did might help (attached), but he didn't
>  address whether the server's response contained anything that could be
>  "sensitive" (probably not).

=> in the "coffee-shop" case I can't see what the DHCP server could know
which is "sensitive" so I added nothing about from server to client
messages. BTW there are some recommendations in the two RFCs I
referenced because these messages can have an impact on privacy
in some other cases, and 3315bis privacy considerations have some
statements about resource allocation strategies.
(i.e. it was not relevant in my analysis but is not neutral in some
particular cases).

Regards

PS: I don't put again the whole message but the analysis was about
opportunistic encryption in the coffee-shop case.