From: "Edwin Liava'a" <etuini.liavaa@gmail.com>
To: "David P. Reed" <dpreed@deepplum.com>
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] IXPs in space
Date: Mon, 17 Apr 2023 15:03:58 +1300 [thread overview]
Message-ID: <CAGyzPqm+kAqkQCosfGOR_guUppoAngbEi-7JsCfnhE9XZUJNag@mail.gmail.com> (raw)
In-Reply-To: <1681691279.13362849@apps.rackspace.com>
[-- Attachment #1: Type: text/plain, Size: 5593 bytes --]
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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>
--
Edwin Liava'a
WhatsApp: +61451013850
https://www.linkedin.com/in/edwin-liavaa
[-- Attachment #2: Type: text/html, Size: 8159 bytes --]
next prev parent reply other threads:[~2023-04-17 2:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.711.1681684935.1222.starlink@lists.bufferbloat.net>
2023-04-17 0:27 ` David P. Reed
2023-04-17 0:40 ` Hesham ElBakoury
2023-04-17 1:06 ` David Lang
2023-04-17 1:57 ` Ulrich Speidel
2023-04-17 2:03 ` Edwin Liava'a [this message]
2023-04-17 14:22 David Fernández
2023-04-17 18:55 ` David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGyzPqm+kAqkQCosfGOR_guUppoAngbEi-7JsCfnhE9XZUJNag@mail.gmail.com \
--to=etuini.liavaa@gmail.com \
--cc=dpreed@deepplum.com \
--cc=starlink@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox