BitTorrent Developers Introduce Comcast Busting Encryption
Written by Ernesto on February 15, 2008Several BitTorrent developers have joined forces to propose 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.
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.
Back in August we were the first to report that Comcast was actively disconnecting BitTorrent seeds. Comcast of course denied our allegations, and ever since there has been a lot of debate about the rights and wrongs of Comcast’s actions. On Wednesday, Comcast explained their BitTorrent interference to the FCC in a 57-page filing. Unfortunately they haven’t stopped lying yet, since they now argue that they only delay BitTorrent traffic, while in fact they disconnect people, making it impossible for them to share files with non-Comcast users.
In short, the Comcast interference works like this: A few seconds after you connect to someone in a BitTorrent swarm, a peer reset message (RST flag) is sent by Comcast and the upload immediately stops. Most vulnerable are users in a relatively small swarm where you only have a couple of peers you can upload the file to.
For the networking savvy people among us, here’s an example of real RST interference (video) on a regular BitTorrent connection. In this case, the reset happens immediately after the bitfields are exchanged. Evil? Yes - but there is hope.
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.
“This extension directly addresses a known attack on the BitTorrent protocol performed by some deployed network hardware. By obscuring the ip-port pairs network hardware can no longer easily identify ip-port pairs that are running BitTorrent by observing peer-to-tracker communications. This deployed hardware under some conditions disrupts BitTorrent connections by injecting forged TCP reset packets. Once a BitTorrent connection has been identified, other attacks could be performed such as severely rate limiting or blocking these connections.”
So, the new tracker peer obfuscation technique is especially designed to be a workaround for throttling devices, such as the Sandvine application that Comcast uses. More details on the proposal can be found at BitTorrent.org, which aims to become a coordination platform for BitTorrent developers.
TorrentFreak talked to Ashwin Navin, president and co-founder of BitTorrent Inc. who has some of his employees working on the new extension. He told us: “There are some ISPs who would like people to believe that “slowing down” BitTorrent or “metering” bandwidth consumption serves the greater good. Consumers should be very weary of this claim.”
“In recent months, consumers enjoyed unprecedented participation in the political process thanks to the ability to upload opinions and feedback in the YouTube presidential debates. Musicians, filmmakers and artists are finding ways to connect with their audiences across the world thanks to MySpace and BitTorrent. Students are engaging with interactive learning tools in their schools. Which bandwidth intensive application will banned or shaped or metered next by these ISPs? The creative spirit of millions has been ignited, and our need to participate, to communicate will not be silenced.”
“The US government should encourage ISPs to innovate and invest in their networks,” Ashwin said. “Permitting them to interfere or interrupt in the communications of consumers, to protect ISP profit margins, would be a tremendous set back for our country and economy, when we are already slipping behind the first world (UK, EU, Japan, Korea, Singapore, etc) in its broadband capacity.”
We wholeheartedly agree with Ashwin on this one, as we’ve said before. The Internet is only a few years old, if the plan is to keep using it in the future, ISPs need to upgrade their networks. So, invest in more Internet gateway capacity, 10Gbps interconnect ports, and peering agreements. BitTorrent users are not the problem, they only signal that the ISPs need to upgrade their capacity, because customers will only get more demanding in the future. The Internet is not only about sending email, and browsing on text based websites anymore.
The new protocol extension is still under development, but the goal is of course, to get it out as soon as possible.
Hang on…
Previously: Village People Hire Web Sheriff for Assault on The Pirate Bay, ABBA on Standby
Next: PRQ Fire Takes Down Several Torrent Sites
113 Responses (Add yours or TrackBack)
Pages: « 1 2 3 [4] 5 » Show All
this is useless. its the TCP connection between the 2 peers that comcast is disrupting, not between tracker and client.
also, they are re-inventing the wheel. if you want to encrypt your announces use SSL. the developers pretty must wasted their time.
[quote comment="291866"]People Listen to Me I busted through Comcast with a modem fix my daughters boyfriend did for me, I seed I seedI seed I Dl and I Dl no interferance-Any TV repair shop can do it also any electronics student can too..[/quote]
um, can you make a complete sentence please? maybe then we will be able to do the same as you.
BTW, looks like comcast blocks torrentfreaks website. I came to read this article from my Comcast account and I get:
[10:21] ~> telnet torrentfreak.com 80
Trying 66.228.120.206…
telnet: connect to address 66.228.120.206: Connection refused
telnet: Unable to connect to remote host
But at the same second, from my SBC Yahoo DSL, I can read just fine. Somebody please confirm? I’m in Chicago area.
i heard comcast is going to move towards charging people per protocol per port.
Something needed to be done. I guess some new security measures are always welcome.
M
any people will benefit. Good work from the developers of this new technology.
____________________
Web Efforts
http://www.webefforts.co.uk
So I’m kinda new to all this, but before this all came out, I never had a problem with throttling. But I did get this notice and was wondering if this new encryption would block them from knowing what I am downloading. As you can see from the email below that I got from Comcast, they knew I was downloading. I really don’t care if it blocks them from slowing the connection, I just want to know if it makes them not able to see what i am getting. Also, is there anything better then Utorrent?
“Notice of Action under the Digital Millennium Copyright Act
Dear Comcast High-Speed Internet Subscriber:
Comcast has received a notification by a copyright owner, or its
authorized agent, reporting an alleged infringement of one or more
copyrighted works made on or over Comcast’s High-Speed Internet
service (the ‘Service’). The copyright owner has identified the
Internet Protocol (’IP’) address associated with your Service account
at the time as the source of the infringing works. The works
identified by the copyright owner in its notification are listed
below. Comcast reminds you that use of the Service (or any part of
the Service) in any manner that constitutes an infringement of any
copyrighted work is a violation of Comcast’s Acceptable Use Policy and
may result in the suspension or termination of your Service account.
If you have any questions regarding this notice, you may direct them
to Comcast in writing by sending a letter or e-mail to:
Comcast Legal Response Center
Comcast Cable Communications, LLC
650 Centerton Road
Moorestown, NJ 08057 U.S.A.
Phone: (856) 317-7272
Fax: (856) 317-7319
E-mail: dmca@comcast.net
For more information regarding Comcast’s copyright infringement
policy, procedures, and contact information, please read our
Acceptable Use Policy by clicking on the Terms of Service link at
http://www.comcast.net.
Sincerely,
Comcast Legal Response Center
Copyright work(s) identified in the notification of claimed infringement:
Title: Crysis
Infringement Source: BitTorrent
Infringement Timestamp: 23 Jan 2008 00:09:37 GMT
Infringement Last Documented: 23 Jan 2008 00:09:37 GMT
Infringer Username:
Infringing Filename: Crysis-Razor1911
Infringing Filesize: 6471561394
Infringer IP Address:
Infringer DNS Name:
Infringing URL: http://tv.tracker.thepiratebay.org:80/announce“
[quote comment="291161"]File sharing increases the load on the networks so users who share files should pay for the bandwidth they use. This is the only way ISPs can finance network capacity increase.[/quote]
that is a such a backwards way of looking at it. I already pay my ISP for a certain amount of Down/Up bandwidth. This whole fiasco shows that they have been overbooking bandwidth, probably because they assumed nobody would use what they paid for. I agree that a “scaled” pricing scheme would be one way out of this mess, but to place the blame on the consumer for actually using what they paid for is quite frankly absurd, and makes me wonder if you work for a big Telecom corporation. It is like Greyhound in the States - they’ll sell as many tickets as they possibly can, without concern for how many seats are on the bus. if the bus is overbooked - as they often are - tough shit for the consumer, first come first serve. Does that mean that people who ride the bus a lot should stop doing so? No, it means that the company needs to sell based on real and not infinite supply. If my ISP sells me a certain amount of bandwidth, they have no right to get all pissy when I actually use it. They should use some of their vast profits (not to mention public funds given to them to do just this!) and upgrade their infrastructure to handle the FACT that more and more people are actually going to use the full extent of their broadband connection nowadays.
[quote comment="291161"]File sharing increases the load on the networks so users who share files should pay for the bandwidth they use. This is the only way ISPs can finance network capacity increase.[/quote]
Boo-hoo for the ISP’s. You’re operating under a mistaken impression. Unlike many places around the globe, almost all ISP services in the US are sold to the public as unlimited service. This means that your “users who share files” ALREADY HAVE PAID for the bandwidth they use.
It is not the fault of the customer for taking them up on the unlimited bandwidth that was promised. It is solely the fault of the ISP’s for not taking into account that when they offered unlimited service that some customers would actually expect and use the unlimited bandwidth they contracted and paid for. Now that the ISP’s have been caught with their pants down because they don’t have the capacity to actually deliver the unlimited bandwidth they sold, they choose to blame their customers rather than investing in their own infrastructure to insure that they can deliver what was promised AND paid for.
So does this mean that this will block them from ISP’s knowing what you are downloading or or just from being able to throttle your downloads?
Friend of mine got a message from Comcast that told him to stop or His service will be terminated and they listed the Torrent he was downloading.
[quote comment="292462"]So does this mean that this will block them from ISP’s knowing what you are downloading or or just from being able to throttle your downloads?
Friend of mine got a message from Comcast that told him to stop or His service will be terminated and they listed the Torrent he was downloading.[/quote]
it won’t block them from knowing anything. this is dumb and the developers are wasting their time.
they are reinventing the wheel, if you want to encrypt your connection between tracker - client user HTTPS/SSL
this won’t help out comcast users at all
[quote comment="291427"]Just part of a normal arms race, except what’ll happen at some point is that you get what you wish for and all the ISPs using this technology stop doing so (saving equipment $). Then they move to metered pricing so that they truly do not care what you use your IP connection for — and in fact want you to use more as it generates more money for them. Then a lot of people using torrents won’t want to anymore, because it’ll cost them a lot more than they’re paying. And once one ISP breaks out of flat-rate pricing, they’ll all rush to it because it’ll be more profitable.[/quote]
That’s my worry
Thank you, thank you, THANK YOU! My ability to seed, and even download, has gone to complete shit on Qwest broadband. It pisses me off to no end that I pay top $ for their most powerful residential connection and they decide what I can and can’t do on my webs. My only alternative is Comcast or dialup in my area, so this update is very much appreciated.
Lots of respect to the dev team. Didn’t see this coming for some reason.
It’s incredible to see all you thieves go “hurray” about this.
I see you are happy as you expect to be able to steal even more.
Freeloaders are greedy, selfish idiots that are of no use to anyone.
Way to go team! Very respectable response.
so how would one go about using SSL for downloads and seeding?
its interesting that in the many responses so far , not one single person has bothered to talk about the torrent apps having a re-engineer to better keep the 80%+ of traffic inside the ISPs network were possible.
it seems a simple thing to add a finer grained swarm localisation that trys to keep as much torrent traffic inside the local LAN,then WAN,then ISP, then country, and so on, so keeping the ISPs happy and the users happy too as it should improve throughput.
if you then want to wrap all this inside a tunnel to clean it all up for encryption end to end you must also consider adding the Multicasting DHT extension to once again free up masses of bandwidth.
its not about fighting the ISPs, its more a case of getting more for less and a Multicasting torrent extension will benefit everyone, along side encrypted end to end tunnels.
id rather the able bodyed coder would spend time adding and extending the existing JAVA multicasting DHT abd tunnel code to make far better use of my limited upload pipe for the betterment of all torrent users ,than fight the ISP and l loose out anyway, while the payed binary usenet gets bigger and yet forgotten.
will someone please make a client add-in for AZ to use an _encrypted_ _multicast_ _tunnel_ to other clients etc and we can all be happy in a very short time.
[quote comment="291496"]To all Comcast Users - Change your ISP and say goodbye to Comcast! This company sucks.[/quote]
Exactly: instead of finding workarounds, why not vote with your pocket book? That’s likely to be more effective than identifying work arounds or contacting your legislator.
[quote comment="293650"]its interesting that in the many responses so far , not one single person has bothered to talk about the torrent apps having a re-engineer to better keep the 80%+ of traffic inside the ISPs network were possible.
it seems a simple thing to add a finer grained swarm localisation that trys to keep as much torrent traffic inside the local LAN,then WAN,then ISP, then country, and so on, so keeping the ISPs happy and the users happy too as it should improve throughput.
if you then want to wrap all this inside a tunnel to clean it all up for encryption end to end you must also consider adding the Multicasting DHT extension to once again free up masses of bandwidth.
its not about fighting the ISPs, its more a case of getting more for less and a Multicasting torrent extension will benefit everyone, along side encrypted end to end tunnels.
id rather the able bodyed coder would spend time adding and extending the existing JAVA multicasting DHT abd tunnel code to make far better use of my limited upload pipe for the betterment of all torrent users ,than fight the ISP and l loose out anyway, while the payed binary usenet gets bigger and yet forgotten.
will someone please make a client add-in for AZ to use an _encrypted_ _multicast_ _tunnel_ to other clients etc and we can all be happy in a very short time.[/quote]
It’s more than just transport between ISPs, it’s also about using up the limited upstream capacity of DOCSIS. 16-QAM is just 10 Mbps, while downstream at 256 QAM is ~38 Mbps. Of course there is usually at least 4:1 ratio of upstream ports to down ports, but it doesn’t take too many P2P clients uploading content to fill it up.
Has anyone considered that if Comcast’s current approach is kiboshed that they could go application-neutral rate limiting once a certain bandwidth cap has been exceeded? That wouldn’t be unlike higher ed, where because the Packeteers of the world can’t pump out application signatures fast enough, and where SSL prevents any identification, they’ve just implemented caps followed by rate-limiting to help manage their bandwidth costs?
MAYBE this is just buzz to get people to switch back or use utorrent, who is now in bed with the bad guys.
Google: utorrent mpaa
pip “Multicast….”
“by Anonymous:
It’s more than just transport between ISPs, it’s also about using up the limited upstream capacity of DOCSIS. 16-QAM is just 10 Mbps, while downstream at 256 QAM is ~38 Mbps.
Of course there is usually at least 4:1 ratio of upstream ports to down ports, but it doesn’t take too many P2P clients uploading content to fill it up.”
I agree, and my main point ,rather than the ease with which you might Encrypt the Tunnel, is its got to be FAR more economical to sent a single torrent/data packet _once_ to say 4 of your peers at a time with Multicasting, than send the same packet 4 seperate times to each unicast peer as now.
a very large saving in MC upload packets with even this basic 4/1 ratio compared to now with unicast.
sure it will take some thought regarding the re-transmission IF a seed didnt get that packet intact,but not that much work.
and every single packet saved is one less to send to the next Multicast peer.
its clear that even a very basic torrent Multicast peering is far better at using the very limited upstream capacity than any unicast peer if you have more than one person in a swarm.
id hope by now that multicasting has a clear advantage over uncast and we should at least consider moving to it.
at the very least, make a basic MC plug-in for AZ and try the Multicasting idea out.
bamboo DHT java code would seem to be a good starting point for any experimental Multicasting plug-in, also the java Mtunnel might get some torrent coders interest for inclusion.
4 references to this post
Pages: « 1 2 3 [4] 5 » Show All
Add your response