Disclaimer: haven't read all the prior list discussion so don't know if this duplicates some existing discussion.
I have some fundamental problems with this document as is. 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): > 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. If you have two addresses that simultaneously or over time are associated with the same higher-layer ID, then those two addresses can be linked. Separate is the issue of location. Once you have a stable higher-layer ID that anyone can resolve as you move around, changing the address linked to it doesn't provide any additional privacy (unlinkability). 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. 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. 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. That's faulty logic in my view. Privacy or lack of privacy is an explicit decision the application or administrator can make. If you opt out of it, you can't complain that you don't have it. So if the P2P app opted to use public addresses because the app is already using a higher-layer ID that can be resolved to the addresses it will use then no privacy is lost that wasn't already lost by using the higher-layer ID (which was linkable to the addresses). The same issue occurs with B.1.2 and B.1.3. 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. 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). I would fully support an RFC that uses random public (stable) addresses. 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. 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. A privacy address is one either (a) not intended to be resolvable from higher-layer IDs, OR (b) one resolvable only from a higher-layer ID that is invented for that address and only ever resolvable to that single address (example: the ipv6-literal.net form of the address. See http://ipv6-literal.com/). The doc says that apps wanting "server-like" functions use public addresses. The key is in defining what that means, 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. Once you agree on that definition, I think this notion of public addresses that vary by location does not appear to be useful. Rather than standardizing an ill-motivated notion, I would rather see the WG focus on publishing an RFC focusing on the address scanning problem that solves it in a way that we already have over a decade of operational experience with, which is long overdue. In doing so, the same doc could provide additional clarifications on when to choose public vs privacy addresses. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
