It also now occurs to me that since RFC 3972 has IPR disclosures from both Microsoft and Ericsson, those disclosures may or may not apply to draft-ietf-6man-stable-privacy-addresses as well.
Per the Note Well, I'm at least sending this email, but will check with Microsoft folks to see whether an IPR statement would be needed on this draft (personally I have no clue). I'd suggest that any Ericsson folks paying attention might need to do the same. -Dave > -----Original Message----- > From: Dave Thaler > Sent: Friday, May 24, 2013 3:20 PM > To: Dave Thaler; 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 > > 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: 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 --------------------------------------------------------------------
