Hi Fernando, Comments inline.
On May 26, 2013, at 9:01 AM, Fernando Gont <[email protected]> wrote: > 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. > Fair enough. > > >> -- 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". > 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. > 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? > > > >> (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. > > > >> 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). 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. 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. 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 --------------------------------------------------------------------
