Re: [tor-dev] Proposal 300: Walking Onions: Scaling and Saving Bandwidth

[teor <teor@xxxxxxxxxx>]

> On 12 Feb 2019, at 04:49, Ian Goldberg <iang@xxxxxxxxxxxx> wrote:
> 
> Another issue not addressed by the current proposal is how to handle the
> "not all the relays have upgraded" problem.

And how to handle the onion service protocol (in detail).

Here's one possible migration path:
(I think it works, but we should spec these changes in detail.)

Step 0: graceful protocol upgrades on new relays

The walking onions EXTEND and CREATE cells are different from the
legacy cells. (If the walking onions CREATE cell was exactly the
same as the current CREATE cell, clients would only need to check
the current hop's protocols.)

So, when extending, a client:
* sends the certified index as an additional link specifier in
  the EXTEND cell
* if both relays support the protocol, the EXTENDED cell contains an
  ENDIVE in addition to its legacy content. Otherwise, it is a legacy
  EXTENDED cell.

For v3 onion services:
* service descriptors contain the certified index as
  *an additional* link specifier
* client intro EXTENDs contain the certified index as
  *an additional* link specifier
* client INTRODUCE cells contain the certified index as
  *an additional* link specifier
* service rendezvous EXTEND cells contain the certified index as
  *an additional* link specifier

(If we implement unknown link specifier passthrough from the v3 onion
service proposal, these protocol upgrades should happen automatically.)

For v3 single onion services:
* introduction points are looked up via a 3-hop path, like guards, using a
  random middle index
* rendezvous points are connected to directly, using their IP and ID link
  specifiers. (A 3-hop lookup is too slow for rendezvous.)
* the rest of the protocol remains the same

(v2 onion services can't support walking onions, because their protocol
isn't flexible enough.)

Step 1: require protocol upgrades on new relays

For standard paths, like Step 0, but:
* if both relays support the protocol, send the certified index as
  *the only* link specifier in the EXTEND cell

For v3 onion services:
* descriptors remain the same as step 0.
  (The link specifiers in the descriptor can be 24 hours old, so the
  client can't rely on the service's view of the intro's protocols.)
* if both relays support the new protocol, client intro
  EXTEND cells contain the certified index as *the only* link specifier
* client INTRODUCE cells remain the same as step 0.
  (To support single onion services, which need legacy link specifiers.)
* if both relays support the new protocol, service rendezvous
  EXTEND cells contain the certified index as *the only* link specifier

For v3 single onion services, the protocol remains the same:
* rendezvous points are connected to directly, using their IP and ID link
  specifiers. (A 3-hop lookup is too slow for rendezvous.)

Step 2: ignore legacy relays

Like Step 1, but:
* check the consensus for a flag that tells us to ignore legacy relays

v3 onion services continue to include legacy ID and IP link specifiers,
for older tor versions, and single onion services.

Step 3: remove legacy onion service descriptor link specifiers

Once all onion services and clients support walking onions: 
* service descriptors contain the certified index as
  *the only* link specifier. (Clients will have to make a multi-hop path.
  But that's ok, because we don't support Tor2web on v3 onion services.)
* client INTRODUCE cells continue to include legacy IP and ID
  link specifiers, to support single onion services.

This upgrade process leads to some more questions:

1. How do clients discover protocol versions?

We can do one or more of:
* ENDIVEs contain a list of supported protocol versions for each relay, or
* clients ask the current hop for a copy of its descriptor, which contains
  protocol versions (see below for tradeoffs), or
* we have a flag in the consensus that tells clients if they can safely
  ignore legacy relays

2. How do clients keep their guard information up to date?

Two options:
* They ask the guard for its descriptor.
* They re-extend to the guard via a 3-hop path

Fetching the descriptor could also help us in situations where we need
to discover less common information about the relay. But it's slower,
and it looks different to the relay, and on the wire. So we might want to
avoid it. (That said, Tor already fetches descriptors from bridges.)

3. How do we minimise Tor version distinguishers?

We should implement all the stages in a small number of Tor releases,
then active them using a consensus parameter.

We should try to implement onion service link specifier passthrough in
the same release as full onion service IPv6 support, so we have fewer
onion service version distinguishers.

If we implement it later, we might end up with:
* 2-4 IPv6 distinguishers (until these versions are unsupported)
* 1 passthrough distinguisher
* 1-3 walking onions stage 0/1/2 distinguisher(s)

T

-- 
teor
----------------------------------------------------------------------
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev