Slashdot Mirror
An Education In Deep Packet Inspection
Deep Packet Inspection, or DPI, is at the heart of the debate over Network Neutrality — this relatively new technology threatens to upset the balance of power among consumers, ISPs, and information suppliers. An anonymous reader notes that the Canadian Privacy Commissioner has published a Web site, for Canadians and others, to educate about DPI technology. Online are a number of essays from different interested parties, ranging from DPI company officers to Internet law specialists to security professionals. The articles are open for comments. Here is the CBC's report on the launch.
You go for DPI.
I go for encryption, SSL, and HTTPS. Even my slowest home system can easily handle this.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
They can however arbitrarily assume all encrypted data to be hostile and filter accordingly...
As I understand it:
ISPs don't implement the QoS (Type of Service) field because (back before THEY needed it for services) Microsoft deployed an IP stack in Windows that "improved" their own file transfers and other IP traffic by demanding high QoS for everything.
Because of that (and the threat of bad guys cheating) the ISPs don't trust the field when coming from a customer. So there wasn't a strong driver for implementing QoS in the ISPs and backbone
IMHO the right solution is for ISPs to:
- Write service level agreements that guarantee a certain bandwidth of high QoS traffic - for the whole feed to the customer, not per flow.
- Start honoring the ToS field and policing the data rate at the edge router, and
- When a packet would be dropped for exceeding the data rate for the enhanced service, instead REWRITE THE ToS FIELD for best-effort delivery (or whatever lower service level seems appropriate) and try to forward it under those terms.
That way:
- The ISP doesn't have to classify the flow according to traffic type to give the user high QoS for his critical services.
- The ISP doesn't have to do a packet-recombine if the packet is fragmented to identify the flow for the trailing fragments (which don't carry the TCP/UDP port number).
- The user / application can specify what special handling he / it wants.
- Applications that try to "cheat" can only do so up to the bandwidth cap for the special handling. (But the user paid for that. So he can use his bandwidth for whatever he wants. It's not "cheating" any more.)
- Excess traffic will still go through as well as it does now.
- A "cheating" application WILL hurt the user's own really-needs-high-QoS service, giving users and applications providers an incentive not to request excessive QoS. (But it won't hurt ANYBODY ELSE's traffic.)
- Authors of applications that need high QoS will have an incentive to specify it, since doing so will work.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Do you want your ISP and potential unknown/unaccountable parties to be able to easily monitor, intercept, and record some or all of your Internet traffic? Do you want profiles built on this information that will compromise your privacy and could be used to serve advertisements or to micromanage your Internet usage? Do you feel like QoS, which will be the given reason/excuse, is such a good and desirable thing that it's worth all of these disadvantages?
The Internet will become more like an airport: all your packetages will be subject to inspection without need for a warrant or probable cause and denied travel accordingly.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Take a look at:
SSLIA
Deep packet inspection inside SSL sessions. It's not the only one either.
Charge more for higher QoS. Give a discount for lower QoS.
MITM's. The answer to this is SSL ofcourse, and "don't allow SSL exceptions". (Don't run with scissors)
But there has to be a better way for establishing the 'CA - domain' trust. Why isn't the trust chain 'ICANN CA - country domain operator CA - registrar CA - domain'?
But first you need DNSSec anyway, otherwise you can validate the PKI chain, but not that everybody is who they say they are. (For example: Registrar CA's should only be valid on DNS records where they are listed as the Registrar.)
After that, default to https and deprecate http for bonus points.