Hi, Erik, On 08/20/2013 05:55 AM, Erik Kline wrote: >>> I agree that this all seems fine in theory. Are we collectively >>> convinced this will not lead to tragically (IPv6-)orphaned machines in >>> certain scenarios? >> >> Sorry, what are the scenarios you have in mind? > > Well, I guess first I wasn't 100% sure I could think of all the > link-local uses and how they would interact with needing to load > parameters before starting essential functions for higher layer IPv6 > and application things.
Well, at the point you're going to load v6, you certainly had plenty of chances of loading any "parameters". For instance, you probably have a kernel running, already (which requires many more parameters than just a secret). > However, as I said I can't see a problem with > it in theory. It's one more thing to wait for before waiting for DAD > to complete. No theoretical change; fine. > > But secondly, how would you implement this in, say, Linux? Right now > link-local IPv6 things can begin as soon as the module is loaded or as > soon as an interface becomes active if it's already loaded. Please see above. I'm not that savvy in Linux internals. I'd note, though, that besides the above comment, BSD people didn't find any issues. > To support this scheme as I understand it, the Linux kernel ipv6 code > would need to take some module parameters at boot or load time, so as > to force it to not do link-layer-derived link-local autoconfig but > instead load up the required parameters from non-volatile storage. Is > my understanding correct? You need to have some secret available before you configure IPv6 addresses. Most likely, you'd get this secret from some config file -- but that's up to the implementation. > If so, has anyone written this and gotten > feedback from net maintainers? Not written, yet. But there have been a number of develeopers that have looked at this, and didn't find this "load a secret" thing a show-stopper. > I guess I just think that all of the concerns about addresses raised > in draft-cooper-6man-ipv6-address-generation-privacy *don't* > meaningfully apply to link-local addresses. That's assuming such IPv6 addresses will not leak out -- which I think you cannot guarantee. Stupid example (certainly not the best): your node contacting an MTA with a link local address, which leaks in the mail headers. (again, not the best example, but simply a proof of how addresses can leak, no matter whether they are link-local). > That document's section > 4.2.2 says that the addresses are basically available to an on-link > adversary anyway. So I guess I don't see the point of "fixing" > something that I don't think is actually broken in this specific > context (speaking of link-local use case specifically). Please see above. Moral of the story: be proactive. A bad idea is... a bad idea. So if you don't find a scenario where a bad idea can be harmful, that doesn't mean attacker won't find it, or that such scenario doesn't exist. Cheers, -- 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 --------------------------------------------------------------------
