From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B2A403B2A4 for ; Thu, 3 Mar 2022 18:34:27 -0500 (EST) Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 279A7196C; Thu, 3 Mar 2022 18:34:27 -0500 (EST) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app11.wa-webapps.iad3a (Postfix) with ESMTP id 138CAA1A19; Thu, 3 Mar 2022 18:34:27 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 3 Mar 2022 18:34:27 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Thu, 3 Mar 2022 18:34:27 -0500 (EST) From: "David P. Reed" To: "Dave Taht" Cc: "cerowrt-devel" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20220303183427000000_89184" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1646350467.076919782@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: 66d163f0-77c9-4fdd-8de9-dba794ede413-1-1 Subject: Re: [Cerowrt-devel] I wish we had a good definition of mesh X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2022 23:34:27 -0000 ------=_20220303183427000000_89184 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AI have avoided using the term "mesh networks" for a reason. It's way too= broad already. This also goes for "ad hoc networking" (which was supposedl= y what MANET was about, but the instigators didn't think very clearly about= what the possibilities were - they focused on what "tactical warfighters" = might use in the field only.)=0A =0AGetting to the particulars quickly is f= ar better than creating some kind of "umbrella" term that can be distorted = and confused. Here's two problems with "mesh" as used by others.=0A =0A1) i= t is often assumed that the nodes of a mesh are standardized and all the sa= me. To be this focuses on the wrong problem - it's like talking about 10bas= eT networks as if they are distinct and necessary. Or 802.11. While I can i= magine that in some ways it might be simpler to design a uniformly identica= l set of mesh hardware, the "layers on top" of such a platform at NOT unifo= rm in their requirements. So why stultify what is only one of many underlyi= ng solutions.=0A =0A2) It is often assumed that the "network is intelligent= " unto itself. Often this leads to a design that puts a "control plane" int= o the mesh. There are reasons to have mesh node *protocols* coordinate, but= only those things that are truly necessary. And those can't be predicted a= t design time, not at all.=0A =0AThat's why this "constellation project" se= ems to be of limited value. It reminds me of the ARPA BCR crypto based netw= ork security project. It was the *sole* investment in network security by A= RPA at the time when Vint was the program manager. It wasn't a bad concept = (but all the solution space was narrowed to NSA's beliefs at the time that = the only crypto that could be used for security was a link layer protection= with a sealed black box to which keys had to be periodically distributed. = End-to-end security (which required software encryption and much more decen= tralized key distribution, among other things) was actually *ruled out* by = ARPA as valuable. So BBN built the BCR boxes, spec'ed how to install them o= n, say, the Internet links, and may have even pointed out that inside route= rs the data was en clair, so this required all routers to be guarded to the= level needed to protect the most critical communications. I've never under= stood deeply why my work and Steve Kent's and Roger Needham's and Mike Schr= oeder's work on end-to-end security in the context of the TCP protocol and = UDP was not supported. Steve and I offered to include a complete solution f= or TCP that he had done with me involved a little bit, and we were told to = stop working on it. (partly for national security reasons, but actually sin= ce it offended NSA's rules of thumb).=0A=0AAs a *research* project, learnin= g to use lasers among LEO satellites seems appropriate, but this is NOT pro= posed as research. It seems like DoD thinks the problem is solved already. = I am very sure it is NOT solved. It's like a grand project from the securit= y sector a few years ago where I tried to help - the so-called National Cyb= er Range and its test platform (hardware and opearting environment). Again,= what should have started with R&D, but was instead put out for bid prematu= rely as if a working system could be built and demonstrated. The idea being= proposed by the teams was the idea of using lots of virtual machines in a = cloud to simulate any and all government IT uses and any and all attacks. N= ow Virtual Machines are not real hardware, so simulating seucrity vulnerabi= lities of real hardware in them is either a bear of a research problem yet = to be solved, or you have to define the problems of real life (like Microso= ft Windows running on real laptops throughout the world in DoD, Dept of Sta= te, and even just the gear in the pentagon) as not existing except to the e= xtent that you can build models inside a cloud.=0A =0AAnyway, that's a dist= raction. The USG wastes a hell of a lot of money with these kinds of boondo= ggles.=0A =0AAnyway, if you have a bunch of satellites up there with lasers= and are willing to plan to throw the first prototype away, you'll get real= ly good results from smart engineers.=0A =0AI suspect this project will exp= lain why Iridium, the first space "mesh", might want to be viewed as what c= onstitutes a "mesh", and to choose a new name entirely.=0A =0AMy term for w= hat would be far more interesting (except it isn't focused on hardware at a= ll) is a "near earth Internet". That is, a set of protocols and operating m= ethods that don't specify the hardware at all, but which can incorporate in= a scalable way a huge variety of hardware on the earth and in LEO and even= on non-orbital space vehicles, assuming distances on the order of "light m= illiseconds" are achieved among the nodes.=0A =0ABut hey, that's what they = did at Guifi and Porto. Mix and match and make something that is robustly i= ndependent of the underlying hardware.=0A =0AInstead, yet another boondoggl= e. Let it be called a "mesh" because that sounds futuristic.=0A =0AOn Tuesd= ay, March 1, 2022 9:47pm, "Dave Taht" said:=0A=0A=0A= =0A> https://spacenews.com/lockheed-martin-northrop-grumman-york-space-sele= cted-to-build-dods-internet-in-space-constellation/=0A> =0A> --=0A> I tried= to build a better future, a few times:=0A> https://wayforward.archive.org/= ?site=3Dhttps%3A%2F%2Fwww.icei.org=0A> =0A> Dave T=C3=A4ht CEO, TekLibre, L= LC=0A> _______________________________________________=0A> Cerowrt-devel ma= iling list=0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists.buffer= bloat.net/listinfo/cerowrt-devel=0A> ------=_20220303183427000000_89184 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have avoided using t= he term "mesh networks" for a reason. It's way too broad already. This also= goes for "ad hoc networking" (which was supposedly what MANET was about, b= ut the instigators didn't think very clearly about what the possibilities w= ere - they focused on what "tactical warfighters" might use in the field on= ly.)

