#ls2 (irc2p) | #ls2 Proposal 168 review here 8 PM UTC Tues. Dec. 3

dr|z3d orignal: except whoever they are hasn't switched over to ssu, at least not entirely.

dr|z3d the ntcp attack is still ongoing.

orignal yes, but also many SSU

orignal NfR routers

dr|z3d parallel attack, then.

orignal no. I thin i2pd and Java

dr|z3d nothing about 10K banned routers suggests ntcp attack has run its course.

orignal Tunnel creation success rate: 46%

orignal ha ha

dr|z3d snap.

orignal Floodfills: 1477

orignal I have found a way to clear them ))

dr|z3d 46% exactly build success on the router I'm looking at.

orignal but don't want to tell here for obvious reason

dr|z3d 10K banned routers loading on a java console page, not the best experience :|

obscuratus The attack may be subsiding (for now), my router has also cleared the extraneous routers, but I haven't done anything to clear them.

orignal maybe

orignal but I was not a floodfill

dr|z3d 10h uptime, ~16K banned NTCP-only FFs.

obscuratus hexcellent, the attack is back on!

zzz extra salt for breakfast this morning

dr|z3d what dis one? 37.228.88.201

dr|z3d whatever it is, it's looking super dodgy from here right now.

dr|z3d_ ah, salt.

dr|z3d_ now I get the reference. doctored RIs..

dr|z3d Capabilities: Xfsalt

dr|z3d did that ip I posted earlier hit the channel? about 20m ago..

orignal zzz my approach works well

orignal with this new stuff ))

orignal attack is back on but not for me ))

dr|z3d seeing a bunch of: Corrupt fragment received [Offset: 742] (Null Pointer Exception)

zzz as usual, figure it out, either fix or reproduce on canon

dr|z3d_ as much as I know you want to pin every bug on me, zzz, I doubt that's mine :)

zzz orignal's theory wins, at least some of them are real, I'm connected outbound to several

zzz sure dr|z3d_ but it has to be this way

orignal dr|z3d do you need my patch?

orignal you don't need the code just a explanation what to do

dr|z3d orignal: don't mind taking a look at what you gone and done :)

orignal in PM

dr|z3d wouldn't say I need it, however, my mitigations are working pretty well, but I'm a mere novice in the scheme of things :)

dr|z3d thanks.

zzz ad hoc short-term identification and banning is fine if you're dead in the water, but...

zzz sybil tool is also catching a lot on some of my routers but not others, which is complicating/masking things as well

dr|z3d sure, short term mitigations are by definition short term. but they're not entirely useless.. what remains is arguably more interesting than what generalized mitigations catch.

zzz they may be helpful for some people but would actively get in the way of my R&D

dr|z3d you do your thing, wouldn't want to interfere with that :)

zzz sure, go block salt caps and 0.9.58 routers, that might buy you or your users a couple hours, but I can't go down that road

dr|z3d wouldn't expect anything less. :)

zzz and as for NPEs, they're about the easiest possible class of bugs to find and fix, and I know you have lots of experience :)

dr|z3d if the exploit du jour is seeding out thousands of bogus ff RIs into the network, the fix is presumably fairly easy, conceptually speaking. validate the ips before talking to the routers, or ban if validation fails.

zzz ok he turned off the 0.9.58 routers and they've all expired out

zzz at least my graphs will now add up to 100% again

zzz dr|z3d, at least some of them are real, as I said above, I was connected to them. I don't know if they all are (or were)

zzz and the salts are all gone too

dr|z3d yeah, that tallies with what I'm seeing.

dr|z3d did you get the ip I posted earlier? if not, can pm. interesting one.

zzz no time to chase IPs

dr|z3d ok. 1/2 dozen RIs one of my netdbs, all same ip/port.

dr|z3d origin: moscow.

zzz could be prestium

dr|z3d all Xf, poor to zero lookup success.

zzz but I guess port would change

dr|z3d prestium is likely firewalled too, no?

dr|z3d salt's not gone.

dr|z3d salty routers running on 0.9.57 and .58 here that I can see.

zzz could be different expirations, or different blocks/bans, hard to get a consistent view

zzz but let me boil it down really simple

zzz where we're at yesterday vs. today

zzz yesterday: two theories:

