Traffic blocking evasion and counter-evasion

| Comments (8) | COMSEC
When faced with a traffic blocking (or, as Comcast calls it, delaying) scheme like Comcast is using for BitTorrent, it's natural to ask how to evade the blocking. At a high level, there are two possible strategies:
  • Make your traffic resilient to blocking.
  • Hide your traffic so that it's not blocked by the ISP.

Resilient traffic
The blocking strategy Comcast is using is to forge TCP RST packets to kill the connection. The advantage of this strategy is that it's cheap; you don't need to touch any of the routers at all. Whatever packet inspection box you're using just sources a single packet to each sender, and the ordinary TCP mechanisms shut down the connection. By contrast, if you actually wanted to stop the packets from flowing the traffic you'd need to insert transient filters into some router, which isn't necessarily that convenient, especially if we're talking about a high-speed core router.

The good news from the perspective of the communicating parties is that this leaves open a window to evade the blocking. Richard Clayton observes in the context of the Great Firewall of China that if the peer implementations simply ignore TCP RSTs then they can't be blocked via this mechanism. Unfortunately, this interferes with TCP's normal operation, since RSTs do something useful. Worse yet, there are lots of other ways to interfere with a TCP connection. For instance, the attacker could forge FIN packets, simulating a normal close. Alternately, he could send fake data segments, breaking the protocol parsing at the next level up. The bottom line here is that TCP was not designed to be DoS-resistant, especially from an on-path attacker. That's not straightforward to fix, especially by this kind of crude modification to the TCP stack.

That doesn't mean that it's not possible to make the traffic resilient to blocking. The standard approach here is to use cryptographic message integrity/data origin authentication to prevent the attacker (Comcast) from inserting their own traffic into the connection. Unfortunately, this can't be done at the appplication layer above TCP (e.g., SSL/TLS)—the attacker is attacking the TCP layer and security protocols like SSL/TLS depend on correct functioning of the lower layer protocol to function correctly. In fact, SSL/TLS makes the problem worse, since any interference with the ciphertext causes integrity failures and connection failure. (This is the same reason why SSL/TLS can't be used to fix the BGP TCP connection reset issue.)

In order to be resistant to this kind of injection, you need to have message integrity at a layer below TCP. The standard solution here is to use IPsec, but you could also use a datagram transport protocol layered over DTLS. The important thing is that the traffic has to be authenticated below the connection management state machine.

Of course, all of these schemes can be blocked if you're just willing to inject filters into the router. The good news from the attacker's perspective is that these connections are long-lived and so you don't have to inject the filters that quickly. You also don't need to get every packet—TCP uses packet loss as a congestion signal and backs off, so if you can achieve an even modest packet loss rate, you can have a dramatic impact on the performance of the connection.

Hiding Traffic
The other major strategy is to stop whatever deep packet inspection (DPI) engine the ISP is using to detect filesharing traffic. The idea here is that the ISP only wants to block some of your traffic, since they want you to be able to use your Internet connection for other applications. So, you just need to stop selective blocking.

The natural way to do this is to use encryption. Even an encryption protocol like SSL/TLS that is above TCP does a reasonable job here, since it hides the application traffic. Interestingly, BitTorrent encryption doesn't seem to help here. I don't really know any details of BitTorrent's encryption, but presumably the issue is that there are unencrypted protocol elements that are specific to BitTorrent and so the DPI box can still do some traffic analysis.

Even with a generic protocol like TLS, the attacker can still do a fair amount of traffic analysis based on timing, packet sizes, etc. You also get the TCP port. BitTorrent doesn't use a single fixed port for data connections, so the attacker can't just block that port. However, the port range is somewhat predictable and doesn't overlap with ports for other popular protocols, so if you see a lot of data flowing on one of the potential BitTorrent ports, it's a good guess that it's BitTorrent. Note that if you use IPsec, then you can hide the ports from the attacker, but the packet size, timing information, etc., is still available.

The counter-countermeasure to this kind of traffic analysis is to send deliberate "cover traffic". When you want to send real traffic you just substitute it for some of the cover traffic. Of course, to do this well you need to chew up a lot of bandwidth on the cover traffic, which is unfriendly and hard on the rest of your performance.

The bottom line here is that an attacker who controls your Internet connection can always guarantee that you can't use it. The best you can do is make it hard for the attacker from selectively blocking some of your traffic and leave the rest of it alone.


I think it's naive to assume that Comcast is using DPI or even single-flow traffic analysis. See, in particular, "Transport Layer Identification of P2P Traffic", by Karagiannis, Broido, Faloutsos, and claffy, in Proc. IMC 2004.

The appliance they're rumored to be using, Sandvine, explicitly claims to do DPI.

Any idea what blocking BitTorrent does to Comcast's "common carrier" status with respect to liability for libelous traffic, DDoS, etc.?


I believe the US Supreme Court established, in FCC v. Brand X, that cable carriers are not "common carriers" in the way that term is used in regulatory law.

There are shielding provisions in DMCA and CDA that provide protections to data carriers from most liability stemming from their users' actions, but I don't recall them being predicated on the carriers' blocking or non-blocking of other kinds of traffic.

Might there be 3rd option: jamming the DPI engine? As you know, there are certain types of traffic that put more strain on DPI. Perhaps the software could emit enough of this traffic to degrade DPI effectiveness.

Perhaps this is not actually a separate option but a potentiator for the hiding option.

OMG! Packet Assassins!

I prefer the term Sith Packets.

Actually... I really would not worry about throwing aways RSTs -- they don't do very much useful at all these days. Your firewall throws away unexpected packets, so you never get the chance to send RSTs in response. If the connection is known about then just sending nothing will cause it to close soon enough; all the RSTs do is save a few resources, and modern machines are not short of RAM...

... you're right though to worry about FINs being sent instead, but forging them to look absolutely right (getting the TTL correct for example) isn't entirely simple. Just looking for incorrect TTLs will get you a long way!

Leave a comment