Date: 7/22/13

Group: Path Selection


  • Runa Sandvik
  • Linus Nordberg
  • Rob Jansen
  • Nick Mathewson
  • Weasel
  • Andreas Lehner
  • Aaron Johnson
  1. We are unlikely to come out with a design here. We should try and figure out what the research problems remaining are and what the main approaches to improving path selection part.
  1. Code organization
    • Abstracting out path selection would be helpful in many ways: improving ability of researchers to get results, improving security and understanding of code, improving ability to implement changes
    • Where is this priority
    • Who could do this?
  1. Topology awareness
    • The state of path selection in the research literature is primitive.
    • The only technique suggested right now is AS-independence.
    • And that is limited - we need jurisdiction-awareness, country-awareness,
    • how useful would it be to insert AS numbers into the consensuses?
    • I'm not sure if its either necessary or sufficient. Making a change this speculative is not a change that I would prioritize.
    • Collaborating nations seems like an adversary that we cannot win against.
    • How do you infer these maps in a secure way?
    • And how much data do you communicate to the clients?
    • Another interesting problem is how sensitive the outputs are to errors or maliciously modified inputs.
    • Load balancing will always be affected negatively by security-aware path selection. We need research to figure out the impact.
    • The state of research seems to be too early to use right now.
  1. Changing guard selection
    • Guard selection is one of the more simple of these issues. Multiple guards allow users to profiled, however, choosing a single guard leads to performance issues and could allow the client to be forced into using a bad guard. There are suggestions to maybe group guards together in some intelligent way.
    • Increasing guard rotation period has been done a little from to 0.2.4.
    • We have run some experiments about the security effects of reducing the number of guards and turning off guard rotation. We can look at those results soon.
    • Nobody seems to be a person that does this right now. The Tor proposal process is sometimes not used, and sometimes Tor proposals stay proposals for a very long time.
    • We could limit the number of guards that can be used in a short period of time.
    • Who is the person to turn research results into code changes?
    • We should put resources in the space between research and deployment. Finding engineers that could work in this space is something that we should look for funding for.
    • We could pitch this to funders as: do some research into this problem, and then build *something*, even if that something is not exactly a solution to the problem you did research on.
    • Who is the person that is or could be in charge of this?
    • Karsten has been tracking this problem, Tariq has been involved but is busy writing research papers, and Aaron is in a similar position.
    • Roger has suggested a new/starting graduate student to put on this problem.
    • The problem is that students are interested in papers not working systems. Maybe Nick Hopper could take this role.
  1. Organization
    • Write blog post
    • Find someone to transition guard changes from research to code
    • Bring together researchers and developers interested in path selection to have a blueprint
Last modified 6 years ago Last modified on Aug 1, 2013, 3:05:03 PM