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.xml123
1 files changed, 58 insertions, 65 deletions
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 9e7dd1a..200f28d 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -19,6 +19,7 @@
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<!ENTITY RFC8324 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml">
22<!ENTITY I-D.schanzen-gns PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml"> 23<!ENTITY I-D.schanzen-gns PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schanzen-gns.xml">
23]> 24]>
24<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 25<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
@@ -445,7 +446,6 @@ Connectivity | |Underlay| |Underlay|
445 When the connection attempt is successful, information on the new 446 When the connection attempt is successful, information on the new
446 peer is offered through the <tt>PEER_CONNECTED</tt> signal. 447 peer is offered through the <tt>PEER_CONNECTED</tt> signal.
447 </dd> 448 </dd>
448 If PEER_CONNECT and put in routing table, then HOLD -->
449 <dt> 449 <dt>
450 <tt>HOLD(P)</tt> 450 <tt>HOLD(P)</tt>
451 </dt> 451 </dt>
@@ -641,14 +641,6 @@ Connectivity | |Underlay| |Underlay|
641 of <tt>HELLO</tt>s. 641 of <tt>HELLO</tt>s.
642 </t> 642 </t>
643 <t> 643 <t>
644 <!-- FIXME REPL_LVL unclear, RF_SIZE unclear. Sections like this make me wonder how
645 we can avoid using prose to specify message creation.
646 REPL_LVL: For hello it is 4 => RECOMMENDED to 4
647 RF_SIZE: Specified in HELLO block as connected peers = |E|.
648 RF: All peers I am already connected to should be included in the RF BF
649 XQUERY: => nil
650 Flags? FindApproximate
651 -->
652 To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests 644 To discover peers for its routing table, a peer will initiate <tt>GetMessage</tt> requests
653 <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as 645 <xref target="p2p_get"/> asking for blocks of type <tt>HELLO</tt> using its own peer address as
654 <tt>QUERY_HASH</tt>. 646 <tt>QUERY_HASH</tt>.
@@ -678,12 +670,13 @@ Connectivity | |Underlay| |Underlay|
678 already in the routing table, it must cache it as long as that peer is in its routing table 670 already in the routing table, it must cache it as long as that peer is in its routing table
679 (or until the <tt>HELLO</tt> expires) and serve it in response to 671 (or until the <tt>HELLO</tt> expires) and serve it in response to
680 GET requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>). 672 GET requests for <tt>HELLO</tt> blocks (see <xref target="p2p_get_processing"/>).
673 This behaviour makes it unnecessary to initiate dedicated <tt>PutMessages</tt> containing
674 <tt>HELLO</tt> blocks by the implementation.
681 </t> 675 </t>
682 </section> 676 </section>
683 <section anchor="routing_bloomfilter"> 677 <section anchor="routing_bloomfilter">
684 <name>Peer Bloom Filter</name> 678 <name>Peer Bloom Filter</name>
685 <t> 679 <t>
686 <!-- FIXME HArdcoded to 128 bytes = L/8 -->
687 As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a random path through the network for the 680 As DHT <tt>GetMessage</tt>s and <tt>PutMessage</tt>s traverse a random path through the network for the
688 first N hops, it is essential that routing loops are avoided. 681 first N hops, it is essential that routing loops are avoided.
689 This peer Bloom filter is constant in size at <tt>L=1024</tt> buckets (128 bytes) and 682 This peer Bloom filter is constant in size at <tt>L=1024</tt> buckets (128 bytes) and
@@ -1302,8 +1295,11 @@ BEGIN
1302 is in the future. If the signature is invalid, the message is discarded. 1295 is in the future. If the signature is invalid, the message is discarded.
1303 </li> 1296 </li>
1304 <li> 1297 <li>
1305 The <tt>HELLO</tt> information is cached in the routing table until it expires, 1298 The information contained in the <tt>HelloMessage</tt> can be used to synthesize a
1306 the peer is removed from the routing table, or the information is replaced by another message from the peer. 1299 block of type <tt>HELLO</tt> (<xref target="hello_block"/>).
1300 The block is cached in the routing table until it expires,
1301 the peer is removed from the routing table, or the information is replaced by another message
1302 from the peer.
1307 The implementation <bcp14>SHOULD</bcp14> instruct the Underlay to connect to all now available addresses 1303 The implementation <bcp14>SHOULD</bcp14> instruct the Underlay to connect to all now available addresses
1308 using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and 1304 using <tt>TRY_CONNECT</tt> in order to make the underlay aware of alternative addresses for this connection and
1309 to maintain optimal connectivity. 1305 to maintain optimal connectivity.
@@ -1510,8 +1506,10 @@ BEGIN
1510 <li> 1506 <li>
1511 If the local peer is the closest peer 1507 If the local peer is the closest peer
1512 (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt> 1508 (cf. <tt>IsClosestPeer(SELF, BLOCK_KEY, PeerFilter)</tt>) or the <tt>DemultiplexEverywhere</tt>
1513 flag ist set, the message <bcp14>MUST</bcp14> 1509 flag ist set, the message <bcp14>SHOULD</bcp14>
1514 be stored locally in the block storage if possible. 1510 be stored locally in the block storage if possible.
1511 The implementation <tt>MAY</tt> choose not store the block if external factors or configurations
1512 prevent this, such as limited (alottted) disk space.
1515 </li> 1513 </li>
1516 <li> 1514 <li>
1517 If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the 1515 If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
@@ -1522,8 +1520,9 @@ BEGIN
1522 connection to the peer indicated in the <tt>HELLO</tt> block using 1520 connection to the peer indicated in the <tt>HELLO</tt> block using
1523 the address information 1521 the address information
1524 from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>. 1522 from the <tt>HELLO</tt> block and the Underlay function <tt>TRY_CONNECT</tt>.
1525 The implementation <bcp14>MUST</bcp14> instruct the Underlay to connect to all provided addresses 1523 The implementation <bcp14>MUST</bcp14> instruct the Underlay to try to connect to all
1526 using <tt>TRY_CONNECT</tt> in order to make the underlay aware of multiple addresses for this connection. 1524 provided addresses using <tt>TRY_CONNECT</tt> in order to make the underlay aware of
1525 multiple addresses for this connection.
1527 When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause 1526 When a connection is established, the signal <tt>PEER_CONNECTED</tt> will cause
1528 the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>). 1527 the peer to be added to the respective k-bucket of the routing table (<xref target="routing"/>).
1529 </li> 1528 </li>
@@ -1700,21 +1699,25 @@ BEGIN
1700 </li> 1699 </li>
1701 <li> 1700 <li>
1702 <t> 1701 <t>
1703 If the local peer is the closest peer 1702 The local peer <bcp14>MUST</bcp14> try to produce a reply in any of the following cases:
1704 (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>) or the 1703 (1) If the local peer is the closest peer
1705 <tt>DemultiplexEverywhere</tt> flag is set, a reply 1704 (cf. <tt>IsClosestPeer (SELF, QueryHash, PeerFilter)</tt>, or (2)
1706 <bcp14>MUST</bcp14> be produced (if one is available) using the following 1705 if the <tt>DemultiplexEverywhere</tt> flag is set, or (3)
1706 if the local peer is not the closest and the <tt>GetRequest</tt> was answered previously
1707 resulting in a cached reply (<xref target="p2p_result_processing"/>).
1708 </t>
1709 <t>
1710 The reply is produced (if one is available) using the following
1707 steps: 1711 steps:
1708 </t> 1712 </t>
1709 <ol type="%c)"> 1713 <ol type="%c)">
1710 <!-- FIXME it seems to me as if some blocks need to be "synthesized", e.g.
1711 HELLOs from HelloMessages... this needs to be specified.-->
1712 <li> 1714 <li>
1713 If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or 1715 If the <tt>BTYPE</tt> does not indicate a request for a <tt>HELLO</tt> block or
1714 <tt>ANY</tt>, 1716 <tt>ANY</tt>,
1715 the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage. 1717 the implementation <bcp14>MUST</bcp14> only consider blocks in the local block storage
1716 Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own <tt>HELLO</tt> and 1718 and previously cached <tt>ResultMessage</tt>s.
1717 the <tt>HELLO</tt>s it has cached for the peers in its routing table as blocks. 1719 Otherwise, the implementation <bcp14>MUST</bcp14> only consider its own addresses and
1720 the addresses it has cached for the peers in its routing table.
1718 </li> 1721 </li>
1719 <li> 1722 <li>
1720 If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request, 1723 If <tt>FLAGS</tt> indicate a <tt>FindApproximate</tt> request,
@@ -1725,16 +1728,19 @@ BEGIN
1725 with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is 1728 with a <tt>BLOCK_KEY</tt> that matches the <tt>QUERY_HASH</tt> exactly and that is
1726 not filtered by the <tt>RESULT_BF</tt>. 1729 not filtered by the <tt>RESULT_BF</tt>.
1727 </li> 1730 </li>
1731 <li>
1732 Any resulting (synthesized) block <bcp14>MUST</bcp14> be encapsulated in a
1733 <tt>ResultMessage</tt>.
1734 The cached or created <tt>ResultMessage</tt> <bcp14>SHOULD</bcp14> be transmitted to the
1735 neighbor from which the request was received.
1736 </li>
1728 </ol> 1737 </ol>
1729 <t> 1738 <t>
1730 The resulting block, if any, <bcp14>MUST</bcp14> be encapsulated in a 1739 Implementations <bcp14>MAY</bcp14> not to reply if they are resource-constrained.
1731 <tt>ResultMessage</tt> and <bcp14>SHOULD</bcp14> be transmitted to the 1740 However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
1732 neighbor from which the request was received. 1741 highest priority among competing transmissions.
1733 Implementations <bcp14>MAY</bcp14> drop messages if they are resource-constrained.
1734 However, <tt>ResultMessage</tt>s <bcp14>MUST</bcp14> be given the
1735 highest priority among competing transmissions.
1736 </t> 1742 </t>
1737 <t> 1743 <t>
1738 If the <tt>BTYPE</tt> is supported and <tt>ValidateBlockReply</tt> for the given 1744 If the <tt>BTYPE</tt> is supported and <tt>ValidateBlockReply</tt> for the given
1739 query has yielded a status of <tt>FILTER_LAST</tt>, processing 1745 query has yielded a status of <tt>FILTER_LAST</tt>, processing
1740 <bcp14>MUST</bcp14> end and not continue with forwarding of 1746 <bcp14>MUST</bcp14> end and not continue with forwarding of
@@ -1756,6 +1762,9 @@ BEGIN
1756 to, <tt>SEND(P, GetMessageP)</tt> is called. Here, <tt>GetMessageP</tt> 1762 to, <tt>SEND(P, GetMessageP)</tt> is called. Here, <tt>GetMessageP</tt>
1757 is the original message with the updated fields for <tt>HOPCOUNT</tt> (incremented 1763 is the original message with the updated fields for <tt>HOPCOUNT</tt> (incremented
1758 by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>. 1764 by 1), <tt>PEER_BF</tt> and <tt>RESULT_FILTER</tt>.
1765 <!-- FIXME: For how long? what exactly must be stored? -->
1766 The implementation <tt>MUST</tt> cache the originator peer address and the
1767 <tt>GetMessage</tt> in order to correctly process any <tt>ResultMessage</tt>s.
1759 </li> 1768 </li>
1760 </ol> 1769 </ol>
1761 </section> 1770 </section>
@@ -1951,8 +1960,6 @@ BEGIN
1951 does not have to match the <tt>QUERY_HASH</tt>. 1960 does not have to match the <tt>QUERY_HASH</tt>.
1952 </li> 1961 </li>
1953 <li> 1962 <li>
1954 <!-- FIXME: Discuss: Changed from MUST to SHOULD --
1955 same change as above - MSC -->
1956 If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the 1963 If the <tt>BTYPE</tt> of the message indicates a <tt>HELLO</tt> block, the
1957 peer <bcp14>SHOULD</bcp14> be considered for the local routing 1964 peer <bcp14>SHOULD</bcp14> be considered for the local routing
1958 table by using the peer address computed from the block using<tt>DeriveBlockKey</tt>. 1965 table by using the peer address computed from the block using<tt>DeriveBlockKey</tt>.
@@ -2015,13 +2022,12 @@ BEGIN
2015 </t> 2022 </t>
2016 </li> 2023 </li>
2017 <li> 2024 <li>
2018 <!-- FIXME: If that is the case, then this also needs to be in the 2025 Finally, the implementation <bcp14>SHOULD</bcp14> cache
2019 processing of GetMessage: I think we shoul dmove this to some 2026 <tt>ResultMessage</tt>s in order to provide already seen replies to
2020 performance considerations instead. 2027 future <tt>GetMessage</tt>s.
2021 => same formulation as for PUT to store if possible (MUST) 2028 The implementation <bcp14>MAY</bcp14> choose not no cache any or
2022 usr 1-to-1--> 2029 a limited number of <tt>ResultMessage</tt>s for reasons such as resource
2023 Finally, the implementation <bcp14>MAY</bcp14> choose to 2030 limitations.
2024 cache data from <tt>ResultMessage</tt>s.
2025 </li> 2031 </li>
2026 </ol> 2032 </ol>
2027 </section> 2033 </section>
@@ -2291,26 +2297,12 @@ BEGIN
2291 <dt>SetupResultFilter(FilterSize, Mutator) -&gt; RF</dt> 2297 <dt>SetupResultFilter(FilterSize, Mutator) -&gt; RF</dt>
2292 <dd> 2298 <dd>
2293 <t> 2299 <t>
2294 <!-- FIXME: I do not understand this. Isn't the element set E known
2295 for <tt>HELLO</tt> blocks? Isn't it H_ADDRS XOR MUTATOR?
2296 E => conected peers in routing table
2297 K => is 16
2298 -->
2299 The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a 2300 The RESULT_FILTER for <tt>HELLO</tt> blocks is implemented using a
2300 Bloom filter following the definition from <xref target="bloom_filters"/> 2301 Bloom filter following the definition from <xref target="bloom_filters"/>
2301 and consists of a variable number of buckets <tt>L</tt>. 2302 and consists of a variable number of buckets <tt>L</tt>.
2302 <tt>L</tt> depends on the number of elements <tt>|E|</tt> known to be filtered at the 2303 <tt>L</tt> depends on the number of connected peers <tt>|E|</tt> known to
2303 initiator. 2304 the peer creating a <tt>HELLO</tt> block from its own addresses:
2304 <!-- FIXME: Minimum space for used for what? There is no example given anywhere in the 2305 <tt>L</tt> is set to the minimum of
2305 spec how this becomes relevant. Again, this is not some abstract block,
2306 but specifically a <tt>HELLO</tt> (see above).
2307 E is the number of currently connected peers (neighbors)!
2308 E is no really ever 0 so the following sentence should be amended.
2309 -->
2310 If <tt>|E|</tt> is zero, the size <tt>L</tt> is set to 32 bits to provide some minimum
2311 space (to be used by peers when forwarding the request after
2312 returning local results).
2313 Otherwise, <tt>L</tt> is set to the minimum of
2314 2<sup>18</sup> bits (2<sup>15</sup> bytes) and the lowest power 2306 2<sup>18</sup> bits (2<sup>15</sup> bytes) and the lowest power
2315 of 2 that is strictly larger than <tt>2*K*|E|</tt> bits (<tt>K*|E|/4</tt> bytes). 2307 of 2 that is strictly larger than <tt>2*K*|E|</tt> bits (<tt>K*|E|/4</tt> bytes).
2316 </t> 2308 </t>
@@ -2538,12 +2530,12 @@ BEGIN
2538 control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N, provides 2530 control such as <xref target="RFC6940"/> which, like R<sup>5</sup>N, provides
2539 a peer-to-peer (P2P) signaling protocol with extensible routing and topology 2531 a peer-to-peer (P2P) signaling protocol with extensible routing and topology
2540 mechanisms. 2532 mechanisms.
2541 <!-- FIXME: Can we give examples here? 2533 Some decentralized applications such as the GNU Name System (<xref target="I-D.schanzen-gns"/>)
2542 Centralization DNS roots fixed through GNS. 2534 require a more open system that enables ad-hoc participation and other means to prevent common
2543 --> 2535 attacks on P2P overlays.
2544 Some decentralized applications require a more open system that 2536 GNS, for example, would be in conflict with its goals of providing a solution to the issues of a
2545 enables ad-hoc participation and other means to prevent common attacks 2537 "Single Hierarchy with a Centrally Controlled Root" and "Distribution and Management of Root Servers"
2546 on P2P overlays. 2538 in DNS as raised in <xref target="RFC8324"/>.
2547 </t> 2539 </t>
2548 </section> 2540 </section>
2549 </section> 2541 </section>
@@ -2600,7 +2592,7 @@ BEGIN
2600 Served", as described in <xref target="RFC8126"/>. 2592 Served", as described in <xref target="RFC8126"/>.
2601 GANA created the registry as follows: 2593 GANA created the registry as follows:
2602 </t> 2594 </t>
2603 <!-- FIXME changed GNS Reference to This.I-D because we either need to define it here 2595 <!-- NOTE: changed GNS Reference to This.I-D because we either need to define it here
2604 or in the GNS RFC. And I think here is better or in a separate document 2596 or in the GNS RFC. And I think here is better or in a separate document
2605 => not in here. Use separate document for NAMERECORD draft. 2597 => not in here. Use separate document for NAMERECORD draft.
2606 -MSC --> 2598 -MSC -->
@@ -2609,8 +2601,8 @@ BEGIN
2609Number| Name | References | Description 2601Number| Name | References | Description
2610------+----------------+------------+------------------------- 2602------+----------------+------------+-------------------------
26110 ANY [This.I-D] Reserved 26030 ANY [This.I-D] Reserved
261211 GNS_NAMERECORD [This.I-D] Block for GNS records
261313 DHT_HELLO [This.I-D] Address data for a peer 260413 DHT_HELLO [This.I-D] Address data for a peer
2605
2614Contact: r5n-registry@gnunet.org 2606Contact: r5n-registry@gnunet.org
2615]]></artwork> 2607]]></artwork>
2616 </figure> 2608 </figure>
@@ -2702,6 +2694,7 @@ Type | Name | References | Description
2702 &RFC6940; 2694 &RFC6940;
2703 &RFC8126; 2695 &RFC8126;
2704 &RFC8174; 2696 &RFC8174;
2697 &RFC8324;
2705 &I-D.schanzen-gns; 2698 &I-D.schanzen-gns;
2706 2699
2707 <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> 2700 <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>