commit 7af62db0b06aac937b8f349bd667ad20a9776f79 Author: Isis Lovecruft <isis@torproject.org> Date: Thu Dec 14 00:51:52 2017 +0000 prop#249: Add link specifiers and a section on new subprotocol numbers. --- proposals/249-large-create-cells.txt | 63 ++++++++++++++++++++++++++++++++++-- 1 file changed, 61 insertions(+), 2 deletions(-) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index cbdc436..072cffa 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -110,8 +110,12 @@ Status: Open EXTEND2 { nspec = 2; - { node ID for Y, taking 22 bytes. } - { node address for Y, taking 8 bytes } + lstype = [0x01 || 0x02]; (IPv4 or IPv6 node address) + lslen = [0x04 || 0x16]; + lspec = { node address for Y, taking 8 bytes or 16 bytes}; + lstype = 0x03; (An ed25519 node identity) + lslen = 32; + lspen = { ed25519 node ID for Y, taking 32 bytes } htype = {whatever the handshake type is.} hlen = 2000 hdata = { the first 462 bytes of the handshake } @@ -157,6 +161,61 @@ Status: Open Relays MAY send CREATE2V and CREATED2V cells to relays that don't support them, since unrecognized cell types are ignored. +6.1. New Subprotocols and Subprotocol Versions + + This proposal introduces, following prop#264, the following new + subprotocol numbers and their uses. + +6.1.1. Relay Subprotocol + + "Relay 3" -- The OP supports all of "Relay 2", plus support for CREATE2V + and CREATED2V cells and their above specification for link-layer + authentication specifiers. + +6.1.2. Link Subprotocol + + "Link 5": The OP supports all of "Link 1-4", plus support for the new + EXTEND2 semantics. Namely, it understands that an EXTEND2 cell whose + "hlen" field is greater than 505 will be followed by further "hdata" + in fragmented EXTEND2 cells which MUST follow. It also understands + that the following combination of EXTEND2 payload specifiers + indicates that the cell is a continuation of the earlier payload + portions: + + nspec = 0; + htype = 0xffff; + hlen = 0; + +6.1.3. Handshake Subprotocol + + Additionally, we introduce a new subprotocol, "Handshake" and the + following number assignments for previously occuring instances: + + "Handshake 1" -- The OP supports the TAP handshake. + + "Handshake 2" -- The OP supports the ntor handshake. + + We also reserve the following assignments for future use: + + "Handshake 3" -- The OP supports the "hybrid+null" ntor-like handshake + from prop#269. + + "Handshake 4" -- The OP supports a(n as yet unspecified) post-quantum + secure hybrid handshake, that is, the "hybrid+null" handshake from + "Handshake 3", except with "null" part replaced with another (as yet + unspecified) protocol to be composed with the ntor-like ECDH-based + handshake. + + Further handshakes MUST be specified with "Handshake" subprotocol + numbers, and MUST NOT be specified with "Relay" subprotocol numbers. The + "Relay" subprotocol SHALL be used in the future to denote changes to + handshake protocol handling of CREATE* and EXTEND* cells, i.e. CREATE, + CREATED, CREATE_FAST, CREATED_FAST, CREATE2, CREATED2, CREATE2V, + CREATED2V, EXTEND, EXTENDED, EXTEND2, and EXTENDED2. + + Thus, "Handshake 1" is taken to be synonymous with "Relay 1", and + likewise "Handshake 2" is with "Relay 2". + 7. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell