#saltr (irc2p) | I2P+ 2.7.0-10+ >> 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

dr|z3d not sure why we even attempt to handle packets with no tunnel id. can't we just drop them on sight?

xeiaso dr|z3d: sounds like a good thing to add to i2p+

mesh dr|z3d: one way to find out

mesh dr|z3d: btw is it possible to see the ip addresses of banned routers?

dr|z3d depends on how they're banned, but mostly not. if they're banned, their routerinfo gets purged so no ip.

mesh it's all very leinient. why not remember the ip ... what's to stop the router from simply restarting and changing its identity hash and getting back to hikinks

mesh err hijinks

dr|z3d because that's not how it works. we ban by hash and identify any ips associated with the hash.

dr|z3d if an offending router wants to change their hash and engage in the same behavior that got them banned, they'll get banned again.

mesh dr|z3d: I mean it's not like it's hard to change a hash. It seems strange to ban by hash. But then banning by IP is certainly not perfect given the cloud

dr|z3d ips are cheap, hashes cost more.

mesh I guess the only mitigating factor is that it would probably take a while for a router to realize it's been extensively banned

mesh dr|z3d: you think so? I would think hashes are much cheaper (being free, easy to regen simply by restarting the router) than ips

dr|z3d if ( (target == null) || ( (tunnel == null) && (_context.routerHash().equals(target) ) ) ) {

dr|z3d log_warn("Dropping BAD message with no target and no TunnelID");

dr|z3d return;

xeiaso mesh: sha256 must be very expensive to compute

mesh xeiaso: it's really... not

dr|z3d if you're an attacker or abuser, then you can change ips at a rate of thousands an hour via a vpn as we've seen. really don't want to clog up the ban list with thousands of ips when a single hash will suffice.

dr|z3d no restart of the router required to change ip.

dr|z3d so hashes are more expensive in the scheme of things.

mesh I'm surprised vpns are okay with such behavior. Do we know which vpns?

dr|z3d this is going into the weeds when we're discussing something quite different. some vpns actively promote/enable changing ips. without their explicit support, it wouldn't happen. it's a vpn.

mesh I would still theorize that keeping a list of ips would be cheaper in the long run. Router hashes are infinite but even a large pool of ip addresses can be exhausted. It might be worth an experiment. It would be good to know at least to track which ips are participating in the attacks

obscuratus dr|z3d: I have over 180,000 messages in my logs with no tunnel id.

dr|z3d yikes, obscuratus.

xeiaso obscuratus: that's a lot. im kinda jealous.

obscuratus I added some debugging for that back in February. They're very common.

obscuratus They're all (100.00%) (target: NULL; tunnel: NULL)

obscuratus I have exactly zero not (target: NULL; tunnel: NULL)

obscuratus So, we can drop all the ones where we're not the target. They're shouldn't be any.

xeiaso yeah and dropping them should improve performance

obscuratus Speaking of... I'll be back in a bit. I'm gonna try a modification that drops those.

xeiaso (obscuratus doesn't know)

xeiaso how long do you think it will take him to figure it out?

dr|z3d figure what out? how to drop the packets?

mesh xeiaso: it will take exactly 6.4 minutes

xeiaso No, to figure out what the patch *actually* impacts

dr|z3d moot point, no idea.

xeiaso Oh it's not moot. You'll see.

mesh xeiaso: you of course have no idea what the patch impacts

xeiaso :)))))

mesh oh no he made cryptic smiley faces

mesh pathetic

dr|z3d that's a russian smilie, mesh. keep it civil, non-personal.

dr|z3d actually, no, it's not russian, it's just smilie for super big grin.

dr|z3d russian smilie would be )))))

RN :)) is a smiley with a double chin, so :))))) is Jaba the Hut

mesh attack is over. lasted an hour it seems

xeiaso it stopped around the time obscuratus quit

mesh xeiaso: it actually stoped at the time you "smiled"

xeiaso oh c'mon that's pure speculation

RN don't forget network lag... hehehe

xeiaso_ obscuratus: did you apply dr|z3d's patch?

obscuratus The one dr|z3d was echo-ing out in this channel?

dr|z3d that was speculative. I doubt he applied that.

dr|z3d that would have prevented any client tunnels being built.

xeiaso_ I know. That's why he should have tried to apply it.

