[lsd0004] branch master updated: motivation section, restricted route

[gnunet]

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

martin-schanzenbach pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new bf2b419  motivation section, restricted route
bf2b419 is described below

commit bf2b41910c4c3ac3ecafca6b93b27cca6e6816a5
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Wed Sep 13 17:55:03 2023 +0200

    motivation section, restricted route
---
 draft-schanzen-r5n.xml | 124 +++++++++++++++++++++++++++++++------------------
 1 file changed, 80 insertions(+), 44 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 41843a6..a402b18 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -141,50 +141,6 @@
           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>
@@ -324,6 +280,86 @@ example://12.3.4.5/
       </dd>
     </dl>
     </section>
+    <section numbered="true" toc="default">
+      <name>Motivation</name>
+      <section numbered="true" toc="default">
+        <name>Restricted-route topologies</name>
+        <t>
+          Restricted-route topologies emerge when a connected underlay 
topology prevents
+          (or restricts) direct connections between some of the nodes.
+          This commonly occurs through the use of NAT.
+          Nodes operated behind a NAT cause common DHT routing algorithms such
+          as Kademlia to exhibit degraded performance or even to fail.
+          While excluding such nodes is an option, this limits load 
distribution
+          and is ineffective for some physical networks.
+        </t>
+        <t>
+          For example, some nodes which in terms of a classical distance 
metric such as XOR
+          are considered close, may not be reachable due to a firewall.
+          This leads to multiple (local) minima with respect to where data may 
be
+          stored or where data can be retrieved.
+          From a particular fixed location in the network, a node may only be 
able to
+          find and and store data in the context of its local minimum.
+        </t>
+        <t>
+          R<sup>5</sup>N addresses this problem by prepending a random walk 
before a
+          classical, deterministic XOR-based routing algorithm is employed.
+          If the network exhibits the properties of a small world topology, 
such
+          a random walk will cause the algorithm to land on a random node in 
the network.
+          Consequently, the deterministic part of the algorithm will encounter 
a random
+          local minimum.
+          It is then possible to repeat this process in order to store or 
retrieve data
+          in the context of all or at least multiple local minima.
+          The number of repetitions expected to cover all local minima depends 
on the
+          current network size and this one of the parameters of the 
R<sup>5</sup>N
+          routing algorithm.
+        </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>
       <name>Overview</name>
       <t>

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