back to article Revealed: ITU's deep packet snooping standard leaks online

A moment of inattention has allowed the ITU’s proposed deep packet inspection (DPI) standard to escape. The slip-up happened when an Australian CryptoParty activist Asher Wolf put out a public call on Twitter asking for a copy of the text. The ITU duly sent it by e-mail – only later realising its mistake and asking her to …

COMMENTS

This topic is closed for new posts.
  1. P. Lee
    Terminator

    Boring tech doc

    Just like all other dpi really.

    Not really accurate or reliable enough for anything other than annoying people. You can get it to work ok if you have a very controlled environment, such as a corporate DMZ but outside that, it isn't that great and consumes gobs of cpu. On the internet, its just a pretense that something clever is being done, when in fact they're just checking your torrents and web sites.

    1. Ole Juul

      Re: Boring tech doc

      You seem to be hinting that this is actually more of a political doc than a tech doc, and I'd agree with that.

    2. Anonymous Coward
      Anonymous Coward

      Re: Boring tech doc

      "its just a pretense that something clever is being done, when in fact they're just checking your torrents and web sites"

      And reading all your HTTPS traffic ...

  2. Neoc

    Standardisation.

    The only reason to standardise this stack is to allow someone (be it government or evil company(tm)) to build a single snooper interface which can then be dropped into the communication stack.

    As the author points out, the functionality already exists in many version and APIs and this has (so far) made large-scale snooping or interference difficult without users immediately noticing. But this would provide a single set of APIs to do the same everywhere.

    1. WonkoTheSane
      Pirate

      Re: Standardisation.

      On the upside, standardization would also allow for a single method of bypassing DPI.

      1. Anonymous Coward
        Anonymous Coward

        Re: Standardisation.

        the wonderful thing about standards is that there are so many to choose from.

        © someone or another

      2. Gerhard Mack

        Re: Standardisation.

        There already is a single method of bypassing DPI. It's called SSL/TLS.

        1. Tom Paine
          Trollface

          Re: Standardisation.

          SSL/TLS, a defence against DPI? BWAAAAAhahahahahaha! It's the way you tell 'em!

          1. FordPrefect
            Stop

            Re: Standardisation.

            SSL/TLS is already being inspected. Most security proxies already have the technology. It wont even warn you that your traffic is being inspected if someone has installed a root certificate on your machine. Never assume SSL/TLS isnt being inspected if you dont own the device or have allowed the network/service provider to install stuff.

    2. Chris 3

      Re: Standardisation.

      I think we have a winner.

  3. Chris Miller

    "malicious traffic identification"

    I've never understood (and would welcome clarification from those more knowledgeable) why service providers don't drop IP traffic outbound from their clients with a source address that doesn't match the known network address range (aka spoofed addresses). Anyone who's looked at firewall logs will see lots of dropped traffic with private source addresses (10/8, 172.16/12, 192.168/16), which has obviously 'leaked' from organisations where NAT hasn't been implemented perfectly.

    No deep packet inspection and hence expensive kit required, but it would block an awful lot of rubbish, including many basic DDoS attacks. And it can't break anything (can it?) because such traffic, by its nature, can never return.

    1. Greem

      Re: "malicious traffic identification"

      That's known in the business as BCP38 - see http://tools.ietf.org/html/bcp38 - and is a perennial discussion point amongst network operators. Given that BCP38 is now 12 and a half years old, and bits of it are older than that, the likelihood of it being applied across the board is unlikely.

      The complexity of modern networks can result in it being technically difficult (although not impossible) to completely validate source addresses within networks for which the kit is "authoritative". Responsible network operators know this and apply BCP38 quite strictly, but they are far outnumbered by network operators who don't even know what BCP38 is. Sadly.

      Interestingly if it was applied absolutely religiously it would make spoofed (D)DoS attacks almost impossible. That's a far more laudable aim than cleaning up firewall logs...

      1. Greem

        Re: "malicious traffic identification"

        And yes, I was largely agreeing with Chris there.

      2. Captain Underpants
        Thumb Up

        Re: "malicious traffic identification"

        @Greem:

        Thanks for the pointer to some interesting reading; always nice to learn something new :)

      3. Chris Miller

        Re: "malicious traffic identification"

        Thanks Greem. I'll go away and read the standard.

    2. Fatman

      Re: "malicious traffic identification"

      This (from the article) makes me suspect telco involvement:

      This section looks at various use-cases: service differentiation (which, of course, raises the debate about network neutrality); traffic monitoring for resource allocation based on subscriber policy (ie, “premium” versus “best effort” services – neutrality again); malicious traffic identification[1] (which isn’t a bad idea); service-based billing (which could, again, tie back to the neutrality question)…

      Note the bold items, aren't they about extracting additional revenue?? This action smells worse than the after effects of Red Tide[2] on fish.

      [1] Depending on whose determination of malicious traffic you want to use, malicious traffic could mean VOIP or SIP traffic in a country where the government controls the 'exit points', and wants to set up any, and all kinds of barriers to circumvent it getting its piece of the action.

      [2] Red Tide is something that you wish never comes to your area if you live near the coast. The stench of hundreds of thousands of dead, rotting fish, well, lets say, I hope you are not ready to sit down for a meal. http://en.wikipedia.org/wiki/Red_tide

  4. David_H

    Standards

    As with so many 'standards' from so many 'authoritative organisations' it is a loose collection of the specifications of the first products on the market. There is no attempt to create a 'best practice' in the standard, just an attempt to include what is on the market.

    There are very few standards that are actually defined before products hit the marketplace.

  5. John Smith 19 Gold badge
    Unhappy

    Helping countries spy on each *others* citizens.

    Yay for global cooperation.

    Now getting this BCP38 thing working properly sounds like quite a good idea.

    But I doubt that will happen either.

  6. Flocke Kroes Silver badge

    Do not need DPI to detect malicous content

    http://www.ietf.org/rfc/rfc3514.txt

    1. jubtastic1

      Re: Do not need DPI to detect malicous content

      Bit late in the year for that isn't it?

    2. John Smith 19 Gold badge
      Happy

      Re: Do not need DPI to detect malicous content

      "http://www.ietf.org/rfc/rfc3514.txt"

      Hilarious

      Like IP over carrier pigeon.

    3. Fatman

      Re: Do not need DPI to detect malicous content

      For about 10 seconds, I thought the """proposal""" was legit; that is, until I took careful notice of its date!!!

      Hey eel Reg, since you are thinking of some new icons, how about a 'you naughty bastard' one.

  7. Christian Berger

    Yet another reason...

    To rent a server in a hosting centre and tunnel your traffic to it.

    1. PyLETS
      Boffin

      Re: Yet another reason...

      "To rent a server in a hosting centre and tunnel your traffic to it."

      Worth doing if server and its address is shared between a number of users who can each plausibly deny any connection to particular packets, or is located in a country with more sensible privacy laws than where clients are located. If used for purposes of a single user in a place with similar laws and enforcement, all it does is shift monitoring of traffic from network belonging to ISP A to network belonging to ISP B.

      Plausible deniability of particular packets if the server has multiple users probably also doesn't extend to the situation where traffic analysis makes correlation of unencrypted external packets with encrypted VPN packets, presumably associate by shortness of time interval and traffic size, so pleny of chaff on VPNs needed to obsure this association. Deniability also doesn't work too well if the hosting provider can provide the investigating authorities with binary copies of the (typically virtual) server image at any time to relevant authorities who can work out from this the relationship between internal users and externally monitorable packets. Some of the advanced virtual machine tools advertised now which offer live migration of VMs between physical hosts for load balancing etc, suggesting this kind of forensics to be entirely feasible.

      So I think this privacy technique is only valuable to the extent you trust the laws and enforcement of the server hosting nation, or the extra cost of the attacks described to cause attackers to go after lower hanging fruit.

  8. Anonymous Coward
    Anonymous Coward

    Bring it on!

    Awesome.

    So instead of relying on 'best effort' internet like all the other proles, I will simply install the 'pirate app' that will inevitably be released that will disguise all of my packets as Premium rate packets.

    Cue the inevitable arms race.

    Once again, the only people who suffer are legitimate Joe Internet users.

    1. Ken Hagan Gold badge

      Re: Bring it on!

      An ISP wanting to support "premium rate" customers could simply put them on a different subnet to plebs. (At least, this is straightforward for ISPs who have a single wire to each customer, as it the case for ADSL. It's a bit tricky to "impersonate" which physical wire your traffic has come into the exchange on.) For all I know, they already do this.

      1. Anonymous Coward
        Anonymous Coward

        Re: put them on a different subnet

        Doesn't really work when they're e.g. streaming paid-for movies to regular customers.

  9. Anonymous Coward
    Anonymous Coward

    Regulation madness

    Authorities or telcoms won't get a firm grip on traffic unless they turn the tables completely to block/ban everything that isn't explicitly allowed, and even the there's trouble lurking. Regulators have to thread carefully else application developers, for the fear of having their apps blocked, will wrap anything in SSL and pass all traffic over port 443 (https). Then nobody can differentiate anything even for noble purposes such as capacity management.

    1. Anonymous Coward
      Anonymous Coward

      Re: Regulation madness

      Not if said regs include installing gov/telco CAs in all client software/OSs and blocking anything that won't go through the MITM in cleartext.

      It's only a matter of time. Think of the children.

      1. This post has been deleted by its author

      2. Anonymous Coward
        Anonymous Coward

        Re: Regulation madness

        OOPS! Meant certificates not CAs - obviously

  10. NoneSuch Silver badge
    Devil

    Yes, but standards are like speed limits. Only the law abiding will follow the rules.

  11. nonymous

    oth

    I'm for this, with reservations of course, and hope dictators use it liberally. Because then the boiling point of dissent will be reached, all the dictators will be guillotined, and the Chinese will get their own Gangnam style going. Then the free world can sit back and enjoy as DOS attacks and all kinds of garbage are choked to death, and the perpetrators have to get real jobs.

  12. David Gosnell
    Coat

    Easy phish for not terribly juicy info

    But I guess it's not like the ITU is as security conscious as a royal hospital.

This topic is closed for new posts.