#saltr (irc2p) | I2P+ 2.7.0-17+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

weko For general fix, we must recognize fake FFs (most easy - simple ping with i2p's transport), and block its FFs (and IPs) for long time (week, for example).

weko Also, maybe we need do not flood FFs, that we not check yet.

weko Ofc, we can do some stupid things, like searching patter of fake FFs, but it is temporary and just hot fix "for works"

weko Floodfills: 18861

weko Just for understand.

xeiaso what if you throw out floodfills that aren't also routers?

weko xeiaso: any floodfill is router. Floodfills - is subset of all routers

xeiaso i mean like stormycloud.org/i2p-stats it shows floodfills but they don't route traffic?

weko They can't do not. But they also routers

weko **

weko They can do nt

weko They can do not

weko For example, caps "LUF" is valid

weko Oh

weko Mistake

weko "LRF"*

weko We recognize router as FF if it have cap "F", but we need more verification for recognize reality of this FF.

weko Spam with fake FFs is problem, because router trying get info about RIs and LSs mostly on fake FFs (witch do not sent answer), and this is reason of small TCSR

weko Critically small*

xeiaso TCSR algorithm needs adjustment, it shouldn't go so low

weko And ofc, this more probably special attack.

weko xeiaso: for i2pd now it looks correctly

weko Tunnel creation success rate: 3%

weko Looks like real value for attack time

parrot Hey hey hey!!!

dr|z3d parrot!

dr|z3d are you going to linger for more than 25ms?

dr|z3d I guess not :|

dr|z3d more mitigations in the latest I2P+ dev build.

dr|z3d if you're running a recent I2P+ dev build, router.enableImmediateDisconnect=true will deal with potentially hostile routers more aggressively.

not_bob Blinded message

not_bob 2% build success sucks.

RN quite

obscuratus I'm still hanging in there at 15%. That's my exploratory build success. I don't track overall.

not_bob eah, t's been bad.

RN I recently restarted my i2p+ (latest upgrade) and I'm at 53%

xeiaso I'm a bit of an 8% enjoyer.

RN 53% is close to what I had before applying the last update

RN so I'm pretty stable on that router

not_bob My highest is about 40%.

eyedeekay I got a couple 15-20% periods today corresponding to the worst times, but spent most of the day between 40-60% which is pretty average

eyedeekay That's my laptop, I've got the same graph on my servers, not looked at those yet

not_bob All my ip2d routers are running at 0-2%, I2P+ is doing much better.

not_bob But, that seems to be expected at this point.

eyedeekay That tracks with what most folks are reporting

RN my i2p+ console is showing 66% now

not_bob Nice

not_bob Has anyone heard from origional?

eyedeekay Not me

not_bob I'v pinged him. Hopefully he is already aware.

RN hey, someone was asking about the topic in #ls2 and when is the next meeting?

eyedeekay I'll fix it shortly, monday after next

RN :)

obscuratus Is there a way to send garlic messages so that they're trivial to decrypt, and a router can decrypt them even if they're not the destination.

obscuratus The answer seems obvious, but I was wondering if you could do it intentionally.

orignal eyedeekay seems we have troubles

orignal in our protocols

eyedeekay Lay it on me, what do you know?

eyedeekay obscuratus is "a router" who wants to decrypt it a router you control? If so I think yes, but if not I am less sure, first thing I would try is to just send it without encrypting it at all and see what happens

orignal transport protocol

orignal Alice never verifies Bob's identity

orignal if another guy sits on Bob's IP with righ static key

orignal she will connect successfully and will not know that's it's another router

orignal and that's going on now

not_bob So, how do with mitigate this?

not_bob ALso, this would be useful to deanon people, I would imagine, yes?

eyedeekay Right now I only see DDOS potential unless orignal has more to tell us

orignal let me expalin

obscuratus And, how would one 'sit' on someone else's IP?

orignal they generate fake routers but clone content including address

eyedeekay But the obvious thing to do is make it so Alice can verify Bob when an attacker has Bob's static key

orignal eyedeekay it's opposite

orignal legitimate user tries to connect to a fake router

orignal but sucessesfully conenct to real one

orignal and has no clue it's another router

eyedeekay Please explain then

orignal as reault

orignal say you have a FF

orignal with you published IPs and static keys

orignal an attaker clones your IPs and static keys and produces few hundreds of fake router

orignal and poison the netwrok

not_bob Ahh

orignal users try to connect to that fake routers but connect to you

not_bob But then the connecion is useless, yes?

orignal 1. they have no clue they are connected to another router and believe fake routers are good

orignal 2. When they try to send a TBM it fails because you can't find your record

orignal yes but the netwrok is almost stuch because of this

orignal bunch of fake floodfills that look good

eyedeekay That would explain why Java I2P is seeing such exorbitant ban counts

obscuratus In java i2p, sybil would ban that IP.

eyedeekay 20k or more

not_bob Which is why java routers are fairing pretty well.

orignal then guys you pubish leintimate routers

orignal which IP it should ban?

orignal say you have few hundreds with same IP

eyedeekay The one with 300 routers on it

orignal and only one is real rouyter

orignal there is no 300 routers

orignal he sends 300 datasestore messages

orignal for each floodfill

orignal if you ban such IP you will ban ALL floodfiils now

not_bob Good point.

eyedeekay Ok so the burst of messages essentially knocks the floodfill offline, I see

orignal seems you still don't understan current attack

orignal no

orignal the networks is posioned with fake routerinfos

orignal and you can't differentiate them

not_bob And the attack makes it hard to tell which are real.

not_bob Yes

orignal because they are clones of real floodfills

orignal there is basically only way to tell who is real

orignal one who was Alice somewhen

orignal but my point is that we have a hole in transport protocols

obscuratus OK, I think I've been seeing a few of these. Same IP, same routing key, but differenct NetDB entry.

orignal exacly

orignal Vort found 53 clones of his FF

orignal and stored all of them for analysis

obscuratus Ughh

orignal I think it might be more per each floodfills

orignal mine is completely busy now

orignal although I filter shit there

eyedeekay Definitely seen some here too, I've got 36 ff's on an identical IP in my banned

orignal you should turn the ban off

orignal otherwise you will be short of FFs soon

obscuratus OK, but we'd still be wading through fake FFs.

orignal I have some ideas

not_bob orignal: Awesome.

orignal first thing not accept unsolicited floodfills on non-FF onless it's in peer test

xeiaso ban the bad FFs

orignal xeiaso how do you know which one is bad?

orignal you have 53 routers with same IP

orignal 52 are bad and 1 is real

orignal my approach is different

xeiaso if 1 is legit and 52 are bad you have a 98% accuracy if you ban them all

orignal I will mark a FF as good if it's Alice and IP addresses match one he is connected from

orignal xeiaso how do you differentiate them?

xeiaso you don't but if the attacker has to 50 times more FFs then he'll run out very soon

orignal almost zero cost

orignal xeiaso he doesn't have 52 FFs

orignal he only send messages about these 52 FFs

orignal eyedeekay so any ideas?