Subject: [dhcwg] Security/Privacy & Addressing (was: Re: IETF-93 Follow Up - draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015))

From: Fernando Gont <[email-masked]>
Date: Sat, 01 Aug 2015 11:27:45 +0200

Hi, Christian,

On 07/31/2015 09:34 PM, Christian Huitema wrote:
> On Friday, July 31, 2015 6:35 AM, Fernando Gont wrote:
>> 
>> On 07/29/2015 07:45 PM, Tomek Mrugalski wrote: ...
>>> But my strongest objection to it is that privacy and stable do
>>> not mix well.
>> 
>> It all depends on what you mean by privacy. Here were *aiming* to
>> allow to activity correlation within the same network. It's a goal,
>> not a flaw. If what bothers you is the use of "privacy" in the
>> title, please say so.
> 
> By definition, stable addresses allow for tracking over time, which
> is the antinomy of privacy.

If you really don't want to be tracked, the best advice is: do not
connect to any network.

If you want/have to connect, then to an extent or another there's some
degree of activity correlation that is possible, and sometimes needed or
even desirable -- there are tradeoffs, of course.

I believe it's hard to talk about security/privacy implications without
referring the specifics in this case.

First of all, and for the sake of simplicity, let's assume four
different issues:

1) Correlation of activities across networks
2) Host scanning/network reconnaissance
3) Device-specific attacks
4) Correlation of activities over time

RFC7217 tries to address #1-#3 above, but to explicitly allow for #4,
because that is of value to e.g. many enterprises. Keeping #4 was a
design goal, not a flaw -- because the inabiity to do #4 is what has led
many enterprises to disable RFC4941.

draft-ietf-dhc-stable-privacy-addresses aims at the same thing, with the
addition that if you manage all the local DHCPv6 servers, you can
achieve address stability across servers without any additional protocol.

>> Has anyone really assessed everything that could go wrong with
>> randomized MAC addresses?  -- THink of SAVI and other
>> first-hop-secuity mechanisms, issues with the ND cache, etc.
> 
> There are certainly environments where administrators will require
> users to give up privacy so the network can be controlled more
> efficiently. But it is very obvious that if you want privacy, you do
> not want to use stable identifiers.

The identifiers will have to be stable (for some definition of stable)
if you need "stable" TCP connections. e.g., I have plenty of ssh
sessions at different machines, and do not really want them to break for
some fancy "let's randomize this address over time" -- there's a
tradeoff, of course.

And the ability to e.g. have long-lived ssh sessions trumps in many
cases, the desire to randomize addresses over time.

Now, if you're argument is: "We'd only randomize the link-layer address
and IPv6 address when you connect/re-connect to the network", I could,
just as well, tell you that if you really want privacy, then you don't
want such level of stability. You improve your "privacy" as you increase
the rate at which you randomize all addresses.... until you get to the
point in which such system is probably unusable, and you probably just
disconnect from the net.

Besides, if you're paranoid, you'd always do SLAAC -- because the local
DHCPv6 server can always be evil. And maybe not even SLAAC, because some
of the prefix bits could be advertised to you just for the sake of
tracking you..

Besides, if correlation of network activity over time is a concern,
network traffic patterns, TCP/IP stack fingerprinting, etc., all help,
essentially, to achieve the same purpose.