obscuratus Here's the patch I'm testing. It won't apply cleanly, it's on top of some other debugging I'd already applied.

obscuratus cake.i2p/view/67nVvm9kWe_bMqfQOI2UpakRdYsA7oMWAdhUu65gi_gyFQGsjGRS/67nVvm9kWe.txt

obscuratus I've elevated some debugging to critical because I want to see it highlighted.

obscuratus The final version probably won't have as much debugging.

dr|z3d you're not doing a return on those dodgy packets, effectively dropping them?

obscuratus Yeah, I'm just letting it exit the loop. An explicit return would be better.

dr|z3d then you can add something to the logging that indicates the message has been explicitly dropped. ideally we get the sender logged, too.

dr|z3d and a counter of dodgy packets in a specific timeframe wouldn't hurt, then you can set a theshold for banning the router.

obscuratus Well, I accept the direct packets, we may not know the sender for the other cases.

xeiaso_ check to see if the packet contains the string "salt" too

obscuratus For the packets coming down a tunnel (which are the dangerous ones for de-anonymity), we don't know the sender.

mesh obscuratus: you do know the ip...

obscuratus Not if it comes down a tunnel.

mesh how big are these packets?

xeiaso_ max 64k

obscuratus I've never seen one yet.

obscuratus I've had logging up that would have detected these packets for a day or two. And I've used that logging previously. I've never seen a packet like the ones this patch deflects.

mesh on another project I worked on we adopted a philosophy of "log everything". All incoming and outbound packets were written to (eventually) Chronicle journals. This made the sort of after-the-fact message analysis quite easy. (In fact we ended up making it queryable using SQL which was kind of cool, treating the inbound and outbound message journal as a database)

obscuratus TBH, I'm not at all sure this hypothetical attack is feasable. But, better to be safe.

mesh of course you wouldn't do this in production. and you might limit the log to a few gb

mesh (there's something going on right now hehe)

xeiaso_ I noticed ever since obscuratus joined back my TCSR went down.

xeiaso_ How many kinds of debugging patches are you running?

obscuratus xeiaso_: I've been patching my I2P for years now. I've got a stack of stuff I always apply.

obscuratus Mostly just debugging. Anything useful, I either pass on, or discard.

mesh obscuratus: patching vanilla java i2p?

RN yeah, he runs Obs2p

obscuratus :)

mesh that sounds like a herpes drug

obscuratus mesh: I'm on canon.

mesh I wonder if we'll see build success % drop to 0

xeiaso_ why are some people changing their nicks to guest?

StormyCloud default name scheme if you dont message NickServ

RN only if you are using a registered nick and don't authenticate to nickserv

xeiaso_ ah. people are afk so it automatically switches them when their connection is interrupted and they rejoin.

mesh I wonder if i2p isn't aggressive enough about trusting routers that have proven themselves trustworthy

RN xeiaso_, that happens if their irc client or bouncer fails to respond to nickserv

dr|z3d attack time, bandwidth saturation vector.

mesh dr|z3d: pretty much. but I find it strange that the build success rate falls so low during such an attack

xeiaso_ bandwidth saturation? that must be a ton of RIs.

dr|z3d if the network's being flooded with unresponsive routers that ignore packet requests at the same time, mesh, there's your build success drop.

dr|z3d packet/tunnel

mesh dr|z3d: but why are those new unresponsive routers even being chosen?

orignal seem excessive badnwidth now

dr|z3d I select first hop, good, and between me and the target's inbound gateway, there's a shit router. so the tunnel times out.

dr|z3d or the router I select looks fine until I try and send packets, then it fails.

orignal dr|z3d do you see excessive trafic now?

dr|z3d it's reducing now, orignal, but 5m ago, sure.

orignal <oruge> Transit: 1.37 GiB (9897.02 KiB/s)

xeiaso_ more traffic is good no? it means that people are shifting from the bad routers to the good ones

orignal plaz also sees it

mesh maybe raise the "cost" of being a new router. ignore these guys for a good hour.

orignal xeiaso_ it's good

orignal but current we are under attack

dr|z3d spiked at around 5MB/s on one of the routers I'm watching.

orignal also at asian morning

orignal canguroo ?

xeiaso_ asian monday as well

orignal my crazy thoery that the source is Australia

xeiaso_ if u put iptables drop from australia, does the attack on the network stop?

