Torrenting and Network attack

[cumlord]

attack is ongoing but idk posted a mitigation strategy that sounds like it will be bundled into a release. i2pd did a quick fix too although it requires compile still. my i2pd routers were at 1-4% and are now around 8-10% with the fix.

minus what the devs like idk themselves are saying this is all just my opinion and things are changing, let me know if you think differently. seems like it's been getting better but there is no long-term fix that i know of yet.

my torrenting recommendations:
1. stick with java or i2p+
2. do idk's mitigation strategy to turn off sybil (explained bellow)
3. don't run a floodfill on a router running torrents or other services
4. 4+ hops
5. more tunnels (8-10, maybe more)

Java router mitigation copied from idk:

Java I2P users are suggested to disable the sybil attack tool, delete the sybil-blocklist, and re-start their routers.

To disable the sybil attack detector tool

Open the sybil attack detector in your router console at http://127.0.0.1:7657/netdb?f=3&m=15

Change "Background Analysis Run Frequency" to "Never"

Click "Save" to save the settings.

To delete the sybil blocklist, run:

On Debian and Ubuntu:

rm "/var/lib/i2p/i2p-config/sybil-analysis/blocklist-sybil.txt"

On other Linuxes and on Mac OSX:

rm "$HOME/.i2p/sybil-analysis/blocklist-sybil.txt"

And on Windows:

del %LocalAppData%\i2p\sybil-analysis\blocklist-sybil.txt"

When you are finished, re-start your I2P router.

If you are hosting a service inside I2P and it is hosted on a Floodfill router, you should consider multihoming the service on a Floodfill-disabled router to improve reachability. Other mitigations are being discussed but a long-term, backward-compatible solution is still being worked on.

why
1. testing throughput on i2pd and java, i2pd is still having difficulties maintaining tunnels at 3 hops. way too high failure for 4+ hops, i2pd is just not great to use for torrenting right now with good throughput. java is more reliable although with 4+ hops and more tunnels it will need more cpu/ram for the same speeds.

2. idk explains in his original post (reddit). the gist is attacker is flooding fake copies of real floodfill routers, which ends up causing the real one to get banned. java routers are working fine as but when they're all banning 10k+ routers (many of which may be real floodfills) it segments everyone, so that's no good for the network.

3. floodfill routers are being unstable still especially on lower powered devices. if you're running a floodfill on good hardware and it's being stable it might be ok, but since the sybil tool is still active on most routers that have it it runs the risk of being banned by them. all things not great for torrenting. i've noticed random shutdowns that could have to do with the large number of requests/OOM (i think anyway). timing of the downtime of a floodfill can be linked to related services it runs. the attacker could link services that go down with that router (ex eepsite/irc go down at same time, clearnet mirrors).

floodfills are necessary for i2p to function and the attack is targeting them to cripple the network, so run one if you can especially if you have access to good hardware. i've had to set lower transit tunnel limits with i2pd to keep it online even though resource usage "seems" fine. if you can run one you should run it on its own and use a non-floodfill for other things.

4. if you're not torrenting much, 3 is still "safe," but i wouldn't go less than that. i'd rather be cautious than sorry, there's a ton of fake routers (20k? 200k? no idea) http://stats.i2p/cgi-bin/total_routers_week.cgi. lots of unknowns, don't know the motive, the nature of these routers or if there are other kinds of simultaneous attacks (ex an unknown number of real routers ran by the attacker under cover of the disruptive "zombie router" attack to do some sort of de-anonymization). with numbers like that predecessor and other kinds of attacks have higher probability of success (where attacker can de-anonymize by being at both ends of tunnel) and would be even more effective right now with network segmentation. longer tunnels lower this probability. http://o7jgnp7bubzdn7mxfqmghn3lzsjtpgkb ... uters2.png

5. more tunnels are going to fail from the attack and more hops. increasing hops uses more resources and is going to be slower. more tunnels should help compensate for this, could try doubling what you have now and tune from there.

[lgillis]

1. stick with java or i2p+

If you are using I2Pd as a router and BiglyBT, you can use BiglyBT's built-in Java router to check the information being circulated. This is done by enabling the HTTP proxy in the I2P Helper and changing the port number if necessary.

[cumlord]

absolutely, can save needing to run a separate router.

for java if you want to squeeze more speeds out of it biglybt does a good job of spreading load among many tunnels. for more reliable tracker connection increase shared client tunnels to a high number. i've also used i2pd for reaching certain trackers oddly enough when i couldn't in java, so you can combine http tunnels from an i2pd router and i2cp tunnels from a java router in biglybt. attacks aside i usually have more stable tracker connections using i2pd specifically for http tunnels anyway.

if you're pushing memory limits increase it by editing the wrapper config. i think 512 is the default in i2p+ but less in vanilla java.

in ubuntu/debian do "sudo nano /etc/i2p/wrapper.config" or "sudo nano /etc/default/i2p" and find the line:
wrapper.java.maxmemory=256

increase to 512 or higher if needed for some extra headroom.

ctrl+s and ctrl+x, restart won't read the value again you need to fully shut it down and start again

if you are very limited on memory and can't do this, you can reduce the max transit tunnels. in router.config file (make sure routerconsole.advanced=true then you can do this from the console page) add the line:

router.maxParticipatingTunnels=

and adjust as needed. this doesn't need a restart.