Why Comcast is Spinning Wheels

In what will be an opening salvo in the BitTorrent war with Comcast the Geeks are preparing their next offensive. That’s right they are preparing to set up routines that will mask the traffic markers for BitTorrent. —

Contents

* Announce Parameter
* Announce Response
* Peer List Obfuscation
* Optimizations
* Backwards Compatibility
* Rationale
* References
* Example Python Code

This extends the tracker protocol to support simple obfuscation of the peers it returns, using the infohash as a shared secret between the peer and the tracker. The obfuscation does not provide any security against eavesdroppers that know the infohash of the torrent. The goal is to prevent internet service providers and other network administrators from blocking or disrupting bittorrent traffic connections that span between the receiver of a tracker response and any peer IP-port appearing in that tracker response.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119 [5].
Announce Parameter

When using this extension, instead of passing the info_hash parameter to the tracker, a sha_ih is passed.

The value of sha_ih MUST be the info-hash of the torrent, with a second SHA-1 applied to it.

For example if a torrent has infohash with hex representation aaf4c61ddcc5e8a2dabedef3b482cd9aea9434d then its sha_ih is sha1(infohash)=’6b4f89a54e2d27ecd7e8da5b4ab8fd9d1d8b119′.

The value MUST be url encoded, just like the info_hash. Thus the sha_ih above when url encoded becomes kO%89%A5N-%27%EC%D7%E8%DA%05%B4%AB%8F%D9%D1%D8%B1%19.

This extension does not change the semantics of any parameter passed in the peer’s announce.
Announce Response

If the tracker supports this extension, the response should be exactly the same as if the info_hash had been passed, except that any field that contains peer information (such as peers, peers6 or any other field defined by another extension) MUST be obfuscated as described in the next section.

There are additional parameters the tracker may OPTIONALLY return. These are discussed in the optimizations section.
Peer List Obfuscation

We distinguish between the tracker peer list and the returned peer list. The tracker peer list contains the ip-port pairs of all known peers in a given torrent, i.e., those peers that have reported to the tracker that they are transferring the file with a given infohash. The tracker may store this peer list however it wishes. The returned peer list contains a packed array of ip-port pairs conforming to the BitTorrent protocol specification. If the swarm is sufficiently large then the returned ip-port pairs constitute a subset of the ip-port pairs in the tracker peer list.

The returned peer list is encrypted using RC4-drop768 encryption using the infohash as a shared secret and optionally employing an initialization vector.

So what’s mean for Comcast? Trouble. So far they have spent a good chunk of money on ‘traffic shaping’ hardware that will maybe worthless iron or will have to be retooled. Either way they wasted money.

But that’s just the beginning. If 10 years of internet security has taught us anything it is that the ‘attacker’ has the advantage. The defender can only respond to the latest attack and adjust. That will be the trend here as well. But there will be a difference. I think the Bittorrent guys are smarter than the average bear. Probably by round three they will have developed port level round robin techniques that will make it entirely impossible to track as the transmission hops around the port table on a unprescribed pattern. Kinda of like OFDM for BitTorrent. At that point what does Comcast do, other than punt?

Wouldn’t it be better to spend the money and offer a premium data channel service for nerds? Oh, I forgot, from the nerd to the head end its a shared pipe. Poor Comcast, whats an ISP to do?

Linky.