Re: Impacts of Encryption Everywhere (any solution?)
Well, yes, there is, you simply have to break the end to end encryption On 06/17/2018 03:09 AM, Matthew Petach wrote:
Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
Sadly, it's just falling on deaf ears. Silicon Valley will continue to
On 06/16/2018 10:13 PM, Mike Hammett wrote: think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
Le 2018-06-17 12:40, nanog@jack.fr.eu.org a écrit :
Well, yes, there is, you simply have to break the end to end encryption
Yes, (or) deny service by Policy (remains to evaluate who's happy with that). Cheers, mh
On 06/17/2018 03:09 AM, Matthew Petach wrote:
Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
Sadly, it's just falling on deaf ears. Silicon Valley will continue to
On 06/16/2018 10:13 PM, Mike Hammett wrote: think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
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. Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity. -Brad -------- Original message --------From: Michael Hallgren <mh@xalto.net> Date: 6/17/18 11:14 (GMT-07:00) To: nanog@jack.fr.eu.org Cc: Matthew Petach <matt@petach.org>, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog@jack.fr.eu.org a écrit :
Well, yes, there is, you simply have to break the end to end encryption
Yes, (or) deny service by Policy (remains to evaluate who's happy with that). Cheers, mh
On 06/17/2018 03:09 AM, Matthew Petach wrote:
Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
Sadly, it's just falling on deaf ears. Silicon Valley will continue to
On 06/16/2018 10:13 PM, Mike Hammett wrote: think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
If additional capacity were something feasible, it would be done. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brad" <brad@persius.net> To: nanog@nanog.org Sent: Sunday, June 17, 2018 1:53:52 PM Subject: Re: Impacts of Encryption Everywhere (any solution?) 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. Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity. -Brad -------- Original message --------From: Michael Hallgren <mh@xalto.net> Date: 6/17/18 11:14 (GMT-07:00) To: nanog@jack.fr.eu.org Cc: Matthew Petach <matt@petach.org>, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog@jack.fr.eu.org a écrit :
Well, yes, there is, you simply have to break the end to end encryption
Yes, (or) deny service by Policy (remains to evaluate who's happy with that). Cheers, mh
On 06/17/2018 03:09 AM, Matthew Petach wrote:
Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
Sadly, it's just falling on deaf ears. Silicon Valley will continue to
On 06/16/2018 10:13 PM, Mike Hammett wrote: think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
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.
Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity.
I encourage you to invest billions of dollars in rural broadband capacity worldwide. The rest of us will thank you for your sacrifice. Lee
-Brad
Well, yes, there is, you simply have to break the end to end encryption Yes, (or) deny service by Policy (remains to evaluate who's happy with
-------- Original message --------From: Michael Hallgren <mh@xalto.net> Date: 6/17/18 11:14 (GMT-07:00) To: nanog@jack.fr.eu.org Cc: Matthew Petach <matt@petach.org>, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog@jack.fr.eu.org a écrit : that).
Cheers, mh
On 06/17/2018 03:09 AM, Matthew Petach wrote:
Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
Sadly, it's just falling on deaf ears. Silicon Valley will continue to
On 06/16/2018 10:13 PM, Mike Hammett wrote: think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
I’m confused. People are using last hop (wireless) arguments against HTTPS Everywhere; that’s the part that requires full bandwidth either way (as your non-HTTPS cache is upstream somewhere). The fiber links that are physically fixed and can handle in many cases better lasers, are the ongoing upgradable part. If you’re complaining your fiber backhaul is too big a deal, you’re playing the wrong game to start with. George William Herbert Sent from my iPhone
On Jun 19, 2018, at 7:53 AM, Lee Howard <lee.howard@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.
Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity.
I encourage you to invest billions of dollars in rural broadband capacity worldwide. The rest of us will thank you for your sacrifice.
Lee
-Brad
Well, yes, there is, you simply have to break the end to end encryption Yes, (or) deny service by Policy (remains to evaluate who's happy with
-------- Original message --------From: Michael Hallgren <mh@xalto.net> Date: 6/17/18 11:14 (GMT-07:00) To: nanog@jack.fr.eu.org Cc: Matthew Petach <matt@petach.org>, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog@jack.fr.eu.org a écrit : that).
Cheers, mh
On 06/17/2018 03:09 AM, Matthew Petach wrote: Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
On 06/16/2018 10:13 PM, Mike Hammett wrote: Sadly, it's just falling on deaf ears. Silicon Valley will continue to think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
I encourage you to look at operating a network outside of a datacenter or corporate campus. The wireless last hop is *NOT* the problem. A modern deployment in a small village could put dozens of megabit/s to every house for $10k. The transit or transport connections *ARE* the fiscal problem. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "George Herbert" <george.herbert@gmail.com> To: "Lee Howard" <lee.howard@retevia.net> Cc: nanog@nanog.org Sent: Tuesday, June 19, 2018 10:29:15 AM Subject: Re: Impacts of Encryption Everywhere (any solution?) I’m confused. People are using last hop (wireless) arguments against HTTPS Everywhere; that’s the part that requires full bandwidth either way (as your non-HTTPS cache is upstream somewhere). The fiber links that are physically fixed and can handle in many cases better lasers, are the ongoing upgradable part. If you’re complaining your fiber backhaul is too big a deal, you’re playing the wrong game to start with. George William Herbert Sent from my iPhone
On Jun 19, 2018, at 7:53 AM, Lee Howard <lee.howard@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.
Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity.
I encourage you to invest billions of dollars in rural broadband capacity worldwide. The rest of us will thank you for your sacrifice.
Lee
-Brad
Well, yes, there is, you simply have to break the end to end encryption Yes, (or) deny service by Policy (remains to evaluate who's happy with
-------- Original message --------From: Michael Hallgren <mh@xalto.net> Date: 6/17/18 11:14 (GMT-07:00) To: nanog@jack.fr.eu.org Cc: Matthew Petach <matt@petach.org>, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog@jack.fr.eu.org a écrit : that).
Cheers, mh
On 06/17/2018 03:09 AM, Matthew Petach wrote: Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
On 06/16/2018 10:13 PM, Mike Hammett wrote: Sadly, it's just falling on deaf ears. Silicon Valley will continue to think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
I've always said that the fiber middle mile price themselves out of more money. I want a fiber connection that will service a subdivision(20-50 households) with speeds up to 1gbps, oh that's $2k/mo. The problem is that we want a fiber connection for 10 or 20 subdivisions, oh, that's 2k per, but you get 10% discount because of the amount.. Alternatively, we could get a single 10g connection from an IX/first mile for $2500, and use 10-20 $3k radios to get a gig into every sub division, We've tried to get fiber providers to allow us to purchase bandwidth based upon 3 criteria: 1) the cost for them to buildout, they are a business and need to get their money back. 2) total burstable capacity, 10g circuits cost more than 1g, but 200m circuits shouldn't cost less than 1g. 3) by the number of subscribers on each link. We have offered to 1) pay for their fiber install costs, 2) pay a base tariff and 3) pay up 25% of base revenue per user. In this case, fiber company gets paid to put the fiber in, and ~$500/mo for each connection they're giving to us, in this scenario they will make $10k/mo profit, plus expand their network. In the other scenario they make only $2500/mo and come in uncompetetively for businesses in our market(because they have a new buildout to bake into their price) Just doesn't make sense to us to pay individually for fiber connections when we know it's packet switched anyway, and the load on their network is the same On 19 June 2018 at 18:25, Mike Hammett <nanog@ics-il.net> wrote:
I encourage you to look at operating a network outside of a datacenter or corporate campus.
The wireless last hop is *NOT* the problem. A modern deployment in a small village could put dozens of megabit/s to every house for $10k. The transit or transport connections *ARE* the fiscal problem.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
----- Original Message -----
From: "George Herbert" <george.herbert@gmail.com> To: "Lee Howard" <lee.howard@retevia.net> Cc: nanog@nanog.org Sent: Tuesday, June 19, 2018 10:29:15 AM Subject: Re: Impacts of Encryption Everywhere (any solution?)
I’m confused.
People are using last hop (wireless) arguments against HTTPS Everywhere; that’s the part that requires full bandwidth either way (as your non-HTTPS cache is upstream somewhere). The fiber links that are physically fixed and can handle in many cases better lasers, are the ongoing upgradable part.
If you’re complaining your fiber backhaul is too big a deal, you’re playing the wrong game to start with.
George William Herbert Sent from my iPhone
On Jun 19, 2018, at 7:53 AM, Lee Howard <lee.howard@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.
Just because end to end encryption causes bandwidth issues for a very small number users - then perhaps they could benefit the most by these changes with additional capacity.
I encourage you to invest billions of dollars in rural broadband capacity worldwide. The rest of us will thank you for your sacrifice.
Lee
-Brad
Well, yes, there is, you simply have to break the end to end encryption Yes, (or) deny service by Policy (remains to evaluate who's happy with
-------- Original message --------From: Michael Hallgren <mh@xalto.net> Date: 6/17/18 11:14 (GMT-07:00) To: nanog@jack.fr.eu.org Cc: Matthew Petach <matt@petach.org>, nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) Le 2018-06-17 12:40, nanog@jack.fr.eu.org a écrit : that).
Cheers, mh
On 06/17/2018 03:09 AM, Matthew Petach wrote: Except that if websites are set to HTTPS only, there's no option for disabling encryption on the client side.
Matt
On Sat, Jun 16, 2018, 14:47 <nanog@jack.fr.eu.org> wrote:
> On 06/16/2018 10:13 PM, Mike Hammett wrote: > Sadly, it's just falling on deaf ears. Silicon Valley will continue > to think they know better than everyone else and people outside of that bubble will continue to be disadvantaged.
What, again ? Encryption is what is best for the most people. The few that will not use it can disable it.
No issue then.
On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard <lee.howard@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@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
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@nanog.org] On Behalf Of William Herrin Sent: Tuesday, June 19, 2018 9:34 AM To: Lee Howard <lee.howard@retevia.net> Cc: nanog@nanog.org Subject: Re: Impacts of Encryption Everywhere (any solution?) On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard <lee.howard@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@dirtside.com bill@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.
On Tue, 19 Jun 2018 11:33:50 -0400, William Herrin said:
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.
Congrats, you just re-invented BitTorrent. :)
On Tue, Jun 19, 2018 at 12:09 PM, <valdis.kletnieks@vt.edu> wrote:
On Tue, 19 Jun 2018 11:33:50 -0400, William Herrin said:
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.
Congrats, you just re-invented BitTorrent. :)
Except for the peer to peer part and every other aspect of bit torrent save the chunked transfer. Regards, Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
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@herrin.us> To: "Lee Howard" <lee.howard@retevia.net> Cc: nanog@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@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@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
participants (10)
-
Brad -
George Herbert -
Lee Howard -
McBride, Mack -
Michael Crapse -
Michael Hallgren -
Mike Hammett -
nanog＠jack.fr.eu.org -
valdis.kletnieks＠vt.edu -
William Herrin