An Education In Deep Packet Inspection 126
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.
Your Action, My Reaction (Score:5, Interesting)
I go for encryption, SSL, and HTTPS. Even my slowest home system can easily handle this.
Re:Encryption stops this correct? (Score:5, Interesting)
They can however arbitrarily assume all encrypted data to be hostile and filter accordingly...
Re:The description's a little "excited" (Score:5, Interesting)
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.
Re:Deep inspection up your authorities (Score:5, Interesting)
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.
Re:Encryption stops this correct? (Score:4, Interesting)
Take a look at:
SSLIA [netronome.com]
Deep packet inspection inside SSL sessions. It's not the only one either.
Easy Fix (Score:4, Interesting)
Re:The description's a little "excited" (Score:3, Interesting)
Well, that brings up an interesting philosophical question -- assuming the politician in charge IS evil, who, actually, is responsible for the evil of the totalitarian state? Do the people cause the harm, by supporting the disingenuous politician? Or does the evil politician cause the harm?
I'd say the evil politician causes the harm, because but for his actions, the harm would not happen. Ability to prevent harm, and lack of exercise of that ability due to good intentions, does not imply responsibility for causation -- the people who mean well and don't understand the implications are not the cause of the harm.
That doesn't mean that failure to understand the ramifications is an excuse, it just means that the actual cause should be attributed to the person of bad will, not to the people of good will and little understanding.
Re:Encryption stops this correct? (Score:1, Interesting)
Uh, no, not with some of the new devices comeing along for firewalls. I know my company is preparing to upgrade their firewalling (global presence, 100K+ employees) with such technology explicitly for 2 "big" problem areas as they see it: 1. Intellectual property theft; 2. "Inappropriate" site access (porn, etc.).
As I read the proposal (as part of a wide list of reviewers as potential stakeholders due to my 2-bit role in web administation) I was appalled to realize that this is commercial off-the-shelf technology to instantly decrypt SSL packets, check for the verboten stuff, then pass along the encrypted originals with no hint that your "secure" connection is anything but.
I am not interested in that off-limits stuff, but doing any of my payroll/medical/personal banking stuff on the corporate network with https is now very unappealing to me, but the corporate related "personal" functions have no alternative.
When I mentioned this forthcoming capability to other colleagues at an orientation session after hearing the moderator extol the wonders of doing our HR stuff "securely" online, many were disturbed by my revelation.
Anything for the "bottom line" and "corporate governannce", eh?
Also, this means that the (intentional) bad guys can buy and use this stuff...
FWIW,
RO
Re:Your reaction, my re-reaction (Score:3, Interesting)
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.
Re:Easy Fix (Score:3, Interesting)
Charge more for higher QoS. Give a discount for lower QoS.
That's a given.
I'd expect plans to include some small amount of VoIP quality 2-way high-QoS as standard (about a couple phone calls' worth plus whatever is needed for the plan's special services). Higher amounts could be obtained by subscribing to a higher-priced plan or dynamically-configured as needed - perhaps for a fee (like dialing a toll phone call or subscribing to a pay-per-view).
Want your packets to get reserved bandwidth and better treatment on the backbone? Pay up your fair share (and let the ISPs and backbone providers split the swag according to their contracts). Or take best effort delivery, in competition with file transfers and whatnot, and accept the hiccups when the intertubes get cloggerated.
No Tales from the Encrypt (Score:3, Interesting)
Unencrypted data will always get you in trouble. There is no reason in the year two thousand and nine to send or receive anything over the internet without encapsulating it in a SSH or SSL tunnel. Whine all you like about performance hits, but if the technology has reached the point where your residential ISP can look inside every packet you send to see what's there - in real time - then the point has come to spend some processing power on protecting your data in mid-flight, or invest in some encryption hardware.
I'm more than half convinced that this is how everything =inside= a LAN should communicate with each other, too. The firewall should allow port 22, port 443, and drop the rest.
While we're at it, everything should be firewalled right at the VLAN, on the switch.