Summarizing the above: this I-D tries to tackle at least three concrete
security/privacy issues. It is not meant to (and I don't think we ever
claimed that) the perfect solution for every single privacy concern you
might (correctly. If what bothers folks is the use of "privacy" e.g. in
the filename, we can fix that, of course -- but I think that's a
different discussion.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 03 Aug 2015 22:36:57 +0200

On 31/07/15 15:34, Fernando Gont wrote:
> Tomek,
> 
> On 07/29/2015 07:45 PM, Tomek Mrugalski wrote:
>>
>> With my co-chair hat off, I think this draft could have been useful
>> couple years ago. It defines an allocation strategy that could be
>> beneficial in certain cases. Some modern DHCP servers allow multiple
>> allocation strategies and this could have been one of them. The text
>> suggested that the algorithm specified is the only right way to do it.
>> It is not.
> 
> Could you please point what's the offending text? -- i.e., the text that
> claims that this is the only way to generate IIDs with DHCPv6?
I think that's the same text Erik mentioned in Prague at the mic.

Section 4, first paragraph:

   DHCPv6 server implementations conforming to this specification MUST
   generate non-temporary IPv6 addresses using the algorithm specified
   in this section.

Here's specific example. The implementation I'm working on has the
capability to support multiple allocation strategies: iterative, random
etc. Your proposal can be another one considered. The text above says
that if I implement your proposal, I must also drop support for all
other allocation strategies.

>> The general consensus seems be that changing MAC addresses and all
>> associated identifiers over time is the way to go. That's what the
>> anonymity profile and other associated work in other WGs is proposing.
>> Had we published this draft, it would be confusing for vendors what the
>> recommendation for privacy is: randomize MAC addresses or go with stable
>> privacy addresses. Based on that I'm in favor of dropping this work.
> 
> randomized MAC addresses?  -- THink of SAVI and other first-hop-secuity
> mechanisms, issues with the ND cache, etc.
Authors of the dhcp privacy and anonymity profile drafts received
several comments, but they always could use more. By all means, if you
have anything to add, please comment on them.

> IMO, while probably desirable, I'd flag MAC address randomization as
> "experimental" rather than "the way to go".
Ok, maybe that was a bit inpricise statement. Let me rephrase. It seems
that at this time there's rough consensus that MAC based randomization
is the preferred solution for the privacy concerns raised in RFC7258,
draft-ietf-dhc-dhcp{v6}-privacy and other places.

Keep in mind that WG consensus is not something set in stone. People
change their minds over time. More analysis and better understanding of
a problem is available over time. New solutions are being proposed.
These all influence people decisions. Work that used to be appealing may
lose its appeal over time. Successful adoption call answers the question
whether a WG is willing to work on something, not a promise to publish
the draft no matter what. Drafts can be abandoned at any stage. It may
be disappointing when it happens, but it happens nevertheless.

Tomek

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 5 Aug 2015 02:47:48 +0000

Hi chairs and all,

I would like the wg to continue working in this I-D. 

The mechanism proposed by this draft is useful and practical to prevent many of the associated issues with predictable addresses, and it is useful to have an RFC that we can refer to for dhcpv6 coders, and especially for the scenario where CPEs lack of the capability of maintaining database. 

Regards,
Will 

> -----Original Message-----
> From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
> Sent: Thursday, July 30, 2015 1:45 AM
> To: Bernie Volz (volz); [email-masked]
> Subject: Re: [dhcwg] IETF-93 Follow Up -
> draft-ietf-dhc-stable-privacy-addresses (Respond by Aug 11, 2015)
> 
> On 29/07/15 19:25, Bernie Volz (volz) wrote:
> > At the DHC WG session at IETF-93 (Prague), we had a discussion about
> > next steps for draft-ietf-dhc-stable-privacy-addresses. In particular,
> > I (Bernie Volz) proposed we consider it a "dead WG" document (or
> > possibly continue it as Informational). The consensus (hum) in the
> > room was as
> > follows:
> >
> > - Most felt (loudest hum) we should consider it a "dead WG" document.
> >
> > - A few (minor hum) were in favor of continuing work on it as an
> > Information draft.
> >
> > - None (silent) were in favor of continuing work as is (standards
> > track).
> As a co-chair I confirm that it was my perception as well. The hum indicated
> that people in the room strongly favored marking the doc as dead WG
> document.
> 
> With my co-chair hat off, I think this draft could have been useful couple years
> ago. It defines an allocation strategy that could be beneficial in certain cases.
> Some modern DHCP servers allow multiple allocation strategies and this could
> have been one of them. The text suggested that the algorithm specified is the
> only right way to do it.
> It is not.
> 
> But my strongest objection to it is that privacy and stable do not mix well. The
> general consensus seems be that changing MAC addresses and all associated
> identifiers over time is the way to go. That's what the anonymity profile and
> other associated work in other WGs is proposing.
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Aug 2015 11:58:11 +0900

On Thu, Jul 30, 2015 at 2:25 AM, Bernie Volz (volz) <[email-masked]> wrote:

> Thus, if you do NOT agree with the intended action to mark the document as
> “dead”, please indicate so and specify why you feel this document is needed
> and whether to continue as Standards Track or Informational. Please respond
> on or before August 11th, 2015.
>

Bernie: to be clear, you're saying that if someone does agree with the
action taken in the WG and does not support this document, then no action
is required, right?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 5 Aug 2015 10:39:09 +0000

It does not hurt to state your position either way, but yes the results from hum in Prague were pretty clear that WG favored dropping this work.

- Bernie (from iPad)

On Aug 4, 2015, at 10:58 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jul 30, 2015 at 2:25 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
Thus, if you do NOT agree with the intended action to mark the document as “dead”, please indicate so and specify why you feel this document is needed and whether to continue as Standards Track or Informational. Please respond on or before August 11th, 2015.

Bernie: to be clear, you're saying that if someone does agree with the action taken in the WG and does not support this document, then no action is required, right?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Aug 2015 16:17:07 +0200

On 08/05/2015 12:39 PM, Bernie Volz (volz) wrote:
> It does not hurt to state your position either way, but yes the results
> from hum in Prague were pretty clear that WG favored dropping this work.

So... the wg "favored" a decision with a rationale that is bogus, and
nobody seem to have bothered to discuss or elaborate.... -- I think I
elaborated on the topic myself...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Aug 2015 16:30:08 +0200

> be disappointing when it happens, but it happens nevertheless.

FWIW, I've love to see a "please state whether you want this I-D to be
dropped, and state the reasons for dloing so"..

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Aug 2015 16:29:16 +0200

Tomek,

> other allocation strategies.

It is not meant to do that. It is meant to say "if you're enabling
employing this technique, you must use it for all your DHCPv6 IIDs".

As you may see, if anything, there's room for improvement and tightening
up the text.. but I don't see why this should result in "let's knock
down this I-D" if it doesn't look perfect.

> have anything to add, please comment on them.

This is my comment: "I believe MAC address randomization is extremely
likely to break all sorts of first security techniques."

> draft-ietf-dhc-dhcp{v6}-privacy and other places.

I repeat: Hsa anyone really thoroughly accessed whether this is going to
break FHS techniques currently employed?

> a problem is available over time. 

THat's exactly the point. The technial comments I've seen so far from
LOrenzo are simply bogus. The part that you don't like from the I-D
simply needs to be clarified. And so far, this have been so far the
reasons to say "let's drop this"....

> New solutions are being proposed.

Yes, I'm aware of this 8I've participated in the IETF process for 10+
years). But what I see in this case is that some folks (e.g. Lorenzo)
are arguing to drp this without concrete ans sensible technical reasons.

