commit d7caaa4c21aa986cebf35e31b7891608f1c441b9
parent 7e447e116a4cf9360ac878f222e617ef60b6ac4f
Author: Bernd Fix <brf@hoi-polloi.org>
Date: Wed, 17 Jul 2024 10:17:12 +0200
Section "Path" added to better explain path handling.
Diffstat:
1 file changed, 69 insertions(+), 0 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1261,6 +1261,75 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE):
</dd>
</dl>
</section>
+
+ <section anchor="p2p_path">
+ <name>Path</name>
+ <t>
+ If the <tt>RecordRoute</tt> flag is set, the travel 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.
+ </t>
+ <t>
+ A path element contains a signature and the public key of the peer that
+ created the element. The signature is computed over the public keys of the
+ previous peer (from which the message was received) and next peer (the
+ peer the message is send to). A new message has no previous peer and
+ uses the <tt>NULL</tt> public key for the signature.
+ </t>
+ <t>
+ Assuming peer A sends a new <tt>PUT</tt> message to peer B, which forwards
+ the message to peer C, which forwards to peer D which finally stores the data.
+ The <tt>PATH</tt> field of the message received at peer D contains three
+ path elements (build from top to bottom):
+ </t>
+ <figure anchor="figure_path" title="Example PATH">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
++--------------------+-------+
+| Sig A( 0,Pub B) | Pub A |
++--------------------+-------+
++--------------------+-------+
+| Sig B(Pub A,Pub C) | Pub B |
++--------------------+-------+
++--------------------+-------+
+| Sig C(Pub B,Pub D) | Pub C |
++--------------------+-------+
+ ]]></artwork>
+ </figure>
+ <t>
+ When appending a new path element, a peer <bcp14>MUST</bcp14> verify the
+ path integrity. It first checks that the peer sending the message has the
+ public key recorded in the last path element. It then checks all contained
+ signatures.
+ </t>
+ <t>
+ If an invalid signature is detected, the path is truncated keeping only
+ element fields following the faulty signature and setting the TRUCATED
+ flag. Assume that peer C detects a faulty signature in path element #2,
+ the trunacted path has two entries:
+ </t>
+ <figure anchor="figure_path_truncated" title="Example truncated PATH">
+ <artwork name="" type="" align="left" alt=""><![CDATA[
++-------+ +----------------------+-------+
+| Pub B | | Sig C (Pub B, Pub D) | Pub C |
++-------+ +----------------------+-------+
+ ]]></artwork>
+ </figure>
+ <t>
+ The TRUNCATED flag indicates that the first path element does not contain
+ a signature but only the public key of the peer where the signature fails.
+ </t>
+ <t>
+ The <tt>PATH</tt> is stored along with the payload data from the <tt>PUT</tt>
+ message at the final peer. When the peer delivers the data based on a
+ <tt>GET</tt> request, it initializes the <tt>PATH</tt> field with the stored
+ path value and appends a new path element. The first part of <tt>PATH</tt>
+ in a <tt>GET</tt> response mesage is called the <tt>PutPath</tt>, followed
+ by the <tt>GetPath</tt>.
+ </t>
+ </section>
+
<section anchor="p2p_pathelement">
<!-- TODO-GROTHOFF: Discuss this change again. The text is currently not correct
it is very difficult to understand. Is it worth 32 byte;
