On 12/29/2020 3:00 PM, 44net-request@mailman.ampr.org wrote:

Today's Topics: ... 7. Re: ipencap routing question -> What about the future ? (Toussaint OTTAVI)

I would like to comment briefly on several points made in this thread.

Has the 44NGN list been shut down? Concurrently with it being mentioned in this thread on this list, I received a message indicating I had been unsubscribed from that list.

If lurkers like myself, who post very rarely, only when we feel we really have something to add, are welcome on the TAC, I will apply.

Please take a look at the Host Identity Protocol (HIP) as one way of providing a persistent identity with a reputation (like a call sign) on the Internet, and dynamically establishing tunnels as needed to the corresponding IP addresses (despite changes due to DHCP or mobility).

_Inter alia_, this would obviate moving from a resilient flat mesh to a fragile, congestion-prone hierarchy.

It would also facilitate using 44 and non-44 addresses as needed.

It uses strong crypto to mutually authenticate endpoints.

Yes, HIP enables encryption, automagically establishing IPsec ESP tunnels, but it does not force encryption to be used _over the air_.

See these IETF documents (neither experimental nor obsoleted) on HIP:

RFC 4423 architecture RFC 5207 NAT firewall issues RFC 7401 HIPv2 protocol specification RFC 7402 ESP RFC 8002 certificates RFC 8003 registration extension RFC 8004 rendezvous extension RFC 8005 DNS extension RFC 8046 mobility RFC 8047 multicast

a draft addressing how to deal with the issues in RFC 5207 https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/

and especially the draft update to the 1st doc above https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/

I have a ton of other materials I am willing to share explaining how HIP deconflates identities ("names") from logical locations (IP addresses used for actual packet routing) in the Internet, and naturally integrates cryptographic authentication of said identities, thereby solving many of the problems with current practice that motivated the "clean slate Internet redesign" hype several years ago.

Our company has used it for lots of things, military and commercial, including mesh WANs.

Currently I am working with various standards development organizations, government agencies, commercial product and service providers, _et al_, to standardize/promote its use to identify observed [unmanned] aircraft (and other cyber-physical systems) in a trustworthy manner, enabling authorized observers to immediately establish mutually authenticated communications with the parties responsible for their safe operation.

There is 1 commercial product line that explicitly admits to being HIP based (some others formerly admitted that but no longer disclose the basis of their secret sauce): Tempered Networks https://discover.tempered.io/webinars/how-tempered-uses-hip-to-achieve-zero-...

There are 2 arguably usable open source implementations, one of which is being updated to HIPv2 and enhancements currently being standardized: OpenHIP https://bitbucket.org/openhip/openhip/branches/

73, AC2WH (long ago WB2IEP)