#saltr (irc2p) | I2P+ 2.5.0-11+ >> 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 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

orignal yes

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 yes

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 Shit

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

dr|z3d yup

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.

eyedeekay Yeah

dr|z3d EstablishmentManager is one place you can get in early.