[Discuss] Https - the solution to net neutrality and ISP monopolies

[bogstad at pobox.com (Bill Bogstad)]

On Tue, Jul 22, 2014 at 9:10 AM, Edward Ned Harvey (blu)
<blu at nedharvey.com> wrote:
>...
> So I got to thinking, could encryption be used to circumvent greedy ISP's systematically?  If everything were encrypted and unidentifiable, then the only thing they could do would be to throttle *all* the traffic, not just the big content distributors that they want to shake down.  Then, the slow service would be recognizable to end users for what it is - a crippled internet connection, and not a deficiency of Netflix, Youtube, etc.

Traffic analysis (who is talking to who, when, and how often)
apparently works really well for three letter agencies even when they
can't read the actual messages due to encryption.   Given that your
local ISP doesn't care which movie you are watching, just that it is
coming from Netflix; I don't think encryption would help that much.
They will still have the IP address of the source of that
huge packet flow as well as the identity of the network provider over
which it is coming.

I suspect that if we still allowed source routing of IP packets, that
would have been sufficient to solve your problem.  (No encrypted VPN
required.)   From everything I've read, the residential ISPs have
simply refused to allow connections to their networks of sufficient
size from the network providers that Netflix and others use.   The
result is packet loss and poor streaming.   When you use a VPN, the
traffic flow came onto your ISPs network via a physical connection
which isn't directly associated with Netflix.   Those connections get
upgraded as required when congestion becomes a problem.   The
"filtering" isn't done by IP address, but instead at the network
interconnect level.   Cheaper to implement and more plausible
deniability.

As for Netflix switching to a CDN (like Akamai), you are basically
suggesting that Akamai is so big that your ISP would have to upgrade
their connectivity whenever the link to the CDN became congested.
I'm not sure I like the idea of some other large company ending up in
a position to potentially dictate terms to content providers.   In any
case, I recall that Netflix did use CDNs (including Akamai) for a
while.   I believe they phased that out as they got bigger and felt
they could do it more cheaply themselves.   Switching back to CDNs
would undoubtedly be more expensive and I'm sure that your ISP would
set things up so it was $1 cheaper to pay the ISP directly then go
through a CDN.   In any case, as I understand it, even CDNs the size
of Akamai frequently pay to connect with various large networks just
so they don't have these kinds of problems.   This gets passed along
to their customers.   Exactly what Netflix is trying to avoid.

Bill Bogstad


>
> Even if everything were tunneled over https, there are two obvious counters that the ISP's could take:  They could inspect the DNS traffic and/or SSL subject name to find the name of the server.  And/or they could try to create a list of all of Netflix's and Youtube's IP addresses, and throttle traffic based on these factors.
>
> Recently I noticed, that a lot of time when I go to download some file from some website, the content is actually redirected to come from s3.amazon.com.
>
> My point is to say:
> #1 the hostname doesn't need to be recognizable as "*.youtube.com" or "*.netflix.com" ... These guys could randomize all new DNS names all the time, so the exposed servername doesn't cause a problem.
> And
> #2 Content distribution networks don't necessarily have to have small recognizable IP ranges.  Especially with the expansion of IPv6.  Especially if large content distribution networks aggregate all sorts of traffic - netflix, youtube, and everyone else -
>
> If the content is distributed by a content distribution network, and LOTS of services use those networks, then the SSL cert could be "*.akamai.com" (or whatever) and if the ISP's want to throttle it, their only choice is to throttle *all* of the content indiscriminantly.
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss