From: Marc Blanchet <marc.blanchet@viagenie.ca>
Message-Id: <41A7771E-8D08-4272-B457-F9FE61CD77A3@viagenie.ca>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E8B15D10-D774-4FD1-AB70-CE2405CA907F"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3814.100.5\))
Date: Wed, 24 Jul 2024 11:50:58 -0700
In-Reply-To: 
 <CAEhHO_PbrkKqaJsBD+Fih+i1rY5YN+9=Y-fNUpOp2PfXL+hAuA@mail.gmail.com>
To: Lorenzo Breda <lorenzo@lbreda.com>
References: <65daf988-f696-4f35-5a72-5b11ef4893b8@spacelypackets.com>
 <CAEhHO_MaUFraCuur2uYEBrRcdKUty3ZwoPsFeP3V1iXf5vQxxA@mail.gmail.com>
 <b098f7cb-e42b-c7e4-56b8-dcb9125c17e9@spacelypackets.com>
 <CAEhHO_P4VmCC0VfxHRPdnvUzzwamMThbcuQAp1N98yWTCd-Bsg@mail.gmail.com>
 <0685c4ca-0b10-d7a8-ccd4-507dc6755d1a@spacelypackets.com>
 <CAEhHO_PbrkKqaJsBD+Fih+i1rY5YN+9=Y-fNUpOp2PfXL+hAuA@mail.gmail.com>
Message-ID-Hash: Z3ZIABRGJ3U52RFBLYCIQX624JOIPXER
CC: Scott Johnson <scott@spacelypackets.com>, DTN WG <dtn@ietf.org>,
 dnsop <dnsop@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BDNSOP=5D_Re=3A_=5Bdtn=5D_An_Interplanetary_DNS_Model?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/dnsop/SsONWeAekXWqell9TFCbk9i-yoI>


--Apple-Mail=_E8B15D10-D774-4FD1-AB70-CE2405CA907F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 24 juill. 2024 =C3=A0 11:42, Lorenzo Breda <lorenzo@lbreda.com> a =
=C3=A9crit :
>=20
>=20
>=20
> Il giorno mer 24 lug 2024 alle ore 09:02 Scott Johnson =
<scott@spacelypackets.com <mailto:scott@spacelypackets.com>> ha scritto:
>> Hi Lorenzo,
>>=20
>> [omissis]
>>=20
>> Pardon the background tangent;
>=20
> It was pretty interesting.
> =20
>> I will now address your point regarding=20
>> valid URIs in one network becoming invalid URIs in another, and how =
this=20
>> can be addressed.  As noted above, there are two places, BP network=20=

>> ingress and egress, in which there is a break in segmented=20
>> (HTTPS/IP<-BPSEC/BP->HTTPS/IP) protection.  It is at this place where=20=

>> tampering could take place.  I don't see this as a bug, but a =
feature.=20
>> This is the place where we take the IP payload, turn it into a BP =
payload,=20
>> and extract data from the application headers to be placed in a BP=20
>> extension block, which is used to construct the remote request. This =
can=20
>> also be the place where .earth can be appended to any url in the body =
of=20
>> an email or web page, etc destined for somewhere other than Earth.  =
Don't=20
>> get me wrong;  I am no fan of deep packet inspection, or breaking =
privacy=20
>> 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.
>=20
> 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).
>=20
> 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.


>=20
> --
> Lorenzo Breda
> _______________________________________________
> dtn mailing list -- dtn@ietf.org
> To unsubscribe send an email to dtn-leave@ietf.org


--Apple-Mail=_E8B15D10-D774-4FD1-AB70-CE2405CA907F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Le 24 juill. 2024 =C3=A0 11:42, Lorenzo Breda =
&lt;lorenzo@lbreda.com&gt; a =C3=A9crit :</div><br =
class=3D"Apple-interchange-newline"><div><div dir=3D"ltr"><div =
dir=3D"ltr"><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">Il giorno mer 24 lug 2024 alle ore 09:02 Scott =
Johnson &lt;<a =
href=3D"mailto:scott@spacelypackets.com">scott@spacelypackets.com</a>&gt; =
ha scritto:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div>Hi Lorenzo,<br>
<br></div>[omissis]<br><div>
<br>
Pardon the background tangent;</div></blockquote><div><br></div><div>It =
was pretty interesting.<br></div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div> I will now address your =
point regarding <br>
valid URIs in one network becoming invalid URIs in another, and how this =
<br>
can be addressed.&nbsp; As noted above, there are two places, BP network =
<br>
ingress and egress, in which there is a break in segmented <br>
(HTTPS/IP&lt;-BPSEC/BP-&gt;HTTPS/IP) protection.&nbsp; It is at this =
place where <br>
tampering could take place.&nbsp; I don't see this as a bug, but a =
feature. <br>
This is the place where we take the IP payload, turn it into a BP =
payload, <br>
and extract data from the application headers to be placed in a BP <br>
extension block, which is used to construct the remote request. This can =
<br>
also be the place where .earth can be appended to any url in the body of =
<br>
an email or web page, etc destined for somewhere other than Earth.&nbsp; =
Don't <br>
get me wrong;&nbsp; I am no fan of deep packet inspection, or breaking =
privacy <br>
or integrity.&nbsp; This model is designed to ensure cryptographic =
protection<br>
throughout the "on-wire" delivery, but operational constraints =
dictate<br>
that this happens in a segmented =
fashion.<br></div></blockquote><div><br></div><div>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).</div></div><div><br></div><div>Why are you against =
leaving the current TLDs implicitly on Earth by =
default?<br></div></div></div></blockquote><div><br></div><div>Right.&nbsp=
;<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">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, =
...</span></div><div><br></div><div>This is discussed in:</div><div>- =
running IP in deep space (no BP&lt;-&gt;IP):&nbsp;<a =
href=3D"https://www.ietf.org/archive/id/draft-many-deepspace-ip-assessment=
-01.txt">https://www.ietf.org/archive/id/draft-many-deepspace-ip-assessmen=
t-01.txt</a></div><div>- running DNS in remote places: &nbsp;<a =
href=3D"https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-netw=
orks-01.txt">https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated=
-networks-01.txt</a></div><div><br></div><div><br></div><div>Regards, =
Marc.</div><div><br></div><br><blockquote type=3D"cite"><div><div =
dir=3D"ltr"><div><br></div><span class=3D"gmail_signature_prefix">-- =
</span><br><div dir=3D"ltr" class=3D"gmail_signature">Lorenzo =
Breda</div></div>
_______________________________________________<br>dtn mailing list -- =
dtn@ietf.org<br>To unsubscribe send an email to =
dtn-leave@ietf.org<br></div></blockquote></div><br></body></html>=

--Apple-Mail=_E8B15D10-D774-4FD1-AB70-CE2405CA907F--