On 05/21/2013 10:34 PM, Dave Thaler wrote: >> >> 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.
I'm always open for improvements. I personally believe that the current version of the I-D is clear enough in that respect. In any case, since you consider there's room for improvement, hopefully this email exchange will either clarify things a bit and/or lead to improvements. >> 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. You are assuming those identifiers are there. But they needn't. > 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'm not sure why you bring this "higher-layer identifiers". The attack vector I mentioned (actively polling possible addresses as opposed to passively looking at IIDs still works pretty well without any sort of higher-layer IID). >> 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. I disagree it has been solved -- the only thing you've solved is address-scanning. >> ---- 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. You don't mitigate tracking as long as you still keep some address with constant IDs. The only thing that you "mitigate" with RFC 4941 is that with RFC 4941 in place, the attacker can no longer "passively" track you, but rather has to send some packet to cause you to use the address that will leak your identity. -- Just firing a packet that will elicit a response from that address is enough. >> 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. Let's say that your stable IID is 1111:2222:3333:4444:5555, and that, for the sake of simplicity, the world consists of four networks: 2001:db8:1::/64, 2001:db8:2::/64, 2001:db8:3::/64, and 2001:db8:4::/64. It thus becomes trivial to track you. Just periodically fire probe packets to 2001:db8:1::1111:2222:3333:4444:5555, 2001:db8:2::1111:2222:3333:4444 (and so on), and the address that responds leaks your location. >> 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.) I couldn't understand any motivation for keeping them constant. And past experience with virtually every ID you can think of indicates that, the less predictable/constant such IDs are, the better. >>> 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. Agreed. Will fix this. > 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). As noted above, the app can use any address it wants. But since the stable address is still there, and attacker can cause the node to use that stable address by simpl directing a packet to it. > 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. All the above said the main benefit that temporary addresses buy you is trying to mitigate correlation of node activities within the same network (which, at times, is not possible no matter whether your addresses are temporary of not). In those cases where temporary addressess are deemed to be unacceptable (from an ops perspective), draft-ietf-6man-stable-privacy-addreses can result in an acceptable tradeoff. > >>> 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. Such higher-layer IDs are not required for all apps.. And employing constant IIDs hurts the privacy of nodes that are not using using such higher-layer IDs. >> 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... It wasn't meant to. > 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. The fact that you clarify "Note: I'm behind a firewall" is pretty much an implicit acknowledgement that the scheme you're using is flawed. (With that logic, you can use any flawed scheme as long as you keep your node unplugged from the net.) You don't need any firewall to mitigate this attack vector if you implement draft-ietf-6man-stable-privacy-addresses rather than the scheme currently implemented by Windows. > 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.) Well, the challenge is in tracking nodes that we assume that do not want to be tracked.... >>> 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. The onus is on you for wanting to keep them constant, rather than on me for being proactive (and avoiding the kind of IDs that lead to flaws in so many other protocols). > 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". Sound pretty much sound like "It works -- as long as nobody wants to exploit it --.. but our customers bought it anyway... so why should we don't care?" to me. That said, draft-ietf-6amn-stable-privacy-addresses doesn't obsolete the traditional SLAAC IIDs, nor your non-standard approach... So you're free to keep your stack "as is". In the same way that those who care about an improved scheme, can implement it. It's a win-win situation, you might say. :-) FWIW, I know of at least three OSes that plan to implement draft-ietf-6man-stableprivacy-addresses. Thanks, -- 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 --------------------------------------------------------------------
