Hi, Tassos, On 01/20/2013 07:15 AM, Tassos Chatzithomaoglou wrote: >> 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.
Simple example: let's say there are two hosts within a subnet, and that the lifetime of each temp address is 10 hours. Let's say that Host 1 was bootstrapped at time=0h, while Host 2 was bootstrapped at time=5hs. Let's say that at time=5h: Host 1: 2001:db8::1 Host 2: 2001:db8::5 Let's say that at time 10h, I start seeing the following addresses: 2001:db8::7 2001:db8::5 (i.e., one of the addresses is the same, and there's a new address) It wouldn't be hard to infer that 2001:db8::7 (i.e., Host 1 has changed its temp address). >>> 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. Note: EUI-64 != MAC address. draft-ietf6man-stable-privacy-addresses is said to generate Modified EUI64-format addresses, because it sets the global/local unicast/multicast bits as appropriate. > I was hoping to include some stable IIDs like the ones generated by the > described > algorithm, for various combinations of parameters (prefixes, networks, etc). They are going to be random, so... except for the example I referenced above (in the slideware), I'm not sure how they'd be of help. (the example from the slideware tries to illustrate that addresses are constant within a subnet, but *not* across networks). >>> ...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 secret is supposed to be constant. So it should be stored in non-volatile memory (i.e., nothing special would happen across reboots). OTOH, if you manually change the secret, of course the corresponding addresses would change. For instance, that's why two hosts (employing the same OS) would generate different addresses: because they will employ different secrets. >>> 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. No. I just consider the case that the host might be using e.g. temporary addresses. Simply put, the aforementioned text is meant to catch cases in which the algorithm generated an IID that is already in use, or that is reserved. However, the case of *addresses* that are duplicate is handled by DAD -- since that's part of SLAAC itself. 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 --------------------------------------------------------------------
