[tor-commits] [torspec/master] Add proposal 214 for 4-byte circuit IDs

[nickm at torproject.org]

commit 4fa4febaed361f453bb430c57b5784863f1e0b3d
Author: Nick Mathewson <nickm at 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!
+