Hi, Eliot Lear commented:
#I'm sure many of us had the first reaction that all this stuff should #be decentralized, which of course leads to "let's all get to IPv6". #To the extent that consumers are able to have a choice about this, #it's quite possible that a decentralized model using our existing #protocol suite could *harm* privacy as Ned mentioned above. Beyond #that, one has to ponder what externalities are introduced by having #yet more consumer code accessible to the great wild world. I. From my POV, IPv6 has the potential to either help OR harm privacy, depending on the addressing model employed. On the one hand, IPv6 privacy addresses, at least if used in a relatively densely populated and actively used IPv6 /64, has the potential to make it harder to persistently track individual users. (If you're one of just a handful of IPv6 users in a given /64, or the *only* IPv6 user in a given /64, privacy addresses are less helpful when it comes to making tracking difficult). Many sites deploying IPv6 may routinely deprecate or discourage use of IPv6 privacy addresses, however. -- If SLAAC is being used, instead, and a modified EUI-64 address is embedded in the IPv6 address, I would assert that privacy is *worse* than the IPv4 case, since that embedded MAC address allows persistent per-device (and in the case of dedicated end-points, per-user) tracking. -- If DHCPv6 is being used, I would assert that it has privacy properties essentially *equivalent* to IPv4 addresses assigned via DHCP (e.g., the address assigning entity can typically map the user's assigned address to a given entity, whether that's an ethernet jack in an assigned office or an authenticated wireless identity, etc.) So depending on the addressing model, you may see equivalent privacy, better privacy, or worse privacy from using IPv6. II. I'd also note, addressing aside, that IPv6 application traffic may be more likely than IPv4 traffic to end up getting forced through intentionally introduced control points. That is, coming back to mail, I wouldn't expect most ISP mail servers, even if they were enabled to accept IPv6 traffic (and make no mistake, most aren't), to accept mail traffic from random IPv6 end points. In most cases, if you want SMTP traffic over IPv6 to be accepted by major providers, it will need to be relayed via a mail server that has been specially configured for that role. (Terry Zink has done some nice work in this area, see for example http://blogs.msdn.com/b/tzink/archive/2013/09/11/supporting-email-over-ipv6-part-1-an-introduction.aspx ) Of course, any time you have a control point, that control point exists in part to "process" traffic -- hopefully handling things like filtering unwanted spam and malware, but we cannot discount the possibility that national authorities may also leverage that choke point for monitoring purposes. Eliot also commented: #One of my favorite studies to cite is that of Stephan Frei who looked at #update rates and compared business models. [snip] I'm thinking of code #used in SCADA systems and automobiles in particular. Almost ten years ago now, I was invited to do a talk about SCADA security and critical infrastructure for the local Infragard chapter. While that's an old talk, sadly all too little has changed since then. If you want to eyeball it, see http://pages.uoregon.edu/joe/scadaig/infraguard-scada.pdf On slide 41, I noted that plants and the instrumentation they use tend to have long life cycles -- ten, fifteen or even twenty year projects in many cases. What gets installed at the birth of that project may still be in use a decade or more later. (And of course, that can be the equivalent of having a "Model T" on I-95) On slide 43, I noted that many remote devices tend to be hard or impossible to upgrade. Code may be burned in a ROM, and upgrading code may involve replacing ROMs. Devices may be physically sealed and non-upgradeable. Or devices may be located in hard-to-reach locations (top of a smokestack, perhaps) or the vendor that produced the device may no longer be in business. Upgrades may simply be rare or non-existent. You get the idea. My point is that patching cycles that are routinely expected and accepted in the enterprise space may be completely impractical in the control system space. Of course, the historical excuse for tolerating this was, "Oh, but these devices will be run over a dedicated network airgapped from the Internet," but naturally, over time, things like Bob Radvanovsky's "Project SHINE" have empirically illustrated that theory and practice diverged somewhere along the line. (For a recent article on Project SHINE, see for example http://www.darkreading.com/vulnerability/project-shine-illuminates-sad-state-of-s/240162739 ) Regards, Joe _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
