~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cancername
+cumlord
+hk
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest19353
Irc2PGuest46029
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
acetone_
anon4
anu
boonst
enoxa
mareki2pb
mittwerk
not_bob_afk
plap
poriori_
shiver_
simprelay
solidx66
u5657_1
weko_
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.