From b7e1a8730483052c8773af05b808401c2cd6d96c Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Fri, 11 Nov 2005 17:06:54 +0000 Subject: router twins are long gone from tor. take them out of the spec. also note two spec things that need more explanation. svn:r5355 --- doc/tor-spec.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/tor-spec.txt b/doc/tor-spec.txt index d26e83598..6f059bd8f 100644 --- a/doc/tor-spec.txt +++ b/doc/tor-spec.txt @@ -15,6 +15,7 @@ more information on why Tor acts as it does, see tor-design.pdf. TODO: (very soon) - REASON_CONNECTFAILED should include an IP. - Copy prose from tor-design to make everything more readable. +when do we rotate which keys (tls, link, etc)? 0. Notation: @@ -189,6 +190,9 @@ TODO: (very soon) The port and address field denote the IPV4 address and port of the next onion router in the circuit; the public key hash is the SHA1 hash of the PKCS#1 ASN1 encoding of the next onion router's identity (signing) key. +[XXX please describe why we have this hash. my first guess is that this +way we can notice that we're already connected to this guy even if he's +connected at a different place. anything else? -RD] The payload for a CREATED cell, or the relay payload for an EXTENDED cell, contains: @@ -315,10 +319,6 @@ TODO: (very soon) section 4.1. above, concerning choosing circIDs based on lexicographic order of nicknames.) - As an extension (called router twins), if the desired next onion - router R in the circuit is down, and some other onion router R' - has the same public keys as R, then it's ok to extend to R' rather than R. - When an onion router receives a CREATE cell, if it already has a circuit on the given connection with the given circID, it drops the cell. Otherwise, after receiving the CREATE cell, it completes the -- cgit v1.2.3