dr|z3d for more aggressive handling of potentially shitty routers, router.enableImmediateDisconnect=true in I2P+

orignal Transit: 6091.19 GiB (7786.30 KiB/s)

orignal mine

orignal no it will not

orignal the thoery is lokinet

orignal as the major competitor

xeiaso_ wait it jumped from 1.37 GiB to 6091.19 GiB?

orignal 6K Gb is since restart

mesh orignal: the attacks are pretty pathetic

orignal it's about a mnoth

dr|z3d lokinet wouldn't stoop so low as to attack this network. well, I hope not :|

mesh dr|z3d: sure they would. people will do pretty much anything for money

xeiaso_ does plaz endorse lokinet?

orignal no

orignal lokinet is psi

orignal he works for them

orignal but they are australians

mesh it's not like the attacks are sophisticated though. it's like start a bunch of routers, create some tunnels, pump data through the tunnels

orignal no

mesh when the attack begins there's a sharp rise in participating tunnel count, bandwidth usage, and fall in build success

orignal bunch of data goes through few tunnels only

xeiaso_ yeah who has this amount of traffic i was think it has to be a big network attacking i2p

mesh orignal: yeah, some routers are sending data dn others are dropping packets

orignal it's very heavy traffic

orignal can't be explained by resends or tunnel build messages like gradpa blamed me and bitcoin

dr|z3d on the plus side, it gives the network a good workout.

mesh it doesn't seem like it would be difficult to mitigate the attack. the attacks are also transient. that's why it's sort of silly. whoever's doing it isn't seriously trying to degrade i2p... it's either a probe or they're just trolling

orignal look

xeiaso_ maybe sending tons of probes to test issue 397?

orignal this attack doesn;t affect us

orignal we are powerful enough to handle all this traffic

orignal but idk what's going on with Java routers

mesh orignal: well it is annoying that stuff becomes unreachable

orignal I saw 5 diffent attacks so far

xeiaso_ Anonymouse person said in thread: "Once I get to it I will modify my router to send forged garlic cloves."

xeiaso_ lambdaplusjs35padjaiz4jw2fugdoeutse262phqr72uf634s2wdbqd.onion/tech/34039#P39461

orignal that's why we have congestion caps now

mesh that's the real problem. who cares about bandwidth. all my routers have effectively unlimited bandwidth. 90% dedicated to i2p. but during these attacks it looks like certain i2p services and sites are actually going down

orignal xeiaso_ there is only one problem

dr|z3d fine here, orignal, dip in build success but otherwise not much of an issue.

orignal no such thing as "garlic cloves" anymore )))

orignal that dude is too outdated

eyedeekay If it's any of the 50 or so sites and services I run, that's unrelated

orignal dr|z3d no issue for us

orignal even build success is low

orignal eyedeekay check your bandwidth usage please

mesh it would be good if build success didn't drop to the single digits during the attacks

orignal I have 20-25% now

xeiaso_ which websites are down? are they the target?

dr|z3d build success varies from router to router here, between 40 and 80% right now.

orignal hence no issue

mesh I saw build success as low as 8% just a few minutes ago

dr|z3d indeed.

mesh 30m ago

dr|z3d router should recover fairly quickly from that.

mesh dr|z3d: it does recover... fairly quickly, hehe. which is to say the attack ends and it bounces back

xeiaso_ how many EXTEND garlic frames can someone send down a tunnel? could someone extend it indefinitely ?

mesh anyways in other news something has happened to the youtube algorithm that is making youtube serve up the most amazing playlist mixes

eyedeekay still pretty nominal on my laptop and phone, lowest build success I have seen on any canon router I run was 18%, which lasted less than the ten-minute intervals I log them at

mesh I suspect this is an actual tangible benefit produced by AI

orignal gralic clove has own delivery instructions

orignal but it's also taken care

orignal plus no more cloves in ECIES but blocks

orignal garlic message can be up to 62K or so

xeiaso_ orignal but garlic can contains more garlic, so nested instruction are possible

orignal i2pd drops it

orignal LogPrint (eLogWarning, "Destination: Unexpected I2NP message type ", typeID);

orignal that's what you will see

xeiaso_ line 394

xeiaso_ i see it

obscuratus major is usually so quiet.

dr|z3d he has his moments :)

xeiaso_ wb major, good bot

