Weekly Edition
Return to the Security page
| |||||||||||||
Deep packet inspectionAt its core, the internet is a set of agreements; not just on protocols, but also on practices amongst carriers. Part of what has allowed the explosive growth—in both participants and services—of the internet can be attributed to these agreements. When a new technology like deep packet inspection (DPI) comes along to threaten these long-standing practices, it should be cause for concern. Internet packets are constructed much like postal mail. There is an envelope with addressing information contained in the packet header and a message which is contained in the data payload portion of the packet. Internet carriers are supposed to make their best effort to deliver a packet based on the information in its header. DPI violates that compact by looking inside the data portion, as the packet is en route to its destination, and making decisions based on that. There are some potentially valid uses for DPI—network performance monitoring and law enforcement surveillance, perhaps even with a warrant, are two—but the potential for abuse is large. Because network processing has gotten to the point where devices can do more than just observe and record, packets are being modified and generated on-the-fly in a technique known as deep packet processing (DPP). Various examples of DPI and DPP—generally lumped together as DPI—have been in the news over the last year. Comcast used DPI to try and throttle Bittorrent traffic, while Phorm and NebuAd have used it to rewrite web pages to deliver advertising to unsuspecting users. The DPI problem has gotten enough attention that even various governments have started showing interest. The designer of User Datagram Protocol (UDP)—the connectionless analog to Transmission Control Protocol (TCP)—David Reed recently testified to the US Congress about DPI. In his testimony [PDF] he outlines numerous technical issues, but the biggest may lead to breaking the fundamental model of internet communication:
This is the real risk: [a] service or technology unnecessary to the correct
functioning of
the Internet is introduced at a place where it cannot function correctly
because it does [not]
know the endpoints' intent, yet it operates invisibly and violates rules of
behavior that
the end-users and end-point businesses depend to work in a specific way.
We have seen this behavior from internet companies in other guises as well. Verisign and various ISPs have tried redirecting failed DNS queries to pages they control (and generally fill with ads). Once again, that breaks many applications; it functions more or less correctly for web browsing, but other applications depend on receiving proper errors when querying for nonexistent domains. Because many ISPs hold a near-monopoly on high-speed access in a particular geographical area, they can hold their customers hostage with little concern that competition will come along to force a change. It is this abuse of their monopoly position that tends to interest regulators. In addition, most of their customers are unlikely to notice these "enhancements", making it easier to get away with—at least until those more technically savvy recognize and raise the issue. Using encrypted communications, HTTPS for web browsing for example, is one defense against DPI. There is some cost associated with encryption, of course, but it is one that is likely to be borne if internet carriers persist in these shenanigans. Another option might be Obfuscated TCP, which is a technique to do backwards-compatible encryption at the packet level. Because it doesn't require all hosts to support it at once—it is negotiated between the endpoints when the connection is established—it could incrementally be added into the arsenal of tools to thwart DPI. DPI uses techniques that have generally been attributed to the "cracking" community. Things like man-in-the-middle attacks and IP address spoofing are difficult-to-solve security problems for many applications. When the "legitimate" middlemen start manipulating packets using these means for their own benefit, they come very close to—or cross—the line into illegality. This is a battle about control; our freedoms to communicate and innovate on the internet are at stake. A phone system that randomly inserted advertising into calls or a postal system that kicked back letters whose contents it didn't like as undeliverable would not be considered functioning systems. The internet requires the same treatment. (Log in to post comments)
Napster redux Posted Jul 24, 2008 6:02 UTC (Thu) by felixfix (subscriber, #242) [Link] This reminds me so much of Napster and similar situations. The *AA didn't like Napster, so they broke it into a million headed monster which is breaking them. So the supposedly common carriers are messing with the basic internet for short term gain; they will push people into Obfuscated TCP, and lose what they had, not just the possibility of inserting ads, but of filtering and redirecting based on deep packet inspection. Governments, who one might think would have the most to gain from a silent read-only DPI, will try censorship, thus contributing to the switchover. Sometimes people are so shortsighted and greedy that it still catches me by surprise.
Deep packet inspection Posted Jul 24, 2008 17:20 UTC (Thu) by sitaram (subscriber, #5959) [Link] "perhaps even with a warrant"? There goes Jake doing his Jon imitation again... :-) Jake: that's a compliment, but you knew that right?
Deep packet inspection Posted Jul 24, 2008 17:26 UTC (Thu) by sitaram (subscriber, #5959) [Link] "A phone system that randomly inserted advertising into calls or a postal system that kicked back letters whose contents it didn't like as undeliverable would not be considered functioning systems. The internet requires the same treatment. " This is the crux of the whole thing. Gets the message across to people who will not be bothered to actually think about the issue.
Deep packet inspection vs accounting Posted Jul 25, 2008 16:12 UTC (Fri) by giraffedata (subscriber, #1954) [Link] The traffic shaping side of deep packet inspection/processing just points out the need for better accounting. We have packet carriers sticking their noses where they don't belong -- inside packets -- to try to determine the value of giving service to those packets. We know this is bad because the packet carriers are in no position to make that judgement. But the folks who are in that position, e.g. the Bittorent program and the person who uses it, aren't given the ability to make the traffic shaping decision.If we paid by the packet, we could make our own decision as to whether our song download is as urgent as our neighbor's web browsing. Especially if we could choose different service levels at different prices. As it stands, Comcast's reprehensible packet rewriting does benefit large numbers of Internet users. Taking that ability away from Comcast hurts them.
Deep packet inspection Posted Jul 26, 2008 5:06 UTC (Sat) by dirtyepic (subscriber, #30178) [Link] Great article. Thanks.
Deep packet inspection Posted Jul 28, 2008 10:20 UTC (Mon) by dps (subscriber, #5725) [Link] It should be perhaps remarked that deep packet ispection features are already a standard feature of firewalls. I assume you *do* have a firewall with stateful inspection features infront of your linux box and it does drop at least some incoming attack traffic. This involves looking at more than the just the IP header, which is normally sufficient to route the packet (modulo NAT). If you want interesting throtling features then vanilla linux kernels do have optional policy routing which can do that too. I suspect some readers might have implemented a transparent HTTP proxy which clearly constitutes a man in the middle. Anything like a NebuAd trial would be a powerful reason for me to use another ISP. I do not exist to be fed advertising, period.
Deep packet inspection Posted Jul 31, 2008 13:33 UTC (Thu) by forthy (guest, #1525) [Link] Firewalls sometimes have to inspect packet content. That's especially true for "abominations" like FTP, where the packet can contain the port number a client expects to be connected on. Or worse, the portmapper used by NFS and YP (most firewalls don't pass these), or the way Flexlm license servers work. This sort of protocols haven't been designed for firewalls. The other reason for a firewall to look into the packets is application-level filtering. This sort of firewall consists of (transparent) web and mail proxy, and filters out spam and malware. However, this is a "you want it, you got it" type of man-in-the-middle. Different story.
Deep packet inspection Posted Nov 25, 2008 20:24 UTC (Tue) by aldba2003 (guest, #55329) [Link]
Forgive me if I sound ignorant and overly suspicious, but is it possible for online retailers who offers there own financial services to monitor and divert packets at will? What I am asking is this; I attempted to make an online payment recently and the financial website was down, or so I thought. I tried from three of my home PC's and each time I received a error page saying the site could not be reached. I then tried from my work laptop which was connected via VPN to our corporate network and I was able to access the financial section of the retailers website and therefore make my monthly payment. I checked online to see if others had posted complaints about the same thing and I was amazed at the number of people having the same issue. So, here's my question, is it possible for a online retailer (with who I and countless others have used their registration feature to register our PC's with them)to monitor outbound packets from account holders who are trying to access their financial website to make a payment and return a error page instead of linking us to it?, thereby causing us to be late on making our payments and accessing us late fees in the process?
|
|||||||||||||