Commit aec36da1 authored by George Kadianakis's avatar George Kadianakis
Browse files

Improve vanguard-lite proposal. 

- Mention that an extra hop is added on service-side intro circs
- Add circuit path length diagram
- Mention max number of L2 guards
- Add control port events to control spec
parent 49196be6

control-spec.txt

+2 −0
Original line number Diff line number Diff line
@@ -3097,6 +3097,8 @@ 
    "DOWN" -- The guard now seems to be unreachable.

    "BAD"  -- Because of flags set in the consensus and/or values in the

              configuration, this node is now unusable as a guard.

    "BAD_L2" -- This layer2 guard has expired or got removed from the

              consensus. This node is removed from the layer2 guard set.

    "GOOD" -- Because of flags set in the consensus and/or values in the

              configuration, this node is now usable as a guard.

proposals/332-vanguards-lite.md

+20 −6
Original line number Diff line number Diff line
@@ -23,22 +23,36 @@ Status: Draft 
  - No third layer of guards is used.

  - The Layer2 lifetime uses the max(x,x) distribution with a minimum of one

    day and maximum of 12 days. This makes the average lifetime approximately a

    week. We let NUM_LAYER2_GUARDS=4.

    week.

  - We let NUM_LAYER2_GUARDS=4. We also introduce a consensus parameter

    `guard-hs-l2-number` that controls the number of layer2 guards (with a

    maximum of 19 layer2 guards).

  - We don't write guards on disk. This means that the guard topology resets

    when tor restarts.



  By avoiding a third-layer of guards we reduce the linkability issues

  of Proposal 292, which means that we don't have to add an extra hop on top of

  our paths. This simplifies engineering.

  By avoiding a third-layer of guards we avoid most of the linkability issues

  of Proposal 292. This means that we don't add an extra hop on top of most of

  our onion service paths, which increases performance. However, we do add an

  extra middle hop at the end of service-side introduction circuits to avoid

  linkability of L2s by the intro points.



# 2. Rotation Period Analysis

  This is how onion service circuits look like with this proposal:



	 Client rend:   C -> G -> L2 -> Rend

	 Client intro:  C -> G -> L2 -> M -> Intro

	 Client hsdir:  C -> G -> L2 -> M -> HSDir

	 Service rend:  C -> G -> L2 -> M -> Rend

	 Service intro: C -> G -> L2 -> M -> Intro

	 Service hsdir: C -> G -> L2 -> M -> HSDir



# 3. Rotation Period Analysis



  From the table in Section 3.1 of Proposal 292, with NUM_LAYER2_GUARDS=4 it

  can be seen that this means that the Sybil attack on Layer2 will complete

  with 50% chance in 18*7 days (126 days) for the 1% adversary, 4*7 days (one

  month) for the 5% adversary, and 2*7 days (two weeks) for the 10% adversary.



# 3. Tradeoffs from Proposal 292

# 4. Tradeoffs from Proposal 292



  This proposal has several advantages over Proposal 292: