Re: [tor-bugs] #13837 [Core Tor/Tor]: Mitigate guard discovery by pinning middle node

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13837: Mitigate guard discovery by pinning middle node
------------------------------------------------+--------------------------
 Reporter:  asn                                 |          Owner:
                                                |  mikeperry
     Type:  defect                              |         Status:  assigned
 Priority:  Medium                              |      Milestone:  Tor:
                                                |  unspecified
Component:  Core Tor/Tor                        |        Version:
 Severity:  Normal                              |     Resolution:
 Keywords:  tor-hs, tor-guard, guard-discovery  |  Actual Points:
Parent ID:  #9001                               |         Points:
 Reviewer:                                      |        Sponsor:
                                                |  SponsorV-can
------------------------------------------------+--------------------------

Comment (by mikeperry):

 Replying to [comment:15 nickm]:
 > Just skimmed the simulation code -- this looks like a plausible place to
 begin with the measurements. Do we have a plan to do these measurements,
 or should we make one?

 There is a rough outline of a plan in the comments of that script, but
 I've been thinking a bit more about it since then. Basically, I think we
 want to run several onionperf instances with different values for each of
 the NUM_LAYERN_GUARDS values. We may also want to play with cutting off
 various percentiles of the network (though this capability is not written
 in the prototype yet).

 We're going to need to measure variance of these instances somehow, or
 ideally even capture the full performance density distribution for a given
 parameter set. Variance in performance over time will be the key thing
 that changes with the parameters. We want to minimize this variance for
 sane parameter values. I think what this means is that we want to scale
 the rotation times down, so as to capture the effect of rotation on our
 performance variance over time for a fixed parameter set.

 > Also, I'm assuming that this simulation isn't trying to simulate the
 exact way in which guard sets change over time. If it is, we need to bring
 it into conformance with prop271.

 I thought about this and I don't think we want something very much like
 prop271 at all. prop271 has a lot of logic about trying to determine
 connectivity and detect and protect against various guard biasing
 attempts. For this code, I think we should trust the consensus completely,
 and have the notion of a "fallback set" and the "primary set", where we
 prefer the "primary set" if they are in the consensus, but fall back to
 members of the "fallback set" otherwise. This is kind of what the code
 does, but hat part is a bit wonky and could be done better.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13837#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

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