This discussion got me thinking about how to be rigorous in articulating the specific threats that different kinds of addresses do and do not mitigate. I put together a little table to try to sum this up: http://www.alissacooper.com/files/IPv6-address-threats.pdf
The table assumes, for simplicity, that the node in question doesn't use any higher-layer identifiers and is never behind a firewall. I think I've seen four different kinds of threats described in the course of the discussion of this draft, listed as the columns in the table: (a) A typical address scanning attack for the purpose of exploiting the nodes found by scanning (b) An attack that involves scanning an address space, identifying which nodes respond, and subsequently tracking the locations of those nodes. I'm not exactly sure what the point of doing this is, so maybe it shouldn't be included, but I left it in. (c) An attack wherein the attacker receives a node's address through some channel (email, p2p serving, etc.) and then tracks the location of that node later. (d) An attack wherein the attacker receives a node's address through some channel and then correlates the node's activities together. The rows of the table are the address generation methods that have been discussed. The first three are for nodes that only use stable addresses and never use temporary addresses. Incidentally, I assume that it is this kind of configuration that Fernando's draft is targeting -- the scenario where a network administrator has disabled temporary addresses regardless of the desires of the user, as described in section 1 of the draft. As can be seen in the table, both random and random-per-network (my term for what the draft calls stable privacy addresses) mitigate both types of address scanning attacks. Random-per-network additionally mitigates location tracking and potentially reduces the amount of time over which correlation can take place. The second group of three are for nodes that only use temporary addresses (but that also configure a stable address that never gets used). This is what would be expected by users that want to avoid correlation attacks, assuming their admins allow it. In this case random and random-per-network provide equivalent protection. The last group of three are for nodes that use both temporary and stable addresses. Again here both random and random-per-network prevent the first two attacks, but random-per-network also prevents location tracking and potentially reduces the scope for correlation. I think the conclusion from this is that if there are lots of nodes out there that want to be protected from location tracking and correlation but their admins won't let them use temporary addresses, then random-per-network (row 3) provides some benefits over random (row 2). If we're talking about the case where a node can use temporary addresses and only uses them, random and random-per-network provide the same benefits (rows 5 and 6). I'm assuming those are the two common cases (could be wrong though). If we take away the assumption that the node uses no higher-layer identifiers, then correlation becomes possible in all of the cases for the duration of max(life of higher-layer identifier, longest-lived address). If we take away the assumption that the node is never behind a firewall and assume that it will never respond to unsolicited packets (maybe too much too assume, but let's try), then the only differences between the address generation mechanisms are with respect to correlation. Random-per-network still provides some benefits over random in this case. Not sure if this is helpful to anyone else, but it clarified my thinking on this a bit, and it might be worth making the threat analysis in the draft more specific along these lines. Alissa On May 24, 2013, at 5:31 AM, Fernando Gont <[email protected]> wrote: > On 05/22/2013 03:34 AM, Dave Thaler wrote: >>> 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. > > As noted, this wasn't meant to be personal -- it was just meant to be an > example. > > Now, given the example under discussion: > > I could learn your IID when we both attend the IETF meeting. And I could > learn your prefixes when you post to mailing-lists from such places. > Then I could use Prefix|IID to track you. > > The fact that you use a firewall is mostly irrelevant. I'd bet your > firewall still reponds to some packets (e.g., packets with unsupported > options?). And, if that were not the case, I could rely on the > ICMPv6 "address resolution failed" error messages sent by your local > router (i.e., if I receive one of such messages, you're not there. If I > don't, you are). > > I've seen similar discussions for different kinds of IDs in the past, > and every time someone pushed a flawed/sub-optimal approach, they got > bitten. Moral of the story: don't leak more than necessary to achieve > your desired goal, or you'll be bitten. > > P.S.: This was discussed off-list already... but I posted this on-list > so that wg participants are aware of my response. > > Cheers, > -- > 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 --------------------------------------------------------------------
