Hi, Tim, Thanks so much for your feedback! -- Please find my comments in-line...
On 05/22/2013 10:19 AM, Tim Chown wrote: > > Overall, I think this is good work and should be progressed. Thanks! > First, some general comments: > > You may wish to be clearer earlier in the document (abstract and/or > introduction) that your method applies to all prefixes a host may > have, including link-local, ULA, and global(s). As it stands, you > only, for example, mention link-locals first in Section 3. Good point. I've tweaked the abstract, and have also clarified this point in Section 3. > The implication of the above is that a multihomed host will have > different IIDs per ISP it receives a prefix from. This may have > privacy advantages in a static device scenario (this is implied, but > never stated anywhere that I can see). So... how about a bullet along the lines of: "Since the method specified in this document will result in different Interface Identifiers, knowledge/leakage of the Interface Identifier employed for the stable address of one prefix will not negatively affect the security/privacy of the stable addresses configured for other prefixes" > There is some focus in your text on why you might disable 4941. > That's not that common a practice, esp. in campus networks, or home > networks. While some admins may wish to disable 4941 where they can, > I think you should promote use of your method with 4941 being > perfectly reasonable to use alongside it, rather than saying "because > 4941 may be turned off, we need this method". Related, is that in a > few places you talk about your method helping to reduce tracking > between networks, while in practice using 4941 for static (desktop) > devices does have benefits. I'm all for the use of this method along with RFC4941...I was just noting that in some scenarios RFC4941 might be turned off not because a non-desire for privacy, but for operational reasons. I've tweaked the text a bit in the hopes that readers don't get the impression that I'm arguing against use of RFC4941. (Most likely, by the time you read this I'll have posted version -08... so please check that one... and if there's still room for improvement in this area, I could post a -09 version based on your suggestions). > Specific comments: > > Section 1: > > In the bullet point "since embedding" you may wish to be clearer that > the "pattern" is the IID format caused by, for example, basing the > IID on an IEEE identifier. I have added a clarification to that bullet. - Thanks! > "other information collectors", I guess you mean sites running > services, e.g. typically through web server logs. This was borrowed from RFC 4941. -- anything to tweak here? > Not sure what the point about inferring that temporary addresses are > in use buys you. If you know that they are temporary addresses, you will expect them to change. On the other hand, if temporary addresses looked exactly the same as stable addresses, you'd have to figure out whether they are different nodes, or the same node with a new temporary address. > Do you mean that with a small number of hosts in a > subnet you may be able to deduce which devices are which by looking > for when their addresses change? Yes. > That doesn't help you identify that same host later or in a different network > though? If you can continually poll/see/communicate_with the node and detect the address changes, you might still correlate the activities of a node within a network (of course, when the number of nodes increases, and/or the lifetime of temporary addresses is reduced, it gets much trickier). The simple example would be: Let's say you see two addresses on a given network. Say, 2001:db8::1 and 2001:db8::2. All out of the sudden you stop seeing packets from 2001:db8::2, but also start seeing packets from 2001:db8::10. -- It would all look like 2001:db8::10 is the same node as 2001:db8::2. > As an aside here, I looked in our network monitoring database, and my > desktop Mac over the last month has been seen to use a link-local > IPv6 address, many IPv6 privacy addresses, and an IPv4 global > address, but not its global SLAAC address. That's because nothing > has connected to it from outside the local subnet. Sure, if we did > not have an IPv6 firewall (as Dave pointed out) the host could be > scannable due to its "predictable" Mac OUI, but it's interesting that > in the last month, my global SLAAC address has never been used. Of > course I don't happen to run any advertised services, though if I did > my address would most likely be discoverable by looking at the DNS > name it is referred to by. The problem here is that once the stable address (or, more specifically, its IID) becomes known to an attacker, you can be subject to host-tracking by active probing. The stable IID might become known to an attacker because at some point in time you advertised that IPv6 address, but also because you e.g. shared a network with an attacker. A simple example is that if we attend the same conference/cafe/whatever and you could learn my stable IID (based on my MAC address). Then you check the headers of my emails, and learn the v6 prefixes of the networks I typically connect to. And, after that, you could tell whether I am online by polling KnownPrefixes|IID. An you shouldn't need a firewall to prevent *this*. Actually, strictly speaking, the fireall won't prevent this: you can still probe the node in different ways that the firewall won't block. > Section 3: > > Second main paragraph, you might add "just as per SLAAC today", or > words to that effect. I don't think this is any change as such. Agreed. I just wanted to clarify that the requirement of "MUST use this method for all addresses" does not apply to temporary addresses -- since they *can* be used in conjunction with draft-ietf-6man-stable-privacy-addresses. -- I've moved the sentence you mention right befre the parenthetical note. > Not sure about mentioning IIDs smaller than 64 bits here. You may > wish to more clearly recommend that your method uses 64-bit IIDs? Previous versions of the I-D didn't. But then I was told that there was no reason to hardcode the IID length in this I-D -- hence I tweaked the text accordingly. Although I agree that hardcoding the length of IIDs to be 64-bit long makes the text clearer. > "Including the SLAAC prefix"... you say the IID then varies across > networks, but you may wish to add that the IID will also vary across > each prefix the nodes uses (link-local, ULA, each global if > multihomed). I've tweaked the text accordingly. > There's a conflict in the next paragraph about "desirable" and "MUST" > - which is it? s/desirable/required/ :-) -- fixed! > The comment about MS Windows should perhaps be more orthogonal. A > node IID may be manually configured, it may use DHCP, it may use > SLAAC with IEEE identifiers, it may use your method, it may use the > method MS Windows uses, or it may even use the tokenised identifier > method that I posted a while ago. It can use any of those, AND use > 4941 as well. But saying "such implementations would not be affected > by the method" doesn't sound quite right. The point I was trying to make is that traditional slaac (in terms of # of nodes) is not as widely deployed as one would expect. > Section 4: > > Fourth main paragraph, what is the most likely cause of repeated DAD > conflicts/failures? NS/NA DoS? Yes (of course, assuming 64-bit IIDs). > Is there anything else that would be likely to cause this? Worth > elaborating on that when considering tuning the retry limit? My take is that, in a really unlucky scenario, you might get 1 collision, but no more than that. The value "3" is somewhat arbitrary, I should say. > Section 7: > > Maybe clarify that the first bullet point is for inbound connections > only. That's correct if this is implemented along RFC4941. However, if this is implemented without RFC4941, this method still prevents such trivial host tracking. > A fourth bullet point could be that you do not disclose hints about > hardware types. Good point. Added! > A fifth could be that IIDs may only be tracked or probed for each > prefix the host is known to use, e.g. detection or disclosure of the > link-local IID does not compromise the IID used for incoming global > connections. So if you sniff for IPv6 service discovery traffic, for > example, you may learn a node's link-local IID, but not be able to > deduce its global address. Added as: "Since the method specified in this document will result in different Interface Identifiers, knowledge/leakage of the Interface Identifier employed for the stable address of one prefix will not negatively affect the security/privacy of the stable addresses configured for other prefixes" > How does your RA "attack" work in practice here? Do you mean issuing > a rogue RA for the same prefix? We should perhaps assume that robust > rogue RA protection is in place, and if not there are many worse > things an attacker can do! Agreed. I added this attack vector description, since it was described by Christian Huitema... so I added it for completeness sake. Should I twek the text? Remove it? > Perhaps note/remind here that RFC4862 says to run DAD per prefix > (section 5.4). mmmm... not sure what you mean. > Appendix B: > > B.1 you say "one possible attack", then list more than one. Fixed. > B.1.3 Worth any consideration of MIPv6 here? It has been years since I last checked MIPv6 (and when I did, I mostly just skimmed through it). So... up to you. :-) > The Home Address is > obviously trackable, by design, but any Care-of Address could benefit > from your approach. Are there mobility methods anywhere else that > might assume static IIDs though? You mean "IIDs that are stable across networks"? P.S.: Please check version -08, and let me know if there are any further tweaks I should apply. Thanks so much! 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 --------------------------------------------------------------------
