Subject: Re: [perpass] Traffic analysis

From: "Joe St Sauver" <[email-masked]>
Date: Wed, 30 Oct 2013 09:52:35 -0700 (PDT)

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 Oct 2013 18:55:51 +0100

Hi Joe,

> national authorities may also leverage that choke point for monitoring 

That's an important point.  And so when a service offers a
spamfree/malware-free environment with few bugs, it still comes at a cost.

Eliot