[DNSOP] Re: An Interplanetary DNS Model

[Scott Johnson <[e-mail]>]

Hi Ben,

On Wed, 24 Jul 2024, Ben Schwartz wrote:

> 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".

Right, but end to end confidentiality and integrity can be achieved in a 
segmented approach.

> 
> 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.

I would challenge the notion of these being semi-isolated networks.  I 
would also challenge the notion that we need to perform this task for the 
users, but I am happy to offer a solution _if_ we have to.  People know to 
dial 1 before a long distance number.  They will figure out hey have to 
append .mars if they wish to access a resource on Mars which came linked 
in an email.

> 
> 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,

Were you privy to what I am privy to, you would not make that assertion. 
You may find that your situational awareness related to this matter is 
incomplete.  You will note that DTN, which was primarily chartered to 
standardize protocols for space networking (in parallel with CCSDS), is 
copied in addition to DNSOP.

> and we should
> not regard them as standards questions until we start getting
> complaints from grumpy sysadmins on the moon. 

Space just does not work that way.  Missions are planned out years in 
advance, based on the technology that is either available or which can be 
developed within the window to completion.  The situation is now more 
complex, as there are many commercial participants, each with their own 
ideas and requirements, yet a desire for interoperability.  I regularly 
participate in meetings that work through use cases which are not 
hypothetical, but real problems faced by real operators today.  That is 
the closest equivalent to grumpy sysadmins on the moon that hopefully we 
ever see; grumpy engineers planning out interoperabilty.

> Good standards are
> reactive, not speculative.

If that is your opinion, you are welcome to it.  It does not match the 
reality of space communications, unfortunately.  Further, if you wish to 
be reactive, as opposed to proactive, then I will happily sieze the 
opportunity you fail to see coming.

> 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. 

I have dozens, produced by stakeholders, waiting in queue at a widely 
diverse thinktank dedicated to this effort.  Would you be interested in 
working some of those to better your understanding of the situation?

> 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.

My first IETF was 2002 in Atlanta, how about you?  Sorry, I am not really 
interested in working the network edges you indicate at this time, 
although I understand they may be a priority for your employer.  At 
present, I am busy implementing a solution to a problem that few know 
exists.

I have spent a good share of my career bridging the digital divide in very 
remote locations across the world, extending that edge to connect the 
unconnected in some of the worlds least wealthy places.  I have another 
draft on that effort coming soon, but that is an IRTF draft, chiefly on 
how to drive down the power load of the network so it is suitable for 
operation solely from renewable energy.  Go ahead and react, if you like. 
I act proactively, ahead of time, because I know what is coming ;)

ScottJ



> 
> --Ben
> 
> _______________________________________________________________________
> From: Scott Johnson <[e-mail]>
> Sent: Wednesday, July 24, 2024 3:02 AM
> To: Lorenzo Breda <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> 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
> > <[e-mail]> 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
> >
> >
> 
>