Slashdot Mirror
Beating Comcast's Sandvine On Linux With Iptables
HiroDeckard writes "Multiple sites reported a while ago that Comcast was using Sandvine to do TCP packet resets to throttle BitTorrent connections of their users. This practice may be a thing of the past as it's been found a simple rule in the Linux firewall, iptables, can simply just block their reset packets, returning your BitTorrent back to normal speeds and allowing you to once again connect to all your seeds and peer. If blocking the TCP packet resets becomes a common practice, on and off of Linux, it'll be interesting to see the next move in the cat-and-mouse game between customers and service providers, and who controls that bandwidth."
While it is good that it is easy to ignore reset packets that were created by the ISP, the question still remains:
Why should we have to block forged packets made by the ISP? If the MAFIAA suits are banking on IP == identity, and the ISP is forging packets with an IP that doesn't belong to any computer they own, isn't that a fairly serious form of forgery?
And, wow that site went down fast.
If I have nothing to hide, don't search me
As a Comcast customer, I've never had my torrents completely stop, they just go around 300k... I did notice a speed increase when I chose to encrypt the traffic (uTorrent has it under Speed Guide).
Comcast is evil and I want them to DIAF, but my torrents, which are legal, haven't been that impacted.
When I want fast, I use the Comcast sponsored newsgroups through Giganews.
By the way - While onto it - if they are to ratelimit live sports events and do on, they MUST prioritize the version for hearing impaired which have a square with a commentator speaking in sign language in the corner ABOVE the one for the rest. This simply because it is illegal to discriminate against hearing impaired and everyone is able to see the screen even though a part of it might not be of such interest to most of us. Of course - if the hearing impaired could set these option themselves, then we don't need to degrade the performance for those not hearing impaired neither.
'Sandvine also sends RSTs to the other end of the connection. That means it isn't enough for you to be running this iptables rule - all the peers you connect to have to be running it too.'
Isn't that your ISP committing fraud? Altering a private communication with the intent of disrupting it, or the very least it's the 'ISP' impersonating you and also the other party.
They recently bumped up service to a full megabit upload speed, mostly because of Verizon FiOS service (which still isn't available anywhere in MA except the rich white suburbs- Boston's completely "dark", yet surrounded by towns and cities which have it.) However, if you use it past the old limit (384kbit), after a few minutes, latency skyrockets.
It takes anywhere from a minute to several minutes to kick in, but when it does, ping times to google jumped from 20-30ms to over 300ms. Sometimes I found ping times would be *seconds* long, and ssh became almost completely unresponsive. Curiously, none of the packets would actually be dropped- they'd just very, very badly delayed.
Seems very clearly designed to a)look the same as Verizon "on paper", 2)Satisfy people who want to email photos of the kids to grandma and grandpa (I will admit, it's insanely nice to be able to upload at four times the speed, when it works).
Please help metamoderate.
Technical merit? I think not.
They can't block the packets, they sold their users "unlimited" internet. If certain packets are just blocked that's not really unlimited, is it?
They sure didn't tell anyone they were secretly installing Sandvine boxes that nobody had heard of specifically to screw up certain kinds of traffic. They did it in secret. It was subterfuge. A dirty trick. Mischief.
Now that they are found out their story is they are just "managing bandwidth".
But what they are really doing is trying to stop 2% of their customers from using 98% of the bandwidth, bandwidth they have to pay for. Remember, though they are selling "unlimited" internet access at some level *all* bandwidth is measured. Theirs is certainly measured by their upstream provider. There is really no "unlimited" bandwidth.
.
It's a response to a violation of the TCP protocol to begin with, so it's not surprising that it has some negative side effects.
Probably the best thing to do would be to build a filter that registers the presence of the RST packet and waits to see if you get more data from the site that supposedly sent it.
* If the site that the RST packet supposedly came from continues to act like it's got an open session, then you can ignore the RST as a forgery.
* If you have no more non-closure packets after the RST, then you can apply an aggressive timeout and then deliver the RST after 2-3 seconds of silence.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Last time this came up for discussion, some people suggested that RST-injection was computationally easier than packet blocking, because it works on the connection level rather than the packet level.
It still seems to me like you'd have to do quite a bit of DPI to determine which connections are being used for Bittorrent, but maybe you can identify a connection, send a forged RST packet, and then ignore the packets in that connection for a while (saving you load on the DPI box) for a while, maybe just until it closes.
I'm not entirely clear how these Sandvine boxes work, but it seems like it would be easier to identify "okay, this connection is being used for x," "this connection is being used for Y," and then not have to pay more attention to them, than it would be to examine every single packet. That's where you get your cost reduction, I suspect.
Sandvine has a few patents out there that probably describe in greater detail how their QoS tool works (and which I haven't read yet); apparently the QoS RST-forging are part of their "Stateful Policy Management" product.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Although, I've never had this issue and am not a Comcast customer...
I'd assume that the RST coming from Comcast would probably have a different TTL than a legitimate RST.. As a matter of fact, all the RST coming from Comcast would probably have the same TTL.
Anyone looked into this?
I expect we'll see development of protocols more robust than TCP to a MITM attack (this is ultimately a MITM denial of service).
That it is a great idea. Combined with only dropping RST packets for your torrent port you could have it match a specific TTL as well. Try this: iptables -I FORWARD 3 -p tcp --dport 36745 --tcp-flags RST RST -ttl-eq $EVILISPTTL -j DROP