IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/04/25
~dr|z3d
@RN
@StormyCloud
@T3s|4
@eyedeekay
@orignal
@zzz
%Liorar
+Hikari
+Minogami
+RTP
+Xeha
+acetone
+cumlord
+profetikla
+snex
+uop23ip
+weko
Arch
DeltaOreo
FreefallHeavens
Irc2PGuest35694
Irc2PGuest51258
Leopold
Nausicaa
Onn4l7h
Onn4|7h
anon1
anontor2
anu
itsjustme
j6
limak_
not_bob_afk
pihole
poriori_
qend-irc2p
u5657
dr|z3d personally i prefer double quotes, where single quotes get used when required (nesting etc).
zzz what is horrible
dr|z3d targeting the form like that.
dr|z3d give the forms ids, and target them that way. much better, then you won't need to change the index if the form order changes.
zzz look at the diff, it was form[0], now form[3], no change in "targeting" method
dr|z3d that's my point.
dr|z3d <form id="susisearch" or whatever, and getElementById.
dr|z3d and I didn't say change in the targeting method re diff, I said change in the index.
zzz ok, thaks for the review
dr|z3d giving the forms ids also helps with css, if required.
zzz it's not perfect yet, it's losing the search param when sorting or paging within search results, to be fixed soon hopefully
dr|z3d maybe store the param in localstorage and restore / delete as required?
dr|z3d or if you don't need session persistence, a cookie will do.
zzz it's one of those half-done where I thought it was working
zzz or it was working and broke
dr|z3d I know that one only too well :|
zzz I think it's not surviving the P-R-G, just have to track it down
orignal onon has inspired me an idea
orignal tell me what's wrong with it
orignal FF should accept only own RI from U routers
orignal and don't accept from R if IP doesn't match
zzz by "accept" you mean a database store?
orignal if we receive a DatabaseStore from R router we must check if it couldn't connect to us directly
zzz DatabaseStore of your own RI?
orignal by "accept" I mean we let databasestore go through otherwise drop it
zzz ofc you should never accept a databasestore of your own RI, from any router
orignal if I'm a floodfill I always accept DataseStore of link it came from
orignal not this
orignal I'm a floodfill, if I receive a DataseStore from session I check if it's DatasebaseStore of that router I accept
orignal if it's of someone else I check if session if with U router
orignal if U I drop
orignal if R I check if it was a reason to publish it through a tunnel
orignal if no reason I drop it too
orignal hat's the proposal
zzz so you mean store of a 3rd-party RI, not alice or bob
orignal that's what the atack is about
zzz you can't do that. It would break ssu2 peertest/relay, and break database stores in general
orignal and NEVER accept other floodfills through other
zzz stores can go out expl tunnels, but the OBGW sends it direct to ff, not through a ff tunnel
orignal please example why
zzz *OBEP
orignal but why they go thorugh expl tunnels rather than directly?
zzz ssu2 bob sends selected peer test RI back to alice
zzz there's no requirement that a store be direct
orignal it can of relay test Alice knows it was requested
orignal don't we have such requeirements about floodfiils?
orignal the requerements is simple
orignal "floodfill can be sent only directly or as flood from another floodfill"
orignal it can never come from OBEP
zzz that's not a requirement now
orignal then we should change it
zzz can't. backward compatibility
orignal floodfill coming from non-floodfill should be dropped
zzz it also would affect connection limits on floodfills.
orignal how often did it happen?
orignal I meant publishing floodfills nomn-directly
zzz else if (ctx.commSystem().isEstablished(h) ||
zzz (!ctx.commSystem().wasUnreachable(h) && _connectChecker.canConnect(_connectMask, peer)))
zzz sendDirect(msg, peer, expiration);
zzz else
zzz sendStoreThroughExploratory(msg, peer, expiration);
orignal how can floodfill not connect to another floodfills?
orignal by this change we will elimite the attack immediately
zzz you could maybe use it as a heuristic in times of overload
orignal that's what I'm going to do
orignal and once we receive a floodfill from another floodfill we can check distance
zzz so if another floodfill is sending, it's exempt from the checks?
orignal the rule is
orignal you can only accpet floodfill from another floodfill
orignal if floodfill doesn't come from direct connection with it (e.g. through flood) we check distance
orignal if too far we don't accept
zzz will think about it. I need to go look at that part of the code, was already on my todo list
zzz something like this?
zzz if (caps.indexOf(FloodfillNetworkDatabaseFacade.CAPABILITY_FLOODFILL) >= 0)
zzz pdrop *= 3;
zzz if (!key.equals(_fromHash))
zzz pdrop *= 3;
orignal we need to check if
orignal 1. we are a floodfill
orignal 2. DatabaseStore is floodfill
orignal 3. if it comes from that router directly
zzz yup
zzz no luck sending mail after midnight either
zzz I'm not sure our sybil IP checks are salvageable. As orignal points out it's a big part of our downfall.
zzz been working for days on improvements but I keep thinking of ways it can still be gamed
zzz depending on how much of a hurry we're in, the most expedient approach would be do simply disable them
zzz the dr|z3d solution of running sybil 24x more often would seem to make the problem 24x worse
snex and yet i2p+ seem to be the only people not having major issues
Irc2PGuest38694 snex: what major issues?
snex people keep coming into other chats saying stuff is totally unusable
Irc2PGuest38694 I switched back to vanilla because I was having tons of issues with i2p+ roughly 16 hours ago
snex myself and behemoth run i2p+ and have not seen any issues at all
Irc2PGuest38694 hmm the number of floodfills has crashedw
Irc2PGuest38694 snex: is there some sort of attack underway?
snex thats what they say
Irc2PGuest38694 earlier the network was completely unusable. I switched back to vanilla and things got better.
Irc2PGuest38694 now the number of floodfills has crashed
Irc2PGuest38694 reseeding helps a little
Irc2PGuest38694 it's the fucking russians
snex rUsSiA rUsSiA rUsSiA
Irc2PGuest38694 somebody managed to kill all the floodfills
Irc2PGuest38694 is that the basic idea
dr|z3d doesn't appear to be making the issue worse here, zzz, probably because on + sybil detection is the last line of defense.
dr|z3d XfU / 0.9.59 is mostly what's being detected here, which seems fine.
uop23ip "myself and behemoth run i2p+ and have not seen any issues at all" but you are still running i2p right? ;)
dr|z3d he's telling you he runs I2P+. it couldn't be clearer.
uop23ip :) i2p and no issues
dr|z3d if you haven't got any issues then you're probably running your own testnet :)
uop23ip had the attack gone so advanced ?
dr|z3d all routers have issues right now, it's a question of how much and whether or not the network still functions for you.
snex or maybe im the attacker! DUN DUN DUNNNNN
snex (im not pls no ban)
zzz I don't know how many fake XfU routers are out there but there's hundreds of real ones, if you're banning them you are harming the network imho. See yesterday's discussion
dr|z3d I beg to differ. XfU is crap.
dr|z3d If you're running a floodfill, the least you can do is be reachable. Otherwise, don't bother.
zzz then file a bug with i2pd and state your case, 99% of them are i2pd, but banning is not justified, they are no worse than e.g. PfU
zzz as the X is only advisary
dr|z3d XfU isn't routinely being banned, anyways, it's just that I've got my points threshold low.
zzz ok but XfU is not per se illegal or abuse or attack. If you feel otherwise you should work with i2pd to change/fix it, not whip out your banhammer
dr|z3d I'm pretty sure I've had the discussion with orignal before. Do not allow unreachable routers to be a floodfill. Discussion went nowhere iirc.
dr|z3d We could probably handle something similar in java-land, to prevent force-floodfill from allowing unreachable routers to be ff.
dr|z3d And if you want to talk about hurting the network, running an XfU router is arguably hurting the network more, if it's receiving lookups.
zzz you can choose or not to use it as a ff but to deny it from building tunnels is draconian
not_bob 153 recently dead sites, a rise from about 120 from yesterday.
dr|z3d maybe, zzz, but I'd rather err on the side of draconian than lenience while the network's under attack.
dr|z3d expect turbulence, not_bob. this is going to play out for a while.
not_bob Yes, understood.
uop23ip is the symmetry of the in/out bandwith of particpating traffic an health indicator? Usually i examined that is somewhat symmetric, besides latency of the connection of src or dst difference which of course comes into play. if dst is not there, get the package dropped? If this is massive, would i see that in an asymmetric bandwith use?
dr|z3d when the network's under attack, like now, asymmetric traffic isn't unusual.
uop23ip can't remember seeing this the last attack, but maybe i don't remember right or it is more massive now.
uop23ip when i saw it, i thought about unreachable fake routers. :) More down then up
snex i have always had more send than rcv
dr|z3d the opposite is usually true for an attack, more traffic in than your router wants to route, lots of traffic being rebuffed.
uop23ip are we talking about 10-20% or more difference, snex?
dr|z3d if you're seeding a bunch of active torrents, then outbound will normally be > inbound.
snex i guess my podcast is just that popular!
dr|z3d must be!
uop23ip no i stopped all but i2prouter
uop23ip Is the china no2 in my netdb of any importance regarding the attack. I ignored it for some days, but it seems to stay. I thought it wasn't that national specific with the toronto canada increase. But 98% of these are .58 with rest 0.61. The version first mentioned
dr|z3d you can but speculate. maybe yes, maybe no.
uop23ip is a higher partTraffic (around 50-100% over a low normal) ascribable to the attack? Are we real PR getting more load as usually? The other attack maxed out, this stays in the mentioned range.
orignal XfU is sign of an idiot
orignal that's all
orignal zzz, I have another idea for flood
orignal why doesn't flooding router add his own signature to database store?
snex how can i see my own cap flags? theyre not in /info
orignal in i2pd?
orignal Router Caps: PRE
snex i2p+
Minogami thats not in netdb local router ?
eyedeekay uop23ip the Toronto routers are fake, they're cloning a specific router located in Toronto in fake RI's to get it banned across the network, currently it has 4 participating tunnels
eyedeekay \/cloning a specific router/cloning a specific IP/
snex stupid hosers
eyedeekay There are probably some other targets with similar characteristics to that one
orignal eyedeekay they are cloning ALL floodfiils
orignal not only one in Toronto
eyedeekay no more focus then
eyedeekay There were several I identified by chasing down colocators
eyedeekay My hypothesis was anybody running in clearnet and I2P was the target a couple days ago
snex is it just a coincidence that this is happening at the same exact time US is banning tiktok and going after samourai wallet?
eyedeekay So I had found acetone, myself, several monero services, basically anybody bridging
not_bob_afk Long live tiktok!
snex apparently going after metamask too..
not_bob_afk But, I do not support the ban of that video sharing platform.
eyedeekay Found my office
not_bob_afk snex: The ETH wallet?
orignal eyedeekay do you understand how this attack work and why it's even possible?
eyedeekay Yes I do, it's very simple
eyedeekay We've discussed it several times last year
uop23ip orignal, is this one attack?
snex orignal: yes
orignal then what's your proposal?
orignal uop23ip yes it is attack
orignal bunch of fake routers with real IPs
eyedeekay You put real router IP's in fake RI's and blast them out to the network. Java bans them, i2pd sees them and has to figure out what to do with them
snex i dont understand why routers arent expected to prove their identity from the get-go?
eyedeekay But in doing so Java causes collateral damage by banning the real with the fakes
orignal Java bans not only them but all routers with this IP
orignal including real one
orignal so my last proposal to let flodfill accept new floodfills from other floodfills only
orignal if not direct flood flag must be set
orignal and I suggest to go futher and let flooding router add his signature
orignal hence an advasry wouldn't be able to mimic his shit to flood
eyedeekay I am 99% on board with prop165
orignal zzz suggested another idea
eyedeekay Hold up a sec my bouncer has these messages all repeated and out-of-order here
orignal to add one more MixHash with Bob's ident hash and set an additional flag
eyedeekay which flag? New flag?
orignal even in SessionRequest
orignal there is flag field in SSU2 header
orignal we introduce a flag saying that you must do one more MixHash round with Bob's ident
orignal for Poly1305 verification
orignal if the flag is presented
orignal Alice should check Bob's version and do it with newer versions
uop23ip sounds like modrna auto-immune attack - i hate you schwab
uop23ip rna = router network address
uop23ip the reaction is the goal
eyedeekay I see every reason to do something like that, what I am not seeing yet is the advantages or disadvantages of each approach. Whatever we choose, it seems 165.1 is required for backward compatibility
eyedeekay But I do not think it's a good idea to do that without a solution for new routers
eyedeekay My preference from a year ago was 165.3
eyedeekay Largrly due to being comparatively simple
dr|z3d snex: hit your router id link on /info
orignal let me clarify
orignal right now anybody can send DatabaseStore
orignal more improtant any DatabaseStore including fakes
orignal you don't have to have any relation with content of DatabaseStore
orignal I want to fix it
orignal router creating DatabaseStore must sign the content with his signgning key and attack it to the message
orignal in this case reciever can always verify this signature to see if it come from a router it;s supposed to come
orignal partcular case, if floodfill flood RI to another routers it signs with it's key
orignal receiver receives this message checks what connection it came from and verify signature against the public key of remote peer
orignal remeber, that a floodfill is required to flood directly
eyedeekay So this is only for floodfills. Please remind me about third-party RI stores in this situation?
not_bob_afk I like this idea.
orignal not only
orignal in gerenral for every router making DatabaseSetor msg
orignal *Store
orignal so, I'm as receiver would like to know if DataseStore came from expected source
eyedeekay So routers always sign their databasestore messages?
orignal rather than inserted by an advesary
orignal eyedeekay yes
orignal excpeting those who go through connections
orignal but if you send DatabaseStore through tunnel or flood third party RI you sign it
eyedeekay So you're signing their RI's with yours because the point is to verify the sender
orignal this proposal address not only current but any other furure attacks
dr|z3d verifiability, it's what I was getting at before.
dr|z3d albeit in not quite so well-formed a proposal.
orignal if I'm need to flood somthing I would like to tell that I relly did it
orignal see my logic
orignal I would like to limit unsolicited floodfill from floodfils only
dr|z3d sure, you want to add something to my netdb, I want validation before I do it.
orignal but I can't require them directly because flood
orignal and if adversary know it
orignal he will build all his tunnel with floodfills for OBEP
orignal and set flood flag
orignal pretending that his shit is just flood
dr|z3d we should also be verifying any RIs before we store them.
orignal temoprary solution is to check distance
orignal permanent solution is signature
orignal verifying with what?
dr|z3d RI has cloned IP, RI is fake. we can already detect fake RIs.
orignal yes, but do you know who is original?
dr|z3d only the valid RI can be communicated with on the published IP.
eyedeekay doing it before it hits the sybil detector would be useful maybe
orignal that's what I'm doing now
orignal but they are faster than I can verify this way
orignal while signature let you do it right a way
dr|z3d so, throttle.
dr|z3d at least for now.
dr|z3d (for unsolicited store requests)
orignal unsolicited DatabaseStore came through a connection. Verify the signature with pper's public key
orignal if failed drop it
orignal and it's easy to implement
orignal additional flag in "type" field
dr|z3d eyedeekay: useful definitely. if we can flag a router as valid before the sybil detector hits, then we can assign negative points to offset any clones, or just exclude it entirely from any ip-based points calculations.
eyedeekay I have no serious objections
orignal let's wait for zzz
eyedeekay dr|zed those were my thoughts on what to do with it
eyedeekay But at a certain point there are too many
dr|z3d yeah, that's why we exclude from ip-based calulations.
dr|z3d I mean, it might still be marked as a sybil for other reasons, but we can validate the ip at least.
dr|z3d might need certain conditions to be met first, like, is there only 1 valid RI that responds to the published ip.
eyedeekay Maybe once you know the real RI just ban every clone and be done with it
eyedeekay Probably not, then the 3 routers 1 IP guy gets screwed
dr|z3d yeah, you still want to validate the ip against the RI.
dr|z3d otherwise you're going to be hitting routers hosted on a single vpn ip etc.
dr|z3d EstablishmentManager is one place you can get in early.