lsd0004

commit a79a93f4928b11b631d71974cbe06d723a46bc3f
parent 52430e3ab17df6160c645358108b5bfdff8206c5
Author: Bernd Fix <brf@hoi-polloi.org>
Date:   Wed, 17 Jul 2024 11:11:58 +0200

Section p2p_path: clarified PATH check conditions.

Diffstat:
M
draft-schanzen-r5n.xml
 | 
31
+++++++++++++++++++------------

1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -1299,10 +1299,25 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE):
           ]]></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.
+          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.
+        </t>
+        <t>
+          When the storing 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
+          message is called the <tt>PutPath</tt>, followed
+          by the <tt>GetPath</tt>. This way the combined <tt>PATH</tt> will record the
+          whole route of the payload from the originating peer (initial
+          <tt>PutMessage</tt>) to the requesting peer (initial <tt>GetMessage</tt>).
+        </t>
+        <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.
         </t>
         <t>
           If an invalid signature is detected, the path is truncated keeping only
@@ -1321,14 +1336,6 @@ ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE):
           The <tt>Truncated</tt> 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 message is called the <tt>PutPath</tt>, followed
-          by the <tt>GetPath</tt>.
-        </t>
       </section>
 
       <section anchor="p2p_pathelement">