Opened 5 years ago

Last modified 3 years ago

#1149 open enhancement

Implement stream isolation

Reported by: dg Owned by:
Priority: minor Milestone:
Component: apps/i2ptunnel Version: 0.9.9
Keywords: Cc:
Parent Tickets:

Description

Stream isolation involves the ability to separate each inbound connection from another's circuit (or, in I2P's case, tunnel). For example, stream isolation would help if 2 users access Susimail (or the same person accessing two accounts) and the person did not wish for the server operator to see a correlation.

Suggested by 'rfree' in #i2p. Snark was also mentioned but the resource usage would be high.
Could we 'close' a tunnel after each connection? Or implement it the way Tor does (each connection, if the right flag is used uses a new circuit from the others)?

Tor has the following isolation flags:

           The isolation flags arguments give Tor rules for which streams received on this SOCKSPort are allowed to share circuits with one another. Recognized
           isolation flags are:

           IsolateClientAddr
               Don’t share circuits with streams from a different client address. (On by default and strongly recommended; you can disable it with
               NoIsolateClientAddr.)

           IsolateSOCKSAuth
               Don’t share circuits with streams for which different SOCKS authentication was provided. (On by default; you can disable it with
               NoIsolateSOCKSAuth.)

           IsolateClientProtocol
               Don’t share circuits with streams using a different protocol. (SOCKS 4, SOCKS 5, TransPort connections, NATDPort connections, and DNSPort requests
               are all considered to be different protocols.)

           IsolateDestPort
               Don’t share circuits with streams targetting a different destination port.

           IsolateDestAddr
               Don’t share circuits with streams targetting a different destination address.

I think this could be important, particularly for 'naive' solutions (people given access to a Susimail/IRC2P tunnel and told to let rip, etc could be correlated unknowingly).
For users running traffic into I2P without thinking much about it (network level privoxy/similar), correlation may be a problem.

Subtickets (add)

Change History (6)

comment:1 follow-up: Changed 5 years ago by zzz

  • Milestone 0.9.10 deleted
  • Type changed from defect to enhancement

The first one maps (i.e. closest equivalent) to our shared-clients setting, right?

How are you mapping "circuit" to I2P? Is it a tunnel pool (aka Destination) or a specific IB or OB tunnel within the pool?

comment:2 Changed 5 years ago by zzz

  • Status changed from new to infoneeded_new

comment:3 in reply to: ↑ 1 Changed 5 years ago by str4d

  • Status changed from infoneeded_new to new

Replying to zzz:

The first one maps (i.e. closest equivalent) to our shared-clients setting, right?

Yes, inasmuch as our shared-clients settings increases correlation over the status quo.

How are you mapping "circuit" to I2P? Is it a tunnel pool (aka Destination) or a specific IB or OB tunnel within the pool?

The Tor isolation flags prevent the same circuit being used for certain combinations of clients. For example, a web browser and a mail client could both use the Tor SOCKS port, but supply different SOCKS authentication; then Tor would know to create and use different circuits for the different clients.

For this use case, "circuit" maps to a Destination (ie. tunnel pool), because that is what remote server ops can see in I2P and use to directly correlate activity (two users connecting to the same eepsite from the same Destination could be reasonably assumed to be the same person).

In I2P, the equivalent of Tor's isolation flags would be to allow multiple concurrent and independent Destinations for a single configured tunnel. This might not be necessary for all tunnel types; I think it is probably only useful for the HTTP and SOCKS types, which are intended to be used as proxies. Supporting this for a dedicated tunnel to e.g. mail.i2p is harder, because the Standard I2PTunnel type has no knowledge of what is actually being sent over it. How could a non-I2P-specific app pass this knowledge on? IMHO it is not possible. For I2P-aware apps that use the Java API or BOB/SAM, they can spin up a new tunnel themselves for different identities.

Incidentally, this might become trivial to implement once multi-Destination support is added to tunnels for the migration to better signatures in Destinations.

comment:4 Changed 5 years ago by zzz

  • Priority changed from major to minor

comment:5 Changed 4 years ago by str4d

Related: #731

comment:6 Changed 3 years ago by str4d

  • Status changed from new to open
Note: See TracTickets for help on using tickets.