Thanks Alissa for the nice table, this is very helpful. > -----Original Message----- > From: Alissa Cooper [mailto:acoo...@cdt.org] > Sent: Friday, May 24, 2013 2:34 PM > To: Fernando Gont > Cc: Dave Thaler; 6...@ietf.org; 6man-cha...@tools.ietf.org; Brian > Haberman; Ray Hunter; tom.petch; Christian Huitema; He Xuan > Subject: Re: Comments on draft-ietf-6man-stable-privacy-addresses-07 > > 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.
I'm assuming here by (d) you mean correlation over_time_ of activities from the same node, even if it never moves. > > 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). Also, for nodes that never move (e.g., servers, desktop PCs, etc.) random and random-per-network are equivalent. > > 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). Agree. > > 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. Agree. For nodes that move between networks, yes. Nodes that never move don't gain those benefits of course. > > 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. I think it would definitely help the draft to include this analysis. Thanks again, -Dave > > Alissa > > On May 24, 2013, at 5:31 AM, Fernando Gont <fg...@si6networks.com> > 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: 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 --------------------------------------------------------------------
