[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] Add reasons to DESTROY and RELAY_TRUNCATED cells.
Update of /home/or/cvsroot/tor/doc
In directory moria:/tmp/cvs-serv29413/doc
Modified Files:
TODO tor-spec.txt
Log Message:
Add reasons to DESTROY and RELAY_TRUNCATED cells.
Index: TODO
===================================================================
RCS file: /home/or/cvsroot/tor/doc/TODO,v
retrieving revision 1.396
retrieving revision 1.397
diff -u -p -d -r1.396 -r1.397
--- TODO 31 Dec 2005 07:39:47 -0000 1.396
+++ TODO 5 Jan 2006 21:23:03 -0000 1.397
@@ -43,9 +43,10 @@ N - if they're trying to be a tor server
other nodes *are* reachable.
o Make EntryNodes and StrictEntrynodes do what we want.
-N - Destroy and truncated cells should have reasons.
- - Specify
- - Implement
+N . Destroy and truncated cells should have reasons.
+ o Specify
+ o Implement
+ - Display the reasons under some circumstances?
N . Only use a routerdesc if you recognize its hash.
o (Must defer till dirservers are upgraded to latest code, which
@@ -85,9 +86,6 @@ N . Only use a routerdesc if you recogni
- Test.
- Non-directories don't need to keep descriptors in memory.
-N - Should router info have a pointer to routerstatus?
- - We should at least do something about the duplicated fields.
-
R - Christian Grothoff's attack of infinite-length circuit.
the solution is to have a separate 'extend-data' cell type
which is used for the first N data cells, and only
@@ -115,6 +113,9 @@ Deferred from 0.1.1.x:
those, if circuits aren't working and it's a pattern we recognize
("port 443 worked once and port 9001 keeps not working").
+N - Should router info have a pointer to routerstatus?
+ - We should at least do something about the duplicated fields.
+
N . Additional controller features
o Find a way to make event info more extensible
- change circuit status events to give more details, like purpose,
Index: tor-spec.txt
===================================================================
RCS file: /home/or/cvsroot/tor/doc/tor-spec.txt,v
retrieving revision 1.107
retrieving revision 1.108
diff -u -p -d -r1.107 -r1.108
--- tor-spec.txt 4 Jan 2006 07:11:45 -0000 1.107
+++ tor-spec.txt 5 Jan 2006 21:23:03 -0000 1.108
@@ -136,7 +136,8 @@ when do we rotate which keys (tls, link,
CREATE: Payload contains the handshake challenge.
CREATED: Payload contains the handshake response.
RELAY: Payload contains the relay header and relay body.
- DESTROY: Payload is unused.
+ DESTROY: Payload contains a reason for closing the circuit.
+ (see 4.4)
Upon receiving any other value for the command field, an OR must
drop the cell.
@@ -376,6 +377,28 @@ when do we rotate which keys (tls, link,
RELAY_TRUNCATED cell towards the OP; the node farther from the OP
should send a DESTROY cell down the circuit.
+ The payload of a RELAY_TRUNCATED or DESTROY cell contains a single octet,
+ describing why the circuit is being closed or truncated. When sending a
+ TRUNCATED or DESTROY cell because of another TRUNCATED or DESTROY cell,
+ the error code should be propagated. The origin of a circuit always sets
+ this error code to 0, to avoid leaking its version.
+
+ The error codes are:
+ 0 -- NONE (No reason given.)
+ 1 -- PROTOCOL (Tor protocol violation.)
+ 2 -- INTERNAL (Internal error.)
+ 3 -- REQUESTED (A client sent a TRUNCATE command.)
+ 4 -- HIBERNATING (Not currently operating; trying to save bandwidth.)
+ 5 -- RESOURCELIMIT (Out of memory, sockets, or circuit IDs.)
+ 6 -- CONNECTFAILED (Unable to reach server.)
+ 7 -- OR_IDENTITY (Connected to server, but its OR identity was not
+ as expected.)
+ 8 -- OR_CONN_CLOSED (The OR connection that was carrying this circuit
+ died.)
+
+ [Versions of Tor prior to 0.1.0.11 didn't sent versions; implementations
+ MUST accept empty TRUNCATED and DESTROY cells.]
+
4.5. Routing relay cells
When an OR receives a RELAY cell, it checks the cell's circID and