Re: [Starlink] something of a step backwards

Re: [Starlink] something of a step backwards

[David P. Reed]

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


I don't think StarLink will be an Internet Access Provider if it includes a bundled router that is sealed off with proprietary (even DMCA and FCC certification protection from modification).
 
I can see them taking control as folks like Comcast have tried to do - for example:
 
They may start MITM's https connections to read traffic and gather surveillance data on users' DNS and HTTP uses.
 
They may start blocking bittorrent because they claim it's all "piracy" and theft.
 
They may start charging differentially based on the type or endpoints of traffic.
 
They may start blocking countries' access geographically to other countries over Starlink.
 
This always comes with some argument that "bundling" a provider-controlled service will reduce "consumer price" (of course, monopolies rarely pass cost on in the form of minimized price, in reality, but when they talk to regulators, they lie and wave their hands about "economics" that conflates cost with price).
 
But those who are fans of satellites and love Elon Musk to death because he's a "hero" will not worry about these things, even though in the past that is exactly what has happened.
 
So, you'll buy into what you buy into. Just don't say I didn't tell you this will happen.
 

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

Re: [Starlink] something of a step backwards

[Livingood, Jason]

[-- Attachment #1: Type: text/plain, Size: 1181 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?



> 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: 3576 bytes --]

Re: [Starlink] something of a step backwards

[David P. Reed]

[-- 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 --]

Re: [Starlink] something of a step backwards

[Michael Richardson]

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


David P. Reed <dpreed@deepplum.com> wrote:
    > 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.

No, this is just not the case.
While there are occasionally issues that affect some strange corner case,
there are no issues in browsers available on any platforms I know of.

It can only be done in Enterprise cases where the Enterprise uses a
management system to push new anchors.  That part is "well-known".

As for blaming protocols when the fault is bufferbloat, you are definitely
right on.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[Starlink] something of a step backwards

[Dave Taht]

The new "squary" doesn't let you use your own router. Sigh. There is
so much more you can do with control of your own firewall and
router...

https://twitter.com/awlnx/status/1458786406722121742

sure hope they got all the bufferbloat-fighting algos in the uplink,
wifi, and ethernet, in there, and ipv6 support.

-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC

Re: [Starlink] something of a step backwards

[Nathan Owens]

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

My guess is they moved the "smarts" from the dish to the router, so no net
change.

On Thu, Nov 11, 2021 at 7:54 AM Dave Taht <dave.taht@gmail.com> wrote:

> The new "squary" doesn't let you use your own router. Sigh. There is
> so much more you can do with control of your own firewall and
> router...
>
> https://twitter.com/awlnx/status/1458786406722121742
>
> sure hope they got all the bufferbloat-fighting algos in the uplink,
> wifi, and ethernet, in there, and ipv6 support.
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

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

Re: [Starlink] something of a step backwards

[Jonathan Bennett]

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

They are putting the PoE supply in the router -- no more power brick. I
suppose it's too much to hope that they cut power draw enough to use
standardized PoE++ equipment. They do offer an add-on Ethernet adapter, and
have promised a bridged mode. That at least gets us back to the
functionality we have now.

On Thu, Nov 11, 2021, 9:55 AM Nathan Owens <nathan@nathan.io> wrote:

> My guess is they moved the "smarts" from the dish to the router, so no net
> change.
>
> On Thu, Nov 11, 2021 at 7:54 AM Dave Taht <dave.taht@gmail.com> wrote:
>
>> The new "squary" doesn't let you use your own router. Sigh. There is
>> so much more you can do with control of your own firewall and
>> router...
>>
>> https://twitter.com/awlnx/status/1458786406722121742
>>
>> sure hope they got all the bufferbloat-fighting algos in the uplink,
>> wifi, and ethernet, in there, and ipv6 support.
>>
>> --
>> I tried to build a better future, a few times:
>> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>>
>> Dave Täht CEO, TekLibre, LLC
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

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