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 protected]> Sent: Wednesday, July 24, 2024 3:02 AM To: Lorenzo Breda <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> 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 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]