I've elaborated on teh value, and on the issues raised by LOrenzo.
However, it seems that "the default is to drop", because of a hum taking
at the dhc meeting, when no ne uming really make a strong technical
point against this document. Thus, such action does not seem sensible to me.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 Aug 2015 16:36:58 +0200

Bernie,

On 07/31/2015 04:28 PM, Bernie Volz (volz) wrote:
> 
> But we haven't yet seen sufficient support for continuing this work.
> And unless we do, there's little point in doing so as it obviously
> does not have WG consensus to move forward.

mm... wasn't it better to ask folks to contribute, or poll whether
anyone was willing to review, rather than first opting to drop the I-D
before trying the other option first?

> Actually, my proposal to drop this work was to assure that if people
> felt it was important, they WOULD respond. Just asking a vague "do
> you support this work" tends to get little response.

I agree. But that is the same for asking for a vague "hum to drop" when,
as noted a few times already the main technical comments 8from Lorenzo)
were bogus, and the other nits (from Tomek) simply require a tweak.

Thanks,

---

From: Linhui Sun <[email-masked]>
Date: Mon, 10 Aug 2015 16:15:25 +0800

Hi all,

Sorry for the late response. Have a brief look at this document, it defines an algorithm to solve the safety problem brought by IPv6 SLAAC, where the MAC address is encapsulated in the IPv6 address. I think it is useful to have a document specifying the algorithm, as it is something that the implementors could choose depending on their need. I do agree that the document need some improvements, but there are use cases where this allocation strategy is useful. I think more considerations should be taken before dropping this work completely. If the final result is not to drop it, it would be more reasonable that the document should be continued as an informational document.

Best regards,

