commit 73e4265cd7269b79643f9ddc7e32b10399db6e53
parent a139d3cafd16a7188aa4c24ec1d9b3eeb7ff8418
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 31 Dec 2021 13:23:12 +0100
hello moved
Diffstat:
1 file changed, 248 insertions(+), 261 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -5,7 +5,7 @@
<!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
<!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml">
<!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml">
-<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">
+<!-- <!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml"> -->
<!ENTITY RFC3986 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4648 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml">
@@ -333,83 +333,8 @@ PUT(Key, Block, BlockType[, PutParams])
for this document, it is necessary to define a universal addressing
format in order to facilitate the distribution of connectivity
information to other peers in the DHT overlay.
- This format is the "HELLO" message. A "HELLO" is a human-readable
- UTF-8 <xref target="RFC3629" /> string consisting of the peer
- public key and the HELLO URI <xref target="RFC3986" />.
+ This format is the "HELLO" message.
</t>
- <figure>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-hello-format := <peer-public-key> <hello-uri>
-peer-public-key := [A-HJ-NP-Z1-9]+
- ]]></artwork>
- </figure>
- <t>
- For the string representation of the peer public key,
- the base-32 encoding "StringEncode" is used.
- However, instead of following <xref target="RFC4648"/> the
- character map is based on the optical character recognition friendly
- proposal of Crockford <xref target="CrockfordB32"/>.
- The only difference to Crockford is that the letter
- "U" decodes to the same base-32 value as the letter "V" (27).
- </t>
- <t>
- The "scheme" part of the HELLO URI defined the addressing scheme
- which is used. An example of an addressing scheme used throughout
- this document is "ip+tcp", which refers to a standard TCP/IP socket
- connection. The "hier"-part of the URI must provide a suitable
- address for the given addressing scheme.
- The following is a non-normative example of a HELLO containing three
- HELLO URIs:
- </t>
- <figure anchor="figure_hello">
- <artwork name="" type="" align="left" alt=""><![CDATA[
-0 8 16 24 32 40 48 56
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| TYPE | SIZE | NODEID /
-+-----+-----+-----+-----+ (variable length) /
-/ /
-+-----+-----+-----+-----+-----+-----+-----+-----+
-| ADDRESSES /
-/ (variable length) |
-+-----+-----+-----+-----+-----+-----+-----+-----+
- ]]></artwork>
- </figure>
- <dl>
- <dt>TYPE</dt>
- <dd>
- is the type of HELLO. A 16-bit number in network byte order.
- This value determines the type of the NODEID field.
- </dd>
- <dt>SIZE</dt>
- <dd>
- is the SIZE of the following fields NODEID and ADDRESSES in bytes.
- In network byte order.
- </dd>
- <dt>NODEID</dt>
- <dd>
- is the Node ID of the peer which has generated this HELLO.
- The length content of the NODEID is determined by the TYPE field.
- Usually, this is a cryptographic public key which allows the
- Underlay to uniquely identify and authenticate the node.
- </dd>
- <dt>ADDRESSES</dt>
- <dd>
- is a list of strings which can be used as addresses to contact the
- node. The strings MUST be 0-terminated.
- FIXME: Examples? Format determined?
- </dd>
- </dl>
- <!-- FIXME peer id type | length | id payload | 0-terminated strings for addresses
- <figure>
- <artwork name="" type="" align="left" alt=""><![CDATA[
-Y924NSHMMZ1N1SQCE5TXF93ED6S6JY311K0QT86G9WJC68F6XVZ0 \
- ip+tcp://1.2.3.4:6789 \
- gnunet+tcp://12.3.4.5/ \
- i2p+udp://1.2.4.5:424/ \
- tor+onionv3://rasdflkjasdfliasduf.onion/
- ]]></artwork>
- </figure>
- -->
<!--
1) The current API is always fire+forget, it doesn't allow for flow
@@ -1193,228 +1118,290 @@ END
<name>HELLO</name>
<t>
The HELLO block type wire format is illustrated in
- <xref target="figure_hellobt"/>. A block of type HELLO MUST NOT
- include extended query data (xquery). Any implementation
- encountering a HELLO block with xquery data MUST consider the
+ <xref target="figure_hello"/>. A query for block of type HELLO MUST
+ NOT include extended query data (XQuery). Any implementation
+ encountering a HELLO block with XQuery data MUST consider the
block invalid and ignore it.
</t>
+ <figure anchor="figure_hello">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
+0 8 16 24 32 40 48 56
++-----+-----+-----+-----+-----+-----+-----+-----+
+| TYPE | SIZE | NODEID /
++-----+-----+-----+-----+ (variable length) /
+/ /
++-----+-----+-----+-----+-----+-----+-----+-----+
+| ADDRESSES /
+/ (variable length) |
++-----+-----+-----+-----+-----+-----+-----+-----+
+ ]]>
+ </artwork>
+ </figure>
+ <dl>
+ <dt>TYPE</dt>
+ <dd>
+ is the type of HELLO. A 16-bit number in network byte order.
+ This value determines the type of the NODEID field.
+ </dd>
+ <dt>SIZE</dt>
+ <dd>
+ is the SIZE of the following fields NODEID and ADDRESSES in bytes.
+ In network byte order.
+ </dd>
+ <dt>NODEID</dt>
+ <dd>
+ is the Node ID of the peer which has generated this HELLO.
+ The length content of the NODEID is determined by the TYPE field.
+ Usually, this is a cryptographic public key which allows the
+ Underlay to uniquely identify and authenticate the node.
+ </dd>
+ <dt>ADDRESSES</dt>
+ <dd>
+ is a list of UTF-8 strings <xref target="RFC3629"/> which can be
+ used as addresses to contact the node.
+ The strings MUST be 0-terminated.
+ FIXME: Examples? Format determined?
+ </dd>
+ </dl>
<t>
A HELLO reply block MAY be empty. Otherwise, it contains the
- HELLO URI of a peer.
+ HELLO of a node.
+ </t>
+ <t>
+ For the string representation of the peer public key,
+ the base-32 encoding "StringEncode" is used.
+ However, instead of following <xref target="RFC4648"/> the
+ character map is based on the optical character recognition friendly
+ proposal of Crockford <xref target="CrockfordB32"/>.
+ The only difference to Crockford is that the letter
+ "U" decodes to the same base-32 value as the letter "V" (27).
+ </t>
+ <t>
+ The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
+ which can be used by the Underlay in order to establish a connection
+ with the node identified by <tt>NODEID</tt>.
+ An example of an addressing scheme used throughout
+ this document is "ip+tcp", which refers to a standard TCP/IP socket
+ connection. The "hier"-part of the URI must provide a suitable
+ address for the given addressing scheme.
+ The following is a non-normative example of address strings:
</t>
- <figure anchor="figure_hellobt">
+ <figure>
<artwork name="" type="" align="left" alt=""><![CDATA[
- FIXME: Wire format
- ]]></artwork>
- </figure>
- </section>
+ip+tcp://1.2.3.4:6789 \
+gnunet+tcp://12.3.4.5/ \
+i2p+udp://1.2.4.5:424/ \
+tor+onionv3://rasdflkjasdfliasduf.onion/
+ ]]></artwork>
+ </figure>
</section>
</section>
-
-
- <section>
- <name>Bootstrapping</name>
- <t>
- It is assumed that the peer is already connected to at least
- one other peer.
- First, those initial peers are sorted into their respective buckets.
- </t>
- <t>
- In order to find the closest peers in the network to itself, an
- implementation MUST now periodically send HELLO GET queries for its own
- peer ID.
- Both the "record route" and "find peer" message options are set in the
- GET queries in order to learn peers and network topology from the
- message route and in order to receive approximate replies to the
- query key (the peer ID).
- </t>
- <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known peers, busy/idle etc.</t>
- <t>
- Any implementation encountering a HELLO GET request initially
- sends its own peer ID if it.
- </t>
- </section>
- <section anchor="security" numbered="true" toc="default">
- <name>Security Considerations</name>
- <!-- FIXME: Here we should (again) discuss how the system is open and
+ </section>
+ <section>
+ <name>Bootstrapping</name>
+ <t>
+ It is assumed that the peer is already connected to at least
+ one other peer.
+ First, those initial peers are sorted into their respective buckets.
+ </t>
+ <t>
+ In order to find the closest peers in the network to itself, an
+ implementation MUST now periodically send HELLO GET queries for its own
+ peer ID.
+ Both the "record route" and "find peer" message options are set in the
+ GET queries in order to learn peers and network topology from the
+ message route and in order to receive approximate replies to the
+ query key (the peer ID).
+ </t>
+ <t>FIXME: Periodically -> more specific? No. Frequency may be adapted depending on network conditions, known peers, busy/idle etc.</t>
+ <t>
+ Any implementation encountering a HELLO GET request initially
+ sends its own peer ID if it.
+ </t>
+ </section>
+ <section anchor="security" numbered="true" toc="default">
+ <name>Security Considerations</name>
+ <!-- FIXME: Here we should (again) discuss how the system is open and
does not have/require a trust anchor a priori. This is (again) in contrast
- to RELOAD -->
- </section>
- <section anchor="gana" numbered="true" toc="default">
- <name>GANA Considerations</name>
- <t>
- GANA <xref target="GANA" />
- is requested to create a "DHT Block Types" registry.
- The registry shall record for each entry:
- </t>
- <ul>
- <li>Name: The name of the block type (case-insensitive ASCII
- string, restricted to alphanumeric characters</li>
- <li>Number: 32-bit</li>
- <li>Comment: Optionally, a brief English text describing the purpose of
- the block type (in UTF-8)</li>
- <li>Contact: Optionally, the contact information of a person to contact for
- further information</li>
- <li>References: Optionally, references describing the record type
- (such as an RFC)</li>
- </ul>
- <t>
- The registration policy for this sub-registry is "First Come First
- Served", as described in <xref target="RFC8126"/>.
- GANA is requested to populate this registry as follows:
- </t>
- <figure anchor="figure_btypenums">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+ to RELOAD -->
+ </section>
+ <section anchor="gana" numbered="true" toc="default">
+ <name>GANA Considerations</name>
+ <t>
+ GANA <xref target="GANA" />
+ is requested to create a "DHT Block Types" registry.
+ The registry shall record for each entry:
+ </t>
+ <ul>
+ <li>Name: The name of the block type (case-insensitive ASCII
+ string, restricted to alphanumeric characters</li>
+ <li>Number: 32-bit</li>
+ <li>Comment: Optionally, a brief English text describing the purpose of
+ the block type (in UTF-8)</li>
+ <li>Contact: Optionally, the contact information of a person to contact for
+ further information</li>
+ <li>References: Optionally, references describing the record type
+ (such as an RFC)</li>
+ </ul>
+ <t>
+ The registration policy for this sub-registry is "First Come First
+ Served", as described in <xref target="RFC8126"/>.
+ GANA is requested to populate this registry as follows:
+ </t>
+ <figure anchor="figure_btypenums">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
Number | Name | Contact | References | Description
-------+--------+---------+------------+-------------------------
0 ANY N/A [This.I-D] Reserved
7 HELLO N/A [This.I-D] Type of a block that contains
- a HELLO for a peer
+a HELLO for a peer
11 GNS N/A GNS Block for storing record data
- ]]></artwork>
- </figure>
- <t>
- GANA is requested to amend the "GNUnet Signature Purpose" registry
- as follows:
- </t>
- <figure anchor="figure_purposenums">
- <artwork name="" type="" align="left" alt=""><![CDATA[
+]]>
+ </artwork>
+ </figure>
+ <t>
+ GANA is requested to amend the "GNUnet Signature Purpose" registry
+ as follows:
+ </t>
+ <figure anchor="figure_purposenums">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
Purpose | Name | References | Description
--------+-----------------+------------+--------------------------
- ]]></artwork>
- </figure>
- </section>
- <!-- gana -->
- <section>
- <name>Test Vectors</name>
+]]>
+ </artwork>
+ </figure>
+ </section>
+ <!-- gana -->
+ <section>
+ <name>Test Vectors</name>
</section>
- </middle>
- <back>
- <references>
- <name>Normative References</name>
+ </middle>
+ <back>
+ <references>
+ <name>Normative References</name>
- &RFC2119;
- &RFC3629;
- &RFC3986;
- &RFC4648;
- &RFC6940;
- &RFC8126;
- &RFC8174;
-
- <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>
+ &RFC2119;
+ &RFC3629;
+ <!--&RFC3986; URI-->
+ &RFC4648;
+ &RFC6940;
+ &RFC8126;
+ &RFC8174;
- <author initials="N." surname="Duif"
- fullname="Niels Duif">
- <organization>Technische Universiteit Eindhoven</organization>
+ <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>
- <author initials="T." surname="Lange"
- fullname="Tanja Lange">
- <organization>Technische Universiteit Eindhoven</organization>
+ <author initials="N." surname="Duif"
+ fullname="Niels Duif">
+ <organization>Technische Universiteit Eindhoven</organization>
- </author>
- <author initials="P." surname="Schwabe"
- fullname="Peter Schwabe">
- <organization>National Taiwan University</organization>
+ </author>
+ <author initials="T." surname="Lange"
+ fullname="Tanja Lange">
+ <organization>Technische Universiteit Eindhoven</organization>
- </author>
- <author initials="B." surname="Yang"
- fullname="Bo-Yin Yang">
- <organization>Academia Sinica</organization>
+ </author>
+ <author initials="P." surname="Schwabe"
+ fullname="Peter Schwabe">
+ <organization>National Taiwan University</organization>
- </author>
- <date year="2011"/>
- </front>
- </reference>
+ </author>
+ <author initials="B." surname="Yang"
+ fullname="Bo-Yin Yang">
+ <organization>Academia Sinica</organization>
- <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html">
- <front>
- <title>Base32</title>
- <author initials="D." surname="Douglas" fullname="Crockford">
- </author>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
- <date year="2019" month="March"/>
- </front>
- </reference>
+ <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html">
+ <front>
+ <title>Base32</title>
+ <author initials="D." surname="Douglas" fullname="Crockford">
+ </author>
- <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>
+ <date year="2019" month="March"/>
+ </front>
+ </reference>
+ <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>
- </references>
- <references>
- <name>Informative References</name>
- <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
- <front>
- <title>R5N: Randomized recursive routing for restricted-route networks</title>
- <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
- <organization>Technische Universität München</organization>
- </author>
- <author initials="C." surname="Grothoff"
- fullname="Christian Grothoff">
- <organization>Technische Universität München</organization>
- </author>
- <date year="2011"/>
- </front>
- </reference>
- <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
- <front>
- <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
- <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
- </author>
+ </references>
+ <references>
+ <name>Informative References</name>
+ <reference anchor="R5N" target="https://doi.org/10.1109/ICNSS.2011.6060022">
+ <front>
+ <title>R5N: Randomized recursive routing for restricted-route networks</title>
+ <author initials="N. S." surname="Evans" fullname="Nathan S. Evans">
+ <organization>Technische Universität München</organization>
+ </author>
+
+ <author initials="C." surname="Grothoff"
+ fullname="Christian Grothoff">
+ <organization>Technische Universität München</organization>
+ </author>
+ <date year="2011"/>
+ </front>
+ </reference>
+ <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf">
+ <front>
+ <title>Kademlia: A peer-to-peer information system based on the xor metric.</title>
+ <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov">
+ </author>
- <author initials="D." surname="Mazieres"
- fullname="David Mazieres">
- </author>
- <date year="2002"/>
- </front>
+ <author initials="D." surname="Mazieres"
+ fullname="David Mazieres">
+ </author>
+ <date year="2002"/>
+ </front>
</reference>
<reference anchor="cadet" target="https://doi.org/10.1109/MedHocNet.2014.6849107">
<front>
<title>CADET: Confidential ad-hoc decentralized end-to-end transport</title>
- <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
- <organization>Technische Universität München</organization>
- </author>
+ <author initials="B." surname="Polot" fullname="Bartlomiej Polot">
+ <organization>Technische Universität München</organization>
+ </author>
- <author initials="C." surname="Grothoff"
- fullname="Christian Grothoff">
- <organization>Technische Universität München</organization>
- </author>
- <date year="2014"/>
- </front>
- </reference>
- <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
- <front>
- <title>The GNU Name System</title>
- <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
- <organization>GNUnet e.V.</organization>
- </author>
+ <author initials="C." surname="Grothoff"
+ fullname="Christian Grothoff">
+ <organization>Technische Universität München</organization>
+ </author>
+ <date year="2014"/>
+ </front>
+ </reference>
+ <reference anchor="I-D.draft-schanzen-gns" target="https://datatracker.ietf.org/doc/draft-schanzen-gns/">
+ <front>
+ <title>The GNU Name System</title>
+ <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach">
+ <organization>GNUnet e.V.</organization>
+ </author>
- <author initials="C." surname="Grothoff"
- fullname="Christian Grothoff">
- <organization>GNUnet e.V.</organization>
- </author>
- <author initials="B." surname="Fix"
- fullname="Bernd Fix">
- <organization>GNUnet e.V.</organization>
- </author>
- <date year="2021"/>
- </front>
- </reference>
+ <author initials="C." surname="Grothoff"
+ fullname="Christian Grothoff">
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <author initials="B." surname="Fix"
+ fullname="Bernd Fix">
+ <organization>GNUnet e.V.</organization>
+ </author>
+ <date year="2021"/>
+ </front>
+ </reference>
