[tor-commits] [torspec/master] rransom gets proposal 200: "Adding new, extensible CREATE, EXTEND, and related cells"
nickm at torproject.org
nickm at torproject.org
Thu Mar 22 15:28:12 UTC 2012
commit 2367819cef4faefe0cea1942086a43df30b971a3
Author: Nick Mathewson <nickm at torproject.org>
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.
-
-
More information about the tor-commits
mailing list