> -----Original Message----- > From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Monday, May 20, 2013 6:42 PM > To: Dave Thaler > Cc: 6...@ietf.org; 6man-cha...@tools.ietf.org; Brian Haberman; Ray Hunter; > Alissa Cooper; tom.petch; Christian Huitema; He Xuan > Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 > > 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.
The problem is that the draft does not contain any understandable justification, and does not explain the threat model it's trying to address in a way that's sufficient for readers like me to understand. So regardless of whether or not the WG has consensus, the document is lacking in any case. > 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. Agreed, that's the part I'm 100% in agreement with addressing. > 2) They employ constant identifiers, which allow host-tracking. By design. Host tracking is already allowed with constant higher-layer identifiers, e.g., DNS names, etc. So having constant addresses associated with constant higher-layer identifiers is not any different. And having non-constant address associated with them does not provide any value add. > I'll focus on "2)", since it seems that you agree with "1)" being a problem > that > remains to be solved. Actually it's been solved (and widely deployed) since over a decade ago. It remains to be *standardized*, which is the part I agree with. > 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). Right. > 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 ---- As you might know, that text is Alissa's nicely edited version of a talk I gave to the IAB Privacy Program, so I will of course agree with all quotes from it and fully endorse their use in any WG document :) Some of the information on that page is not currently in any IETF document to my knowledge, but ought to be. > 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. Your conclusion doesn't make sense. The text is explaining that there are two issues. Address scanning is mitigated by random suffixes. Tracking is mitigated by using temporary addresses (that change over time and location). Windows does both, so is not "flawed" as you incorrectly conclude. > 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. The key question is "employ" for what? For example, if "employ for registering in DNS" then I assure you I don't need your tool to track that... If "employ for making outbound TCP connections", then temporary addresses (not constant IIDs) are used for that, so again it doesn't apply. So please elaborate on what you meant. > 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"] I couldn't understand any motivation that made sense to me for changing the IID of a *public* address or a *link-local* address, when moving. (I of course understand motivation for preventing address scans.) > >> 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). Remove superfluous text that confuses the issue. My point remains about either there's a higher-layer ID that's constant (in which case changing the IID is not helpful) or there's not (in which case the app should be using temporary addresses not stable addresses). The text provides no clue as to why an app would opt into stable addresses and then be concerned about privacy, which makes no sense to me. > > 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. Yes, and if you have a higher-layer ID that's constant, linking it to non-constant IIDs is not helpful. So I fail to see the point. > > 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. RFC 4941 never intended to get rid of constant IIDs, which would only make sense if you got rid of constant higher-layer IDs like DNS names. But this is the real world where such higher-layer IDs are used all the time. > 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. Since you're making this personal... please explain how you can probe whether I'm at the office or at home, both of which are behind firewalls (so won't respond to arbitrary probes) and have address prefixes you don't know to begin with. Furthermore, how do you know I don't publish my addresses in a well-known DNS name and hence want my node's location to be public? (More generally, replace DNS name with any constant higher-layer ID.) > > 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. I have yet to see a coherent threat model described for these "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. Have yet to see how. > 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). Not a great excuse. There's plenty of other examples of documents that were flawed for more than a year and the WG reversed direction. (I could point to one recent one in the 6man WG but this is really off topic.) > > 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, I provided you one in this thread, which you seem to have missed, so I'll repeat it again. If you have a constant higher-layer ID, such as a DNS name that you keep up to date with your current public address, there's no value in having an IID that varies by network. It only adds extra complexity without real value. So the justification is "it works, it's widely deployed, and there's no reason to change it in this particular case". > 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. Already answered above. > 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 --------------------------------------------------------------------
