[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated (5f42ddd -> a1beda5)
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated (5f42ddd -> a1beda5) |
|
Date: |
Fri, 23 Dec 2022 11:13:37 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a change to branch master
in repository lsd0004.
from 5f42ddd Reorder terminology alphabetically
new afe9997 Typo R5N
new cd8c94d Reorder sections and add a note on reload
new a1beda5 Rewrite architecture and structure into an overview
The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
draft-schanzen-r5n.xml | 303 +++++++++++++++++++++++++++----------------------
1 file changed, 166 insertions(+), 137 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 3bcc45c..384872b 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -98,7 +98,11 @@
<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 ?
@@ -119,7 +123,7 @@
security aspects (path signatures).-->
<t>
This specification describes the protocol of R<sup>5</sup>N.
- R<sup>5</sup> stands for "randomized recursive routing for
restricted-route
+ R<sup>5</sup>N stands for "randomized recursive routing for
restricted-route
networks" and its first academic description can be found in
<xref target="R5N"/>.
</t>
@@ -156,133 +160,169 @@
when, they appear in all capitals, as shown here.
</t>
</section>
- <section anchor="terminology">
- <name>Terminology</name>
- <dl>
- <dt>Applications</dt>
- <dd>
- Applications are components which directly use the DHT overlay
- interfaces. Possible applications include the GNU Name System
- <xref target="I-D.draft-schanzen-gns"/> and the CADET transport
system
- <xref target="cadet"/>.
- </dd>
- <dt>Application API</dt>
- <dd>
- The application API exposes the core operations of the DHT overlay
- to applications.
- This includes storing blocks in the DHT and retrieving blocks from
the DHT.
- </dd>
- <dt>Block</dt>
- <dd>
- Variable-size unit of payload stored in the DHT
- under a <tt>Key</tt>. Commonly also called a "value" when
talking
- about a DHT as a "key-value store".
- </dd>
- <dt>Block Storage</dt>
- <dd>
- The <tt>Block Storage</tt> component is used to persist and manage
- <tt>Block</tt> data by peers.
- It includes logic for enforcing storage quotas, caching strategies
and
- data validation.
- </dd>
- <dt>Block-Type:</dt>
- <dd>
- A unique 32-bit value identifying the data format of a
<tt>Block</tt>.
- Block-Types are either private or allocated by GANA (see
- <xref target="gana"/>).
- </dd>
- <dt>Key</dt>
- <dd>
- 512-bit identifier of a location in the DHT. Multiple
<tt>Block</tt>s can be
- stored under the same key. <tt>Peer Addresses</tt> are valid keys.
- </dd>
- <dt>Message Processing</dt>
- <dd>
- The Message Processing component processes requests from and
- generates responses to applications and the underlay network.
- </dd>
- <dt>Neighbor</dt>
- <dd>
- A neighbor is a peer which is directly able to communicate
- with our peer via the <tt>Underlay Interface</tt>.
- </dd>
- <dt>Peer</dt>
- <dd>
- A host that is participating in the overlay. Peers are
- responsible for holding some portion of the data that has been
- stored in the overlay, and they are responsible for routing
- messages on behalf of other hosts as needed by the Routing
- Algorithm.
- </dd>
- <dt>Peer Address</dt>
- <dd>
- The <tt>Peer Address</tt> is the identifier used on the Overlay
- to address a peer.
- It is a SHA-512 hash of the <tt>Peer ID</tt>.
- </dd>
- <dt>Peer ID</dt>
- <dd>
- The <tt>Peer ID</tt> is the public key which is used to authenticate
- a peer in the underlay.
- The Peer ID is the public key of the corresponding
- Ed25519<xref target="ed25519" /> peer private key.
- </dd>
- <dt>Routing</dt>
- <dd>
- The Routing component includes the routing table as well as
- routing and peer selection logic. It facilitates the R<sup>5</sup>N
routing
- algorithm with required data structures and algorithms.
- </dd>
- <dt>Responsible Peer</dt>
- <dd>
- The peer <tt>N</tt> that is responsible for a specific key
<tt>K</tt>, as
- defined by the <tt>SelectClosestPeer(K, P)</tt> algorithm (see
- <xref target="routing"/>.
- </dd>
- <dt>Underlay Interface</dt>
- <dd>
- The Underlay Interface is an abstraction layer on top of the
- supported links of a peer. Peers may be linked by a variety of
- different transports, including "classical" protocols such as
- TCP, UDP and TLS or advanced protocols such as GNUnet, I2P or Tor.
- </dd>
- </dl>
- </section>
- <section>
- <name>Structure of This Document</name>
- <t>
- <xref target="terminology"/> gives an overview of the terminology
used in
- this document.
- <xref target="architecture"/> then describes the overall
architecture and
- the scope of this specification.
- <xref target="overlay"/> describes the application API, which
clarifies
- the semantics provided by R<sup>5</sup>N for applications
- and thus is crucial as it motivates the rest of the design.
- <xref target="underlay"/> describes the underlay interface. This is
the
- abstraction that applications must provide to R<sup>5</sup>N
- and thus a prerequisite for using the DHT.
- Before a DHT is usable, it must be bootstrapped.
- Bootstrapping is described in <xref target="bootstrapping"/>.
- Bloom filters, a key data structure used in various
- places, are introduced in <xref target="bloom_filters" />
- The central operation of a DHT is routing, which is
- detailed in <xref target="routing"/>. The processing of the various
- network messages is described in <xref target="p2p_messages"/>.
Handling
- of Blocks, including validation and storage are described
- in <xref target="blockstorage"/>. General security considerations
are detailed
- in <xref target="security" />. IANA and GANA registry updates are
listed
- in <xref target="iana" /> and <xref target="gana"/>. The document
concludes with test
- vectors in <xref target="testvectors"/> and appendices with
references.
- </t>
- </section>
</section>
- <section anchor="architecture" numbered="true" toc="default">
- <name>Architecture</name>
+ <section anchor="terminology">
+ <name>Terminology</name>
+ <dl>
+ <dt>Applications</dt>
+ <dd>
+ Applications are components which directly use the DHT overlay
+ interfaces. Possible applications include the GNU Name System
+ <xref target="I-D.draft-schanzen-gns"/> and the CADET transport system
+ <xref target="cadet"/>.
+ </dd>
+ <dt>Application API</dt>
+ <dd>
+ The application API exposes the core operations of the DHT overlay
+ to applications.
+ This includes storing blocks in the DHT and retrieving blocks from the
DHT.
+ </dd>
+ <dt>Block</dt>
+ <dd>
+ Variable-size unit of payload stored in the DHT
+ under a <tt>Key</tt>. Commonly also called a "value" when talking
+ about a DHT as a "key-value store".
+ </dd>
+ <dt>Block Storage</dt>
+ <dd>
+ The <tt>Block Storage</tt> component is used to persist and manage
+ <tt>Block</tt> data by peers.
+ It includes logic for enforcing storage quotas, caching strategies and
+ data validation.
+ </dd>
+ <dt>Block-Type:</dt>
+ <dd>
+ A unique 32-bit value identifying the data format of a <tt>Block</tt>.
+ Block-Types are either private or allocated by GANA (see
+ <xref target="gana"/>).
+ </dd>
+ <dt>Key</dt>
+ <dd>
+ 512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s
can be
+ stored under the same key. <tt>Peer Addresses</tt> are valid keys.
+ </dd>
+ <dt>Message Processing</dt>
+ <dd>
+ The Message Processing component processes requests from and
+ generates responses to applications and the underlay network.
+ </dd>
+ <dt>Neighbor</dt>
+ <dd>
+ A neighbor is a peer which is directly able to communicate
+ with our peer via the <tt>Underlay Interface</tt>.
+ </dd>
+ <dt>Peer</dt>
+ <dd>
+ A host that is participating in the overlay. Peers are
+ responsible for holding some portion of the data that has been
+ stored in the overlay, and they are responsible for routing
+ messages on behalf of other hosts as needed by the Routing
+ Algorithm.
+ </dd>
+ <dt>Peer Address</dt>
+ <dd>
+ The <tt>Peer Address</tt> is the identifier used on the Overlay
+ to address a peer.
+ It is a SHA-512 hash of the <tt>Peer ID</tt>.
+ </dd>
+ <dt>Peer ID</dt>
+ <dd>
+ The <tt>Peer ID</tt> is the public key which is used to authenticate
+ a peer in the underlay.
+ The Peer ID is the public key of the corresponding
+ Ed25519<xref target="ed25519" /> peer private key.
+ </dd>
+ <dt>Routing</dt>
+ <dd>
+ The Routing component includes the routing table as well as
+ routing and peer selection logic. It facilitates the R<sup>5</sup>N
routing
+ algorithm with required data structures and algorithms.
+ </dd>
+ <dt>Responsible Peer</dt>
+ <dd>
+ The peer <tt>N</tt> that is responsible for a specific key <tt>K</tt>,
as
+ defined by the <tt>SelectClosestPeer(K, P)</tt> algorithm (see
+ <xref target="routing"/>.
+ </dd>
+ <dt>Underlay Interface</dt>
+ <dd>
+ The Underlay Interface is an abstraction layer on top of the
+ supported links of a peer. Peers may be linked by a variety of
+ different transports, including "classical" protocols such as
+ TCP, UDP and TLS or advanced protocols such as GNUnet, I2P or Tor.
+ </dd>
+ </dl>
+ </section>
+ <section>
+ <name>Overview</name>
+ <t>
+ In R<sup>5</sup>N peers communicate with each other in order to
realize and
+ maintain two basic operations of a distributed hash table:
+ </t>
+ <ul>
+ <li>
+ PUT: This operation stores a block payload on one or more peers with
+ the goal of making the block availiable for queries using the GET
operation.
+ In the classical definition of a dictionary interface, this
operation would be
+ called "insert".
+ </li>
+ <li>
+ GET: This operation queries the network of peers for blocks
+ previously stored under or near the key.
+ In the classical definition of a dictionary interface, this
operation would be
+ called "find".
+ </li>
+ </ul>
+ <t>
+ The specific semantics of the above operations as provided by
R<sup>5</sup>N
+ for applications are defined in <xref target="overlay"/>.
+ The handling of blocks and their validation and storage is defined in
+ <xref target="blockstorage".
+ </t>
<t>
- R<sup>5</sup>N is an overlay network with a pluggable transport layer.
- The following figure shows the R<sup>5</sup>N architecture.
+ In a trivial scenario where there is only one peer (the local host),
+ R<sup>5</sup>N operates in a very similar fashion to a dictionary data
structure.
+ However, the default use case is one where nodes communicate directly
and
+ indirectly in order to realize a distributed storage mechanism.
+ This communication requires a lower-level peer addressing and message
transport
+ mechanism such as TCP/IP.
+ R<sup>5</sup>N is agnostic to the underlying transport protocol which
is why
+ this document defines a common addressing and messaging interface in
+ <xref target="underlay"/>.
+ The interface provided by this underlay is used across the
specification of the
+ R<sup>5</sup>N protocol.
+ It also serves as a set of requirements of possible transport
mechanism that
+ can be used to implement R<sup>5</sup>N on.
+ That being said, common transport protocols such as TCP/IP or UDP/IP
are
+ supported.
</t>
- <figure title="The R5N Architecture.">
+ <!-- consider moving some of this back into sec considerations -->
+ <t>
+ Specifics about the protocols of the underlays providing
+ connectivity or the applications using the DHT are out of
+ the scope of this document. However, we note that peers
+ implementing disjoint sets of underlay protocols may
+ experience difficulties communicating (unless other peers
+ bridge the respective underlays). Similarly, peers that
+ do not support a particular application will not be able
+ to validate application-specific payloads and may thus be
+ tricked into storing or forwarding corrupt blocks.
+ </t>
+ <t>
+ In order to establish an initial connection to a network of
R<sup>5</sup>N
+ peers, an initial, addressable bootstrap peer is required.
+ Further peers, including neighbors, are then learned via a
bootstrapping
+ process as defined in <xref target="bootstrapping"/>.
+ </t>
+ <t>
+ Across this document, the functional components of an R<sup>5</sup>N
+ implementation are divided into block processing (<xref
target="blockstorage"),
+ message processing (<xref target="p2p_messages") and routing
+ (<xref target="routing").
+ <xref taget="figure_r5n_arch" illustrates the architectural overview of
+ R<sup>5</sup>N.
+ </t>
+ <figure anchor="figure_r5n_arch" title="The R5N architecture.">
<artwork><![CDATA[
| +-----------------+ +-------+
Applications | | GNU Name System | | CADET | ...
@@ -308,17 +348,6 @@ Connectivity | |Underlay| |Underlay|
]]>
</artwork>
</figure>
- <t>
- Specifics about the protocols of the underlays providing
- connectivity or the applications using the DHT are out of
- the scope of this document. However, we note that peers
- implementing disjoint sets of underlay protocols may
- experience difficulties communicating (unless other peers
- bridge the respective underlays). Similarly, peers that
- do not support a particular application will not be able
- to validate application-specific payloads and may thus be
- tricked into storing or forwarding corrupt blocks.
- </t>
</section>
<section anchor="overlay" numbered="true" toc="default">
<name>Application API</name>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0004] branch master updated (5f42ddd -> a1beda5),
gnunet <=