Impacts of Encryption Everywhere (any solution?)

Tue Jun 19 15:50:05 UTC 2018

Netflix is not supposed to be cacheable by third parties for legal reasons 
that have absolutely nothing to do with routing.
Similar with most streaming services including stupid geolocation usage.
If you have sufficient eyeballs, Netflix will work with you to get a local cache
set up using their devices.  If it is just you and a half dozen neighbors they won't.

A far larger problem than the encryption is website design that doesn't cater to
low bandwidth links.  HTML5 is cool but marking a 10mbyte animation as non-cachable
and putting it on the front page of a major bank website is a misuse of resources.

Mack

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of William Herrin
Sent: Tuesday, June 19, 2018 9:34 AM
To: Lee Howard <lee.howard at retevia.net>
Cc: nanog at nanog.org
Subject: Re: Impacts of Encryption Everywhere (any solution?)

On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard <lee.howard at retevia.net> wrote:
> On 06/17/2018 02:53 PM, Brad wrote:
>> While I agree there are unintended consequences every time 
>> advancements are made in relation to the security and stability of 
>> the Internet- I disagree we should be rejecting their 
>> implementations. Instead, we should innovate further.
>
>
> I look forward to your innovations.

The innovation I'd like to see is a multi-level streaming cache.
Here's the basic idea:

Define a network protocol such as "mlcache"

mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some video that netflix has. It's encrypted. The client got the decryption key for that chunk and instructions on how to load the chunks in what order in an authenticated http connection.

The client does not connect to data.netflix.com. Instead, it probes an anycast IP address to find the nearest cache. If there is no cache, then it falls back on contacting data.netflix.com directly.

If the cache probe returned a unicast IP address for a nearby cache then the client asks the cache to retrieve that chunk instead. If lots of folks using the cache are watching that particular video, the cache can supply the chunk without asking netflix for it again.

If the cache doesn't have the chunk, it contacts the next cache upstream. If there is no next cache upstream, it contacts data.netflix.com directly.

The cache is not application-specific. Anything willing to talk the cache protocol can use it to fetch chunks of data from any server.

In principle this should work for live streams too. The head end server either replies "not yet" or holds the request open until the next chunk of data is available. The cache requests the chunk once and supplies it to all clients once retrieved. Keep the chunks small enough that the caching process delays the live stream by a second or two, no different than the television broadcasts do.

Regards,
Bill Herrin

--
William Herrin ................ herrin at dirtside.com  bill at herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.