[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated: add new truncated origin signed fields
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated: add new truncated origin signed fields to messages |
|
Date: |
Thu, 07 Jul 2022 20:42:19 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0004.
The following commit(s) were added to refs/heads/master by this push:
new 2124404 add new truncated origin signed fields to messages
2124404 is described below
commit 2124404d5749bf30e89f7ebec7cec2355107b8cb
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Thu Jul 7 20:40:22 2022 +0200
add new truncated origin signed fields to messages
---
draft-schanzen-r5n.xml | 214 ++++++++++++++++++++++++++++++++-----------------
1 file changed, 139 insertions(+), 75 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 641397c..c662e87 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -133,7 +133,7 @@
permissionless participation and support for
topologies in restricted-route environments. R<sup>5</sup>N also
includes advanced features like tracing paths messages take through the
- network, response filters and on-path application-specific data
validation.
+ network, response filters and on-path application-specific data
validation.
</t>
<t>
This document defines the normative wire format of peer-to-peer
@@ -195,7 +195,7 @@
a peer in the underlay.
The Peer ID is the public key of the corresponding
Ed25519<xref target="ed25519" /> peer private key.
-
+
</dd>
<dt>Peer Address:</dt>
<dd>
@@ -619,7 +619,7 @@ Connectivity | |Underlay| |Underlay|
<t>
These signals then drive updates of the routing table, local storage
and message transmission.
- </t>
+ </t>
</section>
<section anchor="bootstrapping">
<name>Bootstrapping</name>
@@ -630,7 +630,7 @@ Connectivity | |Underlay| |Underlay|
least one working HELLO to the DHT for bootstrapping.
While details on how the first connection is established
<bcp14>MAY</bcp14>
depend on the specific implementation, this <bcp14>SHOULD</bcp14>
usually be done
- by an out-of-band exchange of the information from a HELLO block.
+ by an out-of-band exchange of the information from a HELLO block.
For this, section <xref target="hello_url"/> specifies a URL format
for encoding HELLO
blocks as text strings which <bcp14>SHOULD</bcp14> be supported by
implementations.
</t>
@@ -654,20 +654,20 @@ Connectivity | |Underlay| |Underlay|
</t>
<t>
The frequency of advertisement and peer discovery messages
- <bcp14>MAY</bcp14> be adapted according to network conditions,
+ <bcp14>MAY</bcp14> be adapted according to network conditions,
the set of already connected neighbors,
the workload of the system and other factors which are at the
discretion of
the developer.
</t>
<t>
- Any implementation encountering a HELLO GET request
<bcp14>MUST</bcp14> respond
+ Any implementation encountering a HELLO GET request
<bcp14>MUST</bcp14> respond
with its own HELLO block except if that block is
- filtered by the request's result filter (see <xref
target="result_filter"/>).
- Implementations <bcp14>MAY</bcp14> respond
+ filtered by the request's result filter (see <xref
target="result_filter"/>).
+ Implementations <bcp14>MAY</bcp14> respond
with additional valid HELLO blocks of other peers with keys
closest to the key of the GET request. A HELLO block is "valid"
if it is non-expired and
- is not excluded by the result filter. "closest" is defined
+ is not excluded by the result filter. "closest" is defined
by considering the distances between the request's key and the
peer addresses of all of the valid HELLO blocks known at the local
node.
</t>
@@ -678,7 +678,7 @@ Connectivity | |Underlay| |Underlay|
as the scheme, followed by "hello/" for the name
of the GNUnet subsystem, followed by "/"-separated values
with the GNS
- Base32 encoding (FIXME: described here or reference GNS draft?) of
+ Base32 encoding (FIXME: described here or reference GNS draft?) of
the <tt>Peer ID</tt>, a Base32-encoded EdDSA signature, and an
expiration
time in seconds since the UNIX Epoch in decimal format.
After this a "?" begins a list of key-value pairs where the key
@@ -700,7 +700,7 @@ ZFK0G9BWETY3CCE2QWGVT4WA7JN5M9HMWG\
FIXME: signature is invalid, should
maybe generate proper test vector.
]]>
- </artwork>
+ </artwork>
</figure>
<t>
It specifies that the peer with the ID "RH1M...6Y3G"
@@ -728,7 +728,7 @@ addr-name = scheme
addr-value = *pchar
bchar = *(ALPHA / DIGIT)
]]>
- </artwork>
+ </artwork>
</figure>
<t>
'scheme' is defined in <xref target="RFC3986" /> in Section 3.1.
@@ -787,10 +787,10 @@ bchar = *(ALPHA / DIGIT)
follows an XOR-based peer distance calculation.
</t>
<t>
- To enable routing, any R<sup>5</sup>N implementation must keep
+ To enable routing, any R<sup>5</sup>N implementation must keep
information about its current set of neighbors.
Upon receiving a connection notification from the Underlay through
- <tt>PEER_CONNECTED</tt>, information on the new neighbor
+ <tt>PEER_CONNECTED</tt>, information on the new neighbor
<bcp14>MUST</bcp14> be added, and similarly when
a disconnect is indicated by the Underlay through
<tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed.
@@ -826,7 +826,7 @@ bchar = *(ALPHA / DIGIT)
signalling to indicate that they are merely a client utilizing a
DHT and not able to participate in routing. DHT peers receiving
such connections <bcp14>MUST NOT</bcp14> include connections to
- such restricted systems in their k-buckets, thereby effectively
+ such restricted systems in their k-buckets, thereby effectively
excluding them when making routing decisions.
</t>
<t>
@@ -843,7 +843,7 @@ bchar = *(ALPHA / DIGIT)
To build its routing table, a peer will send out requests
asking for blocks of type HELLO using its own location as the key,
but filtering all of its neighbors via the Bloom filter described
- in <xref target="result_filter"/>.
+ in <xref target="result_filter"/>.
These requests <bcp14>MUST</bcp14> use the FindApproximate and
DemultiplexEverywhere
flags. FindApproximate will ensure that other peers will reply
with keys they merely consider close-enough, while
DemultiplexEverywhere
@@ -885,7 +885,7 @@ bchar = *(ALPHA / DIGIT)
<t>
The peer Bloom filter is always a 128 byte field. The elements
hashed into the Bloom filter are the 32 byte peer IDs. We note
- that the peer Bloom filter may exclude peers due to false-postive
+ that the peer Bloom filter may exclude peers due to false-postive
matches. This is acceptable as routing should nevertheless
terminate (with high probability) in close vicinity of the key.
</t>
@@ -893,9 +893,9 @@ bchar = *(ALPHA / DIGIT)
<section anchor="routing_functions">
<name>Routing Functions</name>
<t>
- Using the data structures described so far,
- the R<sup>5</sup>N routing component provides
- the following functions for
+ Using the data structures described so far,
+ the R<sup>5</sup>N routing component provides
+ the following functions for
message processing (<xref target="p2p_messages"/>):
</t>
<dl>
@@ -915,16 +915,16 @@ bchar = *(ALPHA / DIGIT)
routing table with the shortest XOR-distance to the key <tt>K</tt>.
This means that for all other peers <tt>N'</tt> in the routing
table
<tt>GetDistance(N, K) < GetDistance(N',K)</tt>.
- Peers with a positive test against the peer Bloom
+ Peers with a positive test against the peer Bloom
filter <tt>B</tt> are not considered.
</dd>
<dt>
<tt>SelectRandompeer(B) -> N</tt>
</dt>
<dd>
- This function selects a random peer <tt>N</tt> from
+ This function selects a random peer <tt>N</tt> from
all neighbors.
- Peers with a positive test in the peer Bloom
+ Peers with a positive test in the peer Bloom
filter <tt>B</tt> are not considered.
</dd>
<dt>
@@ -974,7 +974,7 @@ BEGIN
if (REPL_LEVEL > 16)
REPL_LEVEL = 16
RM1 = REPL_LEVEL - 1
- return 1 + (RM1 / (L2NSE + RM1 * HOPCOUNT))
+ return 1 + (RM1 / (L2NSE + RM1 * HOPCOUNT))
]]></artwork>
</figure>
<t>
@@ -1030,7 +1030,7 @@ BEGIN
track requests from local applications separately and
preserve the information until the application explicitly
stops the request.
- </t>
+ </t>
</section>
</section>
<section anchor="p2p_messages" numbered="true" toc="default">
@@ -1070,13 +1070,20 @@ BEGIN
<dt>1: RecordRoute</dt>
<dd>
This bit indicates to keep track of the path that the message takes
- in the P2P network.
+ in the P2P network.
</dd>
<dt>2: FindApproximate</dt>
<dd>
This bit allows results where the key does not match exactly.
</dd>
- <dt>3-15: Reserved</dt>
+ <dt>3: Truncated</dt>
+ <dd>
+ This is a special flag which is set if a peer truncated the path
+ and thus the first hop on the path is given without a signature
+ to enable checking of the next signature. MUST never be set in
+ a query.
+ </dd>
+ <dt>4-15: Reserved</dt>
<dd>
The remaining bits are reserved for future use and
<bcp14>MUST</bcp14> be set to 0 when initiating an operation.
@@ -1101,7 +1108,7 @@ BEGIN
<t>
The public key of the peer which created the signature is in the
next path element, or is the sender of the message if this was the
- last path element.
+ last path element.
The wire format of a Path Element is illustrated in
<xref target="figure_pathelement"/>.
</t>
@@ -1141,7 +1148,7 @@ BEGIN
The SIGNATURE covers a 64-bit contextualization header, the
the block expiration, a hash of the block
payload, as well as the predecessor peer ID and the peer ID of the
- successor that the peer making the signature is routing the
+ successor that the peer making the signature is routing the
message to. Thus, the signature made by SELF basically says that
SELF received the block payload from PEER PREDECESSOR and has
forwarded
it to PEER SUCCESSOR. The wire format is illustrated
@@ -1212,7 +1219,7 @@ BEGIN
<section anchor="p2p_hello" numbered="true" toc="default">
<name>HelloMessage</name>
<t>
- <tt>HelloMessage</tt>s are used to inform neighbors of
+ <tt>HelloMessage</tt>s are used to inform neighbors of
a peer about the sender's available addresses. The
recipients use these messages to inform their respective
Underlays about ways to sustain the connections and to
@@ -1221,11 +1228,11 @@ BEGIN
from other peers. In contrast to a HELLO block, a
<tt>HelloMessage</tt> does not contain the ID of
the peer the address information is about: in a
- <tt>HelloMessage</tt>, the address information is always
+ <tt>HelloMessage</tt>, the address information is always
about the sender. Since
the Underlay is responsible to determine the
peer ID of the sender for all messages, it would thus be
- redundant to also include the peer ID in the
+ redundant to also include the peer ID in the
<tt>HelloMessage</tt>.
</t>
<section anchor="p2p_hello_wire">
@@ -1340,8 +1347,12 @@ BEGIN
| BLOCK_KEY /
/ (64 byte) |
+-----+-----+-----+-----+-----+-----+-----+-----+
+/ TRUNCATED ORIGIN (0 or 32 bytes) /
++-----+-----+-----+-----+-----+-----+-----+-----+
/ PUTPATH (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
+/ LAST HOP SIGNATURE (0 or 64 bytes) /
++-----+-----+-----+-----+-----+-----+-----+-----+
/ BLOCK (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
@@ -1398,11 +1409,35 @@ BEGIN
The key under which the <tt>PutMessage</tt> wants to store
content
under.
</dd>
+ <dt>TRUNCATED ORIGIN</dt>
+ <dd>
+ is only provided if the TRUNCATED flag
+ is set in OPTIONS. If present, this is
+ the public key of the peer just before
+ the first entry on the PUTPATH and the
+ first peer on the PUTPATH is not the
+ actual origin of the message. Thus, to
+ verify the first signature on the PUTPATH,
+ this public key must be used. Note that
+ due to the truncation, this last hop
+ cannot be verified to exist.
+ </dd>
<dt>PUTPATH</dt>
<dd>
the variable-length PUT path.
The path consists of a list of PATH_LEN Path Elements.
</dd>
+ <dt>LAST HOP SIGNATURE</dt>
+ <dd>
+ is only provided if the RECORD ROUTE flag
+ is set in OPTIONS. If present, this is
+ an EdDSA signature of the sender of this message
+ (using the same format as the signatures in PUTPATH)
+ affirming that the sender forwarded the message from
+ the predecessor (all zeros if PATH_LEN is 0,
+ otherwise the last peer in PUTPATH) to
+ the target peer.
+ </dd>
<dt>BLOCK</dt>
<dd>
the variable-length block payload. The contents are determined
@@ -1448,14 +1483,14 @@ BEGIN
<li>
If the <tt>RecordRoute</tt> flag is set in FLAGS,
the local peer address <bcp14>MUST</bcp14> be appended to the
<tt>PUTPATH</tt>
- of the message. If the flag is not set, the <tt>PATH_LEN</tt>
+ of the message. If the flag is not set, the <tt>PATH_LEN</tt>
<bcp14>MUST</bcp14> be set to zero.
</li>
<li>
- If the <tt>PATH_LEN</tt> is non-zero,
+ If the <tt>PATH_LEN</tt> is non-zero,
the local peer <bcp14>SHOULD</bcp14> verify the signatures from
the <tt>PUTPATH</tt>.
Verification <bcp14>MAY</bcp14> involve checking all signatures
or any random
- subset of the signatures. It is <bcp14>RECOMMENDED</bcp14> that
peers adapt
+ subset of the signatures. It is <bcp14>RECOMMENDED</bcp14> that
peers adapt
their behavior to available computational resources so as to not
make signature
verification a bottleneck. If an invalid signature is found, the
<tt>PUTPATH</tt> <bcp14>MUST</bcp14> be truncated to only include
the elements
@@ -1469,9 +1504,9 @@ BEGIN
</li>
<li>
If the <tt>MTYPE</tt> of the message indicates a HELLO block, the
- peer <bcp14>MUST</bcp14> be considered for the local routing
+ peer <bcp14>MUST</bcp14> be considered for the local routing
table if the respective k-bucket is not yet full. In this case,
- the local peer <bcp14>MUST</bcp14> try to establish a connection
+ the local peer <bcp14>MUST</bcp14> try to establish a connection
to the peer indicated in the HELLO block using the address
information
from the HELLO block. If a connection is established,
the peer is added to the respective k-bucket of the routing
table.
@@ -1482,7 +1517,7 @@ BEGIN
Given the value in <tt>REPL_LVL</tt>, <tt>HOPCOUNT</tt> and the
result of <tt>IsClosestpeer(SELF, BLOCK_KEY)</tt> the number of
peers to
forward to <bcp14>MUST</bcp14> be calculated
- using <tt>ComputeOutDegree()</tt>.
+ using <tt>ComputeOutDegree()</tt>.
The implementation <bcp14>SHOULD</bcp14> select up to this
number of peers to forward the message to. The implementation
<bcp14>MAY</bcp14>
forward to fewer or no peers in order to handle resource
constraints
@@ -1491,7 +1526,7 @@ BEGIN
<tt>PEER_BF</tt> before forwarding the message.
For all peers with peer address <tt>P</tt> selected to forward
the message
to, <tt>SEND(P, PutMessage')</tt> is called. Here,
<tt>PutMessage'</tt>
- is the original message with updated fields. In particular,
<tt>HOPCOUNT</tt>
+ is the original message with updated fields. In particular,
<tt>HOPCOUNT</tt>
<bcp14>MUST</bcp14> be incremented by 1.
</li>
</ol>
@@ -1604,7 +1639,7 @@ BEGIN
<t>
How exactly a block result is added to a result filter
<bcp14>MUST</bcp14> be
- specified as part of the definition of a block type.
+ specified as part of the definition of a block type.
</t>
</section>
<section anchor="p2p_get_processing">
@@ -1669,7 +1704,7 @@ BEGIN
</t>
<t>
If the <tt>BTYPE</tt> is supported and
<tt>ValidateBlockReply</tt> for the given
- query has yielded a status of <tt>FILTER_LAST</tt>, processing
+ query has yielded a status of <tt>FILTER_LAST</tt>, processing
<bcp14>MUST</bcp14> end and not continue with forwarding of
the request to other peers.
</t>
@@ -1687,7 +1722,7 @@ BEGIN
peer address <tt>SELF</tt>.
For all peers with peer address <tt>P'</tt> chosen to forward
the message
to, <tt>SEND(P', GetMessage')</tt> is called. Here,
<tt>GetMessage'</tt>
- is the original message with updated fields. In particular,
<tt>HOPCOUNT</tt>
+ is the original message with updated fields. In particular,
<tt>HOPCOUNT</tt>
<bcp14>MUST</bcp14> be incremented by 1.
</li>
</ol>
@@ -1713,12 +1748,16 @@ BEGIN
| QUERY_HASH /
/ (64 byte) |
+-----+-----+-----+-----+-----+-----+-----+-----+
+/ TRUNCATED ORIGIN (0 or 32 bytes) /
++-----+-----+-----+-----+-----+-----+-----+-----+
/ PUTPATH /
/ (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
/ GETPATH /
/ (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
+/ LAST HOP SIGNATURE (0 or 64 bytes) /
++-----+-----+-----+-----+-----+-----+-----+-----+
/ BLOCK /
/ (variable length) /
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1737,7 +1776,7 @@ BEGIN
</dd>
<dt>RESERVED</dt>
<dd>
- is a 32-bit value. Implementations <bcp14>MUST</bcp14>
+ is a 32-bit value. Implementations <bcp14>MUST</bcp14>
set this value to zero when originating a result message.
Implementations <bcp14>MUST</bcp14> forward
this value unchanged even if it is non-zero.
@@ -1772,6 +1811,19 @@ BEGIN
the query hash corresponding to the <tt>GetMessage</tt> which
caused this reply message to be sent.
</dd>
+ <dt>TRUNCATED ORIGIN</dt>
+ <dd>
+ is only provided if the TRUNCATED flag
+ is set in OPTIONS. If present, this is
+ the public key of the peer just before
+ the first entry on the PUTPATH and the
+ first peer on the PUTPATH is not the
+ actual origin of the message. Thus, to
+ verify the first signature on the PUTPATH,
+ this public key must be used. Note that
+ due to the truncation, this last hop
+ cannot be verified to exist.
+ </dd>
<dt>PUTPATH</dt>
<dd>
the variable-length PUT path.
@@ -1782,6 +1834,17 @@ BEGIN
the variable-length PUT path.
The path consists of a list of <tt>GET_PATH_LEN</tt> Path
Elements.
</dd>
+ <dt>LAST HOP SIGNATURE</dt>
+ <dd>
+ is only provided if the RECORD ROUTE flag
+ is set in OPTIONS. If present, this is
+ an EdDSA signature of the sender of this message
+ (using the same format as the signatures in PUTPATH)
+ affirming that the sender forwarded the message from
+ the predecessor (all zeros if PATH_LEN is 0,
+ otherwise the last peer in PUTPATH) to
+ the target peer.
+ </dd>
<dt>BLOCK</dt>
<dd>
the variable-length resource record data payload.
@@ -1801,19 +1864,19 @@ BEGIN
If the message is expired, it <bcp14>MUST</bcp14> be discarded.
</li>
<li>
- If the <tt>BTYPE</tt> is supported, then the <tt>BLOCK</tt>
- <bcp14>MUST</bcp14> be validated against the
+ If the <tt>BTYPE</tt> is supported, then the <tt>BLOCK</tt>
+ <bcp14>MUST</bcp14> be validated against the
requested <tt>BTYPE</tt>. To do this, the peer
checks that the block is valid using
<tt>ValidateBlockStoreRequest</tt>.
If the result is <tt>BLOCK_INVALID</tt>, the message
<bcp14>MUST</bcp14> be
discarded.
</li>
<li>
- If the <tt>PUT_PATH_LEN</tt> or the <tt>GET_PATH_LEN</tt> are
non-zero,
+ If the <tt>PUT_PATH_LEN</tt> or the <tt>GET_PATH_LEN</tt> are
non-zero,
the local peer <bcp14>SHOULD</bcp14> verify the signatures from
the <tt>PUTPATH</tt>
and the <tt>GETPATH</tt>.
Verification <bcp14>MAY</bcp14> involve checking all signatures
or any random
- subset of the signatures. It is <bcp14>RECOMMENDED</bcp14> that
peers adapt
+ subset of the signatures. It is <bcp14>RECOMMENDED</bcp14> that
peers adapt
their behavior to available computational resources so as to not
make signature
verification a bottleneck. If an invalid signature is found, the
path <bcp14>MUST</bcp14> be truncated to only include the elements
@@ -1828,9 +1891,9 @@ BEGIN
</li>
<li>
If the <tt>MTYPE</tt> of the message indicates a HELLO block, the
- peer <bcp14>MUST</bcp14> be considered for the local routing
+ peer <bcp14>MUST</bcp14> be considered for the local routing
table if the respective k-bucket is not yet full. In this case,
- the local peer <bcp14>MUST</bcp14> try to establish a connection
+ the local peer <bcp14>MUST</bcp14> try to establish a connection
to the peer indicated in the HELLO block using the address
information
from the HELLO block. If a connection is established,
the peer is added to the respective k-bucket of the routing
table.
@@ -1848,7 +1911,7 @@ BEGIN
If the <tt>FindApproximate</tt> flag was not set in the query
and the <tt>BTYPE</tt> allowed the
implementation to compute the key from the block, the
computed key must
exactly match the <tt>QUERY_HASH</tt>, otherwise the result
does
- not match the pending query and processing continues with the
next pending query.
+ not match the pending query and processing continues with the
next pending query.
</li>
<li>
If the <tt>BTYPE</tt> is supported, result block
<bcp14>MUST</bcp14>
@@ -1859,7 +1922,7 @@ BEGIN
query.
</li>
<li>
- If the <tt>BTYPE</tt> is not supported, filtering of exact
duplicate
+ If the <tt>BTYPE</tt> is not supported, filtering of exact
duplicate
replies <bcp14>MUST</bcp14> still be performed before
forwarding
the reply.
Such duplicate filtering <bcp14>MAY</bcp14> be implemented
@@ -1872,8 +1935,8 @@ BEGIN
the local peer address <bcp14>MUST</bcp14> be appended to
the <tt>GETPATH</tt>
of the message and the respective signature
<bcp14>MUST</bcp14> be
set using the query origin as the <tt>PEER SUCCESSOR</tt>
and the
- response origin as the <tt>PEER PREDECESSOR</tt>. If the
flag is not set,
- the <tt>GET_PATH_LEN</tt> and <tt>PUT_PATH_LEN</tt>
+ response origin as the <tt>PEER PREDECESSOR</tt>. If the
flag is not set,
+ the <tt>GET_PATH_LEN</tt> and <tt>PUT_PATH_LEN</tt>
<bcp14>MUST</bcp14> be set to zero when forwarding the result.
</li>
</ol>
@@ -1885,9 +1948,9 @@ BEGIN
</t>
</li>
<li>
- Finally, the implementation <bcp14>MAY</bcp14> choose to
+ Finally, the implementation <bcp14>MAY</bcp14> choose to
cache data from <tt>ResultMessage</tt>s.
- </li>
+ </li>
</ol>
</section>
</section>
@@ -1896,7 +1959,7 @@ BEGIN
<name>Blocks</name>
<t>
This section describes various considerations R<sup>5</sup>N
- implementations must consider with respect to blocks.
+ implementations must consider with respect to blocks.
Specifically, implementations <bcp14>SHOULD</bcp14> be able
to validate and persist blocks. Implementations
<bcp14>MAY</bcp14> not support validation for all types
@@ -1907,7 +1970,7 @@ BEGIN
Applications can and should define their own block types.
The block type determines the format and handling of the block
payload by peers in <tt>PutMessage</tt>s and <tt>ResultMessage</tt>s.
- Block types <bcp14>MUST</bcp14> be registered with GANA
+ Block types <bcp14>MUST</bcp14> be registered with GANA
(see <xref target="gana_block_type"/>).
</t>
<t>
@@ -1916,7 +1979,7 @@ BEGIN
<name>Block Operations</name>
<t>
Block validation may be necessary for all types of DHT
- messages. To enable these validations, any block type
+ messages. To enable these validations, any block type
specification <bcp14>MUST</bcp14> define the following functions:
</t>
<dl>
@@ -1926,7 +1989,7 @@ BEGIN
<t>
is used to evaluate the request for a block as part of
<tt>GetMessage</tt> processing. Here, the block payload is
unkown,
- but if possible the <tt>XQuery</tt> and <tt>Key</tt>
+ but if possible the <tt>XQuery</tt> and <tt>Key</tt>
<bcp14>SHOULD</bcp14> be verified. Possible values for
the <tt>RequestEvaluationResult</tt> are:
</t>
@@ -1943,7 +2006,7 @@ BEGIN
</dd>
<dt>DeriveBlockKey(Block) -> Key | NONE</dt>
<dd>
- is used to synthesize the block key from the block payload as
+ is used to synthesize the block key from the block payload as
part of <tt>PutMessage</tt> and <tt>ResultMessage</tt>
processing.
The special return value of <tt>NONE</tt> implies that this block
type does not
permit deriving the key from the block. A Key may be returned
@@ -1963,8 +2026,8 @@ BEGIN
<dt>BLOCK_INVALID</dt>
<dd>Block payload does not match the block type.
</dd>
- </dl>
- </dd>
+ </dl>
+ </dd>
<dt>SetupResultFilter(FilterSize, Mutator) -> RF</dt>
<dd>
is used to setup an empty result filter. The arguments
@@ -1999,7 +2062,7 @@ BEGIN
<t>
If the main evaluation result is <tt>FILTER_MORE</tt>, the
function also returns
and updated result filter where the block is added to the set of
- filtered replies. An implementation is not expected to actually
differenciate
+ filtered replies. An implementation is not expected to actually
differenciate
between the <tt>FILTER_DUPLICATE</tt> and
<tt>FILTER_IRRELEVANT</tt> return
values: in both cases the block is ignored for this query.
</t>
@@ -2021,7 +2084,7 @@ BEGIN
The HELLO block type wire format is illustrated in
<xref target="figure_hello"/>. A query for block of type HELLO
<bcp14>MUST NOT</bcp14>
include extended query data (XQuery). Any implementation
- encountering a request for a HELLO with non-empty XQuery
+ encountering a request for a HELLO with non-empty XQuery
data <bcp14>MUST</bcp14> consider the request invalid and ignore it.
</t>
<figure anchor="figure_hello" title="The HELLO Block Format.">
@@ -2204,8 +2267,8 @@ gnunet+tcp://12.3.4.5/ \
deterministic across peers. The 32-bit <tt>MUTATOR</tt>
value is set by the peer initiating the GET request, and changed
every time the GET request is repeated by the initiator. Peers
- forwarding GET requests <bcp14>MUST</bcp14> not change the
- mutator value included in the <tt>RESULT_FILTER</tt> as they might
not
+ forwarding GET requests <bcp14>MUST</bcp14> not change the
+ mutator value included in the <tt>RESULT_FILTER</tt> as they might
not
be able to recalculate the result filter with a different
<tt>MUTATOR</tt>
value.
</t>
@@ -2214,11 +2277,11 @@ gnunet+tcp://12.3.4.5/ \
requests have statistically independent probabilities of creating
false-positives in a result filter. Thus, even if for one request
a result filter may exclude a result as a false-positive
- match, subsequent requests are likely to not have the same
+ match, subsequent requests are likely to not have the same
false-positives.
</t>
<t>
- HELLO result filters can be merged if the
+ HELLO result filters can be merged if the
Bloom filters have the same size and
<tt>MUTATOR</tt> by setting all bits to 1 that are
set in either Bloom filter. This is done whenever
@@ -2233,8 +2296,8 @@ gnunet+tcp://12.3.4.5/ \
the <tt>ADDRESSES</tt>) and XORed with the SHA-512
hash of the <tt>MUTATOR</tt> (in network byte order).
The resulting value is then used when hashing into the
- Bloom filter as described in <xref target="bloom_filters" />.
- Consequently, HELLOs with completely identical sets of
+ Bloom filter as described in <xref target="bloom_filters" />.
+ Consequently, HELLOs with completely identical sets of
addresses will be filtered and FILTER_DUPLICATE is returned.
Any small variation in the set of addresses will cause the block
to no longer be filtered (with high probability) and
@@ -2246,8 +2309,8 @@ gnunet+tcp://12.3.4.5/ \
<name>Persistence</name>
<t>
An implementation <bcp14>SHOULD</bcp14> provide a local persistence
mechanism for
- blocks. Embedded systems that lack storage capability
<bcp14>MAY</bcp14> use
- connection-level signalling to indicate that they are merely a client
utilizing a
+ blocks. Embedded systems that lack storage capability
<bcp14>MAY</bcp14> use
+ connection-level signalling to indicate that they are merely a client
utilizing a
DHT and are not able to participate with storage.
The local storage <bcp14>MUST</bcp14> provide the following
functionality:
</t>
@@ -2257,7 +2320,8 @@ gnunet+tcp://12.3.4.5/ \
Stores a block under the specified key. If an block with identical
payload exists already under the same key, the meta data should
be set to the maximum expiration time of both blocks and use the
- corresponding <tt>PUTPATH</tt> of that version of the block.
+ corresponding <tt>PUTPATH</tt> (and if applicable
+ <tt>TRUNCATED ORIGIN</tt>) of that version of the block.
</dd>
<dt>Lookup(Key) -> List of Blocks</dt>
<dd>
@@ -2358,7 +2422,7 @@ gnunet+tcp://12.3.4.5/ \
The <tt>ComputeOutDegree</tt> function limits the
<tt>REPL_LVL</tt> to a maximum of 16. This imposes
an upper limit on bandwidth amplification an attacker
- may achieve for a given network size and topology.
+ may achieve for a given network size and topology.
</t>
<section>
<name>Approximate Result Filtering</name>
@@ -2404,7 +2468,7 @@ gnunet+tcp://12.3.4.5/ \
</t>
</section>
</section>
-
+
<section anchor="gana" numbered="true" toc="default">
<name>GANA Considerations</name>
<section anchor="gana_block_type" numbered="true" toc="default">
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0004] branch master updated: add new truncated origin signed fields to messages,
gnunet <=