commit 167f106b942033b1ef00c0e7671f85df3a78dd63
parent c7d358ba45257b304f34b52b44ba505469e4e2ee
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sun, 20 Aug 2023 14:48:55 +0200
add text to point out key objective differences to RELOAD
Diffstat:
1 file changed, 50 insertions(+), 27 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -101,32 +101,9 @@
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
- <!--
- 2022/12/23 MSC: I moved references to rfc6940 to security considerations.
- I think we should talk about R5N in the positive here only, not about
- RELOAD in the negative.
-
- - Lean. Can be implemented. Not overengineered.
- - Path tracking (more difficult) -> Not built in
- - Certificates central server ?
- - "self-signed certificates can be used in closed networks."
- - "Security Framework: A P2P network will often be established among a
- set of peers that do not trust each other. RELOAD leverages a
- central enrollment server to provide credentials for each peer,
- which can then be used to authenticate each operation. This
- greatly reduces the possible attack surface." bizarre statement.
- - For a PUT, reload requires that
- "Each element is signed by a credential which is authorized to
- write this Kind at this Resource-ID. If this check fails, the
- request <bcp14>MUST</bcp14> be rejected with an Error_Forbidden error."
- -->
- <!--FIXME: Here we should also cite and discuss RELOAD (https://datatracker.ietf.org/doc/html/rfc6940)
- and establish why we need this spec and are not a "Topology plugin"
- in RELOAD. The argumentation revolves around the trust model (openness) and
- security aspects (path signatures).-->
<t>
This specification describes the protocol of R<sup>5</sup>N.
- R<sup>5</sup>N is a Distributed Hash Table (DHT) is an acronym for
+ R<sup>5</sup>N is a Distributed Hash Table (DHT). The name is an acronym for
"randomized recursive routing for restricted-route
networks" and its first academic description can be found in
<xref target="R5N"/>.
@@ -144,7 +121,8 @@
routing complexity.
</t>
<t>
- R<sup>5</sup>N also includes advanced features like tracing paths messages take
+ R<sup>5</sup>N also includes advanced features like recording the path a
+ key-value pair took
through the network, response filters and on-path application-specific data
validation.
</t>
@@ -163,6 +141,50 @@
when, they appear in all capitals, as shown here.
</t>
</section>
+ <section numbered="true" toc="default">
+ <name>Key differences to RELOAD (<xref target="RFC6940"/>)</name>
+ <t>
+ <xref target="RFC6940"/> specifies the RELOAD DHT. The R<sup>5</sup>N DHT
+ described in this document differs from RELOAD in its objectives
+ and thus in its design. R<sup>5</sup>N is intended for open
+ overlay networks, and thus does not include a central enrollment server to
+ certify participants. As participants could be malicious, R<sup>5</sup>N
+ includes on-path customizable key-value validation to delete malformed
+ data and path randomiziation
+ to help evade malicious peers. R<sup>5</sup>N also expects to perform
+ over a network where not each peer can communicate with every other peer,
+ and where thus its route discovery feature provides utility to higher-level
+ applications. As a result, both the features and the security properties
+ of RELOAD and R<sup>5</sup>N are different, except in that both allow
+ storing and retrieving key-value pairs.
+ <!--
+ 2023/08/20 CG: I believe the above text addresses the comments from MSC below ...
+
+ 2022/12/23 MSC: I moved references to rfc6940 to security considerations.
+ I think we should talk about R5N in the positive here only, not about
+ RELOAD in the negative.
+
+ - Lean. Can be implemented. Not overengineered.
+ - Path tracking (more difficult) -> Not built in
+ - Certificates central server ?
+ - "self-signed certificates can be used in closed networks."
+ - "Security Framework: A P2P network will often be established among a
+ set of peers that do not trust each other. RELOAD leverages a
+ central enrollment server to provide credentials for each peer,
+ which can then be used to authenticate each operation. This
+ greatly reduces the possible attack surface." bizarre statement.
+ - For a PUT, reload requires that
+ "Each element is signed by a credential which is authorized to
+ write this Kind at this Resource-ID. If this check fails, the
+ request <bcp14>MUST</bcp14> be rejected with an Error_Forbidden error."
+ -->
+ <!--FIXME: Here we should also cite and discuss RELOAD (https://datatracker.ietf.org/doc/html/rfc6940)
+ and establish why we need this spec and are not a "Topology plugin"
+ in RELOAD. The argumentation revolves around the trust model (openness) and
+ security aspects (path signatures).-->
+
+ </t>
+ </section>
</section>
<section anchor="terminology">
<name>Terminology</name>
@@ -172,7 +194,7 @@
<t>
is a UTF-8 <xref target="RFC3629"/> URI
<xref target="RFC3986"/> which can be
- used as address to contact a peer.
+ used to contact a peer.
An example of an addressing scheme used in
this document is "r5n+ip+tcp", which refers to a standard TCP/IP socket
connection. The "hier"-part of the URI must provide a suitable
@@ -191,7 +213,8 @@ gnunet+tcp://12.3.4.5/
<dd>
Applications are components which directly use the DHT overlay
interfaces. Possible applications include the GNU Name System
- <xref target="I-D.schanzen-gns"/> and the GNUnet CADET transport system
+ <xref target="I-D.schanzen-gns"/> and the GNUnet
+ Confidential Ad-hoc Decentralized End-to-End Transport (CADET)
<xref target="cadet"/>.
</dd>
<dt>Application API</dt>
