Hi Lorenzo,
On Wed, 24 Jul 2024, Lorenzo Breda wrote:
Il giorno mer 24 lug 2024 alle ore 09:02 Scott Johnson
<[email protected]> ha scritto:
Hi Lorenzo,
[omissis]
Pardon the background tangent;
It was pretty interesting.
Glad you enjoyed it.
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,
Pretty simple since a BP enabled IP listener for each service we want to
support will need to be crafted, i.e. the BP enabled MTA will understand
that it is receiving SMTP destined for a different world.
it would
be break signatures (eg on API payloads and on emails,
Funny you should mention email, as I am in the process of constructing a
working implementation in a dedicated multi-world simulation network. I
don't see smtp to be so difficult. The rest of the more modern functions
tangental to smtp, like DMARC, smtps, etc. can come after this return to
first principles.
API payloads? Via what delivery? http(s)? Not breaking that would come
down to good parsing. As I have said before, attention will be required
to individual protocols we wish to make work across these networks. Do
not expect the full level of functionality you enjoy on low latency, high
speed, reliable links on Earth; at least initially.
which both are
useful applications on the system you described
- emails are
unexpectedly surviving any evolution of the Internet)
Exactly, and e-mail to the Moon is a near term goal.
and it wouldn't
work on transmissions which are encrypted on a message level (encrypted
documents, emails).
Again, users who are encrypting messages will understand the "country
code" analogy, IMHO. It is rocket science, after all :)
Why are you against leaving the current TLDs implicitly on Earth by
default?
Why do you think I am. Just to be sure, can you expound on what that
means, exactly? Use only new, discrete TLDs on other worlds? I have no
problem with that. I have already been willing to back off a new TLD on
Earth because of the cost/paperwork/etc necessary. Given that we can map
3rd level domains to the same hierarchy to access off world resources,
with no change necessary to the terrestrial DNS, it was a technical
solution that worked and prevented having to run the ICANN gauntlet
with a dump truck full of cash.
If someone provides a few paragraphs on this proposal, and what it means,
I will be happy to amend the draft and acknowledge the contribution, if
it passes technical muster. I almost never object to well explained good
ideas :)
Scott
--
Lorenzo Breda
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
