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. > 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>? > 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). > ...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. > 2. The Interface Identifier is finally obtained by taking the > leftmost 64 bits of the RID value computed in the previous step, > and and setting bit 6 (the leftmost bit is numbered 0) to zero. > > and and => and Good grief! - Fixed! > 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. > Also if "a list of reserved identifiers" refers to > http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml, > then it should probably be "the list of...". Really good point. I will add a reference to this registry. Thanks! > 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). > 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? > > since it would mitigate host- > tracking vectors still present when privacy addresses are used > (Appendix A, > > (Appendix A, => (Appendix A), Fixed. Thanks so much! Best regards, -- 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 --------------------------------------------------------------------
