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.'"

Comments

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.

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.

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.

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, 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: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.