[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated (afee8b6 -> 5f42ddd)
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated (afee8b6 -> 5f42ddd) |
|
Date: |
Fri, 23 Dec 2022 10:14:50 +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 afee8b6 no validation ANY
new 2ac5ecf Update authorship
new 9c8096b Rewrite abstract and introduction
new 5f42ddd Reorder terminology alphabetically
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 | 233 +++++++++++++++++++++++++++----------------------
1 file changed, 128 insertions(+), 105 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index dd54f7e..3bcc45c 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -34,15 +34,15 @@
</title>
<seriesInfo name="Internet-Draft" value="draft-schanzen-r5n-00"/>
<author fullname="Martin Schanzenbach" initials="M."
surname="Schanzenbach">
- <organization>GNUnet e.V.</organization>
+ <organization>Fraunhofer AISEC</organization>
<address>
<postal>
- <street>Boltzmannstrasse 3</street>
+ <street>Lichtenbergstrasse 11</street>
<city>Garching</city>
<code>85748</code>
<country>DE</country>
</postal>
- <email>schanzen@gnunet.org</email>
+ <email>martin.schanzenbach@aisec.fraunhofer.de</email>
</address>
</author>
<author fullname="Christian Grothoff" initials="C." surname="Grothoff">
@@ -74,16 +74,24 @@
<workgroup>Independent Stream</workgroup>
<keyword>distributed hash tables</keyword>
<abstract>
- <t>This document contains the R<sup>5</sup>N DHT technical
specification.</t>
<t>
- This document defines the normative wire format of resource records,
- resolution processes, cryptographic routines and security
considerations for
+ This document contains the R<sup>5</sup>N DHT technical specification.
+ R<sup>5</sup>N is a secure distributed hash table (DHT) routing
algorithm
+ and data structure for decentralized applications.
+ It features an open peer-to-peer overlay routing mechanism which
supports ad-hoc
+ permissionless participation and support for topologies in
restricted-route
+ environments.
+ </t>
+ <t>
+ This document defines the normative wire format of protocol messages,
+ routing algorithms, cryptographic routines and security considerations
for
use by implementers.
</t>
<t>
This specification was developed outside the IETF and does not have
IETF
consensus. It is published here to guide implementation of
R<sup>5</sup>N and to
- ensure interoperability among implementations.
+ ensure interoperability among implementations including the
pre-existing
+ GNUnet implementation.
</t>
</abstract>
</front>
@@ -110,30 +118,28 @@
in RELOAD. The argumentation revolves around the trust model
(openness) and
security aspects (path signatures).-->
<t>
- Distributed Hash Tables (DHTs) are a key data structure for the
- construction of decentralized applications.
- DHTs are important because they generally provide a robust and
- efficient means to distribute the storage and retrieval of
- key-value pairs.
+ This specification describes the protocol of R<sup>5</sup>N.
+ R<sup>5</sup> stands for "randomized recursive routing for
restricted-route
+ networks" and its first academic description can be found in
+ <xref target="R5N"/>.
</t>
<t>
- While <xref target="RFC6940"/> already provides a peer-to-peer (P2P)
- signaling protocol with extensible routing and topology mechanisms,
- it also relies on strict admission control through the use of either
- centralized enrollment servers or pre-shared keys.
- Some decentralized applications require a more open system that
- enables ad-hoc participation and other means to prevent common attacks
- on P2P overlays.
+ R<sup>5</sup>N is a Distributed Hash Table (DHTs).
+ DHTs are a key data structure for the construction of decentralized
applications.
+ and they generally provide a robust and efficient means to distribute
the
+ storage and retrieval of key-value pairs.
</t>
<t>
- This document contains the technical specification
- of the R<sup>5</sup>N DHT <xref target="R5N"/>, a secure DHT routing
algorithm
- and data structure for decentralized applications.
- R<sup>5</sup>N is an open P2P overlay routing mechanism which supports
ad-hoc
- permissionless participation and support for
- topologies in restricted-route environments. R<sup>5</sup>N also
- includes advanced features like tracing paths messages take through the
- network, response filters and on-path application-specific data
validation.
+ The core idea behind R<sup>5</sup>N is to combine an initial
randomized routing
+ algorithm with an efficient, classical closest-peer algorithm.
+ This allows us to construct an algorithm that is able to escape and
circumvent
+ restricted route environments while at the same time allow for O(log
n) routing
+ complexity.
+ </t>
+ <t>
+ R<sup>5</sup>N also includes advanced features like tracing paths
messages take
+ through the network, response filters and on-path application-specific
data
+ validation.
</t>
<t>
This document defines the normative wire format of peer-to-peer
@@ -150,108 +156,76 @@
when, they appear in all capitals, as shown here.
</t>
</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="terminology">
+ <section anchor="terminology">
<name>Terminology</name>
<dl>
- <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 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>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>Key</dt>
+ <dt>Applications</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.
+ 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>Neighbor:</dt>
+ <dt>Application API</dt>
<dd>
- A neighbor is a peer which is directly able to communicate
- with our peer via the <tt>Underlay Interface</tt>.
+ 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>
+ <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"/>).
+ Block-Types are either private or allocated by GANA (see
+ <xref target="gana"/>).
</dd>
- <dt>Block Storage</dt>
+ <dt>Key</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.
+ 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>Responsible Peer:</dt>
+ <dt>Message Processing</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"/>.
+ The Message Processing component processes requests from and
+ generates responses to applications and the underlay network.
</dd>
- <dt>Applications</dt>
+ <dt>Neighbor</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"/>.
+ A neighbor is a peer which is directly able to communicate
+ with our peer via the <tt>Underlay Interface</tt>.
</dd>
- <dt>Application API</dt>
+ <dt>Peer</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.
+ 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>Message Processing</dt>
+ <dt>Peer Address</dt>
<dd>
- The Message Processing component processes requests from and
- generates responses to applications and the underlay network.
+ 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>
@@ -259,6 +233,12 @@
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
@@ -267,6 +247,34 @@
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>
@@ -2568,6 +2576,21 @@ gnunet+tcp://12.3.4.5/ \
filtered by the result filter.
</t>
</section>
+ <section>
+ <name>Access control</name>
+ <t>
+ By design R<sup>5</sup>N does not rely on strict admission control
through
+ the use of either centralized enrollment servers or pre-shared keys.
+ This is a key distintion over protocols that do rely on this kind of
access
+ control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N,
provides
+ a peer-to-peer (P2P) signaling protocol with extensible routing and
topology
+ mechanisms.
+ <!-- FIXME: Can we give examples here? -->
+ Some decentralized applications require a more open system that
+ enables ad-hoc participation and other means to prevent common
attacks
+ on P2P overlays.
+ </t>
+ </section>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0004] branch master updated (afee8b6 -> 5f42ddd),
gnunet <=