[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-commits] [torspec/master] rransom gets proposal 200: "Adding new, extensible CREATE, EXTEND, and related cells"



commit 2367819cef4faefe0cea1942086a43df30b971a3
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Thu Mar 22 11:32:00 2012 -0400

    rransom gets proposal 200: "Adding new, extensible CREATE, EXTEND, and related cells"
---
 proposals/000-index.txt                       |    2 +
 proposals/200-new-create-and-extend-cells.txt |  154 +++++++++++++++++++++++++
 proposals/xxx-new-create-and-extend-cells.txt |  149 ------------------------
 3 files changed, 156 insertions(+), 149 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 86a6d5b..a15b02f 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -120,6 +120,7 @@ Proposals by number:
 197  Message-based Inter-Controller IPC Channel [OPEN]
 198  Restore semantics of TLS ClientHello [OPEN]
 199  Integration of BridgeFinder and BridgeFinderHelper [OPEN]
+200  Adding new, extensible CREATE, EXTEND, and related cells [OPEN]
 
 
 Proposals by status:
@@ -160,6 +161,7 @@ Proposals by status:
    197  Message-based Inter-Controller IPC Channel [for 0.2.4.x]
    198  Restore semantics of TLS ClientHello
    199  Integration of BridgeFinder and BridgeFinderHelper [for 0.2.3.x+]
+   200  Adding new, extensible CREATE, EXTEND, and related cells
  ACCEPTED:
    117  IPv6 exits [for 0.2.3.x]
    140  Provide diffs between consensuses
