Encrypted Traffic No Longer Safe From Throttling

coderrr writes "New research could allow ISPs to selectively block or slow down your encrypted traffic even if they cannot snoop on your transmitted data. Italian researchers have found a way to categorize the type of traffic that is hidden inside an encrypted SSH session to around 90% accuracy. They are achieving this by analyzing packet sizes and inter-packet intervals instead of looking at the content itself. Challenges remain for ISPs to implement this technology, but it's clear that encrypting your traffic inside an SSH session or VPN connection is not a solution to protect net neutrality."

Comments

Er, no.

[Cave Dweller]

First, encrypted traffic was never safe from throttling anyway. Second, FTA:

"So it seems the use of a tool like this would be limited to an extremely controlled environment where users are limited to a white-list set of network protocols (so that they can't use a different tunneling mechanism, stunnel for example) and only allowed to ssh to servers under the control of the censoring party. In which case you would wonder why the admin wouldn't just set the ssh server's AllowTcpForwarding option to false."

Kinda useless.

They can already throttle encrypted traffic.

[Digital_Quartz]

Could be worse. Rogers and Bell, here in Canada, just throttle ALL encrypted traffic.

Re:Why bother?

[cryptodan]

how would this work for gaming online? 16 different IP destinations and I play for hours on in. My understanding of Xbox Live is that it is P2P and if they throttle my Halo 3 game, I'm gonna get pwned even more than normal.

I totally agree. Steam creates a lot of connections to various content servers to bring down content faster for the Steam Client. It also creates a shitload of traffic when you refresh the server list via Steam Clinet > Servers Tab. The Steam Client is also P2P by definition.

Now this type of throttling would piss me off greatly.

Re:A Few Misunderstandings for Many

[Adeptus_Luminati]

What you said about the problem being latency, is a little bit hard to swallow given that the core of most ISPs runs multi-terabit routers.

The fact of the matter is that not only have router CPUs increased in power exponentially, but also core router technology, has advanced to implement caching such as CEF (Cisco Express Forwarding), and build into regular router blades additional CPUs such as DCEF (distributed CEF), etc.

Case in point, core routers these days have SO much spare processing power that most routing cores run VRF (virtual routing and forwarding), which allows a single physical router to VIRTUALLY pose as if it is 100 or even 1,000 different routers, all inside the same box.

And further, the total throughput capacity of these routing processors today is measured in the TERABITS. The latest Cisco router can process some 15 Terabits of traffic in a single box. Even if packet sizes were inneficient, you're still looking at 1+ Terabits of throughput... which is many many many OC192s (10Gigabit Sonet rings).

So don't tell me we're hitting router processing capacity, because that's a complete joke, and if that were the case, Bell Canada would have been smart and presented that info right up front to the courts (they're currently being asked to justify why they throttle their end-users).

I think what it actually may come down to is peering costs with other ISPs... which for the most part isn't a problem for the biggest players which are Tier 1 providers. Tier1 here is defined as a Telco/ISP that is so big (i.e. AT&T) that all other providers pay THEM for packets to traverse their network, and they in fact don't pay anyone or their peering costs are way lower than their peering income.

So Tier1's aside, yes I can see ISPs having to fork out significant $$ for bandwidth per month, and of course torrent freaks doing 200+ GigaBytes/month are costing them significant money.

just my $2.22 cents,
Adeptus