summaryrefslogtreecommitdiff
path: root/draft-schanzen-r5n.xml
diff options
context:
space:
mode:
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r--draft-schanzen-r5n.xml2540
1 files changed, 1242 insertions, 1298 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 6bd13ed..a1a20f2 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -1,24 +1,24 @@
1<?xml version='1.0' encoding='utf-8'?> 1<?xml version="1.0" encoding="utf-8"?>
2<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [ 2<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
3<!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 3<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
4<!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"> 4<!ENTITY RFC2782 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
5<!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"> 5<!ENTITY RFC3629 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
6<!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml"> 6<!ENTITY RFC3686 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml">
7<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml"> 7<!ENTITY RFC3826 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
8<!ENTITY RFC3986 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"> 8<!ENTITY RFC3986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
9<!ENTITY RFC4634 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4634.xml"> 9<!ENTITY RFC4634 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4634.xml">
10<!ENTITY RFC4648 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml"> 10<!ENTITY RFC4648 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
11<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> 11<!ENTITY RFC5869 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
12<!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> 12<!ENTITY RFC5890 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
13<!ENTITY RFC5891 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml"> 13<!ENTITY RFC5891 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
14<!ENTITY RFC6781 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml"> 14<!ENTITY RFC6781 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml">
15<!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> 15<!ENTITY RFC6895 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml">
16<!ENTITY RFC6940 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6940.xml"> 16<!ENTITY RFC6940 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6940.xml">
17<!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml"> 17<!ENTITY RFC6979 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
18<!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml"> 18<!ENTITY RFC7748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml">
19<!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml"> 19<!ENTITY RFC8032 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml">
20<!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> 20<!ENTITY RFC8126 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
21<!ENTITY RFC8174 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> 21<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
22]> 22]>
23<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 23<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
24<?rfc strict="yes" ?> 24<?rfc strict="yes" ?>
@@ -28,124 +28,122 @@
28<?rfc compact="yes" ?> 28<?rfc compact="yes" ?>
29<?rfc subcompact="no" ?> 29<?rfc subcompact="no" ?>
30<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-r5n-00" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3"> 30<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-r5n-00" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
31 <!-- xml2rfc v2v3 conversion 2.26.0 --> 31<!-- xml2rfc v2v3 conversion 2.26.0 -->
32 <front> 32<front>
33 <title abbrev="The R5N Distributed Hash Table"> 33<title abbrev="The R5N Distributed Hash Table">
34 The R5N Distributed Hash Table 34The R5N Distributed Hash Table
35 </title> 35</title>
36 <seriesInfo name="Internet-Draft" value="draft-schanzen-r5n-00"/> 36<seriesInfo name="Internet-Draft" value="draft-schanzen-r5n-00"/>
37 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 37<author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
38 <organization>GNUnet e.V.</organization> 38<organization>GNUnet e.V.</organization>
39 <address> 39<address>
40 <postal> 40<postal>
41 <street>Boltzmannstrasse 3</street> 41<street>Boltzmannstrasse 3</street>
42 <city>Garching</city> 42<city>Garching</city>
43 <code>85748</code> 43<code>85748</code>
44 <country>DE</country> 44<country>DE</country>
45 </postal> 45</postal>
46 <email>schanzen@gnunet.org</email> 46<email>schanzen@gnunet.org</email>
47 </address> 47</address>
48 </author> 48</author>
49 <author fullname="Christian Grothoff" initials="C." surname="Grothoff"> 49<author fullname="Christian Grothoff" initials="C." surname="Grothoff">
50 <organization>Berner Fachhochschule</organization> 50<organization>Berner Fachhochschule</organization>
51 <address> 51<address>
52 <postal> 52<postal>
53 <street>Hoeheweg 80</street> 53<street>Hoeheweg 80</street>
54 <city>Biel/Bienne</city> 54<city>Biel/Bienne</city>
55 <code>2501</code> 55<code>2501</code>
56 <country>CH</country> 56<country>CH</country>
57 </postal> 57</postal>
58 <email>grothoff@gnunet.org</email> 58<email>grothoff@gnunet.org</email>
59 </address> 59</address>
60 </author> 60</author>
61 <author fullname="Bernd Fix" initials="B." surname="Fix"> 61<author fullname="Bernd Fix" initials="B." surname="Fix">
62 <organization>GNUnet e.V.</organization> 62<organization>GNUnet e.V.</organization>
63 <address> 63<address>
64 <postal> 64<postal>
65 <street>Boltzmannstrasse 3</street> 65<street>Boltzmannstrasse 3</street>
66 <city>Garching</city> 66<city>Garching</city>
67 <code>85748</code> 67<code>85748</code>
68 <country>DE</country> 68<country>DE</country>
69 </postal> 69</postal>
70 <email>fix@gnunet.org</email> 70<email>fix@gnunet.org</email>
71 </address> 71</address>
72 </author> 72</author>
73 73<!-- Meta-data Declarations -->
74 <!-- Meta-data Declarations --> 74<area>General</area>
75 <area>General</area> 75<workgroup>Independent Stream</workgroup>
76 <workgroup>Independent Stream</workgroup> 76<keyword>distributed hash tables</keyword>
77 <keyword>distributed hash tables</keyword> 77<abstract>
78 <abstract> 78<t>This document contains the R5N DHT technical specification.</t>
79 <t>This document contains the R5N DHT technical specification.</t> 79<t>
80 <t> 80This document defines the normative wire format of resource records,
81 This document defines the normative wire format of resource records, 81resolution processes, cryptographic routines and security considerations for
82 resolution processes, cryptographic routines and security considerations for 82use by implementers.
83 use by implementers. 83</t>
84 </t> 84<t>
85 <t> 85This specification was developed outside the IETF and does not have IETF
86 This specification was developed outside the IETF and does not have IETF 86consensus. It is published here to guide implementation of R5N and to
87 consensus. It is published here to guide implementation of R5N and to 87ensure interoperability among implementations.
88 ensure interoperability among implementations. 88</t>
89 </t> 89</abstract>
90 </abstract> 90</front>
91 </front> 91<middle>
92 <middle> 92<section anchor="introduction" numbered="true" toc="default">
93 <section anchor="introduction" numbered="true" toc="default"> 93<name>Introduction</name>
94 <name>Introduction</name> 94<!-- FIXME: Here we should also cite and discuss RELOAD (https://datatracker.ietf.org/doc/html/rfc6940)
95 <!-- FIXME: Here we should also cite and discuss RELOAD (https://datatracker.ietf.org/doc/html/rfc6940) 95and establish why we need this spec and are not a "Topology plugin"
96 and establish why we need this spec and are not a "Topology plugin" 96in RELOAD. The argumentation revolves around the trust model (openness) and
97 in RELOAD. The argumentation revolves around the trust model (openness) and 97security aspects (path signatures).
98 security aspects (path signatures). 98-->
99 --> 99<t>
100 <t> 100Distributed Hash Tables (DHTs) are a key data structure for the
101 Distributed Hash Tables (DHTs) are a key data structure for the 101construction of completely decentralized applications.
102 construction of completely decentralized applications. 102DHTs are important because they generally provide a robust and
103 DHTs are important because they generally provide a robust and 103efficient means to distribute the storage and retrieval of
104 efficient means to distribute the storage and retrieval of 104key-value pairs.
105 key-value pairs. 105</t>
106 </t> 106<t>
107 <t> 107While <xref target="RFC6940"/> already provides a peer-to-peer (P2P)
108 While <xref target="RFC6940" /> already provides a peer-to-peer (P2P) 108signaling protocol with extensible routing and topology mechanisms,
109 signaling protocol with extensible routing and topology mechanisms, 109it also relies on strict admission control through the use of either
110 it also relies on strict admission control through the use of either 110centralized enrollment servers or pre-shared keys.
111 centralized enrollment servers or pre-shared keys. 111Modern decentralized applications require a more open system that
112 Modern decentralized applications require a more open system that 112enables ad-hoc participation and other means to prevent common attacks
113 enables ad-hoc participation and other means to prevent common attacks 113on P2P overlays.
114 on P2P overlays. 114</t>
115 </t> 115<t>
116 <t> 116This document contains the technical specification
117 This document contains the technical specification 117of the R5N DHT <xref target="R5N"/>, a secure DHT routing algorithm
118 of the R5N DHT <xref target="R5N" />, a secure DHT routing algorithm 118and data structure for decentralized applications.
119 and data structure for decentralized applications. 119R5N is an open P2P overlay routing mechanism which supports ad-hoc
120 R5N is an open P2P overlay routing mechanism which supports ad-hoc 120participation and security properties including support for
121 participation and security properties including support for 121topologies in restricted-route environments and path signatures.
122 topologies in restricted-route environments and path signatures. 122</t>
123 </t> 123<t>
124 <t> 124This document defines the normative wire format of peer-to-peer
125 This document defines the normative wire format of peer-to-peer 125messages, routing algorithms, cryptographic routines and security
126 messages, routing algorithms, cryptographic routines and security 126considerations for use by implementors.
127 considerations for use by implementors. 127</t>
128 </t> 128<section numbered="true" toc="default">
129 <section numbered="true" toc="default"> 129<name>Requirements Notation</name>
130 <name>Requirements Notation</name> 130<t>
131 <t> 131The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133"OPTIONAL" in this document are to be interpreted as described in
134 "OPTIONAL" in this document are to be interpreted as described in 134BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
135 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only 135when, they appear in all capitals, as shown here.
136 when, they appear in all capitals, as shown here. 136</t>
137 </t> 137</section>
138 </section> 138</section>
139 139<section anchor="architecture" numbered="true" toc="default">
140 </section> 140<name>Architecture</name>
141 <section anchor="architecture" numbered="true" toc="default"> 141<t>
142 <name>Architecture</name> 142R5N is an overlay network with a pluggable transport layer.
143 <t> 143The following figure shows the R5N architecture.
144 R5N is an overlay network with a pluggable transport layer. 144</t>
145 The following figure shows the R5N architecture. 145<figure>
146 </t> 146<artwork><![CDATA[
147 <figure>
148 <artwork name="" type="" align="left" alt=""><![CDATA[
149 | +-----------------+ +-------+ 147 | +-----------------+ +-------+
150Applications | | GNU Name System | | CADET | ... 148Applications | | GNU Name System | | CADET | ...
151 | +-----------------+ +-------+ 149 | +-----------------+ +-------+
@@ -167,439 +165,467 @@ R5N | v v
167Connectivity | |Underlay| |Underlay| 165Connectivity | |Underlay| |Underlay|
168 | |Link | |Link | 166 | |Link | |Link |
169 | +--------+ +--------+ 167 | +--------+ +--------+
170 ]]></artwork> 168]]>
171 </figure> 169</artwork>
172 <dl> 170</figure>
173 <dt>Applications</dt> 171<dl>
174 <dd> 172<dt>Applications</dt>
175 Applications are components which directly use the DHT overlay 173<dd>
176 interfaces. Possible applications include the GNU Name System 174Applications are components which directly use the DHT overlay
177 <xref target="I-D.draft-schanzen-gns" /> or the CADET transport system 175interfaces. Possible applications include the GNU Name System
178 <xref target="cadet" />. 176<xref target="I-D.draft-schanzen-gns"/> or the CADET transport system
179 </dd> 177<xref target="cadet"/>.
180 <dt>Overlay Interface</dt> 178</dd>
181 <dd> 179<dt>Overlay Interface</dt>
182 The Overlay Interface exposes the core operations of the DHT overlay 180<dd>
183 to applications. 181The Overlay Interface exposes the core operations of the DHT overlay
184 This includes querying and retrieving data from the DHT. 182to applications.
185 </dd> 183This includes querying and retrieving data from the DHT.
186 <dt>Block Storage</dt> 184</dd>
187 <dd> 185<dt>Block Storage</dt>
188 The Block Storage component is used to persist and manage data 186<dd>
189 by nodes. It includes logic for quotas, caching stragegies and 187The Block Storage component is used to persist and manage data
190 data validation. 188by nodes. It includes logic for quotas, caching stragegies and
191 </dd> 189data validation.
192 <dt>Message Processing</dt> 190</dd>
193 <dd> 191<dt>Message Processing</dt>
194 The Message Processing component processes requests from and responses 192<dd>
195 to applications as well as messages from the underlay network. 193The Message Processing component processes requests from and responses
196 </dd> 194to applications as well as messages from the underlay network.
197 <dt>Routing</dt> 195</dd>
198 <dd> 196<dt>Routing</dt>
199 The Routing component includes the routing table as well as 197<dd>
200 routing and node selection logic. It facilitates the R5N routing 198The Routing component includes the routing table as well as
201 algorithm with required data structures and algorithms. 199routing and node selection logic. It facilitates the R5N routing
202 </dd> 200algorithm with required data structures and algorithms.
203 <dt>Underlay Interface</dt> 201</dd>
204 <dd> 202<dt>Underlay Interface</dt>
205 The DHT Underlay Interface is an abstraction layer on top of the 203<dd>
206 supported links of a node. Nodes may be linked by a variety of 204The DHT Underlay Interface is an abstraction layer on top of the
207 different transports, including "classical" protocols such as 205supported links of a node. Nodes may be linked by a variety of
208 TCP, UDP and TLS or advanced protocols such as GNUnet, L2P or Tor. 206different transports, including "classical" protocols such as
209 </dd> 207TCP, UDP and TLS or advanced protocols such as GNUnet, L2P or Tor.
210 </dl> 208</dd>
211 <t> 209</dl>
212 Other glossary 210<t>
213 </t> 211Other glossary
214 <dl> 212</t>
215 <dt>Node</dt> 213<dl>
216 <dd> 214<dt>Node</dt>
217 A node is participant in the network and addressable through the 215<dd>
218 network overlay. 216A node is participant in the network and addressable through the
219 </dd> 217network overlay.
220 <dt>Node Address</dt> 218</dd>
221 <dd> 219<dt>Node Address</dt>
222 The <tt>Node Address</tt> is the identifier used on the Overlay 220<dd>
223 to address a node. 221The <tt>Node Address</tt> is the identifier used on the Overlay
224 </dd> 222to address a node.
225 <dt>Node ID</dt> 223</dd>
226 <dd> 224<dt>Node ID</dt>
227 The <tt>Node ID</tt> is the identity which is used to authenticate 225<dd>
228 a node in the underlay. 226The <tt>Node ID</tt> is the identity which is used to authenticate
229 The <tt>Node Address</tt> is derived from 227a node in the underlay.
230 the <tt>Node ID</tt>. 228The <tt>Node Address</tt> is derived from the <tt>Node ID</tt>.
231 </dd> 229</dd>
232 <dt>Peer</dt> 230<dt>Peer</dt>
233 <dd> 231<dd>
234 A peer is a node which is directly connected to our peer. 232A peer is a node which is directly connected to our peer.
235 </dd> 233</dd>
236 </dl> 234</dl>
237 </section> 235</section>
238 <section anchor="overlay" numbered="true" toc="default"> 236<section anchor="overlay" numbered="true" toc="default">
239 <name>Overlay</name> 237<name>Overlay</name>
240 <t> 238<t>
241 In the DHT overlay, a node is addressable by its 239In the DHT overlay, a node is addressable by its
242 <tt>Node Address</tt>. 240<tt>Node Address</tt>.
243 The <tt>Node Address</tt> is a SHA-512 hash <xref target="RFC4634"/> 241The <tt>Node Address</tt> is a SHA-512 hash <xref target="RFC4634"/>
244 of the <tt>Node ID</tt>. 242of the <tt>Node ID</tt>.
245 <!-- FIXME should the node ID be agile? Should the signature then 243<!-- FIXME should the node ID be agile? Should the signature then
246 also be agile?--> 244also be agile?-->
247 <!--The node public key is the public key of the corresponding 245<!--The node public key is the public key of the corresponding
248 Ed25519<xref target="ed25519" /> node private key.--> 246Ed25519<xref target="ed25519" /> node private key.-->
249 </t> 247</t>
250 <t> 248<t>
251 Any implementation of this specification MUST expose the two API 249Any implementation of this specification MUST expose the two API
252 procedures "GET" and "PUT". 250procedures "GET" and "PUT".
253 </t> 251</t>
254 <section> 252<section>
255 <name>The GET procedure</name> 253<name>The GET procedure</name>
256 <t> 254<t>
257 The GET procedure is defined as follows: 255The GET procedure is defined as follows:
258 </t> 256</t>
259 <artwork name="" type="" align="left" alt=""><![CDATA[ 257<t>
260GET(Key[, GetParams]) -> Results as List 258<tt>GET(Key[, GetParams]) -> Results as List</tt>
261 ]]></artwork> 259</t>
262 <t> 260<t>
263 The procedure takes a single additional <tt>QueryParams</tt> 261The procedure takes a single additional <tt>QueryParams</tt>
264 argument in order to specify detailed query parameters. 262argument in order to specify detailed query parameters.
265 The <tt>GetParams</tt> consist of the following parameters: 263The <tt>GetParams</tt> consist of the following parameters:
266 </t> 264</t>
267 <dl> 265<dl>
268 <dt>BlockType</dt> 266<dt>BlockType</dt>
269 <dd> 267<dd>
270 The default setting of this parameter is to request any type of 268The default setting of this parameter is to request any type of
271 block types under the key. 269block types under the key.
272 </dd> 270</dd>
273 <dt>ReplicationLevel</dt> 271<dt>ReplicationLevel</dt>
274 <dd>The default setting of this parameter is X (FIXME).</dd> 272<dd>The default setting of this parameter is X (FIXME).</dd>
275 <dt>RouteOptions</dt> 273<dt>RouteOptions</dt>
276 <dd> 274<dd>
277 are used in order to indicate certain 275are used in order to indicate certain
278 processing requirements for messages. 276processing requirements for messages.
279 Any combination of options as defined in <xref target="route_options"/> 277Any combination of options as defined in <xref target="route_options"/>
280 may be specificied. 278may be specificied.
281 The default setting of this parameter is that no option is set. 279The default setting of this parameter is that no option is set.
282 </dd> 280</dd>
283 <dt>XQuery</dt> 281<dt>XQuery</dt>
284 <dd> 282<dd>
285 is extended query medatadata which may be 283is extended query medatadata which may be
286 required depending on the respective <tt>BlockType</tt>. 284required depending on the respective <tt>BlockType</tt>.
287 A <tt>BlockType</tt> must define if the <tt>XQuery</tt> can or must 285A <tt>BlockType</tt> must define if the <tt>XQuery</tt> can or must
288 be used and what the specific format of its contents should be. 286be used and what the specific format of its contents should be.
289 See also <xref target="block_types"/>. 287See also <xref target="block_types"/>.
290 The default setting of this parameter is empty. 288The default setting of this parameter is empty.
291 </dd> 289</dd>
292 </dl> 290</dl>
293 <t> 291<t>
294 The <tt>RouteOptions</tt> consist of the following flags: 292The <tt>RouteOptions</tt> consist of the following flags:
295 </t> 293</t>
296 <dl anchor="route_options"> 294<dl anchor="route_options">
297 <dt>DemultiplexEverywhere</dt> 295<dt>DemultiplexEverywhere</dt>
298 <dd> 296<dd>
299 indicates that each node along the way should process the request. 297indicates that each node along the way should process the request.
300 </dd> 298</dd>
301 <dt>RecordRoute</dt> 299<dt>RecordRoute</dt>
302 <dd> 300<dd>
303 indicates to keep track of the route that the message takes 301indicates to keep track of the route that the message takes
304 in the P2P network. 302in the P2P network.
305 </dd> 303</dd>
306 <dt>FindNode</dt> 304<dt>FindNode</dt>
307 <dd> 305<dd>
308 indicates that this is a request used to find additional nodes. 306indicates that this is a request used to find additional nodes.
309 This is a special flag which modifies the message processing to 307This is a special flag which modifies the message processing to
310 allow approximate results. 308allow approximate results.
311 </dd> 309</dd>
312 </dl> 310</dl>
313 <t> 311<t>
314 As the time it takes for results to arrive may vary an implementation 312As the time it takes for results to arrive may vary an implementation
315 may either return a list of results after a timeout or allow the 313may either return a list of results after a timeout or allow the
316 caller to provide a callback function which is called for any result 314caller to provide a callback function which is called for any result
317 received from the DHT until the procedure is cancelled. 315received from the DHT until the procedure is cancelled.
318 </t> 316</t>
319 </section> 317</section>
320 <section> 318<section>
321 <name>The PUT procedure</name> 319<name>The PUT procedure</name>
322 <t> 320<t>
323 The PUT procedure is defined as follows: 321The PUT procedure is defined as follows:
324 </t> 322</t>
325 <artwork name="" type="" align="left" alt=""><![CDATA[ 323<t>
326PUT(Key, Block, BlockType[, PutParams]) 324<tt>PUT(Key, Block, BlockType[, PutParams])</tt>
327 ]]></artwork> 325</t>
328 <t> 326<t>
329 The procedure takes three mandatory arguments. 327The procedure takes three mandatory arguments.
330 The first argument is the query 328The first argument is the query
331 key under which the block is to be stored. 329key under which the block is to be stored.
332 The second parameter is the block payload. 330The second parameter is the block payload.
333 The third parameter is the type of the block payload. 331The third parameter is the type of the block payload.
334 Block types are defined in <xref target="block_types"/>. 332Block types are defined in <xref target="block_types"/>.
335 The PUT procedure also allows an optional <tt>PutParams</tt> 333The PUT procedure also allows an optional <tt>PutParams</tt>
336 parameter. 334parameter.
337 </t> 335</t>
338 <dl> 336<dl>
339 <dt>ReplicationLevel</dt> 337<dt>ReplicationLevel</dt>
340 <dd>The default setting of this parameter is X (FIXME).</dd> 338<dd>The default setting of this parameter is X (FIXME).</dd>
341 <dt>RouteOptions</dt> 339<dt>RouteOptions</dt>
342 <dd> 340<dd>
343 are used in order to indicate certain 341are used in order to indicate certain
344 processing requirements for messages. 342processing requirements for messages.
345 Any combination of options as defined in <xref target="route_options"/> 343Any combination of options as defined in <xref target="route_options"/>
346 may be specificied. 344may be specificied.
347 The default setting of this parameter is that no option is set. 345The default setting of this parameter is that no option is set.
348 </dd> 346</dd>
349 <dt>Expiration</dt> 347<dt>Expiration</dt>
350 <dd> 348<dd>
351 is the requested expiration date for the block payload. 349is the requested expiration date for the block payload.
352 </dd> 350</dd>
353 </dl> 351</dl>
354 </section> 352</section>
355 </section> 353</section>
356 <section anchor="underlay" numbered="true" toc="default"> 354<section anchor="underlay" numbered="true" toc="default">
357 <name>Underlay</name> 355<name>Underlay</name>
358 <t> 356<t>
359 In the network underlay, a node is addressable by traditional 357In the network underlay, a node is addressable by traditional
360 means out of scope of this document. For example, the node may 358means out of scope of this document. For example, the node may
361 have a TCP/IP address, or a HTTPS endpoint. 359have a TCP/IP address, or a HTTPS endpoint.
362 While the specific addressing options and mechanisms are out of scope 360While the specific addressing options and mechanisms are out of scope
363 for this document, it is necessary to define a universal addressing 361for this document, it is necessary to define a universal addressing
364 format in order to facilitate the distribution of connectivity 362format in order to facilitate the distribution of connectivity
365 information to other nodes in the DHT overlay. 363information to other nodes in the DHT overlay.
366 This format is the "HELLO" message. 364This format is the "HELLO" message.
367 </t> 365</t>
368 366<!--
369 <!-- 3671) The current API is always fire+forget, it doesn't allow for flow
370 1) The current API is always fire+forget, it doesn't allow for flow 368control. I think we need to add that, possibly for sending and receiving.
371 control. I think we need to add that, possibly for sending and receiving.
372 369
373 IDK. 370IDK.
374 371
3752) I'm not sure what to do with the crypto: mandate EdDSA or allow the 3722) I'm not sure what to do with the crypto: mandate EdDSA or allow the
376 underlay to do whatever public keys it likes. 373underlay to do whatever public keys it likes.
377 374
378 We need keys in the overlay. (Path signatures). Do they need to 375We need keys in the overlay. (Path signatures). Do they need to
379 be the same keys??? 376be the same keys???
380 377
3813) I think we may want to mandate that the lower layer at least 3783) I think we may want to mandate that the lower layer at least
382authenticate the other node (i.e. every UDP message could be in 379authenticate the other node (i.e. every UDP message could be in
383cleartext, but would need to come with an EdDSA signature, alas 92 byte 380cleartext, but would need to come with an EdDSA signature, alas 92 byte
384overhead and a signature verification _required_). Otherwise, I don't 381overhead and a signature verification _required_). Otherwise, I don't
385see how we can offer even the most minimal protections against node 382see how we can offer even the most minimal protections against node
386 impersonation attacks. WDYT? 383impersonation attacks. WDYT?
387
388 Security considerations? Prerequisites?
389 -->
390 <t>
391 It is expected that there are basic mechanisms available to
392 manage node connectivity and addressing.
393 The required functionality are abstracted through the following
394 procedures and events:
395 </t>
396 <dl>
397 <dt><tt>PEER_CONNECTED(P)</tt></dt>
398 <dd>
399 is a signal that allows the DHT to react to a newly connected peer
400 <tt>N</tt>.
401 Such an event triggers, for example, updates in the
402 routing table.
403 </dd>
404 <dt><tt>PEER_DISCONNECTED(P)</tt></dt>
405 <dd>
406 is a signal that allows the DHT to react to a recently disconnected
407 peer.
408 Such an event triggers, for example, updates in the
409 routing table.
410 </dd>
411 <dt><tt>TRY_CONNECT(N, A)</tt></dt>
412 <dd>
413 A function which allows the local node to attempt the establishment of
414 a connection to another node <tt>N</tt> using an address <tt>A</tt>.
415 When the connection attempt is successful, information on the new
416 peer is offered through the <tt>PEER_CONNECTED</tt> signal.
417 </dd>
418 <dt><tt>HOLD(P)</tt></dt>
419 <dd>
420 A function which tells the underlay to keep a hold on the connection
421 to a peer <tt>P</tt>. FIXME what is this needed for?
422 </dd>
423 <dt><tt>DROP(P)</tt></dt>
424 <dd>
425 A function which tells the underlay to drop the connection to a
426 peer <tt>P</tt>. FIXME what is this needed for?
427 </dd>
428 <dt><tt>RECEIVE(P, M)</tt></dt>
429 <dd>
430 A function or event that allows the local node to receive a protocol
431 message <tt>M</tt> as defined in this document from a peer <tt>P</tt>.
432 </dd>
433 <dt><tt>SEND(P, M)</tt></dt>
434 <dd>
435 A function that allows the local node to send a protocol message
436 <tt>M</tt> as defined in this document to a peer <tt>P</tt>.
437 If call to SEND fails, the message has not been sent.
438 </dd>
439 <dt><tt>NETWORK_SIZE_ESTIMATE(S)</tt></dt>
440 <dd>
441 A function or event that provides estimates on the network size
442 <tt>S</tt> for use in the DHT routing algorithms.
443 FIXME: What is S and give an example.
444 </dd>
445 <dt><tt>ADDRESS_ADDED(A)</tt></dt>
446 <dd>
447 The underlay signals us that an address <tt>A</tt> was added for our
448 local node.
449 This information is used to advertise
450 connectivity information to the local node.
451 <tt>A</tt> is a string suitable for inclusion in a HELLO payload
452 <xref target="hello_block"/>.
453 </dd>
454 <dt><tt>ADDRESS_DELETED(A)</tt></dt>
455 <dd>
456 The underlay signals us that an address <tt>A</tt> was removed.
457 This information is used, for example, to no longer advertise
458 this address.
459 </dd>
460 <dt><tt>VERIFY(blob)</tt></dt>
461 <dd>
462 Signature verification by underlay. FIXME unclear. Required?
463 </dd>
464 </dl>
465 </section>
466
467 <section anchor="routing" numbered="true" toc="default">
468 <name>Routing</name>
469 <section anchor="peer_storage">
470 <name>Peer Storage</name>
471 <t>
472 A R5N implementation must store the information on connected nodes
473 and update changes accordingly in a local persistance component such
474 as a database.
475 Upon receiving a connection notification from the Underlay through
476 <tt>NODE_CONNECTED</tt>, information on the new peer is added to the
477 local peer storage.
478 When disconnect is indicated by the Underlay through
479 <tt>NODE_DISCONNECTED</tt> the peer MUST be removed from the local
480 peer storage.
481 The data structure for managing connected nodes and their
482 metadata may be implemented using the k-buckets concept of
483 <xref target="Kademlia"/>.
484 In order to select nodes which are suitable destinations for
485 routing messages, R5N uses a hybrid approach:
486 Given an estimated network size N, the node selection for the
487 first N hops is random. After the initial N hops, node selection
488 follows an XOR-based node distance calculation.
489 </t>
490 </section>
491 <section anchor="routing_table">
492 <name>Routing Table</name>
493 <t>
494 As the message traverses a random path through the network for the
495 first N hops, it is essential that routing loops are avoided.
496 In R5N, a bloomfilter is used as part of the routing metadata in
497 messages. The bloomfilter is updates at each hop with the hops
498 node identity.
499 For the next hop selection in both the random and the deterministic
500 case, any node which is in the bloomfilter for the respective message
501 is not included in the node selection process.
502 </t>
503 <t>
504 The R5N routing component MUST implement the following functions:
505 </t>
506 <dl>
507 <dt><tt>GetDistance(A, B) -> Distance as Integer</tt></dt>
508 <dd>
509 this function calculates the binary XOR between A and B.
510 The resulting distance is interpreted as an integer where
511 the leftmost bit is the most significant bit.
512 </dd>
513 <dt><tt>SelectClosestNode(K, B) -> N</tt></dt>
514 <dd>
515 This function selects the connected node <tt>N</tt> from our
516 routing table with the shortest XOR-distance to the key <tt>K</tt>.
517 This means that for all other nodes <tt>N'</tt> in the routing table
518 <tt>GetDistance(N, K) &lt; GetDistance(N',K)</tt>.
519 Nodes in the bloomfilter <tt>B</tt> are not considered.
520 </dd>
521 <dt><tt>SelectRandomNode(B) -> N</tt></dt>
522 <dd>
523 This function selects a random node <tt>N</tt> from all connected
524 nodes.
525 Nodes in the bloomfilter <tt>B</tt> are not considered.
526 </dd>
527 <dt><tt>SelectNode(K, H, B) -> N</tt></dt>
528 <dd>
529 This function selects a node <tt>N</tt> depending on the
530 number of hops <tt>H</tt> parameter.
531 If <tt>H &lt; NETWORK_SIZE_ESTIMATE</tt>
532 this function MUST return <tt>SelectRandomNode()</tt> and
533 <tt>SelectClosestnode(K)</tt> otherwise.
534 Nodes in the bloomfilter <tt>B</tt> are not considered.
535 </dd>
536 <dt><tt>IsClosestNode(N, K, B) -> true | false</tt></dt>
537 <dd>
538 checks if <tt>N</tt> is the closest node for <tt>K</tt>
539 (cf. <tt>SelectClosestNode(K)</tt>).
540 Nodes in the bloomfilter <tt>B</tt> are not considered.
541 </dd>
542 </dl>
543 </section>
544 </section>
545 <section anchor="p2p_messages" numbered="true" toc="default">
546 <name>Message Processing</name>
547 <t>
548 The implementation MUST listen for <tt>RECEIVE(P, M)</tt> signals
549 from the Underlay and respond to the respective messages sent by
550 the peer <tt>P</tt>.
551 In the following, the wire formats of the messages and the required
552 processing are detailed.
553 The local node address is referred to as <tt>N</tt>.
554 </t>
555 <section anchor="p2p_bf" numbered="true" toc="default">
556 <name>Bloomfilter</name>
557 <t>
558 In order to prevent circular routes, GET and PUT messages contain
559 a 128-bit Bloom filter (m=128). The Bloom filter is used to detect duplicate
560 node addresses along the route.
561 A Bloom filter "bf" is initially empty, consisting only of zeroes.
562 There are two functions which can be invoked on the Bloom filter:
563 BF-SET(bf, e) and BF-TEST(bf, e) where "e" is an element which is to
564 be added to the Bloom filter or queried against the set.
565 Any bloom filter uses k=16 different hash functions each of which is
566 defined as follows:
567 </t>
568 <figure>
569 <artwork name="" type="" align="left" alt=""><![CDATA[
570BF-TEST(key, bloomfilter)
571 H_key := SHA512 (key) as UINT32[]
572 FOR i IN 0..15
573 bit := H_key[i] % 1024
574 IF bloomfilter[bit] IS SET
575 RETURN TRUE
576 END
577 END
578 RETURN FALSE
579END
580 384
581BF-SET(key, bloomfilter) 385Security considerations? Prerequisites?
582 H_key := SHA512 (key) as UINT32[] 386-->
583 FOR i IN 0..15 387<t>
584 bit := H_key[i] % 1024 388It is expected that there are basic mechanisms available to
585 bloomfilter[bit] := 1 389manage node connectivity and addressing.
586 END 390The required functionality are abstracted through the following
587END 391procedures and events:
588 ]]></artwork> 392</t>
589 </figure> 393<dl>
590 394<dt>
591 395<tt>PEER_CONNECTED(P)</tt>
592 </section> 396</dt>
593 <section anchor="p2p_xq" numbered="true" toc="default"> 397<dd>
594 <name>Extended query</name> 398is a signal that allows the DHT to react to a newly connected peer
595 <t>TODO: Talk about XQuery in the context of messages.</t> 399<tt>N</tt>.
596 </section> 400Such an event triggers, for example, updates in the
597 <section anchor="p2p_put" numbered="true" toc="default"> 401routing table.
598 <name>PutMessage</name> 402</dd>
599 <section anchor="p2p_put_wire"> 403<dt>
600 <name>Wire Format</name> 404<tt>PEER_DISCONNECTED(P)</tt>
601 <figure anchor="figure_putmsg"> 405</dt>
602 <artwork name="" type="" align="left" alt=""><![CDATA[ 406<dd>
407is a signal that allows the DHT to react to a recently disconnected
408peer.
409Such an event triggers, for example, updates in the
410routing table.
411</dd>
412<dt>
413<tt>TRY_CONNECT(N, A)</tt>
414</dt>
415<dd>
416A function which allows the local node to attempt the establishment of
417a connection to another node <tt>N</tt> using an address <tt>A</tt>.
418When the connection attempt is successful, information on the new
419peer is offered through the <tt>PEER_CONNECTED</tt> signal.
420</dd>
421<dt>
422<tt>HOLD(P)</tt>
423</dt>
424<dd>
425A function which tells the underlay to keep a hold on the connection
426to a peer <tt>P</tt>. FIXME what is this needed for?
427</dd>
428<dt>
429<tt>DROP(P)</tt>
430</dt>
431<dd>
432A function which tells the underlay to drop the connection to a
433peer <tt>P</tt>. FIXME what is this needed for?
434</dd>
435<dt>
436<tt>RECEIVE(P, M)</tt>
437</dt>
438<dd>
439A function or event that allows the local node to receive a protocol
440message <tt>M</tt> as defined in this document from a peer <tt>P</tt>.
441</dd>
442<dt>
443<tt>SEND(P, M)</tt>
444</dt>
445<dd>
446A function that allows the local node to send a protocol message
447<tt>M</tt> as defined in this document to a peer <tt>P</tt>.
448If call to SEND fails, the message has not been sent.
449</dd>
450<dt>
451<tt>NETWORK_SIZE_ESTIMATE(S)</tt>
452</dt>
453<dd>
454A function or event that provides estimates on the network size
455<tt>S</tt> for use in the DHT routing algorithms.
456FIXME: What is S and give an example.
457</dd>
458<dt>
459<tt>ADDRESS_ADDED(A)</tt>
460</dt>
461<dd>
462The underlay signals us that an address <tt>A</tt> was added for our
463local node.
464This information is used to advertise
465connectivity information to the local node.
466<tt>A</tt> is a string suitable for inclusion in a HELLO payload
467<xref target="hello_block"/>.
468</dd>
469<dt>
470<tt>ADDRESS_DELETED(A)</tt>
471</dt>
472<dd>
473The underlay signals us that an address <tt>A</tt> was removed.
474This information is used, for example, to no longer advertise
475this address.
476</dd>
477<dt>
478<tt>VERIFY(blob)</tt>
479</dt>
480<dd>
481Signature verification by underlay. FIXME unclear. Required?
482</dd>
483</dl>
484</section>
485<section>
486<name>Bootstrapping</name>
487<t>
488It is assumed that the node is already connected to at least
489one other node.
490First, those initial nodes are sorted into their respective buckets.
491</t>
492<t>
493In order to find the closest nodes in the network to itself, an
494implementation MUST now periodically send HELLO GET queries for its own
495node address.
496Both the "record route" and "find node" message options are set in the
497GET queries in order to learn nodes and network topology from the
498message route and in order to receive approximate replies to the
499query key (the node address).
500</t>
501<t>FIXME: Periodically -&gt; more specific? No. Frequency may be adapted depending on network conditions, known nodes, busy/idle etc.</t>
502<t>
503Any implementation encountering a HELLO GET request initially
504sends its own node address if it.
505</t>
506</section>
507<section anchor="routing" numbered="true" toc="default">
508<name>Routing</name>
509<section anchor="peer_storage">
510<name>Peer Storage</name>
511<t>
512A R5N implementation must store the information on connected nodes
513and update changes accordingly in a local persistance component such
514as a database.
515Upon receiving a connection notification from the Underlay through
516<tt>NODE_CONNECTED</tt>, information on the new peer is added to the
517local peer storage.
518When disconnect is indicated by the Underlay through
519<tt>NODE_DISCONNECTED</tt> the peer MUST be removed from the local
520peer storage.
521The data structure for managing connected nodes and their
522metadata may be implemented using the k-buckets concept of
523<xref target="Kademlia"/>.
524In order to select nodes which are suitable destinations for
525routing messages, R5N uses a hybrid approach:
526Given an estimated network size N, the node selection for the
527first N hops is random. After the initial N hops, node selection
528follows an XOR-based node distance calculation.
529</t>
530</section>
531<section anchor="routing_table">
532<name>Routing Table</name>
533<t>
534As the message traverses a random path through the network for the
535first N hops, it is essential that routing loops are avoided.
536In R5N, a bloomfilter is used as part of the routing metadata in
537messages. The bloomfilter is updates at each hop with the hops
538node identity.
539For the next hop selection in both the random and the deterministic
540case, any node which is in the bloomfilter for the respective message
541is not included in the node selection process.
542</t>
543<t>
544The R5N routing component MUST implement the following functions:
545</t>
546<dl>
547<dt>
548<tt>GetDistance(A, B) -&gt; Distance as Integer</tt>
549</dt>
550<dd>
551this function calculates the binary XOR between A and B.
552The resulting distance is interpreted as an integer where
553the leftmost bit is the most significant bit.
554</dd>
555<dt>
556<tt>SelectClosestNode(K, B) -&gt; N</tt>
557</dt>
558<dd>
559This function selects the connected node <tt>N</tt> from our
560routing table with the shortest XOR-distance to the key <tt>K</tt>.
561This means that for all other nodes <tt>N'</tt> in the routing table
562<tt>GetDistance(N, K) &lt; GetDistance(N',K)</tt>.
563Nodes in the bloomfilter <tt>B</tt> are not considered.
564</dd>
565<dt>
566<tt>SelectRandomNode(B) -&gt; N</tt>
567</dt>
568<dd>
569This function selects a random node <tt>N</tt> from all connected
570nodes.
571Nodes in the bloomfilter <tt>B</tt> are not considered.
572</dd>
573<dt>
574<tt>SelectNode(K, H, B) -&gt; N</tt>
575</dt>
576<dd>
577This function selects a node <tt>N</tt> depending on the
578number of hops <tt>H</tt> parameter.
579If <tt>H &lt; NETWORK_SIZE_ESTIMATE</tt>
580this function MUST return <tt>SelectRandomNode()</tt> and
581<tt>SelectClosestnode(K)</tt> otherwise.
582Nodes in the bloomfilter <tt>B</tt> are not considered.
583</dd>
584<dt>
585<tt>IsClosestNode(N, K, B) -&gt; true | false</tt>
586</dt>
587<dd>
588checks if <tt>N</tt> is the closest node for <tt>K</tt>
589(cf. <tt>SelectClosestNode(K)</tt>).
590Nodes in the bloomfilter <tt>B</tt> are not considered.
591</dd>
592</dl>
593</section>
594</section>
595<section anchor="p2p_messages" numbered="true" toc="default">
596<name>Message Processing</name>
597<t>
598The implementation MUST listen for <tt>RECEIVE(P, M)</tt> signals
599from the Underlay and respond to the respective messages sent by
600the peer <tt>P</tt>.
601In the following, the wire formats of the messages and the required
602processing are detailed.
603The local node address is referred to as <tt>N</tt>.
604</t>
605<section anchor="p2p_bf" numbered="true" toc="default">
606<name>Bloomfilter</name>
607<t>
608In order to prevent circular routes, GET and PUT messages contain
609a 128-bit Bloom filter (m=128). The Bloom filter is used to detect duplicate
610node addresses along the route.
611A Bloom filter "bf" is initially empty, consisting only of zeroes.
612There are two functions which can be invoked on the Bloom filter:
613BF-SET(bf, e) and BF-TEST(bf, e) where "e" is an element which is to
614be added to the Bloom filter or queried against the set.
615Any bloom filter uses k=16 different hash functions each of which is
616defined as follows:
617</t>
618</section>
619<section anchor="p2p_xq" numbered="true" toc="default">
620<name>Extended query</name>
621<t>TODO: Talk about XQuery in the context of messages.</t>
622</section>
623<section anchor="p2p_put" numbered="true" toc="default">
624<name>PutMessage</name>
625<section anchor="p2p_put_wire">
626<name>Wire Format</name>
627<figure anchor="figure_putmsg">
628<artwork name="" type="" align="left" alt=""><![CDATA[
6030 8 16 24 32 40 48 56 6290 8 16 24 32 40 48 56
604+-----+-----+-----+-----+-----+-----+-----+-----+ 630+-----+-----+-----+-----+-----+-----+-----+-----+
605| MSIZE | MTYPE | BTYPE | 631| MSIZE | MTYPE | BTYPE |
@@ -618,133 +644,133 @@ END
618+-----+-----+-----+-----+-----+-----+-----+-----+ 644+-----+-----+-----+-----+-----+-----+-----+-----+
619/ BLOCK (variable length) / 645/ BLOCK (variable length) /
620+-----+-----+-----+-----+-----+-----+-----+-----+ 646+-----+-----+-----+-----+-----+-----+-----+-----+
621 ]]></artwork> 647]]></artwork>
622 </figure> 648</figure>
623 <t>where:</t> 649<t>where:</t>
624 <dl> 650<dl>
625 <dt>MSIZE</dt> 651<dt>MSIZE</dt>
626 <dd> 652<dd>
627 denotes the size of this message in network byte order. 653denotes the size of this message in network byte order.
628 </dd> 654</dd>
629 <dt>MTYPE</dt> 655<dt>MTYPE</dt>
630 <dd> 656<dd>
631 is the 16-bit message type. This type can be one of the DHT message 657is the 16-bit message type. This type can be one of the DHT message
632 types but for put messages it must be set to 658types but for put messages it must be set to
633 the value 146 in network byte order. 659the value 146 in network byte order.
634 </dd> 660</dd>
635 <dt>BTYPE</dt> 661<dt>BTYPE</dt>
636 <dd> 662<dd>
637 is a 32-bit block type field. The block type indicates the content 663is a 32-bit block type field. The block type indicates the content
638 type of the payload. In network byte order. 664type of the payload. In network byte order.
639 </dd> 665</dd>
640 <dt>OPTIONS</dt> 666<dt>OPTIONS</dt>
641 <dd> 667<dd>
642 is a 16-bit options field (see below). 668is a 16-bit options field (see below).
643 </dd> 669</dd>
644 <dt>HOPCOUNT</dt> 670<dt>HOPCOUNT</dt>
645 <dd> 671<dd>
646 is a 16-bit number indicating how many hops this message has 672is a 16-bit number indicating how many hops this message has
647 traversed to far. In network byte order. 673traversed to far. In network byte order.
648 </dd> 674</dd>
649 <dt>REPL_LVL</dt> 675<dt>REPL_LVL</dt>
650 <dd> 676<dd>
651 is a 16-bit number indicating the desired replication level of 677is a 16-bit number indicating the desired replication level of
652 the data. In network byte order. 678the data. In network byte order.
653 </dd> 679</dd>
654 <dt>PATH_LEN</dt> 680<dt>PATH_LEN</dt>
655 <dd> 681<dd>
656 is a 16-bit number indicating the length of the PUT path recorded 682is a 16-bit number indicating the length of the PUT path recorded
657 in PUTPATH. 683in PUTPATH.
658 As PUTPATH is optional, this value may be zero. 684As PUTPATH is optional, this value may be zero.
659 In network byte order. 685In network byte order.
660 </dd> 686</dd>
661 <dt>EXPIRATION</dt> 687<dt>EXPIRATION</dt>
662 <dd> 688<dd>
663 denotes the absolute 64-bit expiration date of the content. 689denotes the absolute 64-bit expiration date of the content.
664 In microseconds since midnight (0 hour), January 1, 1970 in network 690In microseconds since midnight (0 hour), January 1, 1970 in network
665 byte order. 691byte order.
666 </dd> 692</dd>
667 <dt>BLOOMFILTER</dt> 693<dt>BLOOMFILTER</dt>
668 <dd> 694<dd>
669 A bloomfilter (for node addresses) to stop circular routes. 695A bloomfilter (for node addresses) to stop circular routes.
670 </dd> 696</dd>
671 <dt>KEY</dt> 697<dt>KEY</dt>
672 <dd> 698<dd>
673 The key under which the PUT request wants to store content 699The key under which the PUT request wants to store content
674 under. 700under.
675 </dd> 701</dd>
676 <dt>PUTPATH</dt> 702<dt>PUTPATH</dt>
677 <dd> 703<dd>
678 the variable-length PUT path. 704the variable-length PUT path.
679 The path consists of a list of PATH_LEN node addresses. 705The path consists of a list of PATH_LEN node addresses.
680 </dd> 706</dd>
681 <dt>BLOCK</dt> 707<dt>BLOCK</dt>
682 <dd> 708<dd>
683 the variable-length block payload. The contents are determined 709the variable-length block payload. The contents are determined
684 by the BTYPE field. 710by the BTYPE field.
685 </dd> 711</dd>
686 </dl> 712</dl>
687 </section> 713</section>
688 <section anchor="p2p_put_processing"> 714<section anchor="p2p_put_processing">
689 <name>Processing</name> 715<name>Processing</name>
690 <t> 716<t>
691 Upon receiving a <tt>PutMessage</tt> from a peer <tt>P</tt>. 717Upon receiving a <tt>PutMessage</tt> from a peer <tt>P</tt>.
692 An implementation MUST process it step by step as follows: 718An implementation MUST process it step by step as follows:
693 </t> 719</t>
694 <ol> 720<ol>
695 <li> 721<li>
696 The <tt>EXPIRATION</tt> field is evaluated. 722The <tt>EXPIRATION</tt> field is evaluated.
697 If the message is expired, it MUST be discarded. 723If the message is expired, it MUST be discarded.
698 </li> 724</li>
699 <li> 725<li>
700 If the <tt>BTYPE</tt> is not supported by the implementation, 726If the <tt>BTYPE</tt> is not supported by the implementation,
701 no validation of the block payload is performed and processing 727no validation of the block payload is performed and processing
702 continues at (4). 728continues at (4).
703 Else, the block MUST be validated as defined in (3). 729Else, the block MUST be validated as defined in (3).
704 </li> 730</li>
705 <li> 731<li>
706 The block payload of the message is evaluated using according 732The block payload of the message is evaluated using according
707 to the <tt>BTYPE</tt> using the respective 733to the <tt>BTYPE</tt> using the respective
708 <tt>ValidateBlockStoreRequest</tt> procedure. 734<tt>ValidateBlockStoreRequest</tt> procedure.
709 If the block payload is invalid or does not match the key, 735If the block payload is invalid or does not match the key,
710 it MUST be discarded. 736it MUST be discarded.
711 </li> 737</li>
712 <li> 738<li>
713 The node address of the sender peer <tt>P</tt> SHOULD be in <tt>BLOOMFILTER</tt>. 739The node address of the sender peer <tt>P</tt> SHOULD be in <tt>BLOOMFILTER</tt>.
714 If not, the implementation MAY log an error, but MUST continue. 740If not, the implementation MAY log an error, but MUST continue.
715 </li> 741</li>
716 <li> 742<li>
717 If the <tt>RecordRoute</tt> flag is set in OPTIONS, 743If the <tt>RecordRoute</tt> flag is set in OPTIONS,
718 the local node address MUST be appended to the <tt>PUTPATH</tt> 744the local node address MUST be appended to the <tt>PUTPATH</tt>
719 of the message. 745of the message.
720 </li> 746</li>
721 <li> 747<li>
722 If the local node is the closest node 748If the local node is the closest node
723 (cf. <tt>IsClosestNode(N, Key)</tt>) or the <tt>DemultiplexEverywhere</tt> 749(cf. <tt>IsClosestNode(N, Key)</tt>) or the <tt>DemultiplexEverywhere</tt>
724 options flag ist set, the message MUST 750options flag ist set, the message MUST
725 be stored locally in the block storage. 751be stored locally in the block storage.
726 </li> 752</li>
727 <li> 753<li>
728 Given the value in <tt>REPL_LVL</tt>, the number of peers to 754Given the value in <tt>REPL_LVL</tt>, the number of peers to
729 forward to MUST be calculated. If there is at least one 755forward to MUST be calculated. If there is at least one
730 peers to forward to, the implementation SHOULD select up to this 756peers to forward to, the implementation SHOULD select up to this
731 number of peers to forward the message to. The implementation MAY 757number of peers to forward the message to. The implementation MAY
732 forward to fewer or no peers in order to handle resource constraints 758forward to fewer or no peers in order to handle resource constraints
733 such as bandwidth. 759such as bandwidth.
734 Finally, the local node address MUST be added to the 760Finally, the local node address MUST be added to the
735 <tt>BLOOMFILTER</tt> of the forwarded message. 761<tt>BLOOMFILTER</tt> of the forwarded message.
736 For all peers with node address <tt>P</tt> chosen to forward the message 762For all peers with node address <tt>P</tt> chosen to forward the message
737 to, <tt>SEND(P, PutMessage)</tt> is called. 763to, <tt>SEND(P, PutMessage)</tt> is called.
738 </li> 764</li>
739 </ol> 765</ol>
740 </section> 766</section>
741 </section> 767</section>
742 <section anchor="p2p_get" numbered="true" toc="default"> 768<section anchor="p2p_get" numbered="true" toc="default">
743 <name>GetMessage</name> 769<name>GetMessage</name>
744 <section anchor="p2p_get_wire"> 770<section anchor="p2p_get_wire">
745 <name>Wire Format</name> 771<name>Wire Format</name>
746 <figure anchor="figure_getmsg"> 772<figure anchor="figure_getmsg">
747 <artwork name="" type="" align="left" alt=""><![CDATA[ 773<artwork name="" type="" align="left" alt=""><![CDATA[
7480 8 16 24 32 40 48 56 7740 8 16 24 32 40 48 56
749+-----+-----+-----+-----+-----+-----+-----+-----+ 775+-----+-----+-----+-----+-----+-----+-----+-----+
750| MSIZE | MTYPE | BTYPE | 776| MSIZE | MTYPE | BTYPE |
@@ -763,135 +789,135 @@ END
763+-----+-----+-----+-----+-----+-----+-----+-----+ 789+-----+-----+-----+-----+-----+-----+-----+-----+
764/ BF_RESULT (variable length) / 790/ BF_RESULT (variable length) /
765+-----+-----+-----+-----+-----+-----+-----+-----+ 791+-----+-----+-----+-----+-----+-----+-----+-----+
766 ]]></artwork> 792]]></artwork>
767 </figure> 793</figure>
768 <t>where:</t> 794<t>where:</t>
769 <dl> 795<dl>
770 <dt>MSIZE</dt> 796<dt>MSIZE</dt>
771 <dd> 797<dd>
772 denotes the size of this message in network byte order. 798denotes the size of this message in network byte order.
773 </dd> 799</dd>
774 <dt>MTYPE</dt> 800<dt>MTYPE</dt>
775 <dd> 801<dd>
776 is the 16-bit message type. It must be set to 802is the 16-bit message type. It must be set to
777 the value 147 in network byte order. 803the value 147 in network byte order.
778 </dd> 804</dd>
779 <dt>BTYPE</dt> 805<dt>BTYPE</dt>
780 <dd> 806<dd>
781 is a 32-bit block type field. The block type indicates the content 807is a 32-bit block type field. The block type indicates the content
782 type of the payload. In network byte order. 808type of the payload. In network byte order.
783 </dd> 809</dd>
784 <dt>OPTIONS</dt> 810<dt>OPTIONS</dt>
785 <dd> 811<dd>
786 is a 16-bit options field (see below). 812is a 16-bit options field (see below).
787 </dd> 813</dd>
788 <dt>HOPCOUNT</dt> 814<dt>HOPCOUNT</dt>
789 <dd> 815<dd>
790 is a 16-bit number indicating how many hops this message has 816is a 16-bit number indicating how many hops this message has
791 traversed to far. In network byte order. 817traversed to far. In network byte order.
792 </dd> 818</dd>
793 <dt>REPL_LVL</dt> 819<dt>REPL_LVL</dt>
794 <dd> 820<dd>
795 is a 16-bit number indicating the desired replication level of 821is a 16-bit number indicating the desired replication level of
796 the data. In network byte order. 822the data. In network byte order.
797 </dd> 823</dd>
798 <dt>XQ_SIZE</dt> 824<dt>XQ_SIZE</dt>
799 <dd> 825<dd>
800 is a 32-bit number indicating the length of the optional 826is a 32-bit number indicating the length of the optional
801 extended query XQUERY. In network byte order. 827extended query XQUERY. In network byte order.
802 </dd> 828</dd>
803 <dt>BLOOMFILTER</dt> 829<dt>BLOOMFILTER</dt>
804 <dd> 830<dd>
805 A bloomfilter (for node identities) to stop circular routes. 831A bloomfilter (for node identities) to stop circular routes.
806 </dd> 832</dd>
807 <dt>KEY</dt> 833<dt>KEY</dt>
808 <dd> 834<dd>
809 The key under which the PUT request wants to store content 835The key under which the PUT request wants to store content
810 under. 836under.
811 </dd> 837</dd>
812 <dt>XQUERY</dt> 838<dt>XQUERY</dt>
813 <dd> 839<dd>
814 the variable-length extended query. Optional. 840the variable-length extended query. Optional.
815 </dd> 841</dd>
816 <dt>BF_MUTATOR</dt> 842<dt>BF_MUTATOR</dt>
817 <dd> 843<dd>
818 The 32-bit bloomfilter mutator for the result bloomfilter. 844The 32-bit bloomfilter mutator for the result bloomfilter.
819 </dd> 845</dd>
820 <dt>RESULT_BF</dt> 846<dt>RESULT_BF</dt>
821 <dd> 847<dd>
822 the variable-length result bloomfilter. 848the variable-length result bloomfilter.
823 </dd> 849</dd>
824 </dl> 850</dl>
825 </section> 851</section>
826 <section anchor="p2p_get_processing"> 852<section anchor="p2p_get_processing">
827 <name>Processing</name> 853<name>Processing</name>
828 <t> 854<t>
829 Upon receiving a <tt>GetMmessage</tt> from a peer an 855Upon receiving a <tt>GetMmessage</tt> from a peer an
830 implementation MUST process it step by step as follows: 856implementation MUST process it step by step as follows:
831 </t> 857</t>
832 <ol> 858<ol>
833 <li> 859<li>
834 The <tt>KEY</tt> and <tt>XQUERY</tt> is validated against the 860The <tt>KEY</tt> and <tt>XQUERY</tt> is validated against the
835 requested <tt>BTYPE</tt> as defined by its respective 861requested <tt>BTYPE</tt> as defined by its respective
836 <tt>ValidateBlockQuery</tt> procedure. 862<tt>ValidateBlockQuery</tt> procedure.
837 If the <tt>BTYPE</tt> is not supported, or if the block key 863If the <tt>BTYPE</tt> is not supported, or if the block key
838 does not match or if the <tt>XQUERY</tt> is malformed, 864does not match or if the <tt>XQUERY</tt> is malformed,
839 the message MUST be discarded. 865the message MUST be discarded.
840 </li> 866</li>
841 <li> 867<li>
842 The node address of the sender peer <tt>P</tt> SHOULD be in the 868The node address of the sender peer <tt>P</tt> SHOULD be in the
843 BLOOMFILTER. If not, the 869BLOOMFILTER. If not, the
844 implementation MAY log an error, but MUST continue. 870implementation MAY log an error, but MUST continue.
845 </li> 871</li>
846 <li> 872<li>
847 <t> 873<t>
848 If the local node is the closest node 874If the local node is the closest node
849 (cf. <tt>IsClosestNode (N, Key)</tt>) or the 875(cf. <tt>IsClosestNode (N, Key)</tt>) or the
850 <tt>DemultiplexEverywhere</tt> options flag is set, a reply 876<tt>DemultiplexEverywhere</tt> options flag is set, a reply
851 MUST be produced: 877MUST be produced:
852 </t> 878</t>
853 <ol> 879<ol>
854 <li> 880<li>
855 If <tt>OPTIONS</tt> indicate a <tt>FindNode</tt> request, 881If <tt>OPTIONS</tt> indicate a <tt>FindNode</tt> request,
856 FIXME the node selection 882FIXME the node selection
857 foo from buckets that probably needs fixing. Take into account 883foo from buckets that probably needs fixing. Take into account
858 <tt>REPLY_BF</tt> 884<tt>REPLY_BF</tt>
859 </li> 885</li>
860 <li> 886<li>
861 Else, if there is a block in the local Block Storage which is 887Else, if there is a block in the local Block Storage which is
862 not already in the <tt>RESULT_BF</tt>, 888not already in the <tt>RESULT_BF</tt>,
863 a ResultMessage MUST be sent. 889a ResultMessage MUST be sent.
864 FIXME link to how the result is sent? 890FIXME link to how the result is sent?
865 </li> 891</li>
866 </ol> 892</ol>
867 </li> 893</li>
868 <li> 894<li>
869 FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST. 895FIXME: We only handle if not GNUNET_BLOCK_EVALUATION_OK_LAST.
870 This means that we must evaluate the Reply produced in the 896This means that we must evaluate the Reply produced in the
871 previous step using <tt>ValidateBlockReply</tt> for this 897previous step using <tt>ValidateBlockReply</tt> for this
872 <tt>BTYPE</tt> 898<tt>BTYPE</tt>
873 </li> 899</li>
874 <li> 900<li>
875 Given the value in REPL_LVL, the number of nodes to forward to 901Given the value in REPL_LVL, the number of nodes to forward to
876 MUST be calculated (NUM-FORWARD-nodeS). If there is at least one 902MUST be calculated (NUM-FORWARD-nodeS). If there is at least one
877 node to forward to, the implementation SHOULD select up to this 903node to forward to, the implementation SHOULD select up to this
878 number of nodes to forward the message to. The implementation MAY 904number of nodes to forward the message to. The implementation MAY
879 forward to fewer or no nodes in order to handle resource constraints 905forward to fewer or no nodes in order to handle resource constraints
880 such as bandwidth. 906such as bandwidth.
881 The message BLOOMFILTER MUST be updated with the local node 907The message BLOOMFILTER MUST be updated with the local node
882 address <tt>N</tt>. 908address <tt>N</tt>.
883 For all peers with node address <tt>P'</tt> chosen to forward the message 909For all peers with node address <tt>P'</tt> chosen to forward the message
884 to, <tt>SEND(P', PutMessage)</tt> is called. 910to, <tt>SEND(P', PutMessage)</tt> is called.
885 </li> 911</li>
886 </ol> 912</ol>
887 </section> 913</section>
888 </section> 914</section>
889 <section anchor="p2p_result" numbered="true" toc="default"> 915<section anchor="p2p_result" numbered="true" toc="default">
890 <name>ResultMessage</name> 916<name>ResultMessage</name>
891 <section anchor="p2p_result_wire"> 917<section anchor="p2p_result_wire">
892 <name>Wire Format</name> 918<name>Wire Format</name>
893 <figure anchor="figure_resmsg"> 919<figure anchor="figure_resmsg">
894 <artwork name="" type="" align="left" alt=""><![CDATA[ 920<artwork name="" type="" align="left" alt=""><![CDATA[
8950 8 16 24 32 40 48 56 9210 8 16 24 32 40 48 56
896+-----+-----+-----+-----+-----+-----+-----+-----+ 922+-----+-----+-----+-----+-----+-----+-----+-----+
897| MSIZE | MTYPE | BTYPE | 923| MSIZE | MTYPE | BTYPE |
@@ -912,230 +938,230 @@ END
912/ BLOCK / 938/ BLOCK /
913/ (variable length) / 939/ (variable length) /
914+-----+-----+-----+-----+-----+-----+-----+-----+ 940+-----+-----+-----+-----+-----+-----+-----+-----+
915 ]]></artwork> 941]]></artwork>
916 </figure> 942</figure>
917 <t>where:</t> 943<t>where:</t>
918 <dl> 944<dl>
919 <dt>MSIZE</dt> 945<dt>MSIZE</dt>
920 <dd> 946<dd>
921 denotes the size of this message in network byte order. 947denotes the size of this message in network byte order.
922 </dd> 948</dd>
923 <dt>MTYPE</dt> 949<dt>MTYPE</dt>
924 <dd> 950<dd>
925 is the 16-bit message type. This type can be one of the DHT message 951is the 16-bit message type. This type can be one of the DHT message
926 types but for put messages it must be set to 952types but for put messages it must be set to
927 the value 148 in network byte order. 953the value 148 in network byte order.
928 </dd> 954</dd>
929 <dt>OPTIONS</dt> 955<dt>OPTIONS</dt>
930 <dd> 956<dd>
931 is a 16-bit options field (see below). 957is a 16-bit options field (see below).
932 </dd> 958</dd>
933 <dt>BTYPE</dt> 959<dt>BTYPE</dt>
934 <dd> 960<dd>
935 is a 32-bit block type field. The block type indicates the content 961is a 32-bit block type field. The block type indicates the content
936 type of the payload. In network byte order. 962type of the payload. In network byte order.
937 </dd> 963</dd>
938 <dt>PUTPATH_L</dt> 964<dt>PUTPATH_L</dt>
939 <dd> 965<dd>
940 is a 16-bit number indicating the length of the PUT path recorded 966is a 16-bit number indicating the length of the PUT path recorded
941 in PUTPATH. As PUTPATH is optiona, this value may be zero. 967in PUTPATH. As PUTPATH is optiona, this value may be zero.
942 In network byte order. 968In network byte order.
943 </dd> 969</dd>
944 <dt>GET_PATH_LEN</dt> 970<dt>GET_PATH_LEN</dt>
945 <dd> 971<dd>
946 is a 16-bit number indicating the length of the GET path recorded 972is a 16-bit number indicating the length of the GET path recorded
947 in GETPATH. As PUTPATH is optiona, this value may be zero. 973in GETPATH. As PUTPATH is optiona, this value may be zero.
948 In network byte order. 974In network byte order.
949 </dd> 975</dd>
950 <dt>EXPIRATION</dt> 976<dt>EXPIRATION</dt>
951 <dd> 977<dd>
952 denotes the absolute 64-bit expiration date of the content. 978denotes the absolute 64-bit expiration date of the content.
953 In microseconds since midnight (0 hour), January 1, 1970 in network 979In microseconds since midnight (0 hour), January 1, 1970 in network
954 byte order. 980byte order.
955 </dd> 981</dd>
956 <dt>KEY</dt> 982<dt>KEY</dt>
957 <dd> 983<dd>
958 The key under which the PUT request wants to store content 984The key under which the PUT request wants to store content
959 under. 985under.
960 </dd> 986</dd>
961 <dt>PUTPATH</dt> 987<dt>PUTPATH</dt>
962 <dd> 988<dd>
963 the variable-length PUT path. 989the variable-length PUT path.
964 The path consists of a list of PATH_LEN node addresses. 990The path consists of a list of PATH_LEN node addresses.
965 </dd> 991</dd>
966 <dt>GETPATH</dt> 992<dt>GETPATH</dt>
967 <dd> 993<dd>
968 the variable-length PUT path. 994the variable-length PUT path.
969 The path consists of a list of PATH_LEN node addresses. 995The path consists of a list of PATH_LEN node addresses.
970 </dd> 996</dd>
971 <dt>BLOCK</dt> 997<dt>BLOCK</dt>
972 <dd> 998<dd>
973 the variable-length resource record data payload. 999the variable-length resource record data payload.
974 The contents are defined by the respective type of the resource record. 1000The contents are defined by the respective type of the resource record.
975 </dd> 1001</dd>
976 </dl> 1002</dl>
977 </section> 1003</section>
978 <section anchor="p2p_result_processing"> 1004<section anchor="p2p_result_processing">
979 <name>Processing</name> 1005<name>Processing</name>
980 <t> 1006<t>
981 Upon receiving a <tt>ResultMessage</tt> from a connected node. 1007Upon receiving a <tt>ResultMessage</tt> from a connected node.
982 An implementation MUST process it step by step as follows: 1008An implementation MUST process it step by step as follows:
983 </t> 1009</t>
984 <ol> 1010<ol>
985 <li> 1011<li>
986 The <tt>EXPIRATION</tt> field is evaluated. 1012The <tt>EXPIRATION</tt> field is evaluated.
987 If the message is expired, it MUST be discarded. 1013If the message is expired, it MUST be discarded.
988 </li> 1014</li>
989 <li> 1015<li>
990 If the MTYPE of the message indicates a HELLO block, it 1016If the MTYPE of the message indicates a HELLO block, it
991 must be validated according to <xref target="hello_block"/>. 1017must be validated according to <xref target="hello_block"/>.
992 The payload MUST be considered for the local routing table by 1018The payload MUST be considered for the local routing table by
993 trying to establish a connection to the node using the information 1019trying to establish a connection to the node using the information
994 from the HELLO block. If a connection can be established, 1020from the HELLO block. If a connection can be established,
995 the node is added to the <tt>KBuckets</tt> routing table. 1021the node is added to the <tt>KBuckets</tt> routing table.
996 </li> 1022</li>
997 <li> 1023<li>
998 If the sender node of the message is already found in the 1024If the sender node of the message is already found in the
999 GETPATH, the path MUST be truncated at this position. 1025GETPATH, the path MUST be truncated at this position.
1000 The implementation MAY log a warning in such a case. 1026The implementation MAY log a warning in such a case.
1001 </li> 1027</li>
1002 <li> 1028<li>
1003 If the <tt>KEY</tt> of this <tt>ResultMessage</tt> is found in the 1029If the <tt>KEY</tt> of this <tt>ResultMessage</tt> is found in the
1004 list of pending local queries, the <tt>KEY</tt> and <tt>XQUERY</tt> 1030list of pending local queries, the <tt>KEY</tt> and <tt>XQUERY</tt>
1005 are validated against the requested BTYPE using the respective 1031are validated against the requested BTYPE using the respective
1006 block type implementation of <tt>ValidateBlockReply</tt>. 1032block type implementation of <tt>ValidateBlockReply</tt>.
1007 If the BTYPE is not supported, or if the block key 1033If the BTYPE is not supported, or if the block key
1008 does not match the BTYPE or if the XQUERY is malformed, 1034does not match the BTYPE or if the XQUERY is malformed,
1009 the message MUST be discarded. 1035the message MUST be discarded.
1010 </li> 1036</li>
1011 <li> 1037<li>
1012 The implementation MAY cache RESULT messages. 1038The implementation MAY cache RESULT messages.
1013 </li> 1039</li>
1014 <li> 1040<li>
1015 <t> 1041<t>
1016 If requests by other nodes for this KEY or BTYPE are known, 1042If requests by other nodes for this KEY or BTYPE are known,
1017 the result block is validated against each request using 1043the result block is validated against each request using
1018 the respective <tt>ValidateBlockReply</tt> function. 1044the respective <tt>ValidateBlockReply</tt> function.
1019 </t> 1045</t>
1020 <t> 1046<t>
1021 If the request options include <tt>FindNode</tt> and the result 1047If the request options include <tt>FindNode</tt> and the result
1022 message block type is HELLO the block validation must use the 1048message block type is HELLO the block validation must use the
1023 key derived using <tt>DeriveBlockKey</tt> as the key included in 1049key derived using <tt>DeriveBlockKey</tt> as the key included in
1024 the request is only approximate. (FIXME: So we extract the key 1050the request is only approximate. (FIXME: So we extract the key
1025 to then check it again against the block? This does not make sense...) 1051to then check it again against the block? This does not make sense...)
1026 </t> 1052</t>
1027 <t> 1053<t>
1028 If the result message block cannot be verified against the 1054If the result message block cannot be verified against the
1029 <tt>KEY</tt> of the result message or if <tt>BLOCK</tt> is 1055<tt>KEY</tt> of the result message or if <tt>BLOCK</tt> is
1030 malformed, the message MUST be discarded. 1056malformed, the message MUST be discarded.
1031 </t> 1057</t>
1032 <t> 1058<t>
1033 For each pending request the reply is routed to the requesting 1059For each pending request the reply is routed to the requesting
1034 node <tt>N'</tt>. FIXME routed to node or forwarded to peer? 1060node <tt>N'</tt>. FIXME routed to node or forwarded to peer?
1035 </t> 1061</t>
1036 </li> 1062</li>
1037 </ol> 1063</ol>
1038 </section> 1064</section>
1039 </section> 1065</section>
1040 </section> 1066</section>
1041 <section anchor="blockstorage" numbered="true" toc="default"> 1067<section anchor="blockstorage" numbered="true" toc="default">
1042 <name>Block Storage</name> 1068<name>Block Storage</name>
1043 <section> 1069<section>
1044 <name>Block Processing</name> 1070<name>Block Processing</name>
1045 <t>RequestEvaluationResult</t> 1071<t>RequestEvaluationResult</t>
1046 <dl> 1072<dl>
1047 <dt>REQUEST_VALID</dt> 1073<dt>REQUEST_VALID</dt>
1048 <dd>Query is valid, no reply given.</dd> 1074<dd>Query is valid, no reply given.</dd>
1049 <dt>REQUEST_INVALID</dt> 1075<dt>REQUEST_INVALID</dt>
1050 <dd> 1076<dd>
1051 Query format does not match block type. For example, XQuery not 1077Query format does not match block type. For example, XQuery not
1052 given or of size of XQuery is not appropriate for type. 1078given or of size of XQuery is not appropriate for type.
1053 </dd> 1079</dd>
1054 </dl> 1080</dl>
1055 <t>ReplyEvaluationResult</t> 1081<t>ReplyEvaluationResult</t>
1056 <dl> 1082<dl>
1057 <dt>OK_MORE</dt> 1083<dt>OK_MORE</dt>
1058 <dd>Valid result, and there may be more.</dd> 1084<dd>Valid result, and there may be more.</dd>
1059 <dt>OK_LAST</dt> 1085<dt>OK_LAST</dt>
1060 <dd>Last possible valid result.</dd> 1086<dd>Last possible valid result.</dd>
1061 <dt>OK_DUPLICATE</dt> 1087<dt>OK_DUPLICATE</dt>
1062 <dd>Valid result, but duplicate.</dd> 1088<dd>Valid result, but duplicate.</dd>
1063 <dt>RESULT_INVALID</dt> 1089<dt>RESULT_INVALID</dt>
1064 <dd>Invalid result. Block does not match query. Value = 4.</dd> 1090<dd>Invalid result. Block does not match query. Value = 4.</dd>
1065 <dt>RESULT_IRRELEVANT</dt> 1091<dt>RESULT_IRRELEVANT</dt>
1066 <dd>Block does not match xquery. Valid result, but not relevant for the request.</dd> 1092<dd>Block does not match xquery. Valid result, but not relevant for the request.</dd>
1067 </dl> 1093</dl>
1068 </section> 1094</section>
1069 <section anchor="block_functions"> 1095<section anchor="block_functions">
1070 <name>Block Functions</name> 1096<name>Block Functions</name>
1071 <t> 1097<t>
1072 Any block type implementation MUST implement the following functions. 1098Any block type implementation MUST implement the following functions.
1073 </t> 1099</t>
1074 <dl> 1100<dl>
1075 <dt>ValidateBlockQuery(Key, XQuery) -> RequestEvaluationResult</dt> 1101<dt>ValidateBlockQuery(Key, XQuery) -&gt; RequestEvaluationResult</dt>
1076 <dd> 1102<dd>
1077 is used to evaluate the request for a block. It is used as part of 1103is used to evaluate the request for a block. It is used as part of
1078 <tt>GetMessage</tt> processing, where the block payload is still unkown, 1104<tt>GetMessage</tt> processing, where the block payload is still unkown,
1079 but the block <tt>XQuery</tt> (FIXME: Undefined here) and <tt>Key</tt> can and 1105but the block <tt>XQuery</tt> (FIXME: Undefined here) and <tt>Key</tt> can and
1080 MUST be verified, if possible. 1106MUST be verified, if possible.
1081 </dd> 1107</dd>
1082 <dt>ValidateBlockStoreRequest(Block, Key) -> RequestEvaluationResult</dt> 1108<dt>ValidateBlockStoreRequest(Block, Key) -&gt; RequestEvaluationResult</dt>
1083 <dd> 1109<dd>
1084 is used to evaluate a block including its key and payload. 1110is used to evaluate a block including its key and payload.
1085 It is used as part of <tt>PutMessage</tt> processing. 1111It is used as part of <tt>PutMessage</tt> processing.
1086 The validation MUST include a check of the block payload against the 1112The validation MUST include a check of the block payload against the
1087 <tt>Key</tt> under which it is requested to be stored. 1113<tt>Key</tt> under which it is requested to be stored.
1088 </dd> 1114</dd>
1089 <dt>ValidateBlockReply(Block, XQuery, Key) -> ReplyEvaluationResult</dt> 1115<dt>ValidateBlockReply(Block, XQuery, Key) -&gt; ReplyEvaluationResult</dt>
1090 <dd> 1116<dd>
1091 is used to evaluate a block including its <tt>Key</tt> and payload. 1117is used to evaluate a block including its <tt>Key</tt> and payload.
1092 It is used as part <tt>ResultMessage</tt> processing. 1118It is used as part <tt>ResultMessage</tt> processing.
1093 The validation of the respective <tt>Block</tt> requires a pending local query 1119The validation of the respective <tt>Block</tt> requires a pending local query
1094 or a previously routed request of another node and its associated 1120or a previously routed request of another node and its associated
1095 XQuery data and Key. 1121XQuery data and Key.
1096 The validation MUST include a check of the block payload against the 1122The validation MUST include a check of the block payload against the
1097 key under which it is requested to be stored. 1123key under which it is requested to be stored.
1098 </dd> 1124</dd>
1099 <dt>DeriveBlockKey(Block) -> Key</dt> 1125<dt>DeriveBlockKey(Block) -&gt; Key</dt>
1100 <dd> 1126<dd>
1101 is used to synthesize the block key from the block payload 1127is used to synthesize the block key from the block payload
1102 and metadata. It is used as part of FIND-node message processing. 1128and metadata. It is used as part of FIND-node message processing.
1103 </dd> 1129</dd>
1104 <dt>FilterResult(Block, XQuery, Key) -> ReplyEvaluationResult</dt> 1130<dt>FilterResult(Block, XQuery, Key) -&gt; ReplyEvaluationResult</dt>
1105 <dd> 1131<dd>
1106 is used to filter results stored in the local block storage for local 1132is used to filter results stored in the local block storage for local
1107 queries. Locally stored blocks from previously observed 1133queries. Locally stored blocks from previously observed
1108 <tt>ResultMessages</tt> and <tt>PutMessages</tt> MAY use this 1134<tt>ResultMessages</tt> and <tt>PutMessages</tt> MAY use this
1109 function instead of <tt>ValidateBlockReply</tt> in order to 1135function instead of <tt>ValidateBlockReply</tt> in order to
1110 avoid revalidation of the block and only perform filtering based on 1136avoid revalidation of the block and only perform filtering based on
1111 request parameters. 1137request parameters.
1112 </dd> 1138</dd>
1113 </dl> 1139</dl>
1114 </section> 1140</section>
1115 <section anchor="block_types"> 1141<section anchor="block_types">
1116 <name>Block Types</name> 1142<name>Block Types</name>
1117 <t> 1143<t>
1118 Applications can and should define their own block types. 1144Applications can and should define their own block types.
1119 The block type determines the format and handling of the block 1145The block type determines the format and handling of the block
1120 payload by nodes in PUT and RESULT messages. 1146payload by nodes in PUT and RESULT messages.
1121 Block types MUST be registered with GANA <xref target="gana"/>. 1147Block types MUST be registered with GANA <xref target="gana"/>.
1122 </t> 1148</t>
1123 <t> 1149<t>
1124 For bootstrapping and node discovery, the DHT implementation uses 1150For bootstrapping and node discovery, the DHT implementation uses
1125 its own block type called "HELLO". A block with this block type 1151its own block type called "HELLO". A block with this block type
1126 contains the NodeID of the node initiating the GET request. 1152contains the NodeID of the node initiating the GET request.
1127 </t> 1153</t>
1128 <section anchor="hello_block"> 1154<section anchor="hello_block">
1129 <name>HELLO</name> 1155<name>HELLO</name>
1130 <t> 1156<t>
1131 The HELLO block type wire format is illustrated in 1157The HELLO block type wire format is illustrated in
1132 <xref target="figure_hello"/>. A query for block of type HELLO MUST 1158<xref target="figure_hello"/>. A query for block of type HELLO MUST
1133 NOT include extended query data (XQuery). Any implementation 1159NOT include extended query data (XQuery). Any implementation
1134 encountering a HELLO block with XQuery data MUST consider the 1160encountering a HELLO block with XQuery data MUST consider the
1135 block invalid and ignore it. 1161block invalid and ignore it.
1136 </t> 1162</t>
1137 <figure anchor="figure_hello"> 1163<figure anchor="figure_hello">
1138 <artwork name="" type="" align="left" alt=""><![CDATA[ 1164<artwork name="" type="" align="left" alt=""><![CDATA[
11390 8 16 24 32 40 48 56 11650 8 16 24 32 40 48 56
1140+-----+-----+-----+-----+-----+-----+-----+-----+ 1166+-----+-----+-----+-----+-----+-----+-----+-----+
1141| TYPE | SIZE | NODEID / 1167| TYPE | SIZE | NODEID /
@@ -1145,280 +1171,198 @@ END
1145| ADDRESSES / 1171| ADDRESSES /
1146/ (variable length) | 1172/ (variable length) |
1147+-----+-----+-----+-----+-----+-----+-----+-----+ 1173+-----+-----+-----+-----+-----+-----+-----+-----+
1148 ]]> 1174]]></artwork>
1149 </artwork> 1175</figure>
1150 </figure> 1176<dl>
1151 <dl> 1177<dt>TYPE</dt>
1152 <dt>TYPE</dt> 1178<dd>
1153 <dd> 1179is the type of HELLO. A 16-bit number in network byte order.
1154 is the type of HELLO. A 16-bit number in network byte order. 1180This value determines the type of the NODEID field.
1155 This value determines the type of the NODEID field. 1181</dd>
1156 </dd> 1182<dt>SIZE</dt>
1157 <dt>SIZE</dt> 1183<dd>
1158 <dd> 1184is the SIZE of the following fields NODEID and ADDRESSES in bytes.
1159 is the SIZE of the following fields NODEID and ADDRESSES in bytes. 1185In network byte order.
1160 In network byte order. 1186</dd>
1161 </dd> 1187<dt>NODEID</dt>
1162 <dt>NODEID</dt> 1188<dd>
1163 <dd> 1189is the Node ID of the node which has generated this HELLO.
1164 is the Node ID of the node which has generated this HELLO. 1190The length content of this field is determined by the TYPE.
1165 The length content of this field is determined by the TYPE. 1191Usually, this is a cryptographic public key which allows the
1166 Usually, this is a cryptographic public key which allows the 1192Underlay to uniquely identify and authenticate the node.
1167 Underlay to uniquely identify and authenticate the node. 1193</dd>
1168 </dd> 1194<dt>ADDRESSES</dt>
1169 <dt>ADDRESSES</dt> 1195<dd>
1170 <dd> 1196is a list of UTF-8 strings <xref target="RFC3629"/> which can be
1171 is a list of UTF-8 strings <xref target="RFC3629"/> which can be 1197used as addresses to contact the node.
1172 used as addresses to contact the node. 1198The strings MUST be 0-terminated.
1173 The strings MUST be 0-terminated. 1199FIXME: Examples? Format determined?
1174 FIXME: Examples? Format determined? 1200</dd>
1175 </dd> 1201</dl>
1176 </dl> 1202<t>
1177 <t> 1203A HELLO reply block MAY be empty. Otherwise, it contains the
1178 A HELLO reply block MAY be empty. Otherwise, it contains the 1204HELLO of a node.
1179 HELLO of a node. 1205</t>
1180 </t> 1206<t>
1181 <t> 1207For the string representation of the node public key,
1182 For the string representation of the node public key, 1208the base-32 encoding "StringEncode" is used.
1183 the base-32 encoding "StringEncode" is used. 1209However, instead of following <xref target="RFC4648"/> the
1184 However, instead of following <xref target="RFC4648"/> the 1210character map is based on the optical character recognition friendly
1185 character map is based on the optical character recognition friendly 1211proposal of Crockford <xref target="CrockfordB32"/>.
1186 proposal of Crockford <xref target="CrockfordB32"/>. 1212The only difference to Crockford is that the letter
1187 The only difference to Crockford is that the letter 1213"U" decodes to the same base-32 value as the letter "V" (27).
1188 "U" decodes to the same base-32 value as the letter "V" (27). 1214</t>
1189 </t> 1215<t>
1190 <t> 1216The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
1191 The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints 1217which can be used by the Underlay in order to establish a connection
1192 which can be used by the Underlay in order to establish a connection 1218with the node identified by <tt>NODEKEY</tt>.
1193 with the node identified by <tt>NODEKEY</tt>. 1219An example of an addressing scheme used throughout
1194 An example of an addressing scheme used throughout 1220this document is "ip+tcp", which refers to a standard TCP/IP socket
1195 this document is "ip+tcp", which refers to a standard TCP/IP socket 1221connection. The "hier"-part of the URI must provide a suitable
1196 connection. The "hier"-part of the URI must provide a suitable 1222address for the given addressing scheme.
1197 address for the given addressing scheme. 1223The following is a non-normative example of address strings:
1198 The following is a non-normative example of address strings: 1224</t>
1199 </t> 1225<figure>
1200 <figure> 1226<artwork name="" type="" align="left" alt=""><![CDATA[
1201 <artwork name="" type="" align="left" alt=""><![CDATA[
1202ip+tcp://1.2.3.4:6789 \ 1227ip+tcp://1.2.3.4:6789 \
1203gnunet+tcp://12.3.4.5/ \ 1228gnunet+tcp://12.3.4.5/ \
1204i2p+udp://1.2.4.5:424/ \ 1229i2p+udp://1.2.4.5:424/ \
1205tor+onionv3://rasdflkjasdfliasduf.onion/ 1230tor+onionv3://rasdflkjasdfliasduf.onion/
1206 ]]></artwork> 1231]]></artwork>
1207 </figure> 1232</figure>
1208 </section> 1233</section>
1209 </section> 1234</section>
1210 </section> 1235</section>
1211 <section> 1236<section anchor="security" numbered="true" toc="default">
1212 <name>Bootstrapping</name> 1237<name>Security Considerations</name>
1213 <t> 1238<!-- FIXME: Here we should (again) discuss how the system is open and
1214 It is assumed that the node is already connected to at least 1239does not have/require a trust anchor a priori. This is (again) in contrast
1215 one other node. 1240to RELOAD -->
1216 First, those initial nodes are sorted into their respective buckets. 1241</section>
1217 </t> 1242<section anchor="gana" numbered="true" toc="default">
1218 <t> 1243<name>GANA Considerations</name>
1219 In order to find the closest nodes in the network to itself, an 1244<t>
1220 implementation MUST now periodically send HELLO GET queries for its own 1245GANA <xref target="GANA"/>
1221 node address. 1246is requested to create a "DHT Block Types" registry.
1222 Both the "record route" and "find node" message options are set in the 1247The registry shall record for each entry:
1223 GET queries in order to learn nodes and network topology from the 1248</t>
1224 message route and in order to receive approximate replies to the 1249<ul>
1225 query key (the node address). 1250<li>Name: The name of the block type (case-insensitive ASCII
1226 </t> 1251string, restricted to alphanumeric characters</li>
1227 <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known nodes, busy/idle etc.</t> 1252<li>Number: 32-bit</li>
1228 <t> 1253<li>Comment: Optionally, a brief English text describing the purpose of
1229 Any implementation encountering a HELLO GET request initially 1254the block type (in UTF-8)</li>
1230 sends its own node address if it. 1255<li>Contact: Optionally, the contact information of a person to contact for
1231 </t> 1256further information</li>
1232 </section> 1257<li>References: Optionally, references describing the record type
1233 <section anchor="security" numbered="true" toc="default"> 1258(such as an RFC)</li>
1234 <name>Security Considerations</name> 1259</ul>
1235 <!-- FIXME: Here we should (again) discuss how the system is open and 1260<t>
1236 does not have/require a trust anchor a priori. This is (again) in contrast 1261The registration policy for this sub-registry is "First Come First
1237 to RELOAD --> 1262Served", as described in <xref target="RFC8126"/>.
1238 </section> 1263GANA is requested to populate this registry as follows:
1239 <section anchor="gana" numbered="true" toc="default"> 1264</t>
1240 <name>GANA Considerations</name> 1265<figure anchor="figure_btypenums">
1241 <t> 1266<artwork name="" type="" align="left" alt=""><![CDATA[
1242 GANA <xref target="GANA" />
1243 is requested to create a "DHT Block Types" registry.
1244 The registry shall record for each entry:
1245 </t>
1246 <ul>
1247 <li>Name: The name of the block type (case-insensitive ASCII
1248 string, restricted to alphanumeric characters</li>
1249 <li>Number: 32-bit</li>
1250 <li>Comment: Optionally, a brief English text describing the purpose of
1251 the block type (in UTF-8)</li>
1252 <li>Contact: Optionally, the contact information of a person to contact for
1253 further information</li>
1254 <li>References: Optionally, references describing the record type
1255 (such as an RFC)</li>
1256 </ul>
1257 <t>
1258 The registration policy for this sub-registry is "First Come First
1259 Served", as described in <xref target="RFC8126"/>.
1260 GANA is requested to populate this registry as follows:
1261 </t>
1262 <figure anchor="figure_btypenums">
1263 <artwork name="" type="" align="left" alt=""><![CDATA[
1264Number | Name | Contact | References | Description 1267Number | Name | Contact | References | Description
1265-------+--------+---------+------------+------------------------- 1268-------+--------+---------+------------+-------------------------
12660 ANY N/A [This.I-D] Reserved 12690 ANY N/A [This.I-D] Reserved
12677 HELLO N/A [This.I-D] Type of a block that contains 12707 HELLO N/A [This.I-D] Type of a block that contains
1268a HELLO for a node 1271a HELLO for a node
126911 GNS N/A GNS Block for storing record data 127211 GNS N/A GNS Block for storing record data
1270]]> 1273]]></artwork>
1271 </artwork> 1274</figure>
1272 </figure> 1275<t>
1273 <t> 1276GANA is requested to amend the "GNUnet Signature Purpose" registry
1274 GANA is requested to amend the "GNUnet Signature Purpose" registry 1277as follows:
1275 as follows: 1278</t>
1276 </t> 1279<figure anchor="figure_purposenums">
1277 <figure anchor="figure_purposenums"> 1280<artwork name="" type="" align="left" alt=""><![CDATA[
1278 <artwork name="" type="" align="left" alt=""><![CDATA[
1279Purpose | Name | References | Description 1281Purpose | Name | References | Description
1280--------+-----------------+------------+-------------------------- 1282--------+-----------------+------------+--------------------------
1281]]> 1283]]></artwork>
1282 </artwork> 1284</figure>
1283 </figure> 1285</section>
1284 </section> 1286<!-- gana -->
1285 <!-- gana --> 1287<section>
1286 <section> 1288<name>Test Vectors</name>
1287 <name>Test Vectors</name> 1289</section>
1288 </section> 1290</middle>
1289 </middle> 1291<back>
1290 <back> 1292<references><name>Normative References</name>
1291 <references>
1292 <name>Normative References</name>
1293
1294 &RFC2119;
1295 &RFC3629;
1296 &RFC4634;
1297 &RFC4648;
1298 &RFC6940;
1299 &RFC8126;
1300 &RFC8174;
1301
1302 <reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9">
1303 <front>
1304 <title>High-Speed High-Security Signatures</title>
1305 <author initials="D." surname="Bernstein" fullname="Daniel Bernstein">
1306 <organization>University of Illinois at Chicago</organization>
1307 </author>
1308
1309 <author initials="N." surname="Duif"
1310 fullname="Niels Duif">
1311 <organization>Technische Universiteit Eindhoven</organization>
1312
1313 </author>
1314 <author initials="T." surname="Lange"
1315 fullname="Tanja Lange">
1316 <organization>Technische Universiteit Eindhoven</organization>
1317
1318 </author>
1319 <author initials="P." surname="Schwabe"
1320 fullname="Peter Schwabe">
1321 <organization>National Taiwan University</organization>
1322
1323 </author>
1324 <author initials="B." surname="Yang"
1325 fullname="Bo-Yin Yang">
1326 <organization>Academia Sinica</organization>
1327
1328 </author>
1329 <date year="2011"/>
1330 </front>
1331 </reference>
1332
1333 <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html">
1334 <front>
1335 <title>Base32</title>
1336 <author initials="D." surname="Douglas" fullname="Crockford">
1337 </author>
1338
1339 <date year="2019" month="March"/>
1340 </front>
1341 </reference>
1342
1343 <reference anchor="GANA" target="https://gana.gnunet.org/">
1344 <front>
1345 <title>GNUnet Assigned Numbers Authority (GANA)</title>
1346 <author><organization>GNUnet e.V.</organization>
1347 </author>
1348 <date month="April" year="2020" />
1349 </front>
1350 </reference>
1351
1352
1353
1354 </references>
1355 <references>
1356 <name>Informative References</name>
1357 <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
1358 <front>
1359 <title>R5N: Randomized recursive routing for restricted-route networks</title>
1360 <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
1361 <organization>Technische Universität München</organization>
1362 </author>
1363
1364 <author initials="C." surname="Grothoff"
1365 fullname="Christian Grothoff">
1366 <organization>Technische Universität München</organization>
1367 </author>
1368 <date year="2011"/>
1369 </front>
1370 </reference>
1371 <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
1372 <front>
1373 <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
1374 <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
1375 </author>
1376 1293
1377 <author initials="D." surname="Mazieres" 1294&RFC2119;
1378 fullname="David Mazieres"> 1295&RFC3629;
1379 </author> 1296&RFC4634;
1380 <date year="2002"/> 1297&RFC4648;
1381 </front> 1298&RFC6940;
1382 </reference> 1299&RFC8126;
1300&RFC8174;
1383 1301
1384 <reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107"> 1302<reference anchor="ed25519" target="http://link.springer.com/chapter/10.1007/978-3-642-23951-9_9"><front><title>High-Speed High-Security Signatures</title><author initials="D." surname="Bernstein" fullname="Daniel Bernstein"><organization>University of Illinois at Chicago</organization></author><author initials="N." surname="Duif" fullname="Niels Duif"><organization>Technische Universiteit Eindhoven</organization></author><author initials="T." surname="Lange" fullname="Tanja Lange"><organization>Technische Universiteit Eindhoven</organization></author><author initials="P." surname="Schwabe" fullname="Peter Schwabe"><organization>National Taiwan University</organization></author><author initials="B." surname="Yang" fullname="Bo-Yin Yang"><organization>Academia Sinica</organization></author><date year="2011"/></front></reference>
1385 <front>
1386 <title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
1387 <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
1388 <organization>Technische Universität München</organization>
1389 </author>
1390 1303
1391 <author initials="C." surname="Grothoff" 1304<reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html"><front><title>Base32</title><author initials="D." surname="Douglas" fullname="Crockford">
1392 fullname="Christian Grothoff"> 1305</author><date year="2019" month="March"/></front></reference>
1393 <organization>Technische Universität München</organization>
1394 </author>
1395 <date year="2014"/>
1396 </front>
1397 </reference>
1398 <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
1399 <front>
1400 <title>The GNU Name System</title>
1401 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
1402 <organization>GNUnet e.V.</organization>
1403 </author>
1404 1306
1405 <author initials="C." surname="Grothoff" 1307<reference anchor="GANA" target="https://gana.gnunet.org/"><front><title>GNUnet Assigned Numbers Authority (GANA)</title><author><organization>GNUnet e.V.</organization></author><date month="April" year="2020"/></front></reference>
1406 fullname="Christian Grothoff">
1407 <organization>GNUnet e.V.</organization>
1408 </author>
1409 <author initials="B." surname="Fix"
1410 fullname="Bernd Fix">
1411 <organization>GNUnet e.V.</organization>
1412 </author>
1413 <date year="2021"/>
1414 </front>
1415 </reference>
1416 1308
1417 1309
1418 1310
1419 </references> 1311</references>
1420 <!-- Change Log 1312<references>
1421 v00 2017-07-23 MS Initial version 1313<name>Informative References</name>
1422 --> 1314<reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
1423 </back> 1315<front>
1424 </rfc> 1316<title>R5N: Randomized recursive routing for restricted-route networks</title>
1317<author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
1318<organization>Technische Universität München</organization>
1319</author>
1320<author initials="C." surname="Grothoff" fullname="Christian Grothoff">
1321<organization>Technische Universität München</organization>
1322</author>
1323<date year="2011"/>
1324</front>
1325</reference>
1326<reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
1327<front>
1328<title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
1329<author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
1330</author>
1331<author initials="D." surname="Mazieres" fullname="David Mazieres">
1332</author>
1333<date year="2002"/>
1334</front>
1335</reference>
1336<reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107">
1337<front>
1338<title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
1339<author initials="B." surname="Polot" fullname="Bartlomiej Polot">
1340<organization>Technische Universität München</organization>
1341</author>
1342<author initials="C." surname="Grothoff" fullname="Christian Grothoff">
1343<organization>Technische Universität München</organization>
1344</author>
1345<date year="2014"/>
1346</front>
1347</reference>
1348<reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
1349<front>
1350<title>The GNU Name System</title>
1351<author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
1352<organization>GNUnet e.V.</organization>
1353</author>
1354<author initials="C." surname="Grothoff" fullname="Christian Grothoff">
1355<organization>GNUnet e.V.</organization>
1356</author>
1357<author initials="B." surname="Fix" fullname="Bernd Fix">
1358<organization>GNUnet e.V.</organization>
1359</author>
1360<date year="2021"/>
1361</front>
1362</reference>
1363</references>
1364<!-- Change Log
1365v00 2017-07-23 MS Initial version
1366-->
1367</back>
1368</rfc>
generated by cgit v1.2.3 (git 2.39.1) at 2025-03-25 11:49:08 +0000