Home Explore Help
Sign In
sengler
/
tor-parallel-relay-conn
1
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Tree: d230827912
Branches Tags
tor-parallel...
/
doc
/
spec
/
proposals
/
ideas
/
xxx-controllers-intercept-extends.txt

xxx-controllers-intercept-extends.txt 2.0 KB
History Raw

1234567891011121314151617181920212223242526272829303132333435363738394041424344 
  1. Author: Geoff Goodell
    2. 

  2. Title: Allow controller to manage circuit extensions
    3. 

  3. Date: 12 March 2006
    4. 

  4. 

  5. History:
    6. 

  6. 

  7.   This was once bug 268.  Moving it into the proposal system for posterity.
    8. 

  8. 

  9. Test:
    10. 

  10. 

  11. Tor controllers should have a means of learning more about circuits built
    12. 

  12. through Tor routers.  Specifically, if a Tor controller is connected to a Tor
    13. 

  13. router, it should be able to subscribe to a new class of events, perhaps
    14. 

  14. "onion" or "router" events.  A Tor router SHOULD then ensure that the
    15. 

  15. controller is informed:
    16. 

  16. 

  17. (a) (NEW) when it receives a connection from some other location, in which
    18. 

  18. case it SHOULD indicate (1) a unique identifier for the circuit, and (2) a
    19. 

  19. ServerID in the event of an OR connection from another Tor router, and
    20. 

  20. Hostname otherwise.
    21. 

  21. 

  22. (b) (REQUEST) when it receives a request to extend an existing circuit to a
    23. 

  23. successive Tor router, in which case it SHOULD provide (1) the unique
    24. 

  24. identifier for the circuit, (2) a Hostname (or, if possible, ServerID) of the
    25. 

  25. previous Tor router in the circuit, and (3) a ServerID for the requested
    26. 

  26. successive Tor router in the circuit;
    27. 

  27. 

  28. (c) (EXTEND) Tor will attempt to extend the circuit to some other router, in
    29. 

  29. which case it SHOULD provide the same fields as provided for REQUEST.
    30. 

  30. 

  31. (d) (SUCCEEDED) The circuit has been successfully extended to some ther
    32. 

  32. router, in which case it SHOULD provide the same fields as provided for
    33. 

  33. REQUEST.
    34. 

  34. 

  35. We also need a new configuration option analogous to _leavestreamsunattached,
    36. 

  36. specifying whether the controller is to manage circuit extensions or not.
    37. 

  37. Perhaps we can call it "_leavecircuitsunextended".  When set to 0, Tor
    38. 

  38. manages everything as usual.  When set to 1, a circuit received by the Tor
    39. 

  39. router cannot transition from "REQUEST" to "EXTEND" state without being
    40. 

  40. directed by a new controller command.  The controller command probably does
    41. 

  41. not need any arguments, since circuits are extended per client source
    42. 

  42. routing, and all that the controller does is accept or reject the extension.
    43. 

  43. 

  44. This feature can be used as a basis for enforcing routing policy.
    45.