commit 471282c82949765c0e32068ea7e01c5d1f800bde
parent 9384ae18482041a162d71a4db0a5a5da352146ad
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 7 Jan 2022 21:47:35 +0100
add some test
Diffstat:
1 file changed, 99 insertions(+), 29 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -91,6 +91,21 @@
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
+ <!--
+ - 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 MUST 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
@@ -135,6 +150,42 @@
when, they appear in all capitals, as shown here.
</t>
</section>
+ <section>
+ <name>Structure of This Document</name>
+ <ul>
+ <li>
+ Section X defines...
+ </li>
+ </ul>
+ </section>
+ </section>
+ <section>
+ <name>Terminology</name>
+ <dl>
+ <dt>Node:</dt>
+ <dd>
+ A node is participant in the network and addressable through the
+ network overlay.
+ </dd>
+ <dt>Node Address:</dt>
+ <dd>
+ The <tt>Node Address</tt> is the identifier used on the Overlay
+ to address a node.
+ </dd>
+ <dt>Node ID:</dt>
+ <dd>
+ The <tt>Node ID</tt> is the identity which is used to authenticate
+ a node in the underlay.
+ The <tt>Node Address</tt> is derived from the <tt>Node ID</tt>.
+ </dd>
+ <dt>Neighbour:</dt>
+ <dd>
+ A neighbour is a node which is directly connected to our node.
+ </dd>
+ <dt>Block:</dt>
+ <dd>
+ </dd>
+ </dl>
</section>
<section anchor="architecture" numbered="true" toc="default">
<name>Architecture</name>
@@ -210,29 +261,7 @@ Connectivity | |Underlay| |Underlay|
<t>
Other glossary
</t>
- <dl>
- <dt>Node</dt>
- <dd>
- A node is participant in the network and addressable through the
- network overlay.
- </dd>
- <dt>Node Address</dt>
- <dd>
- The <tt>Node Address</tt> is the identifier used on the Overlay
- to address a node.
- </dd>
- <dt>Node ID</dt>
- <dd>
- The <tt>Node ID</tt> is the identity which is used to authenticate
- a node in the underlay.
- The <tt>Node Address</tt> is derived from the <tt>Node ID</tt>.
- </dd>
- <dt>Peer</dt>
- <dd>
- A peer is a node which is directly connected to our peer.
- </dd>
- </dl>
- </section>
+ </section>
<section anchor="overlay" numbered="true" toc="default">
<name>Overlay</name>
<t>
@@ -240,10 +269,8 @@ Connectivity | |Underlay| |Underlay|
<tt>Node Address</tt>.
The <tt>Node Address</tt> is a SHA-512 hash <xref target="RFC4634"/>
of the <tt>Node ID</tt>.
- <!-- FIXME should the node ID be agile? Should the signature then
- also be agile?-->
- <!--The node public key is the public key of the corresponding
- Ed25519<xref target="ed25519" /> node private key.-->
+ The Node ID is the public key of the corresponding
+ Ed25519<xref target="ed25519" /> node private key.
</t>
<t>
Any implementation of this specification MUST expose the two API
@@ -526,8 +553,9 @@ Connectivity | |Underlay| |Underlay|
When disconnect is indicated by the Underlay through
<tt>NODE_DISCONNECTED</tt> the peer MUST be removed from the local
peer storage.
- The data structure for managing connected nodes and their
- metadata may be implemented using the k-buckets concept of
+ In order to achieve O(log n) routing performance,
+ the data structure for managing connected nodes and their
+ metadata MUST be implemented using the k-buckets concept of
<xref target="Kademlia"/>.
In order to select nodes which are suitable destinations for
routing messages, R5N uses a hybrid approach:
@@ -547,6 +575,16 @@ Connectivity | |Underlay| |Underlay|
<section anchor="routing_table">
<name>Routing Table</name>
<t>
+ The routing table consists of an array of lists of connected nodes.
+ The i-th list stores neighbours whose identifiers are between
+ distance 2^i 2^(i+1) from the local node.
+ An implementation MAY choose an upper limit on the length of the
+ lists, but SHOULD try to keep at least 5 entries per bucket.
+ For example, in case of system constraints with respect to active
+ connections, an implementation SHOULD evict nodes in large buckets
+ rather than nodes from shallow ones.
+ </t>
+ <t>
As the message traverses a random path through the network for the
first N hops, it is essential that routing loops are avoided.
In R5N, a bloomfilter is used as part of the routing metadata in
@@ -637,6 +675,9 @@ Connectivity | |Underlay| |Underlay|
<t>TODO: Talk about XQuery in the context of messages.</t>
</section>
<section anchor="p2p_put" numbered="true" toc="default">
+ <!-- FIXME: Blocks have KEYs. GETs only have
+ QueryHashes the reply refers to the QueryHash, but
+ QueryHash MAY not be Block key -->
<name>PutMessage</name>
<section anchor="p2p_put_wire">
<name>Wire Format</name>
@@ -1254,6 +1295,23 @@ tor+onionv3://rasdflkjasdfliasduf.onion/
<!-- FIXME: Here we should (again) discuss how the system is open and
does not have/require a trust anchor a priori. This is (again) in contrast
to RELOAD -->
+ <t>
+ An implementation MAY limit the number the number of neighbours
+ it stores is any k-bucket of the routing table.
+ However, the lower bound MUST be adhered to. <!-- FIXME define somewhere-->
+ If there is a limit to the maximum number of neighbours in a
+ k-bucket, the implementation must be careful when choosing the
+ which nodes to replace:
+ For example, a simple optimization of the peer selection algorithm may
+ be to oder all nodes within the k-bucket by distance and evict the
+ nodes which are the farthest away.
+ However, this is not a good idea from a resilience perspective.
+ It is much more important to preserve older connections than closer
+ ones.
+ Preferring long-term connections over close connections makes it more
+ difficult for an attacker to execute a Sibyl attack as more resources
+ need to be invested over time.
+ </t>
</section>
<section anchor="gana" numbered="true" toc="default">
<name>GANA Considerations</name>
@@ -1299,6 +1357,18 @@ Purpose | Name | References | Description
]]></artwork>
</figure>
</section>
+ <section>
+ <name>Local Storage</name>
+ <!--
+ - Store(Key, Exp, BType, PUTPATH (combined with old GETPATH), BLOCK)
+ - What to do with duplicates with diff PUTPATH or diff Exps
+ => Use max Exp and corresponding PUTPATH
+ => Else use any
+ - Find(Key, BType) -> List<(Exp,PUTPATH,BLOCK)> #Approximate
+ - Get(Key, BType) -> List<(Exp,PUTPATH,BLOCK)> # Exact
+ - Cache eviction (closest, expiration)
+ -->
+ </section>
<!-- gana -->
<section>
<name>Test Vectors</name>
