Hi, Dave, This issue was debated more than a year ago, at the IETF Paris timeframe. Since then, the wg adopted this document, and we went through WGLC and IETF LC. So I'm not sure how it helps to raise this point again and at this point in time.
That said, please let me try to clarify a few things, and respond to your email. Traditional SLAAC addresses suffer from two problems: 1) They result in addresses that follow specific patterns, and hence allow attackers to reduce the search space when performing address-scanning attacks. 2) They employ constant identifiers, which allow host-tracking. I'll focus on "2)", since it seems that you agree with "1)" being a problem that remains to be solved. RFC 4941 specifies temporary addresses which change over time. Temporary addresses help with passive host-tracking where e.g. a server keeps a log of the IPv6 addresses that connected to it and could possibly correlate node activities based on the IID (if th IID is constant). However, there's still the issue of active-host tracking, where a node (server or otherwise) actively probes a node to track it. As long as nodes employ addresses which embed constant IIDs, such host tracking attacks are feasible. For instance, <http://www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses-privacy-review.txt> notes: ---- cut here ---- For a temporary address to provide protection against tracking and re-identification, it cannot be mixed together with a public address for the same device, otherwise the temporary address could be correlated to the persistent public address. This aspect has sometimes been overlooked in applications' use of multiple addresses generated in different ways. ---- cut here ---- and later adds: ---- cut here ---- The address-scanning problem can be mitigated by using randomly-generated suffixes for all addresses, whether they are public/persistent or temporary. These addresses can still be used for tracking, but they remove the OUI-associated vulnerability and make address scanning for IPv6 addresses no easier than for IPv4 addresses. Windows uses random suffixes for all addresses, but many other implementations do not. ---- cut here ---- This should make it evident that the scheme implemented by Windows fixes the address-scanning problem, but is still flawed when it comes to privacy. We have even implemented a tool to track nodes that employ constant IIDs (whether derived from IEEE-identifiers, or the approach implemented by Windows). The tool is scan6, availble as part of the IS6 toolkit at: <http://www.si6networks.com/tools/ipv6toolkit>). The man page for the tool contains examples of how to use the tool for such purpose. Some additional comments in-line.... On 05/20/2013 04:56 PM, Dave Thaler wrote: > I will concentrate on sections 1, 2, and Appendix B, being the > motivation/goals/justification, as opposed to the technical details. > > Let's start with B.1.1, which attempts to motivate a desire to > prevent tracking hosts across networks using their public > address(es): [FWIW, the motivation is in the Intro, rather than the Appendix. Appendix B simply rovides a clarification regarding issues not fixed with RFC4941... and not that long ago even included a statemet such as "this will be removed prior to publication of this document as an RFC"] >> Some time later, the same host moves to a completely different >> network, and employs the same P2P application, probably even with >> a different username. The attacker now interacts with the same >> host again, and hence can learn its newly-configured stable >> address. Since the Interface Identifier is the same as the one used >> before, the attacker can infer that it is communicating with the >> same device as before. > > The above text convolutes two orthogonal issues: higher-layer ID > (username in this case) and location. The higher-layer ID in other > apps would be the DNS name, but here the text uses the username, > though even in P2P applications the higher-layer ID used to resolve > an application or piece of content would already be stable, and the > question is what you can link it to. The point this para is trying to make is that even if the user is employing a different username in the hopes of hiding its identity, the constant IID would reveal the identity of the device. (Put another way, the text regarding the username could even be considered "superflous" in this case). > So one problem with the quoted text is that it does not address the > problem of "a different username" not having a different address > (when not moving) and hence the two higher-layer IDs can be linked > using a common address. Whether one moves or not is a separate > issue. As noted in draft-ietf-6man-stable-priacy-addresses, mitigating correlation of node activities within the same network is, at times, virtually impossible. And draft-ietf-6man-stable-privacy-addresses does not aim to tackle such problem. > If unlinkability between two location is desired, then it's key that > there be no higher-layer ID in common that can be linked to both > addresses. If you have constant IIDs, node activities can be correlated even without the need of a higher-layer ID. > Furthermore, this notion of unlinkability is that privacy addresses > were designed for. The first paragraph in B.1.1 implies that one > would not want to use privacy addresses in a P2P scenario, and then > goes on to talk about why you lose privacy. No. It actually argues that RFC 4941 didn't get rid of constant IIDs. Hence you're still subject of active probing. Trivial example: I attend an IETF meeting, and learn the IID of your laptop. Then I can actively probe your node regarding "Is David at the office?" "Is David at home?", etc.... simply because your IID is known and constant. > I *do* agree with the address scan prevention goal. This is why > Windows has for the last 10 years used random (not MAC-derived) > public (not just temporary) addresses using the algorithm in 4941. Which, as noted above, still brings you IIDs that are constant across networks -- and the corresponding implications. > The IETF works on rough consensus and running code. We have > running code for over a decade now that's widely deployed (it's the > default on all Windows machines from XPSP3 onwards). A suboptimal (or flawed) scheme implemented in a widely-deployed OS doesn't change the fact that that the scheme is flawed. And the wg has been working (and progressing) on this document for more than a year (which is the "rough consensus" part of your quote above). > But I see no justification for having public addresses (linkable from > DNS names, etc.) that vary by network location. Nor do I see any > justification for having link-local addresses (linkable to MAC > addresses via ND) that vary by network location. Actually, the analysis is: "I see no justification for employing an IID that is constant across networks, nor do I see why should I embed my address". That's the philosophy (pro-activity?) one would expect to be applied. Otherwise you'll likely find out that there's this or that other mechanism or application which informs e.g. all configured addresses (e.g. ICMPv6 node information messages, to name one), and you realize that you should have done the right thing from starters. > I think this comes down to fundamental disagreements on what a public > address is. A public address is one intended to be resolvable from > higher-layer IDs such as DNS names. I prefer to use terms such as stable vs. non-stable. -- At the end of the day, nothing prevents you from advertising a temporary address in the DNS, or *not* advertising a stable one in the DNS. > The doc says that apps wanting "server-like" functions use public > addresses. The key is in defining what that means, "receiving incoming connections". > and I'll fully > agree it would make more sense to have more guidance in this area. > But specifically "server-like" should be "makes the address linkable > to a higher-layer ID whose lifetime or scope is more than just that > one address". In the IAB documents, we try to clarify this notion of > linkability. I should probably s/server-like/receiving incoming connections/ -- although stable addresses are also useful when you want...er.. the addresses to be stable (prevent long-lived connections from breaking, etc.). > Once you agree on that definition, I think this notion of public > addresses that vary by location does not appear to be useful. It's the other way around: you should find a very good reason for embedding a super-cookie in your addresses (whether based on the MAC address, r a random number). Unless you find one, you shouldn't. This problem has hit some many protocols so many times that it's kind of surprising that anyone could argue in favor of constant/predictable IDs where they are not needed. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
