I2P support forum

I am curious what the I2P specific limitations for a big hidden service are.

I come straight from the Tor community and i would like to write a post for /d/I2P in dread where i compare I2P and Tor and their suitability for a bigger hidden service so i hope someone here who knows more about I2P then i do (yet) can help me expanding my mind about I2P.

Since about half a year Tor hidden services are getting easily teared down by a DDoS which sends so many introduction requests to the Tor daemon that Tor fails to build all of them and therefore gets unresponsive for all clients.
Tor uses rendezvous relays which are chosen by the client if a connection to a specific hidden service should be established so a majority of workload when building a connection to a hidden service is on the hidden services side because for every client introduction request the hidden service need to build a connection to that rendezvous relay and need to wait there for the handshake with the client.

As far as i understand an attack like that would not be possible in I2P because the tunnels are already built during startup and all clients enter one of the up to 6 tunnels of the hidden service.
But what seems to be the solution to many of Tors current problems might be a big bottleneck for a bigger hidden service.
Reading that page https://geti2p.net/en/about/performance tells me that in the best case a tunnel can serve 50 KByte/s so 300 KByte/s for a hidden service with 6 tunnels.

I understand that with multihoming (which seems to be similar to Tors naive onion balancing) more than one instance can host the same hidden service public key (address) so you can spread the load through more instances which all provide their own tunnels.

Reading that page https://geti2p.net/spec/proposals/140-i ... ultihoming tells me that 100 multihoming routers "presumably wont work".

How many multihoming instances are feasible before running into other problems?
Are there any known DDoS attacks for I2P yet?

Or more general which are the I2P specific limitations if i would like to operate a bigger hidden service?

(By the way i search a co-mod for the I2P subdread in dread.
viewtopic.php?f=32&t=896 )

Hi

Biggest issue is/are open connections.
A hidden service has incoming tunnels, limited to 6 by the GUI, each tunnel ends on a different I2P router, called IBGW.
This IBGW needs the bandwidth AND the needed open connections for all clients.
Usually a IBGW can serve 10-50 kb/sec per tunnel and ~20-500 open connections, depending on network situation, and state of connection (e.g. just a datagram or streaming, long living).
For real usage of a website, I would assume safe values 30 kb/sec currently and ~100 connections. Which makes it 600 clients for a hidden service with 6 incoming connections.
Multihoming with 5-10 hidden services do work without issues, more not yet tested. You could multihome on the same hardware, with a 2nd i2p server, but that will not scale much. Better to use different hardwares in different locations and (important!) do data sync on your own!
With 10 multihome you can easy serve 6k clients at once, and more.
(on another side, the open tracker hidden service has 15k active users on a 6 incoming tunnel config, which makes it roughly 2500 connections per incoming tunnel, but thats mostly less traffic)

Also, 10 copies of a hidden service with 6 tunnels each makes it need for 60 different IBGW I2P routers, and at least 10*6*6=360 I2P routers to build in/outgoing tunnels. Slight a overhead.

The new specs of leaseset2 does offer some new features with a new multihoming concept, still being worked on.
Check zzz.i2p or proposal sections for the ls2 stuff.

DDOS to i2p has happend on several layers:
- building of useless tunnels, exhausting open connections, partly mitigated
- DDOS traffic to single I2P routers, network will work around a overcrowded/fault router
- DDOS to a hidden service - will change every time the IBGW changes, also more IBGW will help, due to slow network partly mitigated

echelon

Actually there are 16 tunnels selectable in the UI. You can override through .i2p/i2ptunnel.config.d/. Some hundred client tunnels no problem. Perhaps you would want a performance mod.

Hey echelon,

much thank you for all these numbers:)

One question so far:

echelon wrote: ↑03 Dec 2019 08:51 - DDOS traffic to single I2P routers, network will work around a overcrowded/fault router

Do you mean DDoS traffic inside I2P to a single router or useless traffic generated outside of I2P which gets shot to the IP address where that specific router is located to render it unreachable for I2P purposes?

Hi

both, for tunnel building routers are ignored if they are to slow.

echelon

So basically the DDoS attack vectors are comparable to the Tor ones.

- building of useless tunnels, exhausting open connections, partly mitigated

This is pretty much the same like the attacks on Tor with the INTRODUCE2_CELL where a hidden service is forced to open useless connections to rendezvous relays where actually no real client is waiting for him.
The Torproject tries to mitigate them with giving the hidden service the option to at least limit the introduction requests which are hammering on him so that the attack is stopped at the introduction relay which is responsible for transmitting the INTRODUCE2_CELLs to the hidden service.
That way a possible deanonymization of a misconfigured hidden services which might leak his real IP when the Tor daemon fails can be prevented but the main problem is by design and can not be easily solved.


- DDOS traffic to single I2P routers, network will work around a overcrowded/fault router

This problem is the same in Tor but i see a small but important difference. If a Tor relay which is most of the time located in a datacenter gets somehow attacked then its not a big problem. But in I2P where everyone is a router by default your ISP could get mad and probably take a closer look at you after some time.
Not even taking into account that this fact could be frightening for average users if there is something obviously wrong with his internet connection.
So I2P is putting more responsibility on the users than Tor does where the major part of responsibility is on the relay operators and not the users.

If i think further if I2P would get big it would probably be the same like Tor some day where people are "donating" routers on machines in datacenters and the normal user would configure I2P that way that he is no router but in the current state I2P could get a problem for normal users if DDoS attacks would get established for taking down specific routers.


- DDOS to a hidden service - will change every time the IBGW changes, also more IBGW will help, due to slow network partly mitigated

I am not sure if i understood correctly what you mean but if its an attack on the application layer its anyway the same like on Tor.


So as far as i can see in I2P the DDoS attack vectors are comparable to Tor but maybe even worse for the user because he is usually more involved with being a router by default.

The only real difference is that the DDoS in Tor happens right now while I2P is still calm.

While Tor was actually made as a proxy to the clearnet I2P always was a whole network in its own so hidden services actually fits better into I2P.

So my comparison of I2P against Tor:

+ UDP is possible in I2P while it is not possible in Tor (but who really need this these days?)
- Every user first needs to establish himself in the network while a Tor user can start browsing the moment he is connected to his Guard node (a result of I2Ps more decentralized architecture which can be seen as a +)
- In its current state more responsibility on every user (again a result of its more decentralized architecture)


Are there some other noticeable aspects of using I2P for a hidden service compared to Tor?