Avoiding Comcast BitTorrent blocking

Tonight I attended and spoke at the iSec Forum. My topic was recent flaws in TLS/SSL that were fixed in version 1.1. I’ll continue posting details about them here.

There was a good talk by Seth Schoen of the EFF on detecting RST-spoofing attacks by ISPs. He built a tool called pcapdiff that lets you compare client and server-side packet captures to see if someone is dropping your packets or spoofing new ones. This is what they used to catch Comcast blocking BitTorrent connections, among other things.

The approach Comcast apparently uses is to send TCP RST packets to both endpoints whenever the Comcast user’s BitTorrent client offers to seed a complete file. It doesn’t interfere with downloads, presumably because that would lose them a lot of customers. However, by preventing uploads once the download is completed, it prevents users from increasing their share ratio or offering new files for sharing.

I mentioned a simple countermeasure BitTorrent developers might use. Instead of announcing a complete seed, every client would announce a complete file except for a single chunk chosen at random. The random chunk index would be changed at a regular interval. That way, clients requesting a chunk would get it nearly all the time but the seed would never get blocked because it wasn’t complete. This behavior (hack?) could be disabled by default.

This is yet another example of the vantage point problem. Few system designers seem to understand its far-reaching implications. For background, see Ptacek and Newsham or Blaze. The latter summarizes it this way:

“There is unfortunately little room to make conventional loop extender interception systems more robust against these countermeasures within their design constraints; the vulnerabilities arise from inherent properties of their architecture and design.”

[Epilogue:  Azureus developers indicated to me that they have already implemented this option as “lazy bitfield“.  Additionally, they have a weak encryption option for peer chunk transfers.  However, neither of these have an effect on Comcast, who appear to be using Sandvine to implement this blocking.  Instead, they seem to be monitoring connections to the tracker and correlating them with bandwidth consumed by uploading.]