-
Notifications
You must be signed in to change notification settings - Fork 84
/
Copy path200-new-create-and-extend-cells.txt
155 lines (110 loc) · 5.72 KB
/
200-new-create-and-extend-cells.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
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: Closed
Implemented-In: 0.2.4.8-alpha
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.