Direct Connect: Just These Guys, Ya Know?

Defeating traffic shaping with encryption

Many ISPs now throttle P2P connections. The precise mechanisms vary, but rather than concentrate on an individual step in this iterative measure/countermeasure process, this post will attempt to skip several intermediate steps and assume ISPs interfere more than, in general, they currently do. Thus, the threat models of interest will be those ISPs which already implement deep packet inspection to examine not just the structure but the protocol-specific content of users’ traffic. The implementation of L7-filter demonstrates such products’ minimal capabilities; some traffic shapers can do much more.

Therefore, to evade even the level of traffic shaping l7-filter can provide, a P2P protocol must at least avoid regex-detectable patterns. Both NMDC and ADC, as widely implemented, currently fail this metric rather dramatically, leaving them trivially throttled. Importantly, even the initial connection setup must avoid leaking any fixed patterns unique to P2P whilst still allowing the two DC clients to communicate with each other. Satisfying this constraint requires that any extant plaintext be generic enough not to allow traffic shapers to pin it with much probability on DC. Sufficient opportunity exists within an operational DC network to render this much practical.

More sophisticated traffic detection can perform traffic analysis on the timing, number, frequency, and bandwidth usage pattern of connections which remains impervious even to countermeasures sufficient to defeat traffic shaping on the order of l7-filter. Numerous countermeasures, in turn, exist to respond to such analysis, though many of them are of limited utility in a P2P network that aims for bandwidth-efficiency. To the extent a primary goal of DC is to transfer data over a network from one computer to another, indeed, any countermeasure which renders that end more difficult becomes profitable only when the network environment becomes so hostile that protocols with less overhead can’t operate. Since that’s not yet largely the case, prematurely modifying DC to defeat traffic analysis risks instead backfiring and rendering it merely maladaptive.

Alternatively, an ISP might not even bother with such measures but instead effectively whitelist rather than blacklist traffic. Such a provider wouldn’t need to take any elaborate measures to preclude P2P traffic; instead, they would explicitly allow a limited number of approved and identifiable protocols and simply not include, say, DC in that set. Rogers of Canada, for example, has constructed such a system by throttling all encrypted transfers. Surviving under such a system would be difficult at best, but perhaps possible; it would essentially require network-borne steganography to simultaneously encrypt yet hide the very presence of encrypted data. Steganographic systems tend require enough overhead to fall prey to the probable maladaptivity already discussed and as such don’t fit well in the current merely moderately hostile network environment. Further, since as Michael Geist observes, such systems run false positive risks high such that they seem unlikely to long survive on any open or neutral network, they seem to serve more as reductios than sustainable systems.

The threat model this post addresses, then, is that of a network which performs deep packet inspection but allows unrecognized traffic through basically unmolested. This post concentrates on protocol obfuscation and encryption as counters to threats present under this model.

The DC++ mod BCDC++ briefly implemented minimal obfuscation in the form of an option to send ‘garbage commands’. However, its flexibility whilst retaining compatibility unmodified remote NMDC clients was limited. Simply prepending some structurally plausible yet syntactically incorrect NMDC commands to a client-client connection and leaving the rest of the connection unmodified, it could potentially fool simple-minded filtering machines, but even l7-filter could trivially detect it. This outcome was inevitable; NMDC structurally as commonly implemented is incapable of avoiding traffic shaping, though a nominally NMDC-based client willing to break compatibility can solve it. Not only does this protocol not support protocol encryption, but its server-party-speaks-first system strongly hinders attempts to negotiate such a system afterwards. NMDC, then, provides a poor base for avoiding traffic shaping.

ADC, by contrast, not only contains a nascent, standardized secure extension exist in the form of ADCS (section 6.5 of the draft specification) but the connecting client speaks first in a connection. Effort to render DC resistant to traffic shaping is thus better directed towards ADC-based clients than NMDC-based clients. Again, the options of obfuscation and more substantial encryption emerge. Whilst these categories blend into each other, mere obfuscation has the weaknesses of providing barely more protection against traffic shaping than plaintext. In effect, it encourages man-in-the-middle attacks by network operators since, lacking a notion of actual privacy against outside interference, an eavesdropper need merely keep enough state to decode an ongoing DC connection. Although this does appear beyond the ken of l7-filter, stateful inspection, which can perform such attacks, is technically feasible and likely in use.

Given this potential, defeating traffic shaping should not rely just on obfuscation but rather on full-fledged encryption. Man-in-the-middle attacks can affect encryption connections as well, but so long as both sides can communicate out of channel, they can be avoided. For example, the necessary setup for a client-client connection’s encryption to avoid MITM interception could be performed in the client-hub connection from which it spawned.

Having shown at least the otherwise most viable alternatives to implementing true encryption in ADC would fail, at least two more disclaimers remain necessary: first, that because this cryptosystem can be defeated by simply logging on to a hub as an ordinary user, one should be clear that it protects not against RIAA/MPAA-style attacks of searches for files and then reporting the users who return search results, but merely meddlesome network operators; that would be some computational overhead, but for all but 100Mbit+ users or those with ancient computers, it remains relatively unobtrusive CPU-wise; and that one should not under any circumstances use homegrown cryptosystems, because they’re almost certainly insecure, lacking extensive peer review. Using openly documented, widely employed, and extensively analyzed protocol such as TLS or SSH2 not only ensures the similar plaintext as non-P2P protocols towards which ISPs might not be so hostile but also avoids most of the aforementioned pitfalls of cryptosystem implementations, and therefore should be strongly preferred. To further avoid side channel attacks, one should prefer not just such a protocol but a well-developed implementation of that protocol.

Though neither NMDC-based clients nor those merely relying on obfuscation would likely work for long, then, an ADC-based client employing encryption should allow a DC user to evade many mechanisms of traffic shaping.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”