[or-cvs] r17816: {tor} Document RELAY_EARLY cells in tor-spec.txt: proposal 110 is (in tor/trunk/doc/spec: . proposals)

[nickm@xxxxxxxx]

Author: nickm
Date: 2008-12-29 14:55:23 -0500 (Mon, 29 Dec 2008)
New Revision: 17816

Modified:
   tor/trunk/doc/spec/proposals/110-avoid-infinite-circuits.txt
   tor/trunk/doc/spec/tor-spec.txt
Log:
Document RELAY_EARLY cells in tor-spec.txt: proposal 110 is mostly implemented, and the rest of it will need to wait until all current Tor 0.2.0.x clients are obsolete to close.

Modified: tor/trunk/doc/spec/proposals/110-avoid-infinite-circuits.txt
===================================================================
--- tor/trunk/doc/spec/proposals/110-avoid-infinite-circuits.txt	2008-12-29 19:55:17 UTC (rev 17815)
+++ tor/trunk/doc/spec/proposals/110-avoid-infinite-circuits.txt	2008-12-29 19:55:23 UTC (rev 17816)
@@ -57,6 +57,12 @@
   data cells over the stream as relay_early cells, regardless of their
   actual type.
 
+  (Note that a circuit that is out of relay_early cells MUST NOT be
+  cannibalized later, since it can't extend.  Note also that it's always okay
+  to use regular RELAY cells when sending non-EXTEND commands targetted at
+  the first hop of a circuit, since there is no intermediate hop to try to
+  learn the relay command type.)
+
   Each intermediate server would pass on the same type of cell that it
   received (either relay or relay_early), and the cell's destination
   will be able to learn whether it's allowed to contain an Extend request.

Modified: tor/trunk/doc/spec/tor-spec.txt
===================================================================
--- tor/trunk/doc/spec/tor-spec.txt	2008-12-29 19:55:17 UTC (rev 17815)
+++ tor/trunk/doc/spec/tor-spec.txt	2008-12-29 19:55:23 UTC (rev 17816)
@@ -289,6 +289,7 @@
          6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1)
          7 -- VERSIONS    (Negotiate proto version) (See Sec 4)
          8 -- NETINFO     (Time and address info)   (See Sec 4)
+         9 -- RELAY_EARLY (End-to-end data; limited) (See sec 5.6)
 
    The interpretation of 'Payload' depends on the type of the cell.
       PADDING: Payload is unused.
@@ -623,9 +624,9 @@
 
 5.5. Routing relay cells
 
-   When an OR receives a RELAY cell, it checks the cell's circID and
-   determines whether it has a corresponding circuit along that
-   connection.  If not, the OR drops the RELAY cell.
+   When an OR receives a RELAY or RELAY_EARLY cell, it checks the cell's
+   circID and determines whether it has a corresponding circuit along that
+   connection.  If not, the OR drops the cell.
 
    Otherwise, if the OR is not at the OP edge of the circuit (that is,
    either an 'exit node' or a non-edge node), it de/encrypts the payload
@@ -653,6 +654,24 @@
 
    For more information, see section 6 below.
 
+5.6. Handling relay_early cells
+
+   A RELAY_EARLY cell is designed to limit the length any circuit can reach.
+   When an OR receives a RELAY_EARLY cell, and the next node in the circuit
+   is speaking v2 of the link protocol or later, the OR relays the cell as a
+   RELAY_EARLY cell.  Otherwise, it relays it as a RELAY cell.
+
+   If a node ever receives more than 8 RELAY_EARLY cells on a given circuit,
+   it SHOULD close the circuit.
+
+   When speaking v2 of the link protocol or later, clients MUST only send
+   EXTEND cells inside RELAY_EARLY cells.  Clients SHOULD send the first ~8
+   RELAY cells that are not targeted at the first hop of any circuit as
+   RELAY_EARLY cells too, in order to partially conceal the circuit length.
+
+   [In a future version of Tor, servers will reject any EXTEND cell not
+   received in a RELAY_EARLY cell.  See proposal 110.]
+
 6. Application connections and stream management
 
 6.1. Relay cells