Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

[ Create a new account ]

Beating Comcast's Sandvine On Linux With Iptables

Posted by timothy on Monday June 30, @12:20AM
from the and-then-I'd-be-all-like-pow-and-reconfigure-iptables dept.
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."

Related Stories

[+] Your Rights Online: AT&T Denies Resetting P2P Connections 112 comments
betaville points out comments AT&T filed with the FCC in which they denied throttling traffic by resetting P2P file-sharing connections. Earlier this week, a study published by the Vuze team found AT&T to have the 25th highest (13th highest if extra Comcast networks are excluded) median reset rate among the sampled networks. In the past, AT&T has defended Comcast's throttling practices, and said it wants to monitor its network traffic for IP violations. "AT&T vice president of Internet and network systems research Charles Kalmanek, in a letter addressed to Vuze CEO Gilles BianRosa, said that peer-to-peer resets can arise from numerous local network events, including outages, attacks, reconfigurations or overall trends in Internet usage. 'AT&T does not use "false reset messages" to manage its network,' Kalmanek said in the letter. Kalmanek noted that Vuze's analysis said the test 'cannot conclude definitively that any particular network operator is engaging in artificial or false [reset] packet behavior.'"
[+] Your Rights Online: Sandvine CEO Says Internet Monitoring a Necessity 171 comments
Khalid Baheyeldin writes in with a CBC interview with the CEO of Sandvine, Dave Caputo (bio here). Sandvine is the Waterloo, Ontario-based company that provides the technology that Comcast and other ISPs use to overrule Net neutrality by, for example, injecting RST packets to disrupt Bittorrent traffic. Caputo says, among other things, that Internet monitoring is a necessity. Some of the comments to the interview are more tech-savvy than the interviewee comes across.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • by Anonymous Coward on Monday June 30, @12:22AM (#23996505)

    It'll bust their trace buster buster.

      • by Tubal-Cain (1289912) on Monday June 30, @01:46AM (#23996957)

        Straight-up blocking it is probably more clearly illegal than throttling.

      • 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.
      • 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.

  • Tag: !news (Score:5, Insightful)

    by Mr2001 (90979) on Monday June 30, @12:23AM (#23996513) Homepage Journal

    This trick has been around for a while, hasn't it?

    The problem is, you can only filter out the RST packets on your end of the connection. But 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.

    • Re:Tag: !news (Score:5, Informative)

      by Jeffrey Baker (6191) on Monday June 30, @12:35AM (#23996591)
      Not just that, but it filters out RST packets that may in fact have been sent by the peer. So this trick can leave you with sockets hanging open in a bad state.
      • Exactly. (Score:5, Informative)

        by plasmacutter (901737) on Monday June 30, @12:45AM (#23996663) Journal

        I noticed my WoW connection suddenly became unstable at the beginning of the month.

        I implemented similar firewall rules on my mac and the instability was cut in half.

        Guess the other half is being forged to the blizzard servers.

      • by Fallen Kell (165468) on Monday June 30, @01:15AM (#23996815)
        As my subject says. This is why you only put the filter on the specific port you are using for P2P traffic. For instance, my rule is as follows:

        iptables -I FORWARD 3 -p tcp --dport 36745 --tcp-flags RST RST -j DROP;

        The above does what it says, drop TCP RST packets on port 36745. That is all you need to do to keep it from affecting your other network applications which may be getting legit reset packets.
        • Your comment seems to imply that no bittorrent peer will ever need to RST the connection, which is not generally true.
          • Well, if you're getting bitten by ComCast (or other e.g. Canadian) ISPs that are resetting connections, then it's probably better to leave connections open that shouldn't be than to close connections that should stay open.

            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.

    • Re:Tag: !news (Score:5, Interesting)

      by Easy2RememberNick (179395) on Monday June 30, @01:19AM (#23996833)

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

    • Re:Tag: !news (Score:5, Insightful)

      by cryptoluddite (658517) on Monday June 30, @02:23AM (#23997101)

      The problem is, you can only filter out the RST packets on your end of the connection.

      That's only a temporary problem. The real problem -- for the ISPs -- is that the same software is running on each end of a p2p, so all of their efforts are guaranteed to fail eventually.

      For instance, p2p programs can start using UDP spread spectrum... pass packets on random ports. The receiver then basically implements a quick and dirty tcp-like connection over this (ie much worse for an ISP than actual TCP). Add encryption and random length so it's harder to filter out. Or there can be a shared random number seed for the shared ports. Just for example...

      There's probably some computer science or information theory law stating this, but they can't ultimately reduce the targeted traffic by more than the loss from encoding it as 'normal' traffic. For instance, if they limit torrents to 100k/s and the loss is 33% from 'base64' encoding the data as some kind of an html-ish doc then if normal web pages get more than 133k/s then torrents would be faster encoding them as 'normal' traffic.

      ... then they have to try to figure out what are real web pages/servers and what are really some other protocol pretending.

  • Sandvine? (Score:5, Funny)

    by cbrocious (764766) on Monday June 30, @12:24AM (#23996523) Homepage
    I heard it through the sandvine.
    • by Anonymous Coward on Monday June 30, @01:53AM (#23996987)
      I'll bet you're wondering how I knew,
      Why my packets never made it through,
      With some other peer I was sharin' files,
      Between the two of us Comcast was runnin' wild,
      Reset me by surprise (reset by surprise), I'm afraid,
      From the R-I-Double-A,
      Don'tcha know,

      I heard it through the sandvine.



      Not much bandwidth's gonna be mine.
      Oh, I heard it through the sandvine...
      Oh, I'm just about to lose my mind,
      Honey, honey, yeah...

      I know a geek ain't supposed to cry,
      But these fears I can't hold inside,
      Losin' the 'net and it's neutrality,
      Yeah, it means that much to me,
      You coulda told me (you coulda told) yourself,
      That you're forgin' packets for someone else,

      Instead I heard it through the sandvine...
      Not much bandwidth's gonna be mine.
      Oh, I heard it through the sandvine...
      Oh, I'm just about to lose my mind,
      Honey, honey, yeah...

      People say "Believe half of what you see,
      Son, and none of what you hear",
      But my router's mighty confused,
      So if it's true, please tell me dear,
      Do you want (do you want) to make me go,
      Back to the ISP (and USENET feed) I used before,

      Or should I drop packets from your sandvine...
      Plenty bandwidth's gonna be mine.
      Oh, I don't listen to your sandvine...
      MPAA's 'bout to lose its mind,
      Honey, honey, yeah...

      - Original work, composed under the influence of Slashdot and beer. Lyrics in public domain. Someone with vocal talent, feel free to improve, record, and youtube it as a parody under the fair use exemptions.

  • by corsec67 (627446) on Monday June 30, @12:26AM (#23996531) Homepage Journal

    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.

  • I wonder if they will just say that blocking their RST Packets is a violation of TOS and disconnect you.

  • There is no more good reasons and not any easier for the ISP's to block or rate limit our web-use than it is to centrally control spam. People are different, and have different needs plain and square.

    Who should have priority, and how to determine it? I can guarantee that if it is a packet flag, then spammers, virus writers, and even bit torrent users will find a way to use it. And regardless, consider the following:

    - Which priority should online Live football have from site X? Should it have over the one from site Y, and Z, and the 1000+ others with different commentators and different languages?
    - What if you rather wanted live games? Or Live online music concerts? What should have higher priority?
    - What about your live online video rentals - stream from Netflix over one from Blockbuster or should maybe your own ISP be allowed to rate limit all the competition to sell their own?
    - What about my VoIP from Skype over Vonage, Gizmo, Provider X,Y,Z?
    - What about Online games from Xbox 360 above Playstation 3?

    Who are to set the priorities? How on earth should the ISP know what my priorities are? How on earth should the football channel know they should not send with highest priority flags?

    And there is also a much easier way that leaves the internet neutral:
    As with e-mail spam filtering - let the settings be neutral from the ISP side, then let us set up our own profile or custom rules for the downstream traffic.

  • encryption (Score:5, Interesting)

    by socsoc (1116769) on Monday June 30, @12:45AM (#23996659)
    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.
  • 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).