zzz 1) lots of real routers all over

zzz 2) lots of fake RIs being sprayed into the net, possibly from a single source

zzz today:

zzz 1) is proven

zzz 2) is still unconfirmed, but could be a possible 2nd attack. However, unlikely to come from a single source given 1)

zzz so

orignal My theory is that "salt" is difefernt attack than the main one

zzz there's little reason to go hunting for a single source of 2)

zzz the priority is to fix 1) which is proven

orignal and what will it tell you?

orignal say you prove it comes from 37.228.88.201

zzz right, waste of time to "find the single IP"

orignal e.g. you prove that it was Plaz

orignal so?

orignal will he stop doing it? no

zzz agreed

zzz fix the problems 1) is causing

obscuratus Or, I guess, rather pass them on to the closer DHT peer, then ploink them.

orignal LeaseSets: 3

orignal interesting to see it on non-FF router

dr|z3d zzz: +v for not_bob please.

not_bob Thank you

zzz welcome

orignal any updates?

orignal salt said we will be regretting soon ))))

zzz fun times

dr|z3d obscuratus: I'm already grading RIs based on an "interesting" quotient. slow/unreachable peer RIs get dropped a lot sooner, and peers with those caps don't get profiled.

dr|z3d uninteresting peer RIs also stay in ram only, so are expunged at the end of the router session.

not_bob I'm using dr|z3d's latest dev build and that router fucntions much better than the rest of my fleet. 40% tunnel build succcess vs around 10% for my i2pd routers.

zzz all a losing battle when all the salt is interesting

zzz I'm going to spend the next couple days landing simple mitigations

zzz don't hold breath for any clever recommendations

zzz as most of my ideas were w.r.t. fake routers, not real ones

orignal ofc

not_bob Are there any sorts of sanity checks that can be performed on new routers to verify they work before added?

dr|z3d no harm in mitigating against fake routers. this won't be the last time we seem them.

orignal yes weko has this idea

orignal don't consider a new router as as FF until you connect to it al leat once

orignal I like this approach

not_bob That would work well I suspect.

weko Decrease chance for connect to 1/10 for example

orignal if you are floodfill you connect to all other floodfills frequetly

orignal so we have a profile for FF

orignal if we receive one from a reseed we enable it instatly

orignal otherwise try to connect and only that include it to reponses and flood

zzz you don't need a direct connect, just a response to a lookup or store

weko zzz: also

zzz which is essentially what java does now

weko Any prove what it is legal floodfill

weko Proof*

orignal true

orignal might be trough a tunnel

orignal zzz really?

orignal I didn't know it

weko But I guess detect it with destinations can have deanonimity risks...

orignal I will do the same

weko Don't know sure. Just guess.

dr|z3d we have floodfill profiling, orignal.

dr|z3d good, ok, dogshit.

orignal yes, I'm going to implement

orignal but I didn't know you wait

dr|z3d we prefer good over the bad, but in the event of no profiles, anything goes.

weko [22:43:04] <dr|z3d> we have floodfill profiling, orignal.

weko Have you same feature?

zzz yeah we don't declare a ff to be non-ff, but we kinda, more or less, sort them into good/ok/bad based on the profile

orignal and that's wrong

weko zzz: it is very slow process while attack

orignal weko's idea to not use a FF until we know it's good

weko +

orignal LeaseSets: 20

orignal new attack?

weko orignal: on non FFs?

weko I think it is

orignal number of leasesets keep groing on my non-FF router

orignal and it never been a FF

orignal zzz the question is

orignal if you flood new floodfills once you receive them

zzz don't store LS on non-ff

orignal no, you receive new FF on your FF, do you flood it?

zzz sure, following the usual rules

orignal maybe we put it hold

orignal should

orignal until we have proof it's good

weko But we need verify what it is real FF, for prevent spamming with fake RIs

orignal non-FF RIs are fine

orignal who cares?

zzz guys it's meeting time over in #i2p-dev so I will be over there for an hour

weko orignal: it is interesting

weko Maybe attacker found new type of attacks

weko Or just trying

orignal no problem

orignal will talk later

weko orignal: so, we should reject LS store request if we not a floodfill

weko Yes

weko But not reject if we setup floodfill in config but have non OK status

weko For prevent problems

weko With status

weko As I had