On 05/28/2013 11:07 PM, Alissa Cooper wrote: >>> 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". >> > > Intentionally used is what I was going for, since some of the > discussion about the choice of address generation mechanism revolves > around intention. That is, some implementations/users might choose > temporary addresses for specific reasons, sys admins might choose to > disable them for specific reasons, etc.
IMO, there's a big difference between e.g. RFC4941-disabled vs. RFC4941-not-used (e.g. as a result of default source address selection). (the same applies to other combinations). As noted in stable-privacy, an attacker can leverage e.g. the MAC-based addresses even if RFC4941 are implemented, enabled, and preferred. >> An attacker can trigger the use of such addresses, e.g., y sending >> his probe packets to the stable address. > > In the case of a node that only intentionally uses temporary > addresses, are there other uses you envision of that node's stable > address besides the attacks in (a) and (b) in the table? Not sure what you mean. Attack (c) employs the stable addresses, too. >>> (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. > > Not sure what this means -- in terms of the user's intent, I assume > most users intend to either use a stable address all the time or use > temporary addresses all the time. Not necessarily: the policy might be conveyed by the application. BTW, what's "random"? -- Microsoft approach to stable addresses, or what? >>> 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). > > Agreed. However, even with the appendix, there are still some places > where the discussion of the threat models in section 1 could be > clearer, IMO. For example: > > However, even with temporary addresses [RFC4941] in place, preventing > correlation of activities of a node within a network may be difficult > (if at all possible) to achieve. As a trivial example, consider a > scenario where there is a single node (or a reduced number of nodes) > connected to a specific network. An attacker could detect new > addresses in use at that network, an infer which addresses are being > employed by which hosts. This task is made particularly easier by > the fact that use of "temporary addresses" can be easily inferred > (since the follow different patterns from that of traditional SLAAC > addresses), and since they are re-generated periodically (i.e., after > a specific amount of time has elapsed). (FWIW, I moved the above text to Appendix B). > My read of this is that you're talking about either (1) a situation > where a node has a globally unique prefix, Not sure what you mean. > or (2) a situation where a > small number of nodes share the same prefix and an attacker can > disambiguate them using some other information about their behavior > besides their IP addresses. Not sure what you mean by "other information"... > Is that right? If that's the case, isn't > correlation possible regardless of how the suffix is generated? The > document seems to imply that nodes with temporary addresses are more > susceptible to these two situations than nodes that use other address > generation mechanisms, No. The document just says that those attacks are still possible with RFC4941 -- of course, they are possible without RF4941, too. > when in fact the first situation (globally > unique prefix) probably affects all nodes equally regardless of > generation mechanism, and in the second situation the fact that > temporary addresses refresh frequently might erect a barrier that > makes correlation more difficult and that would not exist with random > or random-per-network addresses. Of course, if you don't implement RFC5941, you don't even need to analyze the address changes. Again: The appendix just highlights attacks still present with RFC4941. It does not imply that those attacks are not impossible with the traditional IEEE-based addresses r with the Microsoft approach t stable addresses- > > Another point for clarification: > > On the other hand, in scenarios in which "temporary addresses" are > employed together with stable addresses such as those based on IEEE > identifiers, implementation of the mechanism described in this > document would mitigate address-scanning attacks and also mitigate > some vectors for correlating host activities that are not mitigated > by the use of temporary addresses. > > Which correlation attack vectors do random-per-network addresses > mitigate that temporary addresses do not? See appendix B of drat-ietf-6man-stable-privacy-addresses. > In the analysis in column > (d) of the table, the correlation entries are the same for all of the > address generation mechanisms in cases where the node intentionally > uses temporary addresses. Agreed. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
