On 05/24/2013 03:22 PM, Tim Chown wrote: > >> 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.
I would use stable privacy and RFC 4941, too. What I tried to convey in the text was something like "we need to improve the stable addresses. This scheme have these benefits, which complement those of rfc4941... That aside, in those scenarios where rfc4941 is disabled, implementing this will bring you these benefits, and provide an interesting trade-off for folks that disable rfc4941". Me, i'm in favor of having stable privacy + RFC 4941. Applications are in a better position of deciding which type of address is better for them. But I understand that folks operating e.g. enterprise networks may have valid reasons to disable rfc4941. >>> "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". Ok, done. >>> 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. Agreed. [context: talking about mac-based addreses not used much in practice] >> >> 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. Would relying on something that is not under your control be a wise thing to do? > 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. I'm of the idea that if your implementations suffers from ND exhaustion attacks, you should fix it. -- Temporary mitigations are okay (operators need a quick fix they can apply now), as long as the origin of the problem is tackled, too. >>> 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 :) Please do. :-) -- BTW, ISOC's Mat Ford did, already (have you seen it?). >>> 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. I personally think that we should improve the stable addresses. And for my client node, I'd use RFC 4941, too. Improving the stable addresses help both the guys that do rfc4941, *and* the guys that don't. >>> 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. Agreed. >>> 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. I'd have no problem with adding this. However, isn't it a *requirement* to do that, already? >>> 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. Will try to find one, and ask for input. Thanks! 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 --------------------------------------------------------------------