Linhui

[email-masked]

<
Bernie Volz (volz)> 2015-07-30 01:25:42 wrote:

Hi:

At the DHC WG session at IETF-93 (Prague), we
had a discussion about next steps for
draft-ietf-dhc-stable-privacy-addresses. In particular, I (Bernie
Volz) proposed we consider it a “dead WG” document (or possibly
continue it as Informational). The consensus (hum) in the room was
as follows:

-         Most felt (loudest hum) we should consider it a “dead WG”
document.

-         A few (minor hum) were in favor of continuing work on it
as an Information draft.

-         None (silent) were in favor of continuing work as is
(standards track).

I had also asked this question to the mailing
list a while back, and there was some discussion though no
conclusive action as only a few people voiced an opinion.

While we don’t yet have official minutes for
the meeting, you can view the Etherpad notes and audio track by
visiting https://tools.ietf.org/agenda/93/
and scrolling down to the DHC session (on Thursday afternoon) and
clicking the appropriate links.

The WG chairs are required to confirm any
consensus obtained from a session on the WG mailing list and that
is the purpose of this email.

Thus, if you do NOT agree with the intended
action to mark the document as “dead”, please indicate so and
specify why you feel this document is needed and whether to
continue as Standards Track or Informational. Please respond on or
before August 11th, 2015.

Thanks!

-         Bernie (& Tomek)

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 17:30:54 +0900

> dropped, and state the reasons for dloing so"..

Those statements are already in the list archives. They are also, no doubt,
part of the reason why the chairs chose to proceed as they did, by asking
the "do you want to drop this document" question in the room, registering
strong consensus (and I agree - I was there and it seemed very strong to
me), and taking that question to the mailing list.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 10 Aug 2015 10:36:37 +0200

On 08/10/2015 10:30 AM, Lorenzo Colitti wrote:
> On Thu, Aug 6, 2015 at 11:30 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Those statements are already in the list archives. They are also, no
> doubt, part of the reason why the chairs chose to proceed as they did,
> by asking the "do you want to drop this document" question in the room,
> registering strong consensus (and I agree - I was there and it seemed
> very strong to me), and taking that question to the mailing list.

Can you please point the specific email? So far your technical comments
(other than "I don't think this brings much value") have been, IMO,
bogus. (e.g. our discussion of how this might collide with SLAAC).

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 18:37:48 +0900

> bogus. (e.g. our discussion of how this might collide with SLAAC).

I don't see the point of repeating the conversation here, it will just turn
into me and you repeating the argument we've already had. Anyone else who's
interested can look at the archives.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 10 Aug 2015 09:54:00 -0700

At Mon, 10 Aug 2015 16:15:25 +0800,
Linhui Sun <[email-masked]> wrote:

> Have a brief look at this document, it defines an algorithm to solve
> the safety problem brought by IPv6 SLAAC, where the MAC address is
> encapsulated in the IPv6 address.

I don't get it...draft-ietf-dhc-stable-privacy-addresses has nothing
to do with SLAAC.  Besides, "solutions" to the problem you mentioned
about SLAAC have already been published, first in RFC 3041 back in
2001, then in RFC 4941, and now in RFC 7217.

If you tried to say that dhc-stable-privacy does not embed a MAC
address as the pure SLAAC does, the bare DHCPv6 already has that
property (an awkward server implementation might still embed a MAC
address, but that's not a protocol issue and would be quite unlikely
to be the case in practice anyway).

--
JINMEI, Tatuya

---

From: Linhui Sun <[email-masked]>
Date: Tue, 11 Aug 2015 19:45:53 +0800

Hi Jinmei,

Thanks for your reply and please see comments inline.

Best regards,
Linhui

[email-masked]

<
神明達哉> 2015-08-11 00:54:00 wrote:

[LH]: Sorry for the error and thanks for pointing out that. It seems that I was a little bit confused with the previous work (as you mentioned RFC7217). Have another look on this document, it does have nothing to do with SLAAC. It defines an algorithm to randomly generate interface id that is hard to be predicted to mitigate the privacy issue. Please correct me if I'm wrong again : )

[LH]: Agree, since DHCPv6 and SLAAC are different things, it makes no sense to say this does not embed a MAC address.

