Commit b7e1a873 authored by Roger Dingledine's avatar Roger Dingledine
Browse files

router twins are long gone from tor. take them out of the spec.

also note two spec things that need more explanation.


svn:r5355
parent c136bbe5
Loading
Loading
Loading
Loading
+4 −4
Original line number Diff line number Diff line
@@ -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