summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--draft-schanzen-r5n.xml49
1 files 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|
671 <t> 671 <t>
672 The routing table consists of an array of lists of connected peers. 672 The routing table consists of an array of lists of connected peers.
673 The i-th list stores neighbours whose identifiers are between 673 The i-th list stores neighbours whose identifiers are between
674 distance 2^i 2^(i+1) from the local peer. 674 distance 2^i and 2^(i+1) from the local peer.
675 An implementation <bcp14>MAY</bcp14> choose an upper limit on the length of the 675 System constraints will typically force an implementation to impose some
676 lists, but <bcp14>SHOULD</bcp14> try to keep at least 5 entries per bucket. 676 upper limit on the number of neighbours kept per k-bucket.
677 For example, in case of system constraints with respect to active 677 </t>
678 connections, an implementation <bcp14>SHOULD</bcp14> evict peers in large buckets 678 <t>
679 rather than peers from shallow ones. 679 Implementations <bcp14>SHOULD</bcp14> try to keep at least
680 5 entries per k-bucket. Embedded systems that cannot manage
681 this number of connections <bcp14>MAY</bcp14> use connection-level
682 signalling to indicate that they are merely a client utilizing a
683 DHT and not able to participate in routing. DHT peers receiving
684 such connections <bcp14>MUST NOT</bcp14> include connections to
685 such restricted systems when making routing decisions.
686 <t>
687 If a system hits constraints with respect to
688 the number of active connections, an implementation
689 <bcp14>MUST</bcp14> evict peers from those k-buckets with the
690 largest number of peers. The eviction strategy <bcp14>MUST</bcp14> be
691 to drop the shortest-lived connections first.
680 </t> 692 </t>
681 <t> 693 <t>
682 As the message traverses a random path through the network for the 694 As the message traverses a random path through the network for the
@@ -1309,7 +1321,7 @@ Connectivity | |Underlay| |Underlay|
1309 The payload <bcp14>MUST</bcp14> be considered for the local routing table by 1321 The payload <bcp14>MUST</bcp14> be considered for the local routing table by
1310 trying to establish a connection to the peer using the information 1322 trying to establish a connection to the peer using the information
1311 from the HELLO block. If a connection can be established, 1323 from the HELLO block. If a connection can be established,
1312 the peer is added to the <tt>KBuckets</tt> routing table. 1324 the peer is added to the k-buckets of the routing table.
1313 </li> 1325 </li>
1314 <li> 1326 <li>
1315 If the sender peer of the message is already found in the 1327 If the sender peer of the message is already found in the
@@ -1322,7 +1334,7 @@ Connectivity | |Underlay| |Underlay|
1322 are validated against the requested BTYPE using the respective 1334 are validated against the requested BTYPE using the respective
1323 block type implementation of <tt>ValidateBlockReply</tt>. 1335 block type implementation of <tt>ValidateBlockReply</tt>.
1324 If the approximate flag is set and the BTYPE allows the 1336 If the approximate flag is set and the BTYPE allows the
1325 implementation to compute the key from the block it must match 1337 implementation to compute the key from the block it must match
1326 the QUERY_HASH. If the XQUERY is malformed, the message <bcp14>MUST</bcp14> be discarded. 1338 the QUERY_HASH. If the XQUERY is malformed, the message <bcp14>MUST</bcp14> be discarded.
1327 <!-- FIXME: This should be reviewed. 1339 <!-- FIXME: This should be reviewed.
1328 <= approximate flag --> 1340 <= approximate flag -->
@@ -1689,21 +1701,12 @@ gnunet+tcp://12.3.4.5/ \
1689 does not have/require a trust anchor a priori. This is (again) in contrast 1701 does not have/require a trust anchor a priori. This is (again) in contrast
1690 to RELOAD --> 1702 to RELOAD -->
1691 <t> 1703 <t>
1692 An implementation <bcp14>MAY</bcp14> limit the number the number of neighbours 1704 If an upper bound to the maximum number of neighbours in a
1693 it stores is any k-bucket of the routing table. 1705 k-bucket is reached, the implementation <bcp14>MUST</bcp14>
1694 However, the lower bound <bcp14>MUST</bcp14> be adhered to. <!-- FIXME define somewhere--> 1706 prefer to preserve the oldest working connections instead of
1695 If there is a limit to the maximum number of neighbours in a 1707 new connections. This makes Sybil attacks less effective
1696 k-bucket, the implementation must be careful when choosing the 1708 as an adversary would have to invest more resources over time
1697 which peers to replace: 1709 to mount an effective attack.
1698 For example, a simple optimization of the peer selection algorithm may
1699 be to oder all peers within the k-bucket by distance and evict the
1700 peers which are the farthest away.
1701 However, this is not a good idea from a resilience perspective.
1702 It is much more important to preserve older connections than closer
1703 ones.
1704 Preferring long-term connections over close connections makes it more
1705 difficult for an attacker to execute a Sibyl attack as more resources
1706 need to be invested over time.
1707 </t> 1710 </t>
1708 </section> 1711 </section>
1709 <section anchor="iana" numbered="true" toc="default"> 1712 <section anchor="iana" numbered="true" toc="default">