xeiaso_ orignal though 397 doesn't even make it to that point

orignal in case of nested garlic it will exit on 395

obscuratus What file are you looking at?

xeiaso_ Destination.cpp

orignal Destination.cpp

orignal how we handle cloves

obscuratus Thanks orignal. We should bring this up at the next #ls2 meeting. I think there's a divergence here right now with how we handle that.

xeiaso_ tell me orignal, what happens when a ShortTunnelBuild comes down an inbound tunnel? doesn't TunnelEndpoint::HandleNextMessage send it the generic i2p::HandleI2NPMessage which handles it like normal?

xeiaso_ obscuratus: The i2pd equivalent to InboundMessageDistributor is correct. github.com/PurpleI2P/i2pd/blob/openssl/libi2pd/TunnelEndpoint.cpp#L331

xeiaso_ "!m_IsInbound" rejects all that target router or tunnel when inbound.

dr|z3d we also have a filter for message types, xeiaso

dr|z3d case DatabaseSearchReplyMessage.MESSAGE_TYPE:

dr|z3d case DeliveryStatusMessage.MESSAGE_TYPE:

dr|z3d case GarlicMessage.MESSAGE_TYPE:

dr|z3d case OutboundTunnelBuildReplyMessage.MESSAGE_TYPE:

dr|z3d case TunnelBuildReplyMessage.MESSAGE_TYPE:

dr|z3d case VariableTunnelBuildReplyMessage.MESSAGE_TYPE:

dr|z3d // these are safe, handled below

dr|z3d break;

dr|z3d otherwise, we drop.

dr|z3d default:

dr|z3d _context.statManager().addRateData("tunnel.dropDangerousExplTunnelMessage", 1, type);

dr|z3d _log.error("Dropping dangerous message (" + msg + ") sent down Exploratory tunnel", new Exception("cause"));

dr|z3d return;

xeiaso In Java I2P, yes. Not in i2pd.

dr|z3d so I'm still having a hard time understanding where you think the exploit exists.

dr|z3d there's plenty of commentary in the code that suggests that malicious packets are anticipated and handled.

xeiaso There are plently of comments in the codebase that outdates and sometime outright wrong.

xeiaso *are outdated

dr|z3d well, you seem to have all the answers. where's the patch?

dr|z3d feel free to chime in here: git.idk.i2p/i2p-hackers/i2p.i2p/-/issues/397

dr|z3d obscuratus: a word of advice. resist the urge to use obscure acronyms in your logging output :)

dr|z3d IB == Inbound or inbound. what an IBDM is I'm not entirely sure, seems to mean different things in the space of 3 lines. Inbound Message Distributor? (IBMD?) or Inbound Data Message?

RN Internet Base Moves Data

RN ;)

dr|z3d :)

orignal same as with garlic, it will not be handled

orignal only eply

orignal *reply

orignal yes I see your point. I will check

end50 Hello, I wanted to ask should I have a seperate virtual machine just to self-host an I2P eepsite? or is it fine to run it locally on my host machine?

end50 Maybe this chat isn't the best place to ask about it, though.

RN hi end50

RN the details of your setup depend on your personal threat model

RN it is fine to run locally if that works for you.

RN remember, the more you overtake the plumbing, the easier it is to get plugged up

RN ;)

end50 Ah well i didn't mean to disconnect...

end50 Sometimes my I2P connection is a bit shoddy

end50 I may have missed what RN probably said.

RN the details of your setup depend on your personal threat model

RN it is fine to run locally if that works for you.

RN remember, the more you overtake the plumbing, the easier it is to get plugged up

RN (star trek quote ;) )

RN end50, try increasing your ping timeout in your client. Sometimes the client gives up when the tunnel is just lagging.

end50 That is what I'm trying to do right now.

RN :)

end50 Should be fixed now.

end50 I still wonder if I should take the extra mile of having a seperate virtual machine for an eepsite?

end50 I more want to know what are the risks and if it's really a bad idea in general lol

RN putting it in a vm sandboxes things which is often considered a good thing, but at the same time it also requires more careful configuration for good connectivity

RN is there a reason to do so? That only you can answer.

end50 It was just as I guessed then. I thought there would be something I'd overlook so I wanted to make sure.

RN it can make troubleshooting more difficult

end50 Thanks.

RN :)

end50 Yeah most likely, but I'm good with that.