[Starlink] IXPs in space

Edwin Liava'a etuini.liavaa at gmail.com
Sun Apr 16 22:03:58 EDT 2023


Indeed an interesting and insightful discussion.

Tons of thanks to everyone for sharing.

Bravo!

On Mon, 17 Apr 2023 at 13:28, David P. Reed via Starlink <
starlink at lists.bufferbloat.net> wrote:

> David Fernandez and others here seem to have a *profound* misunderstanding
> of the core architecture of the Internet Protocols with respect to, say,
> Starlink.
>
>
>
> I am having a hard time sitting on my hands listening to this discussion,
> but hey, I just was one of the few people who spent a lot of time on the IP
> architecture, and maybe there are new, better ideas that we somehow missed.
> Clearly not.
>
>
>
> #1: There's a reason that the whole Internet is designed around "not
> putting extra functions" into the underlying network. It's outlined in a
> paper I wrote with Jerry Saltzer and David Clark, based on the work I did
> as part of the team that designed IP, TCP, and UDP, but abstracted as a
> principle of architecture. Please read the original paper carefully (and
> for goodness' sake don't read any of the Wikipedia pages that claim to
> explain the End-to-end principle or End=to-end argument, as a primary
> source I am actively barred from editing it and the paper, as a primary
> source, is viewed as suspect by Wikipedia, because Wikipedia requires that
> all citations be *secondary* sources).
> https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>
>
>
> #2: DNS service doesn't specify that "geolocation" is a function of the
> DNS service. It is the job of the endpoint *after resolving the DNS name to
> one of many IP addresses* to decide which IP address to use for the DNS
> name. That is, "geolocation" is an endpoint function, not something that
> the network does by spying on packet contents and faking a response from
> real DNS servers.
>
>
>
> #4: In general, IP as a protocol underlying ALL of the Internet protocols
> is required to deliver the content to the address specified by the sender,
> *without either reading or modifying the content*. There are certain cases
> where "masquerading" as the destination is sometimes OK, but ONLY when the
> sender and receiver are specifically AWARE of this interception. This is
> called a Man In The Middle *attack* otherwise.
>
>
>
> #5: As a special case, some IP addresses are "anycast", which has nothing
> to do with DNS itself as a protocol, but instead provides some low-level
> "neighborhood" addressing for a class of servers. Cloudflare uses 1.1.1.1,
> for example, as an "anycast" address supported by the global Internet
> Routing architecture (BGP, for example), that can be used as a DNS caching
> resolver (server) address. This works because the DNS database is designed
> to be replicatable, so one can cache subsets of the DNS database for short
> durations without problems, because the servers are "loosely" replicated.
> But"anycast" doesn't guarantee (anymore than DNS itself does) that the most
> up-to-date information is available at any particular anycast instance.
> 8.8.4.4 is another DNS anycast address of a different set of resolvers, and
> may be more up to date or less up to date than 1.1.1.1.
>
>
>
> #6: The idea that one can "identify" DNS requests by snooping on layer 2
> packets is so crazy it is not even wrong. Layer 2 packets have layer 2
> addresses (like Ethernet addresses, e.g.). Their contents above Layer 2
> cannot be decoded. My DNS requests are DNS-over-HTTPS, except within my
> home I cache the answers on a local server that uses DNS/UDP/IP. I
> certainly don't trust any Elon Musk corporation not to spy on my traffic.
>
>
>
> #7: The general idea that one should put more function into Starlink
> Satellites basically will start to "fork" Starlink Enterprises (the Musk
> companies) as an "alternate Internet" where applications must use only the
> functions that Starlink supports (where other Internet providers may
> support broader standards or not support the special "Starlink-only"
> functions). This is a way to balkanize the Internet, and maybe Musk who
> loves Monopoly Power after all because it makes him more Powerful, sees
> that as a great thing. Certainly the Chinese Communist Party is trying hard
> to balkanize a Chinese-only Internet, spending a lot of money to block
> interoperability. Musk may envy China, I don't know.
>
> If you want a Balkanized, non-interoperable Internet, where the carriers
> feel free to examine all the traffic and create their own,
> non-interoperable protocol set, I'd suggest China might be a good place to
> move. Or maybe Mars?
>
>
>
> Now what's a powerful idea in the Internet (so far) is that what prevents
> bad ideas like this is that the Internet interprets such stupid ideas as
> damage, and routes around them. But to route around them, the Internet has
> to be overall, *interoperable*.
>
>
>
> There's no law, and no "cryptocurrency" like Ethereum that prevents bad
> ideas that destroy interoperability, in the Internet Architecture. Anyone
> can invent and deploy a new protocol, and you can invent new layer 2
> transport technologies too. But I daresay we who built the Internet will
> make it very clear that anyone ought to "route around you" (including using
> you with a tunnal that you can't interfere with except by blocking all
> communications).
>
>
>
> So, my recommendation: don't do such dumb things!
>
>
> _______________________________________________
> Starlink mailing list
> Starlink at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Edwin Liava'a
WhatsApp: +61451013850
https://www.linkedin.com/in/edwin-liavaa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230417/c6b9eef3/attachment.html>


More information about the Starlink mailing list