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 protected]> 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
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
