Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#3516 closed enhancement (implemented)

Implement stream isolation backend logic for proposal 171

Reported by: nickm Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: #1865 Points:
Reviewer: Sponsor:

Description

Part of proposal 171 will be looking at two streams and determining whether or not they can share a circuit. In order to make this efficient, we shouldn't do it as an O(n 2) operation, however: instead of comparing each stream with every other stream on a candidate circuit, we should:

  • annotate the circuit with a description of what streams may be attached to it,
  • compare the circuit's rules to any new stream we want to attach to the circuit,
  • and update the rules as needed when we attach a new stream.

To do this efficiently, we'll need to design some data structures to represent a stream's isolation requirements and the isolation a circuit can provide. We'll need some compare and update functions.

Child Tickets

Change History (7)

comment:1 Changed 8 years ago by nickm

Owner: set to nickm
Status: newaccepted

comment:2 Changed 8 years ago by nickm

So, expanding the design, here's an abstract version what I think we need. Every listener has:

  • A sessiongroup. (Any listener without a sessiongroup gets assigned a sessiongroup used by no other listener.)
  • A set of 0 or more isolation flags: ClientAddr, DestAddr, DestPort, SocksAuth, ClientProtocol.
  • The isolation flag "IsolateSessionGroup" (always on).

Each client stream has:

  • The following fields
    • A sessiongroup.
    • A clientaddr.
    • A clientprotocol.
    • A socksauth field.
    • DestAddr, DestPort (streams already have these).
  • A set of 0 or more isolation flags. For each of these that is set, the stream cannot share a circuit with another stream that has the same value for the corresponding field.

Each origin circuit has:

  • The same fields as entry streams have above. Each of these may also take a value "mixed" that is equal to no other value.
  • A set of 0 or more isolation flags.
  • An "unused" flag.

New circuits have the unused flag set, and no isolation flags set.

It is okay to attach a stream to a circuit if the circuit is unused, OR if for every flag set on the stream, the corresponding field of the stream matches the value of the field on the circuit.

It is better to attach stream S to circuit C1 than to attach it to circuit C2 if it is okay to attach S to both circuits, and if attaching S to C1 would require us to set fewer fields to "mixed".

To attach a stream S to a circuit C, clear the circuit's unused flag. Then set C's isolation flags to the logical OR of their old value and the isolation flags of S. Then, if C has no field set, set its fields to match those of S. Otherwise, C has some fields set: for every field of C that is not "mixed" and that is not equal to its value in S, set that field to "mixed".

(Yes, I know how to type ⊥. I just don't feel like being too mathy here.)

comment:3 Changed 8 years ago by nickm

Oh. Also, DestAddr is a hostname. It matches itself case-insensitively, and it matches the IP to which it resolves, and it matches any other hostname that has been resolved to the same IP. (Please scrutinize this last part.)

comment:4 Changed 8 years ago by nickm

Status: acceptedneeds_review

My prop171 branch now has code to do this, except that the DestAddr logic described above and the socksauth code are not yet implemented.

comment:5 Changed 8 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

comment:6 Changed 7 years ago by nickm

Keywords: tor-client added

comment:7 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.