diff options
-rw-r--r-- | draft-schanzen-r5n.xml | 49 |
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"> |