BitTorrent has added a new method for encrypting peer lists. This is an attempt to avoid ISPs (such as Comcast) blocking connections that seem to be P2P traffic, as I previously wrote. This extension’s advantages and limitations are a good example for illustrating the fundamental leverage both sides have in this battle.
The actual extension is pretty straightforward. Trackers manage files by their SHA-1 (aka infohash). The extension specifies that a tracker RC4-encrypt the peer list with a key of SHA-1(infohash). Thus, a peer must know the infohash of the file they are requesting to decrypt the peer list. Obviously, they have the infohash since they had to know it to look up the file in the first place.
There are a couple weaknesses in this design. If an ISP can read the infohash from the peer’s tracker connection, then they can also decrypt the peer list. This is mitigated by some trackers supporting SSL connections. Also, the specification allows for reuse of the RC4 keystream, a definite no-no.
Encryption is only a small skirmish in this battle. Eventually, all traffic will be encrypted and probably encapsulated in SSL-like headers to avoid signature detection. That will leave ISPs with traffic analysis as their only tool. Since it appears that at least Comcast is already doing this and not relying on data in the stream, it’s unclear how effective this additional layer of obfuscation will be.
The BitTorrent developers have the advantage in that they control all endpoints (peers and trackers). Their software can take any measures it wants to obfuscate its data signatures (i.e., encryption) and traffic characteristics (i.e., timing or message sizes). However, the biggest disadvantage is that they don’t control the behavior of non-BitTorrent hosts.
The ISPs have an advantage in that they see all the traffic between the hosts they care about and the Internet. They can forge packets or even add filters to block particular IPs. They know the mapping between IP or MAC address and subscriber account. However, they can’t be sure what software is running on an endpoint and could lose subscribers if their response is too drastic or the wrong application is affected.
Even though traditional wisdom says BitTorrent has the advantage, I think the ISPs have the technical edge in this battle. Since the BitTorrent developers can’t control hosts that don’t run their software, they will be forced to conform to the traffic profile of web browsing. Because this is asymmetrical (uplink is only used for small ACKs), the performance advantages of BitTorrent would be eliminated.
However, it’s likely political/judicial moves will have a longer term impact on which side wins. I think this would be a good thing. Since there are only two broadband circuit providers in the US (telco or cable), competition won’t eliminate a progression of more onerous requirements for endpoints. Without intervention, I could see a slow creep towards requiring virus scanning of endpoints or prohibitions on specific applications. I already have to lie and claim to be running Windows to get tech support to run a line test when my DSL goes down (“oh yeah, it rebooted fine but the line is still down”).
Assuming a bad law doesn’t get added, I think regulation of ISPs would be a good thing to prevent further interference with our traffic. I refuse to use the Internet as a TV.
rdist 
How about a brute force mitigation approach, in the style of FreeBSD’s password file? Run peers through a few hundred / thousand iterations of AES or other expensive algo with a published key and copious salt. As long as you only do a few torrents at once, you’d scarcely notice the overhead. Anyone seeking to do wide monitoring of large numbers of torrents, on the other hand, would have a larger penalty to pay. Ultimately not impossible to surmount and probably tractable to scaling hardware, but it would increase costs.
Well, if your goal is encrypting the peer list, it’s probably sufficient to use the hash of the infohash as the key. With an SSL-encrypted tracker, no one can see the infohash.
However, you’re right that there is a dictionary attack of trying to guess the file someone might be requesting from a list of all popular files and thus get its key. It would be best to just send the key directly but it seems like they’re trying to avoid that for some reason. Your suggestion to add a salt would work, although they’re trying to limit the client overhead, even though it’s not as limited as server overhead.
Still, at some point all the tracker and peer messages will be sufficiently encrypted to avoid string matching. Then the outcome will depend on traffic analysis.
“Even though traditional wisdom says BitTorrent has the advantage, I think the ISPs have the technical edge in this battle. Since the BitTorrent developers can’t control hosts that don’t run their software, they will be forced to conform to the traffic profile of web browsing. Because this is asymmetrical (uplink is only used for small ACKs), the performance advantages of BitTorrent would be eliminated.”
I think there’s an assumption here that most “legit” traffic will have a web-browsing-like traffic profile. Is this a valid assumption? I’m asking because I can think of a number of increasingly-popular applications (MMORPG’s, uploading photo’s to online albums, VoIP stuff a la Skype) that have more uplink activity than just small ACK’s.
Benny, good examples. However, these do differ in that BitTorrent exchanges a lot of data with multiple peers. Games, photo albums, VOIP, and VPNs are all single client/server. And even if ISPs weren’t able to distinguish such applications from BT, they could still charge more for such “premium” Internet access.
This isn’t a hypothetical situation since evidence points to Comcast already reseting connections based on network usage profile. However, the false positives do indicate the profile isn’t very tuned yet.
“However, these do differ in that BitTorrent exchanges a lot of data with multiple peers.”
Duh @ self. Can’t believe I overlooked the “multiple peers” part of BT’s behavior. You’re right, of course, this does stick out quite a bit.
So, just for fun, if ISP’s are using a “simultaneous upload/download connections to multiple peers” profile to start zeroing in on BT-like apps, how would you beat it? Perhaps one could set up multiple “hubs” for users to upload to/download from, which would get us back to the single client/server traffic profile. Give the hubs a web interface and sell ad space on the interface to offset operating costs.
ISPs do “”peer to peer’, two years ago, it was very funny to see newspaper titles like, the danger behind peer-to-peer howto stop it ecetera, I was involved against this http://en.wikipedia.org/wiki/DADVSI because as you show “this is without end” and the problem is rejected (on) the end-user, the real problem is still the same: why bittorrent exists? but nobody wants to start thinking about this, asking the right questions regarding Internet and may be we could find the good answers.
Cheers!
Another way to say it is that P2P takes advantage of a unique inefficiency in the pricing of asymmetric broadband connections. The downstream bandwidth is the most efficiently used while the upstream is overallocated for most apps. However, if they cut the upstream too much, sending email attachments or uploading pictures would be too slow.
I don’t know how new RC4 MSE/PE actually are among bittorrent clients. Encryption similar to this has been around for over 2 years. [1]
And speaking as a Comcast customer, I can demonstrate that MSE works to defeat their QoS/DoS efforts specific to BitTorrent traffic. Trying to get the latest CentOS DVD ISO using rtorrent with “encryption=allow_incoming,prefer_plaintext” in my .rtorrent.rc will cause the download to be choked at 1Kbps, eventually timing out peers and never completing. By changing to “encryption=require,enable_retry” that same torrent file will reach download speeds upwards of 500Kbps per peer, and upload speeds of about 40-50Kbps per peer. That’s in keeping with what I see from single SSH file transfers.
[1] http://en.wikipedia.org/wiki/BitTorrent_protocol_encryption#MSE.2FPE_in_BitTorrent_client_versions
PaulM, MSE/PE are for encrypting data transfers between peers. This new addition was for encrypting the list of peers that is downloaded from the tracker (central server). It’s kind of silly how encryption keeps getting added piecemeal instead of being designed in from the beginning. It can always be turned off if it’s a performance problem for a particular client or tracker.
I’m surprised that just MSE/PE works for you. I was advised by the Azureus developers on irc that it is no longer sufficient for Comcast. The wiki you point to also says this, giving the justification for peer list encryption as a necessary measure to circumvent Sandvine.
http://en.wikipedia.org/wiki/BitTorrent_protocol_encryption#Remains_vulnerable_to_disrupted_peer_traffic
Really the best way to combat this development is to go around it the other way: Develop “the new WoW” except that it’s p2p based and requires symmetrical bandwidth. I’ve already theorized up this type of game from technical standpoint so that the cheating that might plague p2p game would not become an issue. Essentially a 3rd party peer would act as the ‘server’ for resolution of fight between two players (peer 1&2) and the ‘server peer’ would be decided on latency to peer 1&2 etc on the fly.
Now if the encrypted game traffic gets dropped because it looks like torrent traffic then whoops ISP will get sued and go out of business due to word of mouth if they don’t act.
ac, good idea. I was hoping that there would be more opportunistic encryption for legacy traffic, perhaps via growing VPN use, and thus all traffic would eventually be mixed and hard to differentiate. Your p2p game protocol could actually be unencrypted but transparently negotiate encryption for all TCP connections, including ones not part of the game itself. Having the game running would be all that was needed to start hiding a lot of unrelated traffic.
There is one good point in all this. Despite protests by security people, naive ideas like IP-based authentication continue to be reintroduced since active MitM attacks don’t commonly affect ordinary users. Now we all know you have to assume ever-present MitM and your ISP is just the first adopter.