Subject: [DNSOP] Re: An Interplanetary DNS Model
From: Ben Schwartz <[email-masked]>
To: Scott Johnson <[email-masked]>, Lorenzo Breda <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 24 Jul 2024 13:46:48 +0000
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

It seems we have a terminology mismatch: segmented encryption that covers each network hop but requires re-encryption at some relays, as proposed, is the opposite of "end to end encryption".

Regardless, I do not think rewriting of domain names to append a supra-root hierarchy within the domain name syntax is a good solution for resource naming between semi-isolated networks.

The right solution will depend heavily on the social, political, and economic relationships between the users of these networks.  For space, these questions are matter of science fiction at present, and we should not regard them as standards questions until we start getting complaints from grumpy sysadmins on the moon.  Good standards are reactive, not speculative.

If you want to pursue standardization today, I recommend focusing on a use case, where proposed standards could be deployed to improve the lives of current users.  Improving the functionality of internet protocols for users riding in an elevator, driving on remote highways, camping in the wilderness, living in a submarine, or flying on the Tiangong space station, would be appropriate for the IETF.

--Ben
________________________________
From: Scott Johnson <[email-masked]>
Sent: Wednesday, July 24, 2024 3:02 AM
To: Lorenzo Breda <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [DNSOP] Re: An Interplanetary DNS Model

Hi Lorenzo,

I may have accidentally trimmed the lists from my previous reply, thanks
for reincluding them!

On Tue, 23 Jul 2024, Lorenzo Breda wrote:

> Il giorno mar 23 lug 2024 alle ore 08:16 Scott Johnson
> <[email-masked]> ha scritto:
>       Hi Lorenzo,
>
>       On Mon, 22 Jul 2024, Lorenzo Breda wrote:
>
>       > I don't like the way this system permits the same name to
>       refer to
>       > different resources on different planets.
>
>       It is not one of my favorite aspects either, but, at
>       present, it is the
>       only concept that will actually work that I am aware of.  I
>       look at it
>       like a phone call to another country.  One must first
>       prepend the country
>       code.  This is not necessary for calls made to the same
>       number from the
>       same country.
>
>
> Yes, but a lot of content we access on the Internet contains URIs. This
> proposed DNS system potentially lets me reach a web resource on the web
> from another planet, but the URIs referenced by the resource could be
> broken, could reference a legit different resource or could even be
> spoofed. The phone communication doesn't transmit phone numbers.

I see it this way: There will be IP networks on the Moon, and eventually
Mars.  This will be the case chiefly because a) the intrinsic "store and
forward" properties of BP, b) relativistic time dilation, and c)
unavoidable, variable clock skew all work against there being stable time,
or an equivalent of NTP to provide stable time for solely BP networks.
Time flows faster on the Moon. Atomic clocks in each device are expensive.
Still, a stable, synced time reference is required.  IP has that
functionality in NTP, and is a 0-gram payload upgrade.

Given that there this Lunar IP network will exist and face the "latency
barrier" from my previous post, as well as inherent security implications
as respects communicating via IP directly from Earth, we arrive at a
condition where there exist isolated IP networks on each world.
At present, I am aware of no other proposal to provide any IP level
interconnectivity between these two IP networks, much less one that scales
beyond the relatively small distance of Earth/Moon communications.

The need for a BP network between these "islands of IP" is apparent; more
so when considering scaling to Mars, Europa, Alpha Centauri, Sirius, or
where ever else we eventually go.  My work (almost 3 years in the making)
proposes a mechanism by which service requests can transit this BP
network.  Fundamentally, at present, we have a choice between the
evolution and development of what has been proposed, and no mechanism
whatsoever for IP interaction between these disparate networks.

Specific protocols and, to your point, data structures, will require
attention to be made fully functional.

Points have been made as to the lack of end to end confidentiality and
integrity in https application of this model.  While this is an issue that
bears discussion, segmented confidentiality and integrity does provide end
to end protection, however it does so using mechanisms appropriate to the
underlying network.  In a Earth/Mars transit, there are exactly two
times/places where cryptographic protection is not available
(notwithstanding terrestrial MiTM which can break relatively weak TLS in
realtime).  Both happen inside the appropriate IP/BP daemon(s) on the
gateway, on each end of the BP network.  I could see a proprietary gateway
being a problem for network users here; how could a user ensure that the
gateway vendor is not tapping this interprocess operation?  With a fully
open standard, this issue becomes moot, as open source implementations and
the ability to implement internally can ensure this is not the case.

Pardon the background tangent; I will now address your point regarding
valid URIs in one network becoming invalid URIs in another, and how this
can be addressed.  As noted above, there are two places, BP network
ingress and egress, in which there is a break in segmented
(HTTPS/IP<-BPSEC/BP->HTTPS/IP) protection.  It is at this place where
tampering could take place.  I don't see this as a bug, but a feature.
This is the place where we take the IP payload, turn it into a BP payload,
and extract data from the application headers to be placed in a BP
extension block, which is used to construct the remote request. This can
also be the place where .earth can be appended to any url in the body of
an email or web page, etc destined for somewhere other than Earth.  Don't
get me wrong;  I am no fan of deep packet inspection, or breaking privacy
or integrity.  This model is designed to ensure cryptographic protection
throughout the "on-wire" delivery, but operational constraints dictate
that this happens in a segmented fashion.

>
>
>       A suggestion was made to me by Shota Suzuki from the WIDE
>       project;
>       the idea being that we exclusively use new discrete TLDs on
>       other worlds
>       to disambiguate.  I find this suggestion interesting, if
>       Shota is willing to
>       expound upon it?
>
>       > It would probably be better
>       > to default on the Earth all the "old" TLDs, to avoid
>       breaking URIs.
>
>       I am not sure I understand your point here.  I understand
>       the complexity
>       and expense required to add TLDs to the terrestrial DNS
>       network in modern
>       times.  It has been noted that new TLD's on Earth need not
>       be created; 3rd
>       level domain mapping can also work.  That said, new TLDs
>       (moon, luna,
>       mars, europa, etc) which wildcard point to
>       gateways/exchanges are the only
>       change suggested to the terrestrial DNS system.  This model
>       allows
>       identical configurations (albeit with different root zone
>       data) everywhere
>       it is deployed.
>
>
> My point is avoiding the ambiguity. ietf.org would be the same resource
> both on the Earth and on Mars (referencing the Earth website).

As describe above, we can overcome this if the gateway can rewrite URIs in
the transmitted data in a well defined and protected way.  Thank you for
raising this quite valid point.

ScottJ

>
>
>       > This system is built to make planetary networks exchange
>       data, I'd
>       > avoid URIs contained in the data changing their meaning
>       in the process.
>
>       The local phone switch drops the country code or area code
>       extension upon
>       receipt.  I see this no differently... upon entering the BP
>       network, the
>       request metadata is trimmed to allow normal operation on
>       the remote end.
>       I am not married to this, but have not seen an alternate
>       proposal that
>       works.
>
>
> Again, not a fan of exchanging information that have a different
> meaning (URIs that reference different resources) on the two ends of
> the information exchange.
>
> --
> Lorenzo Breda
>
>