prop#249: Add link specifiers and a section on new subprotocol numbers.

1 files 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