wiki:org/meetings/2014WinterDevMeeting/notes/GuardDesign

Version 1 (modified by nickm, 5 years ago) (diff)

--

========================================================================

  • perhaps we should go to 1 guard by default
  • Alternatively, we could go with "guard sets" and similar ideas, but those have deep gaps and unanswered questions.
  • we should probably increase the rotation period.
  • To make it safe to increase the rotation period, perhaps we should add a weight parameter describing how much of the last rotation period you've been a guard. Use that when picking non-guard nodes for bw-relevant activities.
  • Perhaps we should raise the threshold of bandwidth required to be a guard such that...
  • ...the smallest guard is a non-tiny fraction of the whole network ?
  • ...the smallest guard is not too slow
  • Could there be a user parameter to raise guard bw threshold

========================================================================

  • Hey, should there be a different set of guards per identity?
  • Or a different tor state per identity
  • see 10969. see wiki link from there. see tordyguards
  • way to kill state reload state and restart tor
  • need way to not have Tor launch a connection to an old guard before it realizes it's moved.
  • need way to avoid dhcp attack
  • networkmanager / systemd integration?

==================

  • Limit how many guards a user gets/tries at one time?
  • If you get a whole bunch of guards, probably your connection is down...
  • Or maybe somebody's denying your connections till you pick a good guard.

========================================================================

  • Separate guards per isolation profile. That would be neat.
  • Can't do in full. since there are infinite isolation profiles.
  • But it would be cool to separate hidden services from other stuff
  • And it would be cool to allow separation via different socksports, etc

========================================================================

  • "Kill the node and see where users scatter" attack has some complex solutions.
  • fingers to pick next guard from a small set?
  • decide these fingers based on unpredictable shuffle of net?

========================================================================

When to choose sets of guards?

  • option 1: choose more guards, use one at a time. (Needs coding)
  • option 2: choose next guard at time of first-guard failure.

========================================================================

  • LIMIT how many guards can go down (see sniper attack)

  • Should guard rotation period be consensus parameter?

==================================================

new proposal: "i couldn't consense" statement. Anybody could write.

========================================================================

new proposal: "consensus hash chain". Anybody could write.

======================================================================== MORE ISSUES:

  • Guard enumeration, maybe 9 months is far easier then 2 months. Especially if Tor is used infrequently.
  • We need a solution for guard enumeration.
  • 2-hop cascades?
  • pathsel is an abstraction layer.

========================================================================

ARMA blocks unless we have a way to say that the users don't mostly get shoved onto shitty guards.

========================================================================

MORE:

  • why does arma have so many guards in his state file?
  • why are his guards not in sequential order????????

======================================================================

Next steps:

  • Expand above into longer nodes, proposal. (Nick, Nick, George)
  • Investigate questions, issues.
  • Profit!