> correlation but their admins won't let them use temporary addresses, > then random-per-network (row 3) provides some benefits over random (row 2).
So is the goal of the draft to give a new way for network administrators to decrease privacy of users? If yes, then if this goal was removed, would the rest of the outlined benefits still warrant the proposed type of addresses? -----Original Message----- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Dave Thaler Sent: Friday, May 24, 2013 3:04 PM To: Alissa Cooper; Fernando Gont Cc: 6man-cha...@tools.ietf.org; Brian Haberman; 6...@ietf.org; Ray Hunter; tom.petch; Christian Huitema; He Xuan Subject: RE: Comments on draft-ietf-6man-stable-privacy-addresses-07 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
