commit bf2b41910c4c3ac3ecafca6b93b27cca6e6816a5
parent 06f27eb0b81928ecc357bba85211e8195e39ef85
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 13 Sep 2023 17:55:03 +0200
motivation section, restricted route
Diffstat:
1 file changed, 80 insertions(+), 44 deletions(-)
diff --git 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>
