I'd also like to see CGAs (3972) added to this analysis. It seems to me they're the existing standards-track "random-per-network" addresses. So all of the "random-per-network" statements would seem apply equally to the existing RFC.
This draft references that RFC but does not contain any discussion on the relative use cases. I.e., if I already use CGAs for my "random-per-network" solution, is there any benefit in this draft? What problem is this solving that wasn't already solved by that existing Proposed Standard RFC? -Dave > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Dave Thaler > Sent: Friday, May 24, 2013 3:04 PM > To: Alissa Cooper; Fernando Gont > Cc: [email protected]; Brian Haberman; [email protected]; 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:[email protected]] > > Sent: Friday, May 24, 2013 2:34 PM > > To: Fernando Gont > > Cc: Dave Thaler; [email protected]; [email protected]; 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 <[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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
