On 28 May 2013, at 22:07, Alissa Cooper <[email protected]> wrote: > > On May 26, 2013, at 9:01 AM, Fernando Gont <[email protected]> wrote: > >> 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). > > My read of this is that you're talking about either (1) a situation where a > node has a globally unique prefix, 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. 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, 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.
A static global prefix for IPv6 is not that dissimilar to a static IPv4 address with NAT for IPv4. You can correlate the home, for example, not necessarily devices within it. If devices rotate their 4941 address at fixed intervals, then you might be able to infer which devices are which from noting the number of addresses in use, and changes in addresses over time (e.g. old privacy address not seen for an outbound SYN, new address is seen). in principle the use of "TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE - DESYNC_FACTOR" for the refresh should provide some variation. In practice, the implementations I've observed seem pretty regular. More variation could be good in this respect. But that's not the topic for this draft. > 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? 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. If you use 4941 for outbound connections, and IEEE SLAAC default for inbound, then your IEEE based address is more readily guessable than had you used a stable privacy address. The above is currently the default for most IPv6 devices; 4941 support is now very common, and usually on by default. What is rarer (very rare?) is using 4941 addresses to initiate *and* receive new connections. I think that's the type of case that draft-rafiee-6man-ra-privacy discusses/proposes. Tim > > Thanks, > Alissa > >> >> Thanks! >> >> Best regards, >> -- >> Fernando Gont >> e-mail: [email protected] || [email protected] >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> >> -- >> 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 --------------------------------------------------------------------
