Jim Harper

What Do We Think of “Deep Packet Inspection”?

The concept of deep packet inspection has come up a couple of times here at the Progress & Freedom Foundation’s Aspen Summit. And I’ve been interested to find people in other fora talking about deep packet inspection in the way they used to talk about cookies: “You’ll get to like once you understand what it is.”

I’m not so sure. Here’s a sample discussion of the issue among us TLFers, conducted on Twitter yesterday. (I’ve reorganized the tweets, so you can read from top to bottom.)

August 19, 2008 | Comments |

Viewing 11 Comments

    • ^
    • v
    Macroblogging is so 2006.
    • ^
    • v
    Come on, Tim. Take your Twitter profile pic and add it to Disqus so we can see your lovely mug here.
    • ^
    • v
    Is the legality of phone wiretaps left up to phone companies and users?

    Also, I think you need a better Twitter picture.
    • ^
    • v
    DPI isn't all bad. It can be used to identify, and thus prioritize, time-sensitive packets like VoIP. DPI also has potential uses for delivering better-targeted ads to consumers. There are serious privacy concerns with DPI, which is why it's so important that the entity doing the inspection is trustworthy. Robust privacy policies that are legally enforceable must also exist to give consumers recourse should a data breach or transfer of data to an unaccountable third party occur.

    DPI is inherently opt-out because you can always encrypt the payload of your packets if you don't want anybody inspecting them except the computer at the other end.
    • ^
    • v
    How would I encrypt my traffic to TLF? A VPN service? I don't like the idea of encouraging an arms race where my ISP spends (my) money on DPI and I spend more of my money countering DPI.

    Prioritizing VoIP is fine (if it is documented and the customer wants it), but today's DPI boxes are total overkill for that task and I suspect ISPs will always be tempted to use them against their customers' wishes.
    • ^
    • v
    DPI isn't all bad. It can be used to identify, and thus prioritize, time-sensitive packets like VoIP. DPI also has potential uses for delivering better-targeted ads to consumers. There are serious privacy concerns with DPI, which is why it's so important that the entity doing the inspection is trustworthy. Robust privacy policies that are legally enforceable must also exist to give consumers recourse should a data breach or transfer of data to an unaccountable third party occur.

    Besides, DPI is inherently opt-out because you can always encrypt the payload of your packets if you don't want anybody peeking inside except for the computer at the other end of the connection.
    • ^
    • v
    Unfortunately, complete end-to-end encryption isn't currently possible with TLF. But I'd love to see an SSL version of the site that would allow for anonymous commenting without the risk of the man-in-the-middle eavesdropping. A VPN service or an anonymous encrypted proxy site like Proxify would allow you to view and post to TLF without the possibility of your ISP, or any router between you and your ISP, knowing the content of your transmissions.

    I am not a huge fan of DPI, but I defend it because of its clear potential for creating wealth in ways that can benefit consumers. What's so bad about ISPs tracking keywords in unencrypted HTTP packets and using those keywords to deliver better targeted ads? As long as the user can trust that information about their browsing habits won't be turned over to a third party, and assuming there's a way to avoid having your packets inspected, there is a very strong case for allowing the market to develop DPI-based advertising technologies. Of course, with Phorm and NebuAd, there are serious concerns regarding the safety and trustworthiness of the third parties with access to potentially sensitive information. But once you resolve these trust issues, the case for DPI becomes much stronger.

    I, for one, am more paranoid than most when it comes to privacy, so I would probably opt out of a DPI scheme or encrypt my data whenever feasible. Fortunately, it's already possible to do Google searches, browse Usenet, conduct financial transactions, and even login to Facebook under the protection of robust encryption.
    • ^
    • v
    Ryan, what's the advantage of DPI over simply giving the end user a mechanism for marking his own packets as high-priority? DPI is an inherently complex and error-prone technology, likely to suffer from both false-positives (prioritizing stuff that looks like VoIP but isn't) and false-negatives (failing to prioritize latency-sensitive traffic it doesn't understand). An end-to-end friendly prioritization scheme like diffserv provides the same benefits as DPI-based prioritization with less complexity and no danger of technological arms races.
    • ^
    • v
    I’d love to see the ISPs and backbone operators get together and roll out some sort of user-driven, end-to-end prioritization mechanism, but for whatever reason it hasn’t happened yet. I completely agree that traffic prioritization mechanisms like diffserv are way better than DPI. DPI is just one less-than-optimal, but still potentially useful, method of prioritizing various kinds of traffic. I really like the idea of allowing users to pick the priority of their own packets. Then ISPs could offer price tiers or metering where each byte would cost a different amount depending whether it was high or low priority. There is one advantage to DPI, though--it works reasonably well with today's applications, without requiring the end user to know anything about flagging packets based on priority. Obviously if something like diffserv were to be implemented on a large scale, programs like Skype would be upgraded to offer the default setting of "flag all packets as time sensitive." Maybe ISPs like DPI because it works with the hardware and software found in today's devices--as far as I know, my Xbox does not currently have the ability to flag my UDP gaming packets as high priority. You'd need lots of software upgrades and perhaps a user awareness campaign to make sure everybody doing VoIP knows how to make sure their traffic stream is time-sensitive.
    • ^
    • v
    Those are good points. A couple of additional challenges to keep in mind: First, prioritization by one ISP isn't terribly useful. It only becomes useful if it's available end-to-end, which necessitates coordinations between ISPs. So DPI doesn't really save you from having to do prioritization on a large scale, it's just an unnecessarily cumbersome mechanism for deciding which packets will get higher priority.

    Second, DPI—unlike user-determined prioritization—will set off an arms race. If Skype, say, is given high-priority treatment, you'll soon find utilities that allow you to camouflage all of your traffic as Skype traffic. (And Skype traffic is encrypted and highly variable, so it's not going to be easy to distinguish) So ISPs are going to have to be constantly tweaking their prioritization rules in response to new attempts to game the system. IMHO, these long-run costs dwarf the short-term costs of re-designing end-user applications (or operating systems) to mark their packets by priority.

    Finally, and most fundamentally, the proliferation of DPI would mean a massive increase in Internet complexity. Right now, you write an application for vanilla TCP/IP and you can be reasonably sure your packets will get "most favored nation" treatment on every network they encounter. In a future world of ubiquitous DPI, every ISP would have slightly different rules for getting your application qualified for prioritization. Developing a latency-sensitive application would require reading the specs of dozens of different ISPs and possibly negotiating with dozens of telecom bureaucracies for favorable treatment. The result will be that launching a new application will be far more complicated and expensive than it is now, and the success of an application would be based on the developer's ability to negotiate favorable DPI treatment, not the application's intrinsic value.

    I should emphasize that I think this is a sufficiently awful idea that regulation isn't necessary to prevent it from happening. ISPs will abandon it relatively quickly once they discover what a headache it is. I think ISPs should be allowed to try it if they want to, but I plan to criticize any that do.
    • ^
    • v
    You make excellent arguments against DPI-based prioritization, although it's worth noting that since congestion at the local node/DSLAM level seems to be the main point of contention at the moment, even prioritizing packets only for the first few hops might still benefit time-sensitive applications.

    I still don't the idea that the 1986 federal wiretap law might prohibit many forms of deep packet inspection. DPI may well be a bad idea, but I'd rather it be allowed to live or die on its own merits.

Trackbacks

blog comments powered by Disqus