The infamous “Ernesto” announces new countermeasures to grab even more of Comcast’s residential network:
BitTorrent throttling is not a new phenomenon, ISPs have been doing it for years. When the first ISPs started to throttle BitTorrent traffic most BitTorrent clients introduced a countermeasure, namely, protocol header encryption. This was the beginning of an ongoing cat and mouse game between ISPs and BitTorrent client developers, which is about to enter new level.
Unfortunately, protocol header encryption doesn’t help against more aggressive forms of BitTorrent interference, like the Sandvine application used by Comcast. A new extension to the BitTorrent protocol is needed to stay ahead of the ISPs, and that is exactly what is happening right now.
As much fun as this sort of thing is, it’s not really going to work. Bram Cohen, the inventor of BitTorrent explains why:
…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.
This won’t stop the pirates, of course, but it should cause them to think about what they’re doing. Not that it will.
Note: A reader points out that Cohen’s remarks referred to a previous obfuscation scheme that clearly didn’t work, and suggests the current one will work for some magic reason. I doubt it, because all that Comcast has to do is look for a large number of inbound connections when none are going out. No form of obfuscation will hide that scenario because the traffic stats alone are enough to expose it. I never cease to be amazed by how naive these pirates can be.
Bram’s 2006 post addressed peer-to-peer obfuscation, not tracker-peer as in the current proposal. Even when applied to tracker-peer communication none of the Bram’s criticism in that 2006 post apply to the new proposal. For example, there is no Diffie-Hellman (or other) key exchange, it is *not* harmful (to the protocol due to backwards compatibility), etc. In fact, the only potentially valid criticisms that could even remotely apply to the current proposal is that 1. obfuscation is marginally effective 2. it is hostile to the ISP and unprofessional.
(1) does not apply in this case as Bram was talking about the difference in difficulty in identifying obfuscated and non-obfuscated peer-peer communication. The new proposal addresses a RST denial-of-service attack that is made trivial by observing the peer list a client receives from the tracker.
Bram does not elaborate on his reasoning for (2) but it is a value judgment that, needless to say, many people disagree with and would argue that sending resets is the hostile act.
Finally, I would hesitate to point to Bram as a current day opponent to the obfuscation protocol: His company did propose it after all.
That’s a nice clarification, bugmenot, but the proposed scheme is easily beaten, as I explain in a note on the post.
I wasn’t arguing that this would be an effective countermeasure to all forms of traffic analysis and neither do the designers of the proposal: they are very explicit that this only addresses one particular vulnerability that is trivially exploitable by an eavesdropper. I was merely pointing out that Bram’s argument of the relative effectiveness of obfuscation does not apply in this case: it is clear that it is far easier to identify Bittorrent connections using this vulnerability than without it.
Whether obfuscation ‘works’ depends on you measure success. As you point out it is trivial to identify high bandwidth usage. It is not as trivial to identify a particular obfuscated protocol in operation and even less trivial to identify whether a particular TCP session is part of that protocol. So, at best, what can be achieved by obfuscation/encryption is forcing protocol-agnostic traffic management. If an ISP wants to throttle a particular user’s P2P app they will also have to throttle their VPN connection and other unidentifiable connections. So the obfuscated P2P protocol will be treated as well as unidentifiable protocols that received preferential treatment from the ISP.
ISPs have generally shied away from protocol-uniform (per user) traffic management for whatever reason. If this remains the case then obfuscating the protocol has arguably achieved its goal.
It would be best for everyone if ISP traffic management were application-centric as well as user-centric. This is because some applications have more strict time requirements than others, and it’s reasonable to give them higher priority, especially in the case of VoIP where their traffic volume is modest.
BitTorrent obfuscation complicates reasonable application discrimination, so it will become necessary for ISPs to demote all encrypted traffic on high traffic user accounts to lowest priority. The one thing that BitTorrent can’t hide is the volume of traffic it puts on the network.
Yes, this is exactly the point I was driving at. The question for ISPs changes from “Can we throttle Bittorrent without too much consumer backlash?” to “Can we throttle VPN (or SSL email, etc.) on high-volume connections without too much consumer backlash?”. ISPs will have a much harder time justifying the latter than they have the former even in the case where they can correctly identify a P2P user but not the connections in particular. And, for the same reason, if they do decide to decrease QOS for encrypted streams it will be more likely they will do it to a far lesser extent than they have traditionally for P2P. This is the way obfuscation and encryption are forcing the hand of ISPs whether they know it or not.
I don’t think it’s too hard to tell the difference between conventional uses of VPN and BitTorrent swarms, simply counting the connections gets you there. But I would suspect that users who run BitTorrent seeders and VPNs at the same time will have all their traffic demoted. That’s what I would do if I were in charge, at any rate.
There is still the issue of whether P2P traffic will be is demoted as much as it would have been otherwise. But I think the issue is less cut and dried for the ISPs than you make it out to be. First, it becomes very complicated to try to explain to the layman why their VPN traffic is being demoted by the ISP. Trying to explain the relationship between the apparently unrelated VPN and Bittorrent protocols is going to be futile. Worse still will be trying to convince a customer that their VPN is slow because of something that their kid is doing or because some new service they are using happens to use Bittorrent to distribute files (Online video purchases, online gaming patch distribution): “No it was working fine for the past 3 years, what did you (ISP) do?”, “No, my router tells me I have plenty of bandwidth. I read in the newspaper that you are screwing up my VPN”, “I don’t have Bittorrent”, etc.
Second, if Comcast’s RSTs to Bittorrent — a protocol relatively few people even know about — raised the ire of the FCC what do the ISPs think will happen for a work-related protocol like VPN?
I guess we will see how this plays out.
It’s not clear how upset the FCC is about Comcast. They’ve only announced hearings on the subject, which are not going to go well for the Coalition of Clueless Consumer Advocates who’ve made complaints, in my estimation. The lack of empirical data will bite the CCCA in the ass.
But back to your previous point, I think it should be fairly easy to distinguish accounts running VPN from those running obfuscated BT, the trouble will come from those who run both. The ISP will have to screw them over and then explain why.
The better approach for BT is to adopt the P4P recommendations, BTW, but they’re not pirate-friendly.
Aside from the question of traffic shaping measures and countermeasures, the proponents of P2P claim there are legitimate sellers of content that use P2P. I would invite them to name any major seller of video or music (Netflix, Blockbuster, Hollywood, iTunes?) that would ask its customers to use P2P rather than simply download the content from servers controlled by the seller.
Red herring but I’ll bite: Off the top of my head Vuze and Bittorrent Inc (the company) sell Hollywood-authorized content and World-of-Warcraft distributes its patches via Bittorrent. Of course you will decree that these don’t meet whatever standards you have.
But again, it’s irrelevant: A protocol doesn’t need be used by major industries to be justified.