[freehaven-dev] RFC: Revised setup protocol for Tarzan

[Michael J Freedman <mfreed@MIT.EDU>]

Please find below a description of a proposed setup protocol for Tarzan.
Prior messages in the freehaven-dev archive will better describe its goals
(low-latency, two-way, no reply-blocks, provides support for peers behind
NATs/firewalls.)

Comments are highly valued!

Thanks,
--mike



The basic concept is a 4 stage setup protocol, after which A and B
will be connected over a tcp data stream.

Goal:  A connects to B.

1. At some early time, B connects to some number of meeting places.
2. A finds a data proxy over which it wishes to stream data and
   connects to this proxy.
3. A looks up B's meeting places and connects to one (or several) of
   them, sending control messages to B through these meeting places,
   tell B to connect to it through its specified data proxy.
4. B connects to data proxy.

-- A and B now stream data to one another --

Below, we don't go into the process by which A will look up the
meeting places in B -- we describe this briefly in prior
discussions.  Secondly, in our notation, we leave off 
differentiating between PK_{net} and PK_{fs}.  PK_{net} is the 
public key associated with a network reachable node, that is, 
its IP address is known.  PK_{fs} (file system, or PK_{app}) is 
the application-layer PKI for which Tarzan serves as a network 
infrastructure.  In our case, these keys are FreeHaven keys, on 
which reputation is built.  It is critical that PK_{net} and 
PK_{fs} are not linked.

In the example below, PK_A and PK_B are actually PK_{A_{fs}}
and PK_{B_{fs}}.  All other public keys refer to Tarzan network
keys, e.g., PK_{M_{net}}, PK_{DP_{net}}.


4-STAGE SETUP PROTOCOL
----------------------

A and B may be behind NATs or firewalls.  All other nodes in this network
may not be, i.e., they must be able to accept incoming connections.  In the
graph below, this corresponds to all the numbered ones representing anon
path hops, as well as the meeting place and data proxy nodes.


A -->  2 -->  3 -->  M <--  4 <--  5 <-- B
A --> 10 --> 11 --> DP <-- 13 <-- 14 <-- B

B JOINS MEETING PLACE
---------------------

M <-- 4 <-- 5 <-- B

B connects to M with "control session" message:

E_{PK_5} ( K_{5_u}, K_{5_d},
           E_{PK_4} ( K_{4_u}, K_{4_d}, 
                      E_{PK_M} ( K_M, K_{4_d}, K_{5_d}, K_B )))

M now has path to talk back with B, by onion-encrypting 
messages back to B with 

     E_{K_{4_d}} ( E_{K_{5_d}} ( E_{K_B} (msg)))


        
A SETUP TO DATA PROXY
---------------------

A --> 10 --> 11 --> DP

A connects to Data Proxy.

E_{PK_10} ( K_{10_u}, K_{10_d},
            E_{PK_11} ( K_{11_u}, K_{11_d}, 
                        E_{PK_DP} ( K_{DP_u}, K_{DP_d},
                                    hash(token_{A,B}) )))



A SETUP THROUGH MEETING PLACE
-----------------------------

A --> 2 --> 3 --> M 

A connects to M via exact same "one-way" setup protocol as connection
to data proxy, except, along with routing block:

     (Setup data as defined above) o 
          E_{K_{2_u}} ( E_{K_{3_u}} ( E_{K_M} ({ B, blob })))

where blob is that A wants to talk with B (which is probably just
identified by PK_B):

     blob = S_{PK^{-1}_A} ( E_{PK_B} ( 
                       PK_A, K_A, 
                       PK_{DP}, K_{DP_d}, DP_{IPaddr},
                       token_{A,B},
                       K_{10_d}, K_{11_d} ))

M sends blob to B.      

M sends a blob to a bunch of B's Meeting Places.  B gets those blobs,
considers its current load (and possibly other data such as A's
reputation), and chooses whether or not to honor A's request and
connect to Data Proxy DP.

This is the general case.  We can make this somewhat easier by just
having $DP == M$, which allows $2 == 10$ and $3 == 11$.  That's a
specific case, this method allows us more flexibility and places more
decision-making regarding resource and congestion management up to B.


B CONNECTS TO DATA PROXY
------------------------

DP <-- 13 <-- 14 <-- B

B connects to data proxy in largely the same manner which A has
already done.

B sends to DP:

     (Setup data as defined above) o 
          E_{K_{14_u}} ( E_{K_{13_u}} ( E_{K_{DP_d}} ( MSG )))

where MSG = S_{PK^{-1}_B} ( token_{A,B}, blob )

     blob = S_{PK^{-1}_B} ( E_{PK_A} ( 
                       K_B, 
                       K_{14_d}, K_{13_d} ))



OTHER THINGS TO DISCUSS
-----------------------

1. Language Wars (perl, C)
2. Data stream signing
3. PKI, key revocation/rotation

-----
"Not all those who wander are lost."                  mfreed@mit.edu