commit 2367819cef4faefe0cea1942086a43df30b971a3 Author: Nick Mathewson <nickm@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. - -