@eyedeekay
&zzz
+RN
+RN_
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+hagen
+hk
+mareki2p
+not_bob_afk
+postman
+qend-irc2p
+segfault
+weko
+wodencafe
Arch
BubbRubb
Daddy
Danny
DeltaOreo
FreefallHeavens
HowardPlayzOfAdmin1
Irc2PGuest53575
Irc2PGuest58427
Irc2PGuest61675
Irc2PGuest92548
Leopold
Onn4l7h
Onn4|7h
R4SAS
SigSegv
Sisyphus
Sleepy
SlippyJoe
T3s|4_
Teeed
ardu
b3t4f4c3___
bak83_
boonst
cumlord
dr4wd3
eyedeekay_bnc
guest7621
not_human
onon_1
orignal
poriori
profetikla
r3med1tz
shiver_
solidx66
thetia
thirtyseven
u5657
uop23ip
w8rabbit
x74a6
zzz
bigly update released yesterday, now over 1500 ffs
orignal
Floodfills: 1271
dr|z3d
I think I looked at the floodfill enrollment code a while back when postman said he wasn't seeing automatic, what did you do recently, zzz? not sure I caught that in the commits.
zzz
dr|z3d, the fix was in here:
zzz
commit 009630e2dd2c0706dfc3b3d1a386cd1ea7e7cc8c
zzz
Author: zzz <zzz@mail.i2p>
zzz
Date: Wed Apr 9 17:22:45 2025
zzz
NetDB: Maintain ff after restart when configured for auto
dr|z3d
ah, yeah, that one went under my radar I think. thanks.
zzz
the actual fix part was requiring SSU2 instead of SSU, which I discovered when trying to test that change, it all got wrapped into one checkin
dr|z3d
*thumbs up*
zzz
suggest you cross-ref our draft release notes just before releases to see if there's anything you may have missed
dr|z3d
ok
dr|z3d
I'm thinking we might want some checks on manual floodfill enablement.
dr|z3d
Remove the option entirely from the UI if the router doesn't make the grade.
dr|z3d
"This router currently doesn't meet the minimum requirements for floodfill enrollment."
zzz
in general we don't have checks for any manual config, yolo
orignal
however I don't see less load on my floodfills
dr|z3d
if a user really wants ff, and they're running a low bandwidth/firewalled router, they could manually configure it in router.config and override. at least that way the random tweakers don't just turn it on because it's there.
zzz
trying to protect random tweakers from themselves seems like a niche and losing battle
dr|z3d
we're not trying to protect them from themselves, we're trying to protect the network from them :)
dr|z3d
just ask orignal about random tweakers, he seems to think the monkeys are all over XfU without having the slightest idea what they're doing.
orignal
right
orignal
the follow advises from other mokeys
zzz
the botnets are the problem, not the monkeys
orignal
monkey are worse
orignal
they set X and tunnels fail
zzz
99% of the XfU's are botnets
zzz
botnets are also the reason you don't see less load on your ffs
orignal
zzz, I have a question about Bob's ident in stream SYN packet
orignal
can you refresh my memory why do we need to send it for rachets session?
orignal
you will get static key mismatch if connect to wrong dest
zzz
streaming protocol 21 years old, separate layer from ratchets, which is only 6 years old
orignal
this was a recent change
orignal
like 1-2 years ago
orignal
we put it into nacks
orignal
my question is if we can avoid it for a ratchets session
zzz
it's for replay prevention. See proposal 164 for background
orignal
sec
orignal
in your model Bob can't send this packet to Charlie prenending to be Alice
orignal
because Charlie must have Alice's LS before recieving this SYN
orignal
BOB can also store Alice's LS and send to Charlie but it will contain invalid static key
orignal
what did I miss?
orignal
hence if Charlie doesn't support crypto type 0 he is safe
zzz
bob replays the streaming packet, but over a new ratchet session to charlie
orignal
let's see. Assume I'm Charlie
orignal
I receive new SYN from Bob pretending from Alice
orignal
first I look for Alice LS locally
orignal
if not I close stream
orignal
say Bob also sent Alice's LS
orignal
I get Alice's LS extract static key and then compare with static key packet came from
orignal
and ooops
orignal
it doesn't match
zzz
scenario 1) we would lookup ALice LS remotely if not found locally
orignal
I don't do it
zzz
scenario 2) we would still store Alice LS locally
orignal
I alwyas assume it came in prevous block
orignal
if you do lookup remotely you have a vunerability
zzz
that's not very reliable. LS could have expired by the time you get it, or packet with LS could have been dropped
orignal
an advesary can flood you with new stream with non-estsing addresses
orignal
then bad luck
zzz
could happen anyway, static key could match but rest of dest is different, different hash in each packet
zzz
and we rate limit lookups
orignal
how can static key match?
orignal
Bob doesn't know private key
orignal
even if Bob sends NS with Alice's static key he can't agree key
zzz
true, key is in LS, not dest
orignal
static key is in static key section of NS
zzz
our remote LS lookup logic is deep down in the sender code. If we don't have LS locally, we defer and lookup remotely
zzz
same for all messages. datagram, streaming, in, out, whatever
zzz
and streaming knows nothing about ratchet, and ratchet knows nothing about streaming
orignal
even if you lookup and find Alice's real LS
orignal
it still contains Alice's static key
orignal
and Bob can't use it
orignal
if he uses Alice static key Charlie will not be able decrypt payload
orignal
because shared key will not match
zzz
what's your point? I'm getting a little lost
zzz
no, it's a bob-charlie ratchet session, decrypts fine
orignal
my point is
orignal
if I'm Charlie and receive SYN from a racthets session I don't need this check
orignal
bob-charlie session with Alice static key in NS?
zzz
no. Normal bob-charlie session, Bob LS, Bob static key in NS, payload is streaming SYN from Alice
orignal
but if I'm Charlie I see Bob's static key in a session this SYN came from
orignal
and if it's prentending to be Alice I will get static key mismatch
zzz
yeah but at ratchet layer you don't know it's a streaming SYN. At streaming layer you don't know it's a session from Bob
orignal
because I receive it from Bob's session but it says it's from Alice
orignal
ohhh I see
orignal
we think differently
zzz
and we don't drop payload on mismatch
orignal
because I do know racthet session on streaming level ))
orignal
forgot that you handle streaming on other side of I2CP
orignal
well do you think can I eliminate this check in my case?
zzz
I have no idea. This is why we're all standing by awating your proposal since you first mentioned it 3 months ago
orignal
that was about signature
orignal
but now I'm talking abolut 164
orignal
that's different model
zzz
same general topic "get rid of streaming stuff if it knows about ratchets"
orignal
right
orignal
because I'm busy in this stuff now
orignal
so thinking to remove this check
zzz
tracking about 10 things awaiting your proposals going back about two years at stats.i2p/docs/roadmap-2.10-zzz.html
orignal
huh?
orignal
which one?
orignal
if about signatures
orignal
we agreed that it's not possible with I2CP
zzz
don't think so. I said I didn't know how off the top of my head and it made my head hurt, but that doesn't mean impossible
orignal
you said that you didn't see a way to do it though I2CP
orignal
me either
zzz
yeah but I haven't thought about it much. And also things like datagrams and streaming pings have to be considered, it's not just about streaming SYNs
zzz
but everytime you have an idea I add it to the list with a date stamp, just in case
orignal
I have implemented it for sugnatures anyway
zzz
well, as usual, if you want anybody else to implement it or review it, you have to write it down and call a review. If you don't, then don't
orignal
well my question was about proposals 164 only
zzz
ok, I'll add it to the list
orignal
and you answered all my questions
orignal
based on what you have said I don't need this check for ratchets
orignal
if I compare static keys(that's what I do now)
zzz
ok
orignal
one more question
orignal
how are you going to lookup Alice's LS if she is a client?
orignal
you can only put this SYN packet on hold hoping LS will come later
zzz
ofc. The replay thing only makes sense in a p2p scenario where both sides are "servers"