Hi isis,
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.
We usually specify that the numbers will be allocated when the proposal is merged. That avoids gaps in the numbering, and weird semantics like "4 doesn't support 3".
In particular, an upcoming IPv6 proposal will need a new Relay protover, and it might get merged in 0.3.3.
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;
Link version 5 is link padding, which was merged in 0.3.2:
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".
Since this is a new protover field, it's ok to reserve numbers :-)
6.2. Subprotocol Recommendations
After the subprotocol additions above, we change to recommending the
following in the consensus:
recommended-client-protocols […] Link=5 Relay=3 Handshake=2
recommended-relay-protocols […] Link=5 Relay=3 Handshake=2
I don't think we will want to jump straight to recommending the highest protovers.
Is there a reason for this? Does it lead to warnings on clients or relays?
required-client-protocols […] Link=4-5 Relay=2-3 Handshake=1-2
required-relay-protocols […] Link=3-5 Relay=1-3 Handshake=1-2
T |