draft proposal 141: download server descriptors on demand

[Peter Palfrader]

On Mon, 16 Jun 2008, Nick Mathewson wrote:

> >   1) when connecting to a guard node for which the client does not
> >      yet have a cached descriptor it requests the descriptor it
> >      expects by hash.  (The consensus document that the client holds
> >      has a hash for the descriptor of this server.  We want exactly
> >      that descriptor, not a different one.)
> >
> >      [XXX: How?  We could either come up with a new cell type,
> >       RELAY_REQUEST_SD that takes only a hash (of the SD), or use
> >       RELAY_BEGIN_DIR.  The former is probably smarter since we will
> >       want to use it later on as well, and there we will require
> >       padding.]
> 
> My first thought was that I'd prefer to avoid multiplying machinery
> here.  When we design RELAY_REQUEST_SD, let's try to keep looking to
> see whether we can add a padding argument to RELAY_BEGIN_DIR rather
> than forcing a new relay cell type?

Using RELAY_BEGIN_DIR does have a drawback tho.  Since it's just a BEGIN
cell, it will mean the client sends the RELAY_BEGIN_DIR to the server,
and then has to waits for the CONNECTED(?) cell before it can send its
URL.  That's one extra roundtrip.


> Something else to figure out here is migration.  When the first cut of
> this system is done, only new servers will support RELAY_REQUEST_SD.
> This means that clients will still need to pre-download descriptors
> under some circumstances.
> 
> In fact, the rules will be pretty weird here.  If extends are done by
> first asking B for C's descriptor, then clients need to know whether B
> supports RELAY_REQUEST_SD.  If it doesn't, they need to have C's
> descriptor, which means they need to have downloaded it in advance.

One approach is to download individual SDs via a fully anonymized 3-hop
circuit.  This still requires some subset of the network to already
support the new cell type.  But maybe that's fine.


> > 4. Future possibilities
> > 
> >   This proposal still requires that all servers have the descriptors of
> >   every other node in the network in order to answer RELAY_REQUEST_SD
> >   cells.  These cells are sent when a circuit is extended from ending at
> >   node B to a new node C.  In that case B would have to answer a
> >   RELAY_REQUEST_SD cell that asks for C's server descriptor (by SD digest).
> >
> >   In order to answer that request B obviously needs a copy of C's server
> >   descriptor.  In the future we might amend RELAY_REQUEST_SD cells to
> >   contain also the expected IP address and OR-port of the server C (the
> >   client learns them from the network status document), so that B no
> >   longer needs to know all the descriptors of the entire network but
> >   instead can simply go and ask C for its descriptor before passing it
> >   back to the client.
> 
> We might want to include this information in RELAY_REQUEST_SD anyway
> now, so that when servers start supporting fetch-on-demand, clients
> will already be sending them the info they need to do it.  I think it
> should include an identity fingerprint digest too, so that B can open
> an authenticated OR connection to C as needed.

Agreed.


> (These issues also complicate any eventual p2p-Tor designs, if every
> B needs to know every C's descriptor.  We'd also need to keep the
> client cache and the server cache separate, so that it's not so easy
> to probe about whether B already knows C.)

Without checking how feasible this is in the code my first idea was to
keep SDs for client purposes attached to the circuit that fetches and
uses them, and not in a global routerlist.

A client cache might still be useful for the SDs of our guards, and if
we need it for exit stuff.

-- 
weasel