BitTorrent Devs Introduce Comcast-Proof Encryption

Dean Garfield writes "An article at TorrentFreak notes that several BitTorrent developers have proposed a new protocol extension with the ability to bypass the BitTorrent interfering techniques used by Comcast and other ISPs. 'This new form of encryption will be implemented in BitTorrent clients including uTorrent, so Comcast subscribers are free to share again. The goal of this new type of encryption (or obfuscation) is to prevent ISPs 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, according to the proposal.'"

Traffic Analysis

[gaika]

Most blocking systems use traffic analysis to block encrypted protocols, even the ones pretending to be something else. There's no way you can confuse p2p sharing with normal browsing if you look at the pattern of data flows.

Comcast makes $$$$$ disrupting seeds

[colinmcnamara]

Comcast is trying to spin their actions as promoting fair use of the their networks. The truth is that ISP's profit from having data dumped INTO their network and have to pay hard cash for data LEAVING their network. By injecting RST's into the peers seeding traffic, they promote an asymmetric data flow that brings more data (and therefore money) into their network, while minimizing the money they have to pay other ISP's for data going out. This proposal provides protection against the throttling of their upstream Bittorrent traffic only if the ISP is not aware of the info_hash of the torrent. Once this data is known it is possible to apply common data tagging and congestion control techniques to squelch this traffic. All the service provider (or application developers like SandVine) has to do is monitor the common torrent sites, and dynamically update this hashes into the network filters. This is sure to deny a majority of the torrent traffic out there (movies, linux distro's, etc). Colin McNamara CCIE #18233

Re:I wonder...

[budgenator]

there is also a UDP Tracker Protocol for BitTorrent [bittorrent.org], UDP doesn't even hear the RST packet. Comcast will have to figure out a way to turn off something that doesn't have an off switch.

Re:Traffic Analysis

[gaika]

Nobody is going to block all encrypted protocols, that's stupid. They identify the application that is using encryption by looking at the shape of the traffic flows. p2p apps open tons of connections, exchange about equal amount of data both ways, and have a distinct negotiation phase.

FTP.

[Organic Brain Damage]

I agree that normal browsing and P2P are going to look obviously different so hiding P2P within HTTP is not going to be too difficult to detect. However, P2P could look a lot like an FTP download. How's traffic analysis going to be able to tell the difference between a P2P movie download that looks like FTP from real and legit FTP?

Re:Traffic Analysis

[Anonymous Coward]

Actually, IPSec will prevent the ISP from being able to reset the flow. If a packet comes in that is not signed/encrypted (depending on the mode) with the credentials of the other end-point, it is discarded as an attack. It's a pain to set up IPSec security associations in many conditions, but IKEv2 has made it somewhat better.

The fact that you are buying service from the attacker doesn't make them not an attacker. The counter measures developed to fight attackers may have limits, but they are there and are useful in this context.

Re:I wonder...

[Mr2001]

Nope. It's the TCP connection between two peers that Comcast is attacking, not the connection between the peer and the tracker. Using UDP for the latter doesn't solve anything.

Won't work: They clamp on traffic per flow

[ZWithaPGGB]

They don't care about any protocol analysis. Any sufficiently long-lived, high volume, traffic flow between two IP addresses gets hit. I've had IPSEC VPN connections behave strangely and opened tickets, where the techs have admitted I had "accidentally" been flagged (IE, the IPSEC endpoints weren't on the whitelist, even though I have business class service).

The only way around this is to open multiple connections to different addresses, transfer small amounts per connection, and then shut it down, opening the next connection to a different endpoint. It requires a total reengineering of P2P, although the BitTorrent mechanism is closest to what would work.

Re:So uTorrent supports it, big whoop.

[Anonymous Coward]

There's been not a shred of proof that uTorrent "phones home," just lots of FUD. Plus, 1.6.1 was the release right after the buyout, so you really want 1.6.0 if you're going to be paranoid.

Re:Traffic Analysis

[Runefox]

AFAIK, Rogers in Canada is actually doing that. I'm a subscriber... Encrypted traffic causes slowdown everywhere on the net, including the torrents. If I do a torrent/unencrypted, it gets caught by the torrent filter, and my connection slows down again. Some tweaking makes it a little better, but it's difficult to deal with such a massive blow to my net speed (cut down to roughly 1/8th of its normal speed).

Re:Traffic Analysis

[mattpalmer1086]

That may be true in some cases, but in this case, they are not defending against traffic analysis, which requires the ISP to maintain state about lots of data flows and analyse it in near-real time. If you look at what the BitTorrent devs are doing, they are obfuscating the peer list in the protocol, to prevent packet inspection from identifying the connection as BitTorrent. Interestingly, they are also intentionally using weak crypto (for performance reasons) - the goal being simply to raise the detection bar, not to create a cryptographically secure protocol.

Re:Won't work: They clamp on traffic per flow

[Anonymous Coward]

IIRC once they've got an connection open and data transferring, most p2p clients try to stay open as long as possible on that connection, only dumping it if it gets waaaay too slow, or starts actually sending bad data, I think BT tries to do this intelligently not dropping even a very slow connection if there aren't other sources for the chunk about. Most of this is configurable in more advanced clients like azureus.

Intentionally shutting a connection down after each chunk, or smaller would require a change, not major though, but it would slow things down somewhat.

Re:Do arms races ever work?

[Jesus_666]

The eD2k network is still going strong. It's dog slow, granted, but then again it's always been dog slow.

Re:Do arms races ever work?

[mrchaotica]

Obviously, you didn't understand what I said: nothing you do on your end would matter, because the computer on the other end of the connection -- the one you're downloading from or uploading to -- will still receive the fake RST packet that Comcast sends them in your name. In other words, even non-Comcast-users would have to cooperate in order for it to work, and that's not likely to happen (because RST packets are, otherwise, a good thing).