commit 8c16ce42ffe188a8519ea9fe3e8e5f178ff4a6c4
parent 2d43555b1b43b62cc7efb6f234e42f6d2b936335
Author: Christian Grothoff <christian@grothoff.org>
Date: Fri, 12 Jul 2024 00:45:36 +0200
minor improvements/corrections
Diffstat:
1 file changed, 51 insertions(+), 41 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -190,9 +190,9 @@
sufficient number of direct connections with other honest
peers to achieve acceptable performance. As the number of
malicious peers and their connections increases, performance
- of the system SHOULD gracefully degrade, and only collapse
- for peers that an adversary has fully isolated from the
- benign network.
+ of the system <bcp14>SHOULD</bcp14> gracefully degrade, and
+ only collapse for peers that an adversary has fully isolated
+ from the benign network.
</t>
<t>
The main security objectives are to provide honest nodes
@@ -201,21 +201,22 @@
well as invalid routing path data if such routing meta-data
is present. While malicious nodes may make up arbitrary
key-value pairs and paths within the adversary's domain,
- invalid key-value pairs SHOULD ideally be discarded at the
- first honest node, and path data MUST honestly state
- entry- and exit-points from the honest network into the
- subset of malicious nodes.
+ invalid key-value pairs <bcp14>SHOULD</bcp14> ideally be
+ discarded at the first honest node, and path data
+ <bcp14>MUST</bcp14> honestly state entry- and exit-points
+ from the honest network into the subset of malicious nodes.
</t>
<t>
- Malicious nodes MAY attempt to exhaust the storage capacity
- of honest nodes by distributing well-formed (but possibly
- otherwise useless) application data. We assume that storage
- space is relatively cheap compared to bandwidth and that
- honest nodes also frequently re-publish the useful data
- that they publish. As a result, an adversary MAY reduce the
- effectiveness and longevity of data cached in the DHT, but
- is assumed to not be able to effectively prevent publication
- and retrieval of application data by honest nodes.
+ Malicious nodes <bcp14>MAY</bcp14> attempt to exhaust the
+ storage capacity of honest nodes by distributing well-formed
+ (but possibly otherwise useless) application data. We assume
+ that storage space is relatively cheap compared to bandwidth
+ and that honest nodes also frequently re-publish the useful
+ data that they publish. As a result, an adversary
+ <bcp14>MAY</bcp14> reduce the effectiveness and longevity of
+ data cached in the DHT, but is assumed to not be able to
+ effectively prevent publication and retrieval of application
+ data by honest nodes.
</t>
</section>
</section>
@@ -419,7 +420,7 @@
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,
+ over a network where not every 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
@@ -456,8 +457,8 @@
<section>
<name>Overview</name>
<t>
- In R<sup>5</sup>N peers provide
- the two fundamental core operations of any DHT to their applications:
+ In R<sup>5</sup>N peers provide to their applications
+ the two fundamental core operations of any DHT:
</t>
<ul>
<li>
@@ -510,7 +511,7 @@
It also serves as a set of requirements of possible transport mechanisms that
can be used to implement R<sup>5</sup>N with.
That being said, common transport protocols such as TCP/IP or UDP/IP and their
- interfaces are suitable R<sup>5</sup>N underlays used by existing
+ interfaces are suitable R<sup>5</sup>N underlays and are used as such by existing
implementations.
</t>
<!-- consider moving some of this back into sec considerations -->
@@ -538,7 +539,7 @@
<em>Block-Type</em> in the GANA <em>Block-Type</em> registry
(<xref target="gana_block_type"/>) and provide a specification
of the associated block operations (<xref
- target="block_functions"/>). to implementors of
+ target="block_functions"/>) to implementors of
R<sup>5</sup>N. <xref target="figure_r5n_arch"/> illustrates
the architectural overview of R<sup>5</sup>N.
</t>
@@ -3093,7 +3094,7 @@ Type | Name | References | Description
</dd>
</dl>
<t>
- The GET procedure may allow a set of optional parameters in order to
+ The GET procedure may allow additional optional parameters in order to
control or modify the query:
</t>
<dl>
@@ -3143,7 +3144,8 @@ Type | Name | References | Description
</dd>
<dt>Block-Data:</dt>
<dd>
- is the application-specific block payload. Contents are specific to the <tt>Block-Type</tt>.
+ is the application-specific block payload. Contents are
+ specific to the <tt>Block-Type</tt>.
</dd>
<dt>Block-Expiration:</dt>
<dd>
@@ -3153,25 +3155,34 @@ Type | Name | References | Description
<dt>Key:</dt>
<dd>
is the key under which the block was stored. This may be different from the
- key that was queried if the flag FindApproximate was set.
+ key that was queried if the flag <tt>FindApproximate</tt> was set.
</dd>
<dt>GET-Path:</dt>
<dd>
- is a signed path of the public keys of peers which the query
- traversed through the network. The DHT will try to make
- the path available if the <tt>RecordRoute</tt> flag was set by
- the application calling the PUT procedure. The reported
- path may have been silently truncated from the beginning.
+ is a signed path of the public keys of peers which the
+ query traversed through the network. The DHT will try to
+ make the path available if the <tt>RecordRoute</tt> flag
+ was set by the application calling the PUT procedure. The
+ reported path may have been truncated from the beginning.
+ The API <bcp14>SHOULD</bcp14> signal truncation by exposing
+ the <tt>Truncated</tt> flag.
</dd>
<dt>PUT-Path:</dt>
<dd>
is a signed path of the public keys of peers which the
- result message traversed. The DHT will try to make the
- path available if the <tt>RecordRoute</tt> flag was set for the GET procedure.
- The reported path may have been silently truncated from the beginning.
- As the block was cached by the node at the end of this
- path, this path is more likely to be stale compared to the
- <tt>GET-Path</tt>.
+ result message traversed. The DHT will try to make the
+ path available if the <tt>RecordRoute</tt> flag was set
+ for the GET procedure. The reported path may have been
+ truncated from the beginning. The API
+ <bcp14>SHOULD</bcp14> signal truncation by exposing the
+ <tt>Truncated</tt> flag. As the block was cached by the
+ node at the end of this path, this path is more likely to
+ be stale compared to the <tt>GET-Path</tt>.
+ </dd>
+ <dt>Truncated:</dt>
+ <dd>
+ is true if the <tt>GET-Path</tt> or <tt>PUT-Path</tt>
+ was truncated, otherwise false.
</dd>
</dl>
</section>
@@ -3197,8 +3208,8 @@ Type | Name | References | Description
<dd>is the application-specific payload of the block to store.</dd>
</dl>
<t>
- The PUT procedure may allow a set of optional parameters in order to
- control or modify the query:
+ The PUT procedure may accept additional optional parameters that
+ control or modify the operation:
</t>
<dl>
<dt>Replication-Level:</dt>
@@ -3208,10 +3219,9 @@ Type | Name | References | Description
</dd>
<dt>Flags:</dt>
<dd>
- is a bit-vector which indicates certain
- processing requirements for messages.
- Any combination of flags as defined in <xref target="route_flags"/>
- may be specified.
+ is a bit-vector which indicates certain processing
+ requirements for messages. Any combination of flags as
+ defined in <xref target="route_flags"/> may be specified.
</dd>
</dl>
<t>
