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

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492