Fernando Gont wrote on 20/1/2013 03:00: > Hi, Tassos, > > On 01/19/2013 07:49 PM, Tassos Chatzithomaoglou wrote: >> First of all, i would like to see a reference to cases where the prefix >> doesn't change too often (since this is recommended by many people for >> various deployments, i.e. residential dsl) due to mostly renumbering >> issues. In this case, Privacy Extensions seem to offer an advantage in >> terms of host tracking. > This document notes that for the most part, stable-privacy-addresses are > orthogonal to temporary addresses. > > That aside, the main issue with host tracking is when a host moves from > one network to another. If you talk about correlation of host activities > within the same network, then the benefits may be debatable. e.g., if > you have a single host behind a router, then the use of privacy > addresses makes no differences. > > Can you please elaborate more on the last sentence? I can have 2 (or more) hosts within the same network, each one belonging to a different person/floor/family/etc. With temporary addresses i cannot (easily) track each one, while with stable addresses i can. >> Also, it would be good to include some examples of IIDs produced by an >> implementation of the proposed algorithm, taking into account various >> scenarios with common parameters. > You mean something like what's in slide 21 of > <http://www.si6networks.com/presentations/brucon2012/fgont-brucon2012-recent-advances-in-ipv6-security.pdf>? > If i understand correctly, those are EUI-64 IIDs. I was hoping to include some stable IIDs like the ones generated by the described algorithm, for various combinations of parameters (prefixes, networks, etc). >> Lastly, in a comment i had made back in March 2012 regarding your draft >> and source address selection, and now looking at current rfc6724 i can >> see the following: >> >> Rule 7: Prefer temporary addresses. >> If SA is a temporary address and SB is a public address, then prefer >> SA. Similarly, if SB is a temporary address and SA is a public >> address, then prefer SB. >> >> Although the implementations must provide a mechanism allowing an >> application to reverse this, if the above is the default behavior >> meaning that if privacy extensions are enabled, temporary addresses will >> have preference over your stable addresses, then i think the following 2 >> paragraphs don't apply anymore in your draft. Please correct me if i'm >> wrong. >> >> On the other hand, in scenarios in which "Privacy >> Extensions" are employed, implementation of the mechanism described >> in this document would mitigate host-scanning attacks and also >> mitigate correlation of host activities. > They would mitigate host-scanning because they eliminate the remaining > predictable addresses. OTOH, they would mitigate host-tracking, since > they eliminate IIDs that are constant across networks. > > >> On the other hand, in the case of hosts employing "Privacy >> Extensions", the method specified in this document would prevent host >> scanning attacks > For this one, same as above. > >> and correlation of node activities across networks >> (see Appendix A >> <http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02#appendix-A>). > This is correct. If anything, the only thing that might still be > possible is correlation of activities of hosts that belong to the same > network. However, as noted above, it is debatable the extent to which > privacy addresses help in this area (please see the corresponding > references in the I-D). >
I see you already describe that in your doc, so i'm ok. > >> ...and some editorial comments... >> >> The resulting interface identifiers remain constant/stable for >> each prefix used with SLAAC within each subnet. That is, the >> algorithm generates the same interface identifier when configuring >> an address belonging to the same prefix within the same subnet. >> >> within the same subnet. => within the same subnet (assuming parameters >> defined in Section 3 remain the same). > Should we really make this explicit? --If you change the network > parameters (prefix and/or network_id), you can probably argue that, from > a "logical" point of view, it's a different network. > > What happens if i reboot/power-off-on the host or if i manually change the secret key? > >> The resulting Interface >> Identifier should be compared against a list of reserved >> interface identifiers and to those already employed in an address >> of the same network interface and the same network prefix. In >> the event that an unacceptable identifier has been generated, >> this situation should be handled in the same way as the case of >> duplicate addresses >> >> employed in an address of the same network interface and the same >> network prefix = > employed in an address of another host through the >> same local network interface and using the same network prefix > No. This is the job of DAD. > The way it's written, i seems like you expect to have the same host generate more than one stable IIDs for the same interface/prefix. If that's the case, then i don't think DAD will have any effect, unless a multicast loop-back is in effect. And in that case, DAD doesn't consider this a duplicate address. >> Unless, we assume everyone is allowed to use its own list of reserved >> identifiers. >> >> In the event that a DAD conflict cannot be solved (possibly after >> trying a number of different addresses), address configuration would >> fail. In those scenarios, nodes MUST NOT automatically fall back to >> employing other algorithms for generating interface identifiers. >> >> Shouldn't an error message be logged somewhere? > I wouldn't oppose to this -- however, this is probably "out of scope", > since DAD failures should also be logged when they happen for addresses > generated with other algorithms. (i.e., IMHO, this requirement should > be in a DAD specification, rather than here). > > Agree (DAD already logs this). >> This document does not require the use of any specific PRF for the >> function F() above, since the choice of such PRF is usually a trade- >> off between a number of properties (processing requirements, ease of >> implementation, possible intellectual property rights, etc.), and >> since the best possible choice for F() might be different for >> different types of devices (e.g. embedded systems vs. regular >> servers) and might possibly change over time. >> >> and might possibly change over time => it might possibly change over time > Isn't the subject implicit? > Ok. Thanks, Tassos -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
