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.
Summary
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.