Hi, In-line...
On 24 May 2013, at 02:00, Fernando Gont <[email protected]> wrote: > 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" OK. >> 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). OK, I simply think that you were implying that because many enterprises will want to/try to disable 4941, that this was an argument for using stable privacy addresses. In my view, I would certainly use stable privacy *and* 4941. >> 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? Maybe just add an example, ", e.g. such as addresses in web server logs, included in email headers, etc". >> 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. OK, that's an advantage, but you could still deduce something from the addresses that change, and whether the address is used as a source or destination 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. OK, but see above. >> 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. Sure, the above was just an example. But Dave has a point, that if you have a default inbound policy at the edge, this type of exposure is unlikely, at least from network probes. A similar argument to having protection against externally sourced ND exhaustion attacks the same way. It may be worth stating this in the draft, as I'm sure others will point this out in the same way Dave has. >> 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. OK. >> "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. Ah, OK. I must run your script on my address samples some time :) >> 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). OK, I was wondering if you were implying something else. That's fine. >> 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. OK. >> 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. OK, I always assume the former, but I appreciate many prefer to disable 4941 where they can. >> 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" OK. >> 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? I have no strong view, just noting that if a network permits rogue RAs, much worse things can happen. >> Perhaps note/remind here that RFC4862 says to run DAD per prefix >> (section 5.4). > > mmmm... not sure what you mean. For each different IID generated. Currently implementations *might* assume the IID is the same for link-local and global via traditional SLAAC. RFC4862 notes that you should run DAD on all addresses. >> 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. :-) Well, nor me, but if you run MIPv6 you're by design wanting to be reachable by a persistent address. I guess at the very least you can say your method can apply when forming the Home Address during the initial bootstrap with the Home Agent. And when the host roams and gets a Care-of Address, the IID used to form the CoA at each visited network will be different, and different to the IID used for the HoA. This I guess would reduce trackability as you roam, but would be good for a MIP guru to comment. >> 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"? Yes, just wondering. Tim > 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 --------------------------------------------------------------------
