nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 22:03:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Document RELAY_EARLY cells in tor-spec.txt: proposal 110 is mostly implemented, and the rest of it will need to wait until all current Tor 0.2.0.x clients are obsolete to close.

Browse Source 
svn:r17816
This commit is contained in:
Nick Mathewson 2008-12-29 19:55:23 +00:00
parent c1c7f982d9
commit d0924d522d
2 changed files with 28 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/spec/proposals/110-avoid-infinite-circuits.txt
View File

@ -57,6 +57,12 @@ Design:
data cells over the stream as relay_early cells, regardless of their data cells over the stream as relay_early cells, regardless of their
actual type. actual type.
(Note that a circuit that is out of relay_early cells MUST NOT be
cannibalized later, since it can't extend. Note also that it's always okay
to use regular RELAY cells when sending non-EXTEND commands targetted at
the first hop of a circuit, since there is no intermediate hop to try to
learn the relay command type.)
Each intermediate server would pass on the same type of cell that it Each intermediate server would pass on the same type of cell that it
received (either relay or relay_early), and the cell's destination received (either relay or relay_early), and the cell's destination
will be able to learn whether it's allowed to contain an Extend request. will be able to learn whether it's allowed to contain an Extend request.

25
doc/spec/tor-spec.txt
View File

@ -289,6 +289,7 @@ see tor-design.pdf.
6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1) 6 -- CREATED_FAST (Circuit created, no PK) (See Sec 5.1)
7 -- VERSIONS (Negotiate proto version) (See Sec 4) 7 -- VERSIONS (Negotiate proto version) (See Sec 4)
8 -- NETINFO (Time and address info) (See Sec 4) 8 -- NETINFO (Time and address info) (See Sec 4)
9 -- RELAY_EARLY (End-to-end data; limited) (See sec 5.6)
The interpretation of 'Payload' depends on the type of the cell. The interpretation of 'Payload' depends on the type of the cell.
PADDING: Payload is unused. PADDING: Payload is unused.
@ -623,9 +624,9 @@ see tor-design.pdf.
5.5. Routing relay cells 5.5. Routing relay cells
When an OR receives a RELAY cell, it checks the cell's circID and When an OR receives a RELAY or RELAY_EARLY cell, it checks the cell's
determines whether it has a corresponding circuit along that circID and determines whether it has a corresponding circuit along that
connection. If not, the OR drops the RELAY cell. connection. If not, the OR drops the cell.
Otherwise, if the OR is not at the OP edge of the circuit (that is, Otherwise, if the OR is not at the OP edge of the circuit (that is,
either an 'exit node' or a non-edge node), it de/encrypts the payload either an 'exit node' or a non-edge node), it de/encrypts the payload
@ -653,6 +654,24 @@ see tor-design.pdf.
For more information, see section 6 below. For more information, see section 6 below.
5.6. Handling relay_early cells
A RELAY_EARLY cell is designed to limit the length any circuit can reach.
When an OR receives a RELAY_EARLY cell, and the next node in the circuit
is speaking v2 of the link protocol or later, the OR relays the cell as a
RELAY_EARLY cell. Otherwise, it relays it as a RELAY cell.
If a node ever receives more than 8 RELAY_EARLY cells on a given circuit,
it SHOULD close the circuit.
When speaking v2 of the link protocol or later, clients MUST only send
EXTEND cells inside RELAY_EARLY cells. Clients SHOULD send the first ~8
RELAY cells that are not targeted at the first hop of any circuit as
RELAY_EARLY cells too, in order to partially conceal the circuit length.
[In a future version of Tor, servers will reject any EXTEND cell not
received in a RELAY_EARLY cell. See proposal 110.]
6. Application connections and stream management 6. Application connections and stream management
6.1. Relay cells 6.1. Relay cells