[DNSOP] Re: An Interplanetary DNS Model

Scott Johnson <scott@spacelypackets.com> Wed, 24 July 2024 07:04 UTC

Return-Path: <scott@spacelypackets.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38939C1E725E; Wed, 24 Jul 2024 00:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6gJnFz0NpiP; Wed, 24 Jul 2024 00:04:10 -0700 (PDT)
Received: from www.spacelypackets.com (www.spacelypackets.com [IPv6:2602:fdf2:bee:feed::ee]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADE7C14F605; Wed, 24 Jul 2024 00:04:07 -0700 (PDT)
Received: from scott (helo=localhost) by www.spacelypackets.com with local-esmtp (Exim 4.96) (envelope-from <scott@spacelypackets.com>) id 1sWW0m-0006gB-0N; Wed, 24 Jul 2024 07:02:08 +0000
Date: Wed, 24 Jul 2024 07:02:08 +0000
From: Scott Johnson <scott@spacelypackets.com>
To: Lorenzo Breda <lorenzo@lbreda.com>
In-Reply-To: <CAEhHO_P4VmCC0VfxHRPdnvUzzwamMThbcuQAp1N98yWTCd-Bsg@mail.gmail.com>
Message-ID: <0685c4ca-0b10-d7a8-ccd4-507dc6755d1a@spacelypackets.com>
References: <65daf988-f696-4f35-5a72-5b11ef4893b8@spacelypackets.com> <CAEhHO_MaUFraCuur2uYEBrRcdKUty3ZwoPsFeP3V1iXf5vQxxA@mail.gmail.com> <b098f7cb-e42b-c7e4-56b8-dcb9125c17e9@spacelypackets.com> <CAEhHO_P4VmCC0VfxHRPdnvUzzwamMThbcuQAp1N98yWTCd-Bsg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="-2112415152-1632338382-1721804528=:31297"
Message-ID-Hash: 4ODPZVYB3YSZFYHEYIKDIM2YE35NMAUO
X-Message-ID-Hash: 4ODPZVYB3YSZFYHEYIKDIM2YE35NMAUO
X-MailFrom: scott@spacelypackets.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dtn@ietf.org, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: An Interplanetary DNS Model
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Nef6JbjN4hcfRVQZOeN8u2Ha4yw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

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
> <scott@spacelypackets.com> 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
> 
>