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
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."
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.