diff --git a/proposals/200-new-create-and-extend-cells.txt b/proposals/200-new-create-and-extend-cells.txt
new file mode 100644
index 0000000..05f615e
--- /dev/null
+++ b/proposals/200-new-create-and-extend-cells.txt
@@ -0,0 +1,154 @@
+Filename: 200-new-create-and-extend-cells.txt
+Title: Adding new, extensible CREATE, EXTEND, and related cells
+Author: Robert Ransom
+Created: 2012-03-22
+Status: Open
+
+History
+
+  The original draft of this proposal was from 2010-12-27; nickm revised
+  it slightly on 2012-03-22 and added it as proposal 200.
+
+Overview and Motivation:
+
+  In Tor's current circuit protocol, every field, including the 'onion
+  skin', in the EXTEND relay cell has a fixed meaning and length.
+  This prevents us from extending the current EXTEND cell to support
+  IPv6 relays, efficient UDP-based link protocols, larger 'onion
+  keys', new circuit-extension handshake protocols, or larger
+  identity-key fingerprints.  We will need to support all of these
+  extensions in the near future.  This proposal specifies a
+  replacement EXTEND2 cell and related cells that provide more room
+  for future extension.
+
+Design:
+
+  FIXME - allocate command ID numbers (non-RELAY commands for CREATE2 and
+  CREATED2; RELAY commands for EXTEND2 and EXTENDED2)
+
+  The CREATE2 cell contains the following payload:
+
+        Handshake type                        [2 bytes]
+        Handshake data length                 [2 bytes]
+        Handshake data                        [variable]
+
+  The relay payload for an EXTEND2 relay cell contains the following
+  payload:
+
+        Number of link specifiers             [1 byte]
+           N times:
+            Link specifier type               [1 byte]
+            Link specifier length             [1 byte]
+            Link specifier                    [variable]
+        Handshake type                        [2 bytes]
+        Handshake data length                 [2 bytes]
+        Handshake data                        [variable]
+
+  The CREATED2 cell and EXTENDED2 relay cell both contain the following
+  payload:
+
+        Handshake data length                 [2 bytes]
+        Handshake data                        [variable]
+
+  All four cell types are padded to 512-byte cells.
+
+  When a relay X receives an EXTEND2 relay cell:
+
+  * X finds or opens a link to the relay Y using the link target
+    specifiers in the EXTEND2 relay cell; if X fails to open a link, it
+    replies with a TRUNCATED relay cell. (FIXME: what do we do now?)
+
+  * X copies the handshake type and data into a CREATE2 cell and sends
+    it along the link to Y.
+
+  * If the handshake data is valid, Y replies by sending a CREATED2
+    cell along the link to X; otherwise, Y replies with a TRUNCATED
+    relay cell. (XXX: we currently use a DESTROY cell?)
+
+  * X copies the contents of the CREATED2 cell into an EXTENDED2 relay
+    cell and sends it along the circuit to the OP.
+
+
+Link target specifiers:
+
+  The list of link target specifiers must include at least one address and
+  at least one identity fingerprint, in a format that the extending node is
+  known to recognize.
+
+  The extending node MUST NOT accept the connection unless at least one
+  identity matches, and should follow the current rules for making sure that
+  addresses match.
+
+  [00] TLS-over-TCP, IPv4 address
+       A four-byte IPv4 address plus two-byte ORPort
+  [01] TLS-over-TCP, IPv6 address
+       A sixteen-byte IPv6 address plus two-byte ORPort
+  [02] Legacy identity
+       A 20-byte SHA1 identity fingerprint. At most one may be listed.
+
+  As always, values are sent in network (big-endian) order.
+
+Legacy handshake type:
+
+  The current "onionskin" handshake type is defined to be handshake type
+  [00 00], or "legacy".
+
+  The first (client->relay) message in a handshake of type â??legacyâ??
+  contains the following data:
+
+        â??Onion skinâ?? (as in CREATE cell)      [DH_LEN+KEY_LEN+PK_PAD_LEN bytes]
+
+  This value is generated and processed as sections 5.1 and 5.2 of
+  tor-spec.txt specify for the current CREATE cell.
+
+  The second (relay->client) message in a handshake of type â??legacyâ??
+  contains the following data:
+
+        Relay DH public key                   [DH_LEN bytes]
+        KH (see section 5.2 of tor-spec.txt)  [HASH_LEN bytes]
+
+  These values are generated and processed as sections 5.1 and 5.2 of
+  tor-spec.txt specify for the current CREATED cell.
+
+  After successfully completing a handshake of type â??legacyâ??, the
+  client and relay use the current relay cryptography protocol.
+
+Bugs:
+
+  This specification does not accommodate:
+
+  * circuit-extension handshakes requiring more than one round
+
+    No circuit-extension handshake should ever require more than one
+    round (i.e. more than one message from the client and one reply
+    from the relay).  We can easily extend the protocol to handle
+    this, but we will never need to.
+
+  * circuit-extension handshakes in which either message cannot fit in
+    a single 512-byte cell along with the other required fields
+
+    This can be handled by specifying a dummy handshake type whose
+    data (sent from the client) consists of another handshake type and
+    the beginning of the data required by that handshake type, and
+    then using several (newly defined) HANDSHAKE_COMPLETION relay
+    cells sent in each direction to transport the remaining handshake
+    data.
+
+    The specification of a HANDSHAKE_COMPLETION relay cell and its
+    associated dummy handshake type can safely be postponed until we
+    develop a circuit-extension handshake protocol that would require
+    it.
+
+  * link target specifiers that cause EXTEND2 cells to exceed 512
+    bytes
+
+    This can be handled by specifying a LONG_COMMAND relay cell type
+    that can be used to transport a large â??virtual cellâ?? in multiple
+    512-byte cells.
+
+    The specification of a LONG_COMMAND relay cell can safely be
+    postponed until we develop a link target specifier, a RELAY_BEGIN2
+    relay cell and stream target specifier, or some other relay cell
+    type that would require it.
+
+
diff --git a/proposals/xxx-new-create-and-extend-cells.txt b/proposals/xxx-new-create-and-extend-cells.txt
deleted file mode 100644
index 538620e..0000000
--- a/proposals/xxx-new-create-and-extend-cells.txt
+++ /dev/null
@@ -1,149 +0,0 @@
-Filename: xxx-new-create-and-extend-cells.txt
-Title: Adding new, extensible CREATE, EXTEND, and related cells
-Author: Robert Ransom
-Created: 2010-12-27
-Status: Open
-
-Overview and Motivation:
-
-  In Tor's current circuit protocol, every field, including the 'onion
-  skin', in the EXTEND relay cell has a fixed meaning and length.
-  This prevents us from extending the current EXTEND cell to support
-  IPv6 relays, efficient UDP-based link protocols, larger 'onion
-  keys', new circuit-extension handshake protocols, or larger
-  identity-key fingerprints.  We will need to support all of these
-  extensions in the near future.  This proposal specifies a
-  replacement EXTEND2 cell and related cells that provide more room
-  for future extension.
-
-Design:
-
-  FIXME - allocate command ID numbers (non-RELAY commands for CREATE2 and
-  CREATED2; RELAY commands for EXTEND2 and EXTENDED2)
-
-  The CREATE2 cell contains the following payload:
-
-        Handshake type                        [2 bytes]
-        Handshake data length                 [2 bytes]
-        Handshake data                        [variable]
-
-  The relay payload for an EXTEND2 relay cell contains the following
-  payload:
-
-        Number of link specifiers             [1 byte]
-           N times:
-            Link specifier type               [1 byte]
-            Link specifier length             [1 byte]
-            Link specifier                    [variable]
-        Handshake type                        [2 bytes]
-        Handshake data length                 [2 bytes]
-        Handshake data                        [variable]
-
-  The CREATED2 cell and EXTENDED2 relay cell both contain the following
-  payload:
-
-        Handshake data length                 [2 bytes]
-        Handshake data                        [variable]
-
-  All four cell types are padded to 512-byte cells.
-
-  When a relay X receives an EXTEND2 relay cell:
-
-  * X finds or opens a link to the relay Y using the link target
-    specifiers in the EXTEND2 relay cell; if X fails to open a link, it
-    replies with a TRUNCATED relay cell. (FIXME: what do we do now?)
-
-  * X copies the handshake type and data into a CREATE2 cell and sends
-    it along the link to Y.
-
-  * If the handshake data is valid, Y replies by sending a CREATED2
-    cell along the link to X; otherwise, Y replies with a TRUNCATED
-    relay cell. (XXX: we currently use a DESTROY cell?)
-
-  * X copies the contents of the CREATED2 cell into an EXTENDED2 relay
-    cell and sends it along the circuit to the OP.
-
-
-Link target specifiers:
-
-  The list of link target specifiers must include at least one address and
-  at least one identity fingerprint, in a format that the extending node is
-  known to recognize.
-
-  The extending node MUST NOT accept the connection unless at least one
-  identity matches, and should follow the current rules for making sure that
-  addresses match.
-
-  [00] TLS-over-TCP, IPv4 address
-       A four-byte IPv4 address plus two-byte ORPort
-  [01] TLS-over-TCP, IPv6 address
-       A sixteen-byte IPv6 address plus two-byte ORPort
-  [02] Legacy identity
-       A 20-byte SHA1 identity fingerprint. At most one may be listed.
-
-  As always, values are sent in network (big-endian) order.
-
-Legacy handshake type:
-
-  The current "onionskin" handshake type is defined to be handshake type
-  [00 00], or "legacy".
-
-  The first (client->relay) message in a handshake of type â??legacyâ??
-  contains the following data:
-
-        â??Onion skinâ?? (as in CREATE cell)      [DH_LEN+KEY_LEN+PK_PAD_LEN bytes]
-
-  This value is generated and processed as sections 5.1 and 5.2 of
-  tor-spec.txt specify for the current CREATE cell.
-
-  The second (relay->client) message in a handshake of type â??legacyâ??
-  contains the following data:
-
-        Relay DH public key                   [DH_LEN bytes]
-        KH (see section 5.2 of tor-spec.txt)  [HASH_LEN bytes]
-
-  These values are generated and processed as sections 5.1 and 5.2 of
-  tor-spec.txt specify for the current CREATED cell.
-
-  After successfully completing a handshake of type â??legacyâ??, the
-  client and relay use the current relay cryptography protocol.
-
-Bugs:
-
-  This specification does not accommodate:
-
-  * circuit-extension handshakes requiring more than one round
-
-    No circuit-extension handshake should ever require more than one
-    round (i.e. more than one message from the client and one reply
-    from the relay).  We can easily extend the protocol to handle
-    this, but we will never need to.
-
-  * circuit-extension handshakes in which either message cannot fit in
-    a single 512-byte cell along with the other required fields
-
-    This can be handled by specifying a dummy handshake type whose
-    data (sent from the client) consists of another handshake type and
-    the beginning of the data required by that handshake type, and
-    then using several (newly defined) HANDSHAKE_COMPLETION relay
-    cells sent in each direction to transport the remaining handshake
-    data.
-
-    The specification of a HANDSHAKE_COMPLETION relay cell and its
-    associated dummy handshake type can safely be postponed until we
-    develop a circuit-extension handshake protocol that would require
-    it.
-
-  * link target specifiers that cause EXTEND2 cells to exceed 512
-    bytes
-
-    This can be handled by specifying a LONG_COMMAND relay cell type
-    that can be used to transport a large â??virtual cellâ?? in multiple
-    512-byte cells.
-
-    The specification of a LONG_COMMAND relay cell can safely be
-    postponed until we develop a link target specifier, a RELAY_BEGIN2
-    relay cell and stream target specifier, or some other relay cell
-    type that would require it.
-
-

_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits