HI Alissa, Thanks for posting this. Please find my comments inline...
On 05/24/2013 11:33 PM, Alissa Cooper wrote: > > 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 Nope. We're improving stable addresses. Whether you use RFC4941 or not is pretty much orthogonal. >-- 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. This assessment is correct. Note, however, that stable privacy addresses are also meant to be used in conjunction with rfc4941. > 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 problem here is that the assumption of "never gets used" is not correct. Or, well, you might argue "is not intentionally used for legitimate purposes". An attacker can trigger the use of such addresses, e.g., y sending his probe packets to the stable address. > (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). Please see above. > 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. As noted, it is always possible to probe such node. e.g., rely on ICMPv6 "address resolution failed" from the local router at the victim cite to tell whether the node is there or not. > 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. How about including something along these lines (*) in an Appendix? (*) Discussion of possible attacks, and what stable privacy addresses do about them (analyzing this for every possible address generation mechanism would be out of scope for this I-D, IMO). Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -- 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 --------------------------------------------------------------------
