commit 4505c81791f4e7ccdede38b01ede8364b5262344
parent a79a93f4928b11b631d71974cbe06d723a46bc3f
Author: Bernd Fix <brf@hoi-polloi.org>
Date: Wed, 17 Jul 2024 11:36:38 +0200
Clarified PATH verification / reconstruction.
Diffstat:
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1265,11 +1265,11 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE):
<section anchor="p2p_path">
<name>Path</name>
<t>
- If the <tt>RecordRoute</tt> flag is set, the travel of a <tt>PutMessage</tt>
+ If the <tt>RecordRoute</tt> flag is set, the route of a <tt>PutMessage</tt>
or a <tt>ResultMessage</tt> through the overlay network is recorded in the
<tt>PATH</tt> field of the message. <tt>PATH</tt> is a list of path elements.
- A new path element is appended to the existing <tt>PATH</tt> before
- a peer sends the message to the next peer.
+ A new path element (<xref target="p2p_pathelement"/>) is appended to the
+ existing <tt>PATH</tt> before a peer sends the message to the next peer.
</t>
<t>
A path element contains a signature and the public key of the peer that
@@ -1299,6 +1299,12 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE):
]]></artwork>
</figure>
<t>
+ Note that the wire format of <tt>PATH</tt> (<xref target="p2p_pathelement"/>)
+ will not include the last public key (Pub C in our example) as this will be
+ redundant; the receiver of a message can use the public key of the sender as
+ the public key to verify the last signature.
+ </t>
+ <t>
The <tt>PATH</tt> is stored along with the payload data from the <tt>PUT</tt>
message at the final peer. Note that the same payload stored at different
peers will have a different <tt>PATH</tt> associated with it.
@@ -1315,14 +1321,13 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE):
<t>
When receiving a message with flag <tt>RecordRoute</tt> and <tt>PATH</tt>,
a peer is encouraged to verify the integrity of <tt>PATH</tt> (if the
- available resources of the peer allow this). A validator should first check
- that the peer sending the message has its public key recorded in the last
- path element. It may then check all contained signatures.
+ available resources of the peer allow this) by checking the signatures of
+ the path elements.
</t>
<t>
If an invalid signature is detected, the path is truncated keeping only
element fields following the faulty signature and setting the <tt>Truncated</tt>
- flag. Assume that peer C detects a faulty signature in path element #2,
+ flag. Assume that peer C detects a faulty signature from peer B,
the trunacted path has two entries:
</t>
<figure anchor="figure_path_truncated" title="Example truncated PATH">
