diff options
Diffstat (limited to 'spec/padding-spec/circuit-level-padding.md')
| -rw-r--r-- | spec/padding-spec/circuit-level-padding.md | 31 |
1 files changed, 16 insertions, 15 deletions
diff --git a/spec/padding-spec/circuit-level-padding.md b/spec/padding-spec/circuit-level-padding.md index 086d0f8..85f9137 100644 --- a/spec/padding-spec/circuit-level-padding.md +++ b/spec/padding-spec/circuit-level-padding.md @@ -14,7 +14,7 @@ rate limiting, and circuit application conditions have been added. At present, Tor uses this system to deploy two pairs of circuit padding machines, to obscure differences between the setup phase of client-side -onion service circuits, up to the first 10 cells. +onion service circuits, up to the first 10 relay cells. This specification covers only the resulting behavior of these padding machines, and thus does not cover the state machine implementation details or @@ -31,11 +31,11 @@ advertised as "Padding=2". Because circuit padding machines only become active at certain points in circuit lifetime, and because more than one padding machine may be active at -any given point in circuit lifetime, there is also a padding negotiation -cell and a negotiated response. These are relay commands 41 and 42, with -relay headers as per section 6.1 of tor-spec.txt. +any given point in circuit lifetime, there is also a PADDING_NEGOTIATE +message and a PADDING_NEGOTIATED message. These are relay commands 41 and 42 respectively, +with relay headers as per section 6.1 of tor-spec.txt. -The fields of the relay cell Data payload of a negotiate request are +The fields in the body of a PADDING_NEGOTIATE message are as follows: ```text @@ -61,14 +61,14 @@ as follows: When a client wants to start a circuit padding machine, it first checks that the desired destination hop advertises the appropriate subprotocol version for -that machine. It then sends a circpad_negotiate cell to that hop with +that machine. It then sends a PADDING_NEGOTIATE message to that hop with command=CIRCPAD_COMMAND_START, and machine_type=CIRCPAD_MACHINE_CIRC_SETUP (for the circ setup machine, the destination hop is the second hop in the circuit). The machine_ctr is the count of which machine instance this is on the circuit. It is used to disambiguate shutdown requests. -When a relay receives a circpad_negotiate cell, it checks that it supports -the requested machine, and sends a circpad_negotiated cell, which is formatted +When a relay receives a PADDING_NEGOTIATE message, it checks that it supports +the requested machine, and sends a PADDING_NEGOTIATED message, which is formatted in the data payload of a relay cell with command number 42 (see tor-spec.txt section 6.1), as follows: @@ -102,11 +102,12 @@ Clients MAY send padding cells towards the relay before receiving the circpad_negotiated response, to allow for outbound cover traffic before negotiation completes. -Clients MAY send another circpad_negotiate cell before receiving the +Clients MAY send another PADDING_NEGOTIATE message before receiving the circpad_negotiated response, to allow for rapid machine changes. -Relays MUST NOT send padding cells or circpad_negotiated cells, unless a -padding machine is active. Any padding-related cells that arrive at the client +Relays MUST NOT send padding cells or PADDING_NEGOTIATE messages unless a +padding machine is active. Any padding cells or padding-related messages +that arrive at the client from unexpected relay sources are protocol violations, and clients MAY immediately tear down such circuits to avoid side channel risk. @@ -138,7 +139,7 @@ surrounded in \[brackets\] are outgoing, the others are incoming): \[EXTEND2\] -> EXTENDED2 -> \[EXTEND2\] -> EXTENDED2 -> \[BEGIN\] -> CONNECTED When this is done, the client has established a 3-hop circuit and also opened -a stream to the other end. Usually after this comes a series of DATA cell that +a stream to the other end. Usually after this comes a series of DATA message that either fetches pages, establishes an SSL connection or fetches directory information: @@ -227,7 +228,7 @@ becomes: [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EST_REND] -> REND_EST -> [PADDING_NEGOTIATE] -> [DROP] -> PADDING_NEGOTIATED -> DROP... - After which normal application DATA cells continue on the circuit. + After which normal application DATA-bearing cells continue on the circuit. ``` Hence this way we make rendezvous circuits look like general circuits up @@ -243,8 +244,8 @@ will look alike. ### Circuit setup machine overhead { #setup-overhead } For the intro circuit case, we see that the origin-side machine just sends a -single \[PADDING_NEGOTIATE\] cell, whereas the origin-side machine sends a -PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means that the +single PADDING_NEGOTIATE message, whereas the origin-side machine sends a +PADDING_NEGOTIATED message and between 7 to 10 DROP cells. This means that the average overhead of this machine is 11 padding cells per introduction circuit. For the rend circuit case, this machine is quite light. Both sides send 2 |