From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp84.iad3a.emailsrvr.com (smtp84.iad3a.emailsrvr.com [173.203.187.84]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9E9063B2A4 for ; Mon, 15 Nov 2021 13:45:38 -0500 (EST) Received: from app6.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F3D6E4FF5; Mon, 15 Nov 2021 13:45:37 -0500 (EST) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app6.wa-webapps.iad3a (Postfix) with ESMTP id D6D8EE0064; Mon, 15 Nov 2021 13:45:37 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 15 Nov 2021 13:45:37 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Mon, 15 Nov 2021 13:45:37 -0500 (EST) From: "David P. Reed" To: "Livingood, Jason" Cc: "starlink@lists.bufferbloat.net" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20211115134537000000_71729" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <523DB564-9E11-4845-8072-003D9E1863AC@cable.comcast.com> References: <1636655426.376728690@apps.rackspace.com> <523DB564-9E11-4845-8072-003D9E1863AC@cable.comcast.com> X-Client-IP: 209.6.168.128 Message-ID: <1637001937.876717373@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: 9803426c-5983-4ed5-8bd2-1eba6039c92a-1-1 Subject: Re: [Starlink] something of a step backwards X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2021 18:45:38 -0000 ------=_20211115134537000000_71729 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A>> They may start MITM's https connections to read traffic=0A =0A> Unles= s they install certs on client devices how are they going to attack the TLS= connections?=0AI don't know what is the current state of practice, but las= t time I looked, GoGo Internet was MITM'ing with packet content inspection = in order to block "streaming" from passenger seats. This was justified by G= oGo claiming that it was the ONLY way to manage traffic that dealt with str= eaming. In fact, merely fixing their bufferbloat would have completely elim= inated the whole class of "overload" real-time services, and would have mad= e response snappy as hell for all passengers sharing the connection. (And s= treaming would have had to run at very long latencies due to "fairness", es= sentially making Netflix impossible.=0A =0AI don't know if this was ignoran= ce on GoGo's part, or intent to continue to act as a MITM.=0A =0AThe mechan= ism for MITM'ing HTTPS connections is well known. I don't intend to detail = it here, but it is based on the fact that certs aren't properly validated b= y client-end software and server-end software.=0A =0A> FWIW, that was not w= hy P2P connections were reset way back when. It was at root a bufferbloat i= ssue, confounded by a lot of bad responses to & misunderstandings of the is= sue at that time. ;-)=0A =0ABy stating it was "bad responses" this covers u= p the entire Comcast fiasco, which led me to testify before an FCC En Banc = on Network Management.=0AIn fact, Comcast did have a bufferbloat *problem* = technically. But it did not know it. Instead, their top management, includi= ng technical management *made up* a story to justify use of Sandvine DPI cl= assification and packet insertion gear at all CMTS's owned by Comcast, whic= h inspected content and inserted TCP packets to break connections. Comcast = top management also attempted to get me, personally, fired from MIT or disc= iplined, by contacting several MIT executives who had the power to do just = that! This personal attack is all thoroughly witnessed, including by a Sr. = VP at Comcast at the time (whom Jason worked for).=0A =0AComcast PR made up= a story that the "real problem" was BitTorrent use, because BitTorrent cou= ld, in fact, generate lots of upstream traffic. Which smelled funny, becaus= e if there was congestion, BitTorrent actually responded to TCP congestion = control metrics. What was happening was, instead, that DOCSIS 2.0 had the a= bility to turn off packet drops entirely, instead allowing a single home to= fill the entire outbound traffic path.=0A =0AThus, I ended up having to de= al with a) Comcast claiming that "network management" required packet disss= assembly, and required Comcast to inspect the content of *every* packet. It= also boosted lies being told by Sandvine and Ellacoya about the virtues of= their gear, developed by Israeli intelligence services to spy on internet = traffic in real time, for network management. They began marketing their eq= uipment to ALL ISPs in the world; and b) a push by all ISPs to claim that n= etwork management by surveillance gear (DPI) was within the norms of the In= ternet; and c) a push for companies like NebuAd and Phorm to argue that ISP= s should have the right to read all traffic from all subscribers to collect= data about the content of each subscriber's Internet to emulate what would= become the "surveillance capitalist" model at the Internet Access level.= =0A =0AAnd beyond those global issues, having my personal technical ability= and integrity attacked in public by well funded lobbyists in DC.=0A =0ASo,= Jason, since you brought it up, these are the stakes that were, and remain= , in creating an Open, Neutral Internet access model.=0A =0A =0AOn Monday, = November 15, 2021 9:21am, "Livingood, Jason" = said:=0A=0A=0A=0A=0A> They may start MITM's https connections to read traff= ic =0A =0AUnless they install certs on client devices how are they going to= attack the TLS connections?=0A =0A> They may start blocking bittorrent bec= ause they claim it's all "piracy" and theft.=0A =0AFWIW, that was not why P= 2P connections were reset way back when. It was at root a bufferbloat issue= , confounded by a lot of bad responses to & misunderstandings of the issue = at that time. ;-) =0A =0ABut you do raise an interesting point that what=E2= =80=99s considered a reasonable network management practice differs by type= of access network =E2=80=93 which we can see in the US between wired and w= ireless access network practices. What may become standard practice in LEO = access networks is still emerging I suppose.=0A =0A> This always comes with= some argument that "bundling" a provider-controlled service =0A =0AI=E2=80= =99d guess the fastest path to deploy a MVP was to keep the edge access dev= ice as simple as possible and not worry about testing lots of permutations.= So getting to market with 1 device makes sense IMO. What the future holds = is anyone=E2=80=99s guess =E2=80=93 but ISTM they are still fairly early in= deployment. =0A =0AJL=0A ------=_20211115134537000000_71729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>> They may start MITM's https c= onnections to read traffic

=0A

 

=0A

>= ; Unless they install certs on client devices how are they going to attack = the TLS connections?

=0A

I don't know what is= the current state of practice, but last time I looked, GoGo Internet was M= ITM'ing with packet content inspection in order to block "streaming" from p= assenger seats. This was justified by GoGo claiming that it was the ONLY wa= y to manage traffic that dealt with streaming. In fact, merely fixing their= bufferbloat would have completely eliminated the whole class of "overload"= real-time services, and would have made response snappy as hell for all pa= ssengers sharing the connection. (And streaming would have had to run at ve= ry long latencies due to "fairness", essentially making Netflix impossible.=

=0A

 

=0A

I don't know = if this was ignorance on GoGo's part, or intent to continue to act as a MIT= M.

=0A

 

=0A

The mechani= sm for MITM'ing HTTPS connections is well known. I don't intend to detail i= t here, but it is based on the fact that certs aren't properly validated by= client-end software and server-end software.

=0A

&n= bsp;

=0A

> FWIW, that was not why P2P connections were reset w= ay back when. It was at root a bufferbloat issue, confounded by a lot of ba= d responses to & misunderstandings of the issue at that time. ;-)

=0A

 

=0A

By stating it was "bad r= esponses" this covers up the entire Comcast fiasco, which led me to testify= before an FCC En Banc on Network Management.

=0A

In fact,= Comcast did have a bufferbloat *problem* technically. But it did not know = it. Instead, their top management, including technical management *made up*= a story to justify use of Sandvine DPI classification and packet insertion= gear at all CMTS's owned by Comcast, which inspected content and inserted = TCP packets to break connections. Comcast top management also attempted to = get me, personally, fired from MIT or disciplined, by contacting several MI= T executives who had the power to do just that! This personal attack is all= thoroughly witnessed, including by a Sr. VP at Comcast at the time (whom J= ason worked for).

=0A

 

=0A

= Comcast PR made up a story that the "real problem" was BitTorrent use, beca= use BitTorrent could, in fact, generate lots of upstream traffic. Which sme= lled funny, because if there was congestion, BitTorrent actually responded = to TCP congestion control metrics. What was happening was, instead, that DO= CSIS 2.0 had the ability to turn off packet drops entirely, instead allowin= g a single home to fill the entire outbound traffic path.

=0A

 

=0A

Thus, I ended up having to deal with = a) Comcast claiming that "network management" required packet disssassembly= , and required Comcast to inspect the content of *every* packet. It also bo= osted lies being told by Sandvine and Ellacoya about the virtues of their g= ear, developed by Israeli intelligence services to spy on internet traffic = in real time, for network management. They began marketing their equipment = to ALL ISPs in the world; and b) a push by all ISPs to claim that network m= anagement by surveillance gear (DPI) was within the norms of the Internet; = and c) a push for companies like NebuAd and Phorm to argue that ISPs should= have the right to read all traffic from all subscribers to collect data ab= out the content of each subscriber's Internet to emulate what would become = the "surveillance capitalist" model at the Internet Access level.=0A

 

