commit 4fa4febaed361f453bb430c57b5784863f1e0b3d Author: Nick Mathewson nickm@torproject.org Date: Tue Nov 6 21:35:54 2012 -0500

Add proposal 214 for 4-byte circuit IDs --- proposals/000-index.txt | 2 + proposals/214-longer-circids.txt | 93 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 95 insertions(+), 0 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt index a23c412..332b64d 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -134,6 +134,7 @@ Proposals by number: 211 Internal Mapaddress for Tor Configuration Testing [OPEN] 212 Increase Acceptable Consensus Age [OPEN] 213 Remove stream-level sendmes from the design [OPEN] +214 Allow 4-byte circuit IDs in a new link protocol [OPEN]

Proposals by status: @@ -184,6 +185,7 @@ Proposals by status: 211 Internal Mapaddress for Tor Configuration Testing [for 0.2.4.x+] 212 Increase Acceptable Consensus Age [for 0.2.4.x+] 213 Remove stream-level sendmes from the design + 214 Allow 4-byte circuit IDs in a new link protocol ACCEPTED: 117 IPv6 exits [for 0.2.4.x] 140 Provide diffs between consensuses diff --git a/proposals/214-longer-circids.txt b/proposals/214-longer-circids.txt new file mode 100644 index 0000000..9b42424 --- /dev/null +++ b/proposals/214-longer-circids.txt @@ -0,0 +1,93 @@ +Filename: 214-longer-circids.txt +Title: Allow 4-byte circuit IDs in a new link protocol +Author: Nick Mathewson +Created: 6 Nov 2012 +Status: Open + + +0. Overview + + Relays are running out of circuit IDs. It's time to make the field + bigger. + +1. Background and Motivation + + Long ago, we thought that 65535 circuit IDs would be enough for anybody. + It wasn't. But our cell format in link protocols is still: + + Cell [512 bytes] + CircuitID [2 bytes] + Command [1 byte] + Payload [509 bytes] + + Variable-length cell [Length+5 bytes] + CircID [4 bytes] + Command [1 byte] + Length [2 bytes] + Payload [Length bytes] + + This means that a relay can run out of circuit IDs pretty easily. + +2. Design + + I propose a new link cell format for relays that support it. It should + be: + + Cell [514 bytes] + CircuitID [4 bytes] + Command [1 byte] + Payload [509 bytes] + + Variable cell (Length+7 bytes) + CircID [4 bytes] + Command [1 byte] + Length [2 bytes] + Payload [Length bytes] + + We need to keep the payload size in fixed-length cells to its current + value, since otherwise the relay protocol won't work. + + This new cell format should be used only when the link protocol is 4. + (To negotiation link protocol 4, both sides need to use the "v3" + handshake, and include "4" in their version cells. If version 4 or + later is negotiated, this is the cell format to use.) + +2.1. Better allocation of circuitID space + + In the current Tor design, circuit ID allocation is determined by + whose RSA public key has the lower modulus. How ridiculous! + Instead, I propose that when the version 4 link protocol is in use, + the connection initiator use the low half of the circuit ID space, + and the responder use the low half of the circuit ID space. + +3. Discussion + + * Why 4 bytes? + + Because 3 would result in an odd cell size, and 8 seems like + overkill. + + * Will this be distinguishable from the v3 protocol? + + Yes. Anybody who knows they're seeing the Tor protocol can probably + tell by the TLS record sizes which version of the protocol is in + use. Probably not a huge deal though; which approximate range of + versions of Tor a client or server is running is not something + we've done much to hide in the past. + + * Why a new link protocol and not a new cell type? + + Because pretty much every cell has a meaningful circuit ID. + + * Okay, why a new link protocol and not a new _set of_ cell types? + + Because it's a bad idea to mix short and long circIDs on the same + channel. (That would leak which cells go with what kind of + circuits ID, potentially.) + + * How hard is this to implement? + + I wasn't sure, so I coded it up. I've got a probably-buggy + implementation in branch "wide_cird_ids" in my public repository. + Be afraid! More testing is needed! +