Subject: [perpass] Traffic analysis

From: "Christian Huitema" <[email-masked]>
Date: Sun, 29 Sep 2013 22:35:10 -0700

The massive monitoring attacks that we know about seem to fall into three
categories: listening to the content of communications in transit, accessing
content of documents and past exchanges at a server, and analyzing traffic
to find patterns of communications and deduce social exchanges.

I think we understand the "listening on conversations" attack, and we
understand that we need more encryption. We have some good ideas for
reducing the risk of accessing contents on server, such as storing encrypted
contents on servers, or enabling distributed services so that users can
chose server locations that they find more acceptable. But I wonder whether
we have a good approach for traffic analysis.

Traffic analysis proceeds through the collection of "meta data" such as ip
headers, e-mail headers, and other forms of signaling, e.g. SIP headers. DNS
traffic analysis also falls in that category. Such data is easy to harvest
by monitoring big conduits such as backbone links or submarine cables. In
some countries, the data is collected by forcing traffic through a single
exchange or through some form of "national firewall." 

The current internet protocols and applications pay very little attention to
traffic analysis. We should obviously take the easy steps, encrypt the DNS,
e-mail and SIP connections. But when it comes to IP header analysis, we have
pretty few solutions. VPN, of course, but that requires configuration. Could
we change that?

-- Christian Huitema

---

From: "d.nix" <[email-masked]>
Date: Sun, 29 Sep 2013 23:10:50 -0700

On 9/29/2013 10:35 PM, Christian Huitema wrote:

> Traffic analysis proceeds through the collection of "meta data"
> such as ip headers, e-mail headers, and other forms of signaling,
> e.g. SIP headers. DNS traffic analysis also falls in that category.
> Such data is easy to harvest by monitoring big conduits such as
> backbone links or submarine cables. In some countries, the data is
> collected by forcing traffic through a single exchange or through
> some form of "national firewall."
> 
> The current internet protocols and applications pay very little
> attention to traffic analysis. We should obviously take the easy
> steps, encrypt the DNS, e-mail and SIP connections. But when it
> comes to IP header analysis, we have pretty few solutions. VPN, of
> course, but that requires configuration. Could we change that?
> 

I feel in general, that while we can go a long way towards making
content encryption easier and more robust, and simple to use for non
tech savvy users (ie, your parents, aunts, uncles, etc...), *the*
single largest issue is traffic analysis of message headers.

While there are legit concerns by people to troubleshoot and to
identify sources of spam and bulk mail, it's just entirely too easy to
build up graphs of communication patterns and who is contacting who
and when they are doing it. VPN's are a possibility, but as you say,
require careful configuration and setup to prevent leakage of
identifying information. Tech that purports to secure or privatize
your communication but that actually leaks - or worse, can be coerced
into revealing your traffic, is worse than no tech at all.

Mix networks, anonymous remailers, and alternative / out of band
systems start looking worthy of a lot more study.

Dave Nix

BM-2D9jC7gYDpnfprbSXuTCGr6a2DsCAXssAc (bitmessage)

---

From: Brian Trammell <[email-masked]>
Date: Mon, 30 Sep 2013 12:49:34 +0200

On 30 Sep 2013, at 8:10 , "d.nix" <[email-masked]> wrote:

> and when they are doing it.

While traffic analysis can be applied to several areas of investigation, this is the most directly relevant to "intelligence gathering", and can be defended against as you say: prevent leakage of identifying information (which you must be _very_ good at if defense against identification and association is to work -- one weak observable link and you might as well have done nothing).

> VPN's are a possibility, but as you say,

These are good architectural defenses against association attacks, but come with (often high) bandwidth and latency costs, as well as additional operating expenses.

Another area of investigation is behavioral classification and fingerprinting: associating given encrypted traffic with an underlying protocol or activity. The old SSH keystroke timing attack [1] worked this way, as well as related identification attacks on anonymized trace data [2]. This is a completely different type of attack. Defense requires fingerprint resistance built into the protocol design: in an end-to-end, point-to-point encrypted communication system which, as most protocols _implicitly_ are, is optimized somewhere close to the minimal-bandwidth/minimal-latency curve, the presence of traffic on the wire means "someone's using the system", which given access to other information can be enough to answer interesting questions about associations.

Fingerprint resistance necessarily pushes the protocol away from this curve (with associated costs both in bandwidth and latency), and must also be done with attention to detail. Even Skype, a protocol which resists classification to resist blocking by ISPs which provided access to its customers while competing with it, left a signal reasonably well visible in flow data as part of its client association process [3] as of 2011, which at least allowed a single-flow identification of clients and supernodes.

So, I've been thinking about traffic analysis resistance recently (as I suppose a lot of people have :) ) and the question starts coming down to how much resistance for what cost, and is there a point at which we can get a significant win in the face of pervasive surveillance before the point in the cost benefit curve in which we start giving up things we'd really like to keep (acceptable latency/jitter for voice/video, acceptable bandwidth for a given cost, identification and prevention of email abuse, etc.)

Best regards,

Brian

[1] Song et al "Analysis of Keystrokes and Timing Attacks on SSH", USENIX Security 2001

[2] Coull et al, "Playing Devil’s Advocate: Inferring Sensitive Information from Anonymized Network Traces", NDSS 2007

[3] Trammell et al, "Identifying Skype Traffic in a Large-Scale Flow Data Repository", TMA 2011

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 01 Oct 2013 09:01:57 +1300

On 30/09/2013 18:35, Christian Huitema wrote:
...
> pretty few solutions. VPN, of course, but that requires configuration. Could

Jon Crowcroft suggested a nice idea a few years ago, although for a different reason:
sourceless network architecture (yes, a pun on SNA).

Send packets with no source address, and you make the metadata much less useful.
(Of course, if the packet is to get a reply, the source address needs to be
encrypted in the payload.)

As a retro-fit, this is a bit tricky - you'd probably have to set a dummy source
address, and that would have to be one that would not get filtered.

www.cl.cam.ac.uk/~jac22/talks/sna.ppt

   Brian

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 30 Sep 2013 14:24:37 -0700

> www.cl.cam.ac.uk/~jac22/talks/sna.ppt

There may be a halfway measure that is simpler to implement than just
zeroing the IP address. Something along the lines of the IPv6 "privacy"
addresses. If the source address that I use changes often, then the
correlation of traffic over time becomes more difficult.

Of course, the IPv6 privacy addresses only randomizes the lower 64 bits of
the address, leaving the top 64 as a perfectly stable reference for
correlation. But if the ISP cooperates, maybe we can get the top 64 bits to
also change often.

-- Christian Huitema