[lsd0004] branch master updated: edit draft to be very clear on eviction strategy, remove duplication of text between routing table and security considerations; fixes #7141

[gnunet]

This is an automated email from the git hooks/post-receive script.

grothoff pushed a commit to branch master
in repository lsd0004.

The following commit(s) were added to refs/heads/master by this push:
     new c18963a  edit draft to be very clear on eviction strategy, remove 
duplication of text between routing table and security considerations; fixes 
#7141
c18963a is described below

commit c18963a9dd4339f1fdfa850d16dc273522f1d4db
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Wed Feb 23 23:19:24 2022 +0100

    edit draft to be very clear on eviction strategy, remove duplication of 
text between routing table and security considerations; fixes #7141
---
 draft-schanzen-r5n.xml | 49 ++++++++++++++++++++++++++-----------------------
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 4fbfd79..db465f7 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -671,12 +671,24 @@ Connectivity | |Underlay|  |Underlay|
         <t>
           The routing table consists of an array of lists of connected peers.
           The i-th list stores neighbours whose identifiers are between
-          distance 2^i 2^(i+1) from the local peer.
-          An implementation <bcp14>MAY</bcp14> choose an upper limit on the 
length of the
-          lists, but <bcp14>SHOULD</bcp14> try to keep at least 5 entries per 
bucket.
-          For example, in case of system constraints with respect to active
-          connections, an implementation <bcp14>SHOULD</bcp14> evict peers in 
large buckets
-          rather than peers from shallow ones.
+          distance 2^i and 2^(i+1) from the local peer.
+          System constraints will typically force an implementation to impose 
some
+          upper limit on the number of neighbours kept per k-bucket.
+        </t>
+        <t>
+          Implementations <bcp14>SHOULD</bcp14> try to keep at least
+          5 entries per k-bucket.  Embedded systems that cannot manage
+          this number of connections <bcp14>MAY</bcp14> use connection-level
+          signalling to indicate that they are merely a client utilizing a
+          DHT and not able to participate in routing.  DHT peers receiving
+          such connections <bcp14>MUST NOT</bcp14> include connections to
+          such restricted systems when making routing decisions.
+        <t>
+          If a system hits constraints with respect to
+          the number of active connections, an implementation
+          <bcp14>MUST</bcp14> evict peers from those k-buckets with the
+          largest number of peers. The eviction strategy <bcp14>MUST</bcp14> be
+          to drop the shortest-lived connections first.
         </t>
         <t>
           As the message traverses a random path through the network for the
@@ -1309,7 +1321,7 @@ Connectivity | |Underlay|  |Underlay|
               The payload <bcp14>MUST</bcp14> be considered for the local 
routing table by
               trying to establish a connection to the peer using the 
information
               from the HELLO block. If a connection can be established,
-              the peer is added to the <tt>KBuckets</tt> routing table.
+              the peer is added to the k-buckets of the routing table.
             </li>
             <li>
               If the sender peer of the message is already found in the
@@ -1322,7 +1334,7 @@ Connectivity | |Underlay|  |Underlay|
               are validated against the requested BTYPE using the respective
               block type implementation of <tt>ValidateBlockReply</tt>.
               If the approximate flag is set and the BTYPE allows the
-              implementation to compute the key from the block it must match 
+              implementation to compute the key from the block it must match
               the QUERY_HASH. If the XQUERY is malformed, the message 
<bcp14>MUST</bcp14> be discarded.
               <!-- FIXME: This should be reviewed.
               <= approximate flag -->
@@ -1689,21 +1701,12 @@ gnunet+tcp://12.3.4.5/ \
         does not have/require a trust anchor a priori. This is (again) in 
contrast
       to RELOAD -->
       <t>
-        An implementation <bcp14>MAY</bcp14> limit the number the number of 
neighbours
-        it stores is any k-bucket of the routing table.
-        However, the lower bound <bcp14>MUST</bcp14> 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 peers to replace:
-        For example, a simple optimization of the peer selection algorithm may
-        be to oder all peers within the k-bucket by distance and evict the
-        peers 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.
+        If an upper bound to the maximum number of neighbours in a
+        k-bucket is reached, the implementation <bcp14>MUST</bcp14>
+        prefer to preserve the oldest working connections instead of
+        new connections.  This makes Sybil attacks less effective
+        as an adversary would have to invest more resources over time
+        to mount an effective attack.
       </t>
     </section>
     <section anchor="iana" numbered="true" toc="default">

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.