=0A

 

=0A

Getting t= o the particulars quickly is far better than creating some kind of "umbrell= a" term that can be distorted and confused. Here's two problems with "mesh"= as used by others.

=0A

 

=0A

1) it is often assumed that the nodes of a mesh are standardized and = all the same. To be this focuses on the wrong problem - it's like talking a= bout 10baseT networks as if they are distinct and necessary. Or 802.11. Whi= le I can imagine that in some ways it might be simpler to design a uniforml= y identical set of mesh hardware, the "layers on top" of such a platform at= NOT uniform in their requirements. So why stultify what is only one of man= y underlying solutions.

=0A

 

=0A

2) It is often assumed that the "network is intelligent" unto its= elf. Often this leads to a design that puts a "control plane" into the mesh= . There are reasons to have mesh node *protocols* coordinate, but only thos= e things that are truly necessary. And those can't be predicted at design t= ime, not at all.

=0A

 

=0A

That's why this "constellation project" seems to be of limited value. It= reminds me of the ARPA BCR crypto based network security project. It was t= he *sole* investment in network security by ARPA at the time when Vint was = the program manager. It wasn't a bad concept (but all the solution space wa= s narrowed to NSA's beliefs at the time that the only crypto that could be = used for security was a link layer protection with a sealed black box to wh= ich keys had to be periodically distributed. End-to-end security (which req= uired software encryption and much more decentralized key distribution, amo= ng other things) was actually *ruled out* by ARPA as valuable. So BBN built= the BCR boxes, spec'ed how to install them on, say, the Internet links, an= d may have even pointed out that inside routers the data was en clair, so t= his required all routers to be guarded to the level needed to protect the m= ost critical communications. I've never understood deeply why my work and S= teve Kent's and Roger Needham's and Mike Schroeder's work on end-to-end sec= urity in the context of the TCP protocol and UDP was not supported. Steve a= nd I offered to include a complete solution for TCP that he had done with m= e involved a little bit, and we were told to stop working on it. (partly fo= r national security reasons, but actually since it offended NSA's rules of = thumb).

As a *research* project, learning to use lasers among LE= O satellites seems appropriate, but this is NOT proposed as research. It se= ems like DoD thinks the problem is solved already. I am very sure it is NOT= solved. It's like a grand project from the security sector a few years ago= where I tried to help - the so-called National Cyber Range and its test pl= atform (hardware and opearting environment). Again, what should have starte= d with R&D, but was instead put out for bid prematurely as if a working= system could be built and demonstrated. The idea being proposed by the tea= ms was the idea of using lots of virtual machines in a cloud to simulate an= y and all government IT uses and any and all attacks. Now Virtual Machines = are not real hardware, so simulating seucrity vulnerabilities of real hardw= are in them is either a bear of a research problem yet to be solved, or you= have to define the problems of real life (like Microsoft Windows running o= n real laptops throughout the world in DoD, Dept of State, and even just th= e gear in the pentagon) as not existing except to the extent that you can b= uild models inside a cloud.

=0A

 

=0A

Anyway, that's a distraction. The USG wastes a hell of a lot = of money with these kinds of boondoggles.

=0A

 =

=0A

Anyway, if you have a bunch of satellites up th= ere with lasers and are willing to plan to throw the first prototype away, = you'll get really good results from smart engineers.

=0A

 

=0A

I suspect this project will explain = why Iridium, the first space "mesh", might want to be viewed as what consti= tutes a "mesh", and to choose a new name entirely.

=0A

 

=0A

My term for what would be far more int= eresting (except it isn't focused on hardware at all) is a "near earth Inte= rnet". That is, a set of protocols and operating methods that don't specify= the hardware at all, but which can incorporate in a scalable way a huge va= riety of hardware on the earth and in LEO and even on non-orbital space veh= icles, assuming distances on the order of "light milliseconds" are achieved= among the nodes.

=0A

 

=0A

But hey, that's what they did at Guifi and Porto. Mix and match and mak= e something that is robustly independent of the underlying hardware.

=0A=

 

=0A

Instead, yet another= boondoggle. Let it be called a "mesh" because that sounds futuristic.

= =0A

 

=0A

On Tuesday, March= 1, 2022 9:47pm, "Dave Taht" <dave.taht@gmail.com> said:

<= /p>=0A

=0A

> https:/= /spacenews.com/lockheed-martin-northrop-grumman-york-space-selected-to-buil= d-dods-internet-in-space-constellation/
>
> --
> I= tried to build a better future, a few times:
> https://wayforward.= archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org
>
> Dave T= =C3=A4ht CEO, TekLibre, LLC
> _____________________________________= __________
> Cerowrt-devel mailing list
> Cerowrt-devel@lis= ts.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt= -devel
>

=0A
 ------=_20220303183427000000_89184--