Impacts of Encryption Everywhere (any solution?)

Wed Jun 20 00:26:30 UTC 2018

There are solutions like that out there, but some people refuse to play in that sandbox. 

----- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "William Herrin" <bill at herrin.us> 
To: "Lee Howard" <lee.howard at retevia.net> 
Cc: nanog at nanog.org 
Sent: Tuesday, June 19, 2018 10:33:50 AM 
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/> 