Opened 6 years ago

Closed 7 months ago

Last modified 6 months ago

#1149 closed enhancement (wontfix)

Implement stream isolation

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


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:

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

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

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

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

               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.


Change History (8)

comment:1 Changed 6 years ago by zzz

Milestone: 0.9.10
Type: defectenhancement

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 6 years ago by zzz

Status: newinfoneeded_new

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

Status: infoneeded_newnew

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 6 years ago by zzz

Priority: majorminor

comment:5 Changed 5 years ago by str4d

Related: #731

comment:6 Changed 4 years ago by str4d

Status: newopen

comment:7 Changed 7 months ago by zzz

Resolution: wontfix
Sensitive: unset
Status: openclosed

This proposal to do tor-like things on i2p is almost impossible.

If a "circuit" is a destination, i.e. tunnel pool, that would be incredibly complex and resource-hungry to have multiple ones for a single i2ptunnel, and really disruptive to our architecture.

If a "circuit" is redefined to be a single tunnel inside a tunnel pool, we already have that, the mapping of a far-end dest to use of a single tunnel is cached, that's implemented in OCMOSJ.

We did implement multi-dest support for migration to new sig types, that's called subsessions, but subsessions use the same tunnel pool as the main session.

We also have close-on-idle option in i2ptunnel, as suggested in OP (but not close after each connection). It's not the default due to the added latency for creating new tunnels. Although perhaps it should be.

comment:8 Changed 6 months ago by zzz

see also #2361

Note: See TracTickets for help on using tickets.