Skip to content
Snippets Groups Projects

PathSelection

Last edited by Alexander Færøy

Date: 7/22/13

Group: Path Selection

Participants:

  • 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.

  2. 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 0.2.3.35 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

Comments

    Please register or sign in to add a comment.