=0A

And beyond those global issue= s, having my personal technical ability and integrity attacked in public by= well funded lobbyists in DC.

=0A

 

= =0A

So, Jason, since you brought it up, these are the stakes that we= re, and remain, in creating an Open, Neutral Internet access model.<= /p>=0A

 

=0A

 

=0A<= p style=3D"margin:0;padding:0;font-family: arial; font-size: 10pt; overflow= -wrap: break-word;">On Monday, November 15, 2021 9:21am, "Livingood, Jason"= <Jason_Livingood@comcast.com> said:

=0A=0A
=0A
=0A

> They may start MITM's https connections to read tr= affic

=0A

 

=0A

Unless they install certs= on client devices how are they going to attack the TLS connections?=

=0A

 

=0A

> They m= ay start blocking bittorrent because they claim it's all "piracy" and theft= .

=0A

 

=0A

FWIW, that was not why P2P con= nections were reset way back when. It was at root a bufferbloat issue, conf= ounded by a lot of bad responses to & misunderstandings of the issue at= that time. ;-)

=0A

=  

=0A

But you do rais= e an interesting point that what=E2=80=99s considered a reasonable network = management practice differs by type of access network =E2=80=93 which we ca= n see in the US between wired and wireless access network practices. What m= ay become standard practice in LEO access networks is still emerging I supp= ose.

=0A

 

=0A

> This always comes wit= h some argument that "bundling" a provider-controlled service

= =0A

 

=0A

I=E2=80=99d guess the fastest path to depl= oy a MVP was to keep the edge access device as simple as possible and not w= orry about testing lots of permutations. So getting to market with 1 device= makes sense IMO. What the future holds is anyone=E2=80=99s guess =E2=80=93= but ISTM they are still fairly early in deployment.

=0A

&nb= sp;

=0A

JL

=0A

 

=0A
=0A<= /div> ------=_20211115134537000000_71729--