Bram Cohen (bramcohen) wrote,

Obfuscating BitTorrent

People ask about making an 'obfuscated' version of BitTorrent often enough that it ought to be a FAQ. The reason given is that some ISPs are doing traffic shaping on BitTorrent protocol, and people wish to get around that.

There are several whole categories of reasons for not doing it. First, there's hardly any benefit. Most ISPs don't do such shaping, and attempts at obfuscation won't work for long - the ISP traffic shaping tools are already quite sophisticated, and a wire protocol which transfers a lot of data bidirectionally and consistently looks like line noise with no header is only marginally more difficult to identify then one which uses fixed ports. Obfuscating the protocol doesn't even claim to make it difficult to find out who's downloading a particular file.

Second, if done poorly it has the potential to create an outright incompatibility between obfuscating clients and non-obfuscating clients. This would cause a huge amount of performance problems and general pain, made even more ludicrous by the lack of benefit it brings in the first place. There is in fact a proposal being worked on by some people for an obfuscating protocol which would have exactly this problem. Fortunately it's quite simple to avoid this problem - simply add an extension to the tracker protocol so that a client tells the tracker that it supports obfuscation, and when a tracker gets such a request it returns, in addition to the usual list of peers, a list of peers which support obfuscation. It's very easy for trackers to support such an extension, and it has the benefit of allowing trackers to keep peers from using obfuscation, in case they're interested in making sure the ISP can cache data or just don't want it to be used for some other reason. In general, the tracker should be in control.

That was the main reason I'm writing about this - I rather suspect that some developer has gotten rate limited by his ISP, and is more interested in trying to hack around his ISP's limitations than in the performance of the internet as a whole. Hopefully no such idiocy will take place. Backwards-compatible obfuscation (as opposed to incompatible obfuscation) is still a dubious idea, but at least it isn't a harmful idea.

Back to reasons for not doing obfuscation.

Third, any cacheing which the ISP may do (and yes some ISPs do cache BitTorrent protocol reasonably transparently, much to the benefit of their users) is completely obliterated by obfuscation.

Fourth, when it comes to dealing with ISPs, obfuscation is some combination of hostile, unprofessional, and harmful. Software projects which value quality over featuritis generally steer clear of such things, especially when their potential effectiveness level is the equivalent of spitting in one's face than actual utility.

Oh, and by the way, the amount of CPU necessary to do a diffie-hellman key exchange is enough to be annoying, and if you're making a connection via a trusted intermediary, like, say, a tracker, or already have a reasonably secret piece of shared information like, say, an infohash, there's no need to use a diffie-hellman key exchange to establish a shared secret. Imagining that crypto will stop being done by dilettantes is clearly a pipe dream though.
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded  

  • 55 comments