1 files changed, 69 insertions, 0 deletions

diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index e7630f5..4b8e04c 100644
--- 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;