[lsd0004] 02/03: add text to point out key objective differences to RELOAD

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0004.

commit 167f106b942033b1ef00c0e7671f85df3a78dd63
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun Aug 20 14:48:55 2023 +0200

    add text to point out key objective differences to RELOAD
---
 draft-schanzen-r5n.xml | 77 ++++++++++++++++++++++++++++++++------------------
 1 file changed, 50 insertions(+), 27 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 3267a92..a46db61 100644
--- 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>

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.