Hi Fernando, I've read -07 and have some comments. Apologies if they are duplicates of previous comments.
Overall, I think this is good work and should be progressed. First, some general comments: You may wish to be clearer earlier in the document (abstract and/or introduction) that your method applies to all prefixes a host may have, including link-local, ULA, and global(s). As it stands, you only, for example, mention link-locals first in Section 3. The implication of the above is that a multihomed host will have different IIDs per ISP it receives a prefix from. This may have privacy advantages in a static device scenario (this is implied, but never stated anywhere that I can see). There is some focus in your text on why you might disable 4941. That's not that common a practice, esp. in campus networks, or home networks. While some admins may wish to disable 4941 where they can, I think you should promote use of your method with 4941 being perfectly reasonable to use alongside it, rather than saying "because 4941 may be turned off, we need this method". Related, is that in a few places you talk about your method helping to reduce tracking between networks, while in practice using 4941 for static (desktop) devices does have benefits. Specific comments: Section 1: In the bullet point "since embedding" you may wish to be clearer that the "pattern" is the IID format caused by, for example, basing the IID on an IEEE identifier. "other information collectors", I guess you mean sites running services, e.g. typically through web server logs. Not sure what the point about inferring that temporary addresses are in use buys you. Do you mean that with a small number of hosts in a subnet you may be able to deduce which devices are which by looking for when their addresses change? That doesn't help you identify that same host later or in a different network though? As an aside here, I looked in our network monitoring database, and my desktop Mac over the last month has been seen to use a link-local IPv6 address, many IPv6 privacy addresses, and an IPv4 global address, but not its global SLAAC address. That's because nothing has connected to it from outside the local subnet. Sure, if we did not have an IPv6 firewall (as Dave pointed out) the host could be scannable due to its "predictable" Mac OUI, but it's interesting that in the last month, my global SLAAC address has never been used. Of course I don't happen to run any advertised services, though if I did my address would most likely be discoverable by looking at the DNS name it is referred to by. Section 3: Second main paragraph, you might add "just as per SLAAC today", or words to that effect. I don't think this is any change as such. The Network_ID might perhaps in the future be some MIF-related provisioning domain identifier. But your method does not preclude that. Not sure about mentioning IIDs smaller than 64 bits here. You may wish to more clearly recommend that your method uses 64-bit IIDs? "Including the SLAAC prefix"... you say the IID then varies across networks, but you may wish to add that the IID will also vary across each prefix the nodes uses (link-local, ULA, each global if multihomed). There's a conflict in the next paragraph about "desirable" and "MUST" - which is it? Perhaps you should state that you can never guarantee IID stability per prefix on any given interface, but your method seeks to honour that goal where it can. The comment about MS Windows should perhaps be more orthogonal. A node IID may be manually configured, it may use DHCP, it may use SLAAC with IEEE identifiers, it may use your method, it may use the method MS Windows uses, or it may even use the tokenised identifier method that I posted a while ago. It can use any of those, AND use 4941 as well. But saying "such implementations would not be affected by the method" doesn't sound quite right. Section 4: Fourth main paragraph, what is the most likely cause of repeated DAD conflicts/failures? NS/NA DoS? Is there anything else that would be likely to cause this? Worth elaborating on that when considering tuning the retry limit? Section 7: Maybe clarify that the first bullet point is for inbound connections only. A fourth bullet point could be that you do not disclose hints about hardware types. A fifth could be that IIDs may only be tracked or probed for each prefix the host is known to use, e.g. detection or disclosure of the link-local IID does not compromise the IID used for incoming global connections. So if you sniff for IPv6 service discovery traffic, for example, you may learn a node's link-local IID, but not be able to deduce its global address. How does your RA "attack" work in practice here? Do you mean issuing a rogue RA for the same prefix? We should perhaps assume that robust rogue RA protection is in place, and if not there are many worse things an attacker can do! Perhaps note/remind here that RFC4862 says to run DAD per prefix (section 5.4). Appendix B: B.1 you say "one possible attack", then list more than one. B.1.1 It will be interesting to see what emerging IPv6 "peer to peer" applications do. Do both ends use SLAAC/your method, both ends use 4941, or the "client" use 4941 and the "server" SLAAC/your method. B.1.3 Worth any consideration of MIPv6 here? The Home Address is obviously trackable, by design, but any Care-of Address could benefit from your approach. Are there mobility methods anywhere else that might assume static IIDs though? Tim On 22 May 2013, at 05:17, Fernando Gont <[email protected]> wrote: > 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: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
