commit 78a4ca8c314f0668d10c9d24a066b8980bc6e9c7
parent 13463e8b2774ddc4f28ab75e6332c0c77c75a9bd
Author: Christian Grothoff <christian@grothoff.org>
Date: Thu, 11 Jul 2024 22:37:30 +0200
add NSE reference
Diffstat:
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -330,7 +330,7 @@
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
- storing and retrieving key-value pairs.
+ storing and retrieving key-value pairs.
<!--
2023/08/20 CG: I believe the above text addresses the comments from MSC below ...
@@ -469,14 +469,14 @@ R5N | v v
-------------+------------------------------------ Underlay Interface
| +--------+ +--------+ +----------+
| |GNUnet | |IP | | QUIC |
-Connectivity | |Underlay| |Underlay| | Underlay | ...
+Connectivity | |Underlay| |Underlay| | Underlay | ...
| |Link | |Link | | Link |
| +--------+ +--------+ +----------+
]]>
</artwork>
</figure>
</section>
-
+
<section anchor="underlay" numbered="true" toc="default">
<name>Underlay</name>
<t>
@@ -496,7 +496,7 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
1) The current API is always fire+forget, it doesn't allow for flow
control. I think we need to add that, possibly for sending and receiving.
- IDK.
+ IDK.
CG: I think we should not have flow control for the DHT; overkill,
should instead simply define transmission as unreliable.
@@ -518,7 +518,7 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
see how we can offer even the most minimal protections against peer
impersonation attacks. WDYT?
- CG: Yes, I think authentication should be mandatory, but not
+ CG: Yes, I think authentication should be mandatory, but not
any _specific_ type of encryption.
Security considerations? Prerequisites?
@@ -579,7 +579,8 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
A call that provides an estimate of the network size.
The result, <tt>L2NSE</tt>, must be the base-2 logarithm of the estimated number of peers in the network.
It is used by the routing algorithm.
- If the underlay does not support a protocol for network size estimation (such as cite paper NSE) the value
+ If the underlay does not support a protocol for network size estimation
+ (such as <xref target="NSE"/>) the value
is assumed to be provided as a configuration parameter to the implementation.
</dd>
</dl>
@@ -662,7 +663,7 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
Peers added to the routing table <tt>SHOULD</tt> be signalled to the
underlay as important connections using a <tt>HOLD</tt> call.
Similarly when a disconnect is indicated by the underlay through
- a <tt>PEER_DISCONNECTED</tt> signal, the peer
+ a <tt>PEER_DISCONNECTED</tt> signal, the peer
<bcp14>MUST</bcp14> be removed from the routing table.
<!-- FIXME: are we supposed to call DROP if we called HOLD if a peer disconnects!?? -->
</t>
@@ -750,7 +751,7 @@ Connectivity | |Underlay| |Underlay| | Underlay | ...
</t>
<t>
To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests
- (see <xref target="p2p_get"/>) asking for blocks of type <tt>HELLO</tt> using its own peer identity
+ (see <xref target="p2p_get"/>) asking for blocks of type <tt>HELLO</tt> using its own peer identity
in the <tt>QUERY_HASH</tt> field of the message.
The <tt>PEER_BF</tt> is initialized and set using the peers own peer identity as well as the identities
of all currently connected <em>neighbors</em>. <!-- note: we mean the identities here! FIX with terminology... -->
@@ -1628,7 +1629,7 @@ BEGIN
flag ist set, the message <bcp14>SHOULD</bcp14>
be stored locally in the block storage if possible.
The implementation <tt>MAY</tt> choose not store the block if external factors or configurations
- prevent this, such as limited (alottted) disk space.
+ prevent this, such as limited (alottted) disk space.
</li>
<li>
If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
@@ -1858,7 +1859,7 @@ BEGIN
the peer <bcp14>SHOULD</bcp14> respond with the closest block (smallest value
of <tt>GetDistance(QUERY_HASH, BLOCK_KEY)</tt>) it
can find that is not filtered by the <tt>RESULT_BF</tt>.
- Otherwise, the peer <bcp14>MUST</bcp14> respond with the block
+ Otherwise, the peer <bcp14>MUST</bcp14> respond with the block
with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is
not filtered by the <tt>RESULT_BF</tt>.
</li>
@@ -2863,6 +2864,21 @@ Type | Name | References | Description
<date year="2011"/>
</front>
</reference>
+ <reference anchor="NSE" target="https://doi.org/10.1007/978-3-642-30045-5_23">
+ <front>
+ <title>Efficient and Secure Decentralized Network Size Estimation</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
+ <organization>Technische Universität München</organization>
+ </author>
+ <author initials="C." surname="Grothoff" fullname="Christian Grothoff">
+ <organization>Technische Universität München</organization>
+ </author>
+ <date year="2012"/>
+ </front>
+ </reference>
<reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
<front>
<title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
@@ -3122,7 +3138,7 @@ Type | Name | References | Description
<figure>
<artwork type="abnf"><![CDATA[
hello-URL = "gnunet://hello[:version]/" meta [ "?" addrs ]
-version = *(DIGIT)
+version = *(DIGIT)
meta = pid "/" sig "/" exp
pid = *bchar
sig = *bchar
