> Le 24 juill. 2024 à 11:42, Lorenzo Breda <[email protected]> a écrit : > > > > Il giorno mer 24 lug 2024 alle ore 09:02 Scott Johnson > <[email protected] <mailto:[email protected]>> ha scritto: >> Hi Lorenzo, >> >> [omissis] >> >> Pardon the background tangent; > > It was pretty interesting. > >> 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. > > Deep packet inspection is a technical issue, rather than a "merely" > governance one. The inspection/correction system would need to have a pretty > good knowledge about the structure of the transmission, it would be break > signatures (eg on API payloads and on emails, which both are useful > applications on the system you described - emails are unexpectedly surviving > any evolution of the Internet) and it wouldn't work on transmissions which > are encrypted on a message level (encrypted documents, emails). > > Why are you against leaving the current TLDs implicitly on Earth by default?
Right. One do not need a special TLD for space. We can use what we have and it just works fine. One has just to be careful on remote resolution so that it contains what is needed: trust chain, local names, ... This is discussed in: - running IP in deep space (no BP<->IP): https://www.ietf.org/archive/id/draft-many-deepspace-ip-assessment-01.txt - running DNS in remote places: https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-01.txt Regards, Marc. > > -- > Lorenzo Breda > _______________________________________________ > dtn mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
