Re: [Starlink] something of a step backwards

["David P. Reed" <dpreed@deepplum.com>]

[-- Attachment #1: Type: text/plain, Size: 4900 bytes --]


>> They may start MITM's https connections to read traffic
 
> Unless they install certs on client devices how are they going to attack the TLS connections?
I don't know what is the current state of practice, but last time I looked, GoGo Internet was MITM'ing with packet content inspection in order to block "streaming" from passenger seats. This was justified by GoGo claiming that it was the ONLY way 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 passengers sharing the connection. (And streaming would have had to run at very long latencies due to "fairness", essentially making Netflix impossible.
 
I don't know if this was ignorance on GoGo's part, or intent to continue to act as a MITM.
 
The mechanism 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 by client-end software and server-end software.
 
> FWIW, that was not why P2P 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. ;-)
 
By stating it was "bad responses" this covers up the entire Comcast fiasco, which led me to testify before an FCC En Banc on Network Management.
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 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).
 
Comcast PR made up a story that the "real problem" was BitTorrent use, because BitTorrent could, in fact, generate lots of upstream traffic. Which smelled funny, because if there was congestion, BitTorrent actually responded to TCP congestion control metrics. What was happening was, instead, that DOCSIS 2.0 had the ability to turn off packet drops entirely, instead allowing a single home to fill the entire outbound traffic path.
 
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 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 equipment to ALL ISPs in the world; and b) a push by all ISPs to claim that network management 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 about the content of each subscriber's Internet to emulate what would become the "surveillance capitalist" model at the Internet Access level.
 
And beyond those global issues, having my personal technical ability and integrity attacked in public by well funded lobbyists in DC.
 
So, Jason, since you brought it up, these are the stakes that were, and remain, in creating an Open, Neutral Internet access model.
 
 
On Monday, November 15, 2021 9:21am, "Livingood, Jason" <Jason_Livingood@comcast.com> said:




> They may start MITM's https connections to read traffic 
 
Unless they install certs on client devices how are they going to attack the TLS connections?
 
> They may start blocking bittorrent because they claim it's all "piracy" and theft.
 
FWIW, that was not why P2P 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. ;-) 
 
But you do raise an interesting point that what’s considered a reasonable network management practice differs by type of access network – which we can see in the US between wired and wireless access network practices. What may become standard practice in LEO access networks is still emerging I suppose.
 
> This always comes with some argument that "bundling" a provider-controlled service 
 
I’d guess the fastest path to deploy a MVP was to keep the edge access device 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’s guess – but ISTM they are still fairly early in deployment. 
 
JL
 

[-- Attachment #2: Type: text/html, Size: 13236 bytes --]