--
JINMEI, Tatuya

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Aug 2015 15:04:42 +0200

On 08/10/2015 11:37 AM, Lorenzo Colitti wrote:
> On Mon, Aug 10, 2015 at 5:36 PM, Fernando Gont <[email-masked]
> I don't see the point of repeating the conversation here, it will just
> turn into me and you repeating the argument we've already had. Anyone
> else who's interested can look at the archives.

The point is not to repeat the discussion. The point is, whether, after
the discussion we have had, you can clearly state what your bjections
are with respect to this document.

Thanks,

---

From: Chuck Anderson <[email-masked]>
Date: Tue, 11 Aug 2015 10:15:58 -0400

I support keeping this document alive as Standards Track because it
offers a useful way to implement DHCPv6 Failover using a calculated
technique rather than state-sharing, and because I value the ability
for enterprises to correlate activities of a host within a single IPv6
link while still allowing for privacy and non-correlation across
different IPv6 links.

On Wed, Jul 29, 2015 at 05:25:42PM +0000, Bernie Volz (volz) wrote:
> Hi:
> 
> At the DHC WG session at IETF-93 (Prague), we had a discussion about next steps for draft-ietf-dhc-stable-privacy-addresses. In particular, I (Bernie Volz) proposed we consider it a "dead WG" document (or possibly continue it as Informational). The consensus (hum) in the room was as follows:
> 
> -          A few (minor hum) were in favor of continuing work on it as an Information draft.
> 
> -          None (silent) were in favor of continuing work as is (standards track).
> I had also asked this question to the mailing list a while back, and there was some discussion though no conclusive action as only a few people voiced an opinion.
> 
> While we don't yet have official minutes for the meeting, you can view the Etherpad notes and audio track by visiting https://tools.ietf.org/agenda/93/ and scrolling down to the DHC session (on Thursday afternoon) and clicking the appropriate links.
> 
> The WG chairs are required to confirm any consensus obtained from a session on the WG mailing list and that is the purpose of this email.
> 
> Thus, if you do NOT agree with the intended action to mark the document as "dead", please indicate so and specify why you feel this document is needed and whether to continue as Standards Track or Informational. Please respond on or before August 11th, 2015.
> 
> Thanks!
> 
> 
> -          Bernie (& Tomek)

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Aug 2015 10:58:41 +0900

On Tue, Aug 11, 2015 at 11:15 PM, Chuck Anderson <[email-masked]> wrote:

> it offers a useful way to implement DHCPv6 Failover using a
> calculated technique rather than state-sharing,

But it doesn't. With this scheme, if the client issues a DECLINE for any
reason (e.g., because the address that's assigned is a duplicate, or due to
a temporary link problem such as a looped port), there are exactly two
options to make things work correctly:

1. Leave that client without an IPv6 address.
2. Make all the DHCPv6 servers on the link record all leases and share all
lease state, losing all the benefits of statefulness.

This is a fundamental flaw in this scheme which I believe cannot be fixed.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 13 Aug 2015 21:46:04 +0200

On 08/12/2015 03:58 AM, Lorenzo Colitti wrote:
> On Tue, Aug 11, 2015 at 11:15 PM, Chuck Anderson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> reason (e.g., because the address that's assigned is a duplicate, or due
> to a temporary link problem such as a looped port), there are exactly
> two options to make things work correctly:
> 
> 2. Make all the DHCPv6 servers on the link record all leases and share
> all lease state, losing all the benefits of statefulness.
> 

IMO, this is similar to saying that the automobile design is flawed
because they cannot operate on water.

This ID assumes that the address pool enough such that address
collisions are (probabilistically speaking) extremely unlikely.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Aug 2015 14:28:42 +0900

> collisions are (probabilistically speaking) extremely unlikely.

Then you need to change all occurrences of "stateless" to
"probabilistically stateless" and "stable" to "probabilistically stable"
properly document what happens in this case.

Charis, what is the outcome of this consensus call? If your call is that
there is rough consensus for this to cease to be a WG document, then we can
stop having these discussions.

It is not my role to call consensus, but I count a handful of people
supporting this document in this thread; given the hum level and the number
of attendees at the meeting, that certainly doesn't seem to constitute
rough consensus that we should *keep* this document active.