draft proposal: download server descriptors on demand

[Christian Fromme]

Hi,

On 10.11. 08:39, Roger Dingledine wrote:

> So instead we should do like proposal 141, but fetch the onion key on
> demand, rather than the descriptor. The new RELAY_REQUEST_OKEY relay
> cell just sends back the onion key. It fits in one cell, so there's no
> need to mess with this global padding parameter thing, or compressing
> descriptors on the fly, or teaching relays to test if their descriptor
> is too big, etc.
> 
> Clients never learn exact exit policies now. That means we need to
> make exit policies snap-to-fit better into the summaries we put in the
> consensus document. But that's true with the old approach to proposal
> 141 too. The only difference is that now we just try the BEGIN request,
> and get end-reason-exit-policy if we guessed wrong and then try elsewhere.
> 
> We actually want RELAY_REQUEST_OKEY to be more general, in case there
> are other items we want to communicate that we only summarize in the
> consensus. RELAY_REQUEST_DETAILS, maybe.
> 
> How do the mirrors learn the onion keys? Authorities now produce both a
> "mirror consensus" and a "client consensus". They differ in that the
> mirror consensus includes the SD hash, descriptor timestamp, and the
> onion key; and the client consensus has the OKey hash.

> Now, time to consider some optimizations:
> 
> Optimization one: I could be convinced that with consensus diffs,
> putting the onion key in the consensus wouldn't be so bad. Or we can put
> OKey hashes in the consensus, and then let clients fetch and cache the
> onion keys they're missing. They don't change very often at all. Either
> way, now we wouldn't have to introduce any new relay cells, and no new
> round-trips during circuit generation, and relays don't need a global
> view of anything unless they want one. Sure is tempting.
> 
> Optimization two is that we could cut out the separate round-trip for
> the RELAY_REQUEST_DETAILS relay cell if we wrap it into the CREATE cell.
> That is, we could bump the circuit protocol version, and cram more
> stuff into the CREATE cell like we've been meaning to, and one of the
> new items would be the fingerprint for the intended next hop. Then
> the relay can send back a CREATED followed directly by a (series of)
> RELAY_HERE'S_YOUR_DETAILS relay cell(s). This step shouldn't be taken
> lightly though, a) because it requires bumping the circuit protocol
> version (an all-syrup super squishy? such a thing has never been done!),
> b) because Ian showed up our create cells are darn fragile already,
> so let's be careful putting anything else in them, and c) because the
> fingerprint of the next hop is only encrypted to the onion key, and thus
> isn't covered by the PFS you'd get if you wait for the CREATED cell first.

So, to sum this up:

1) Everything a client needs to build a circuit will be found in the new
   client consensus, except (maybe) the onion keys

2) The onion keys will be available to the client in one of the following
   ways:
   a) Part of the concensus, hoping that sizes won't increase too badly 
      over time. With consensus diffs in mind this means for a client to
      fetch about 200KB (I think Roger came up with that number on IRC)
      once and from then on only the diffs, which are naturally less
      + No change in circuit-building
      + No new relay cells
      + Easier to migrate
      - Mightn't scale well in the future
   b) Fetch them via a new RELAY_REQUEST_OKEY/RELAY_REQUEST_DETAILS cell
      + Scales well for the client if network sizes grow
      + Doesn't change circuit building
      - Somewhat more difficult to migrate
      - Increases latency (round-trip!)
   c) Fetch them via a new extented CREATE cell
      + Scales well
      + Doesn't really increase latency
      - Requires bumping the circ protocol version
      - CREATE cells already seem to be fragile
      - PFS at risk
      - Migration more difficult

3) Clients or others can still fetch full router descriptors from the
   authorities anytime they want

The original idea of propsal 141 falls somewhere near 2b).

I hope I got all the facts right. Please correct me if not. Assuming I 
have, why not say we implement 2a) first and see how far we get with 
that. Maybe with consensus diffs it'll be good enough. If it prooves to
have been the wrong way, we still can think about 2b) or 2c). Maybe some
other proposal in the future will make it necessary to change circuit 
building algorithms anyway and we'd have an easier time doing so then.

Best,
    Christian