~dr|z3d
@RN
@T3s|4
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Unbur
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest2974
Irc2PGuest7233
Irc2PGuest91623
Leopold
Liorar_
Nausicaa
Onn4l7h
StormyCloudInc
admin
anon1
anontor2
anu
cheddah
itsjustme_
j6
limak
not_bob_afk
poriori
qend-irc2p_
u5657
orignal
obscuratus because we have a drwaback in Noise protocol
orignal
we never verify if we connect to the same Bob we are supposed to
orignal
so our new filter is in place now
obscuratus
orignal: Thanks
orignal
we did this analisys they just copy content of original routers as is
orignal
even with E caps
orignal
what we need to work with eyedeekay is protocol externsion
orignal
we need to include some blocks into SSU2 and NTCP2 handshake messages
dr|z3d
yeah, you're right about that. the only thing that differs is the router hash, orignal. I've seen my own ip spoofed in my own netdb.
orignal
Vort seeb his own 53 times
eyedeekay
I agree but I think we need to do both, ploink Bobs who don't match an already observed Alice's router hash and also modify the handshake to verify Bob
dr|z3d
There are also a huge number of RIs being seeded with fake ips by the look of things.
obscuratus
Yeah, that's another simple attack that plays to our sybil implementation. You don't even need to mimick a router, just plop a whole buch of random routers on the same IP.
orignal
<orignal_> real routers?
orignal
<orignal_> but nobody builds a tunnel trough routers with same IP
obscuratus
orignal: They don't need to be real routers. Sybil will ban them because too many RI entries with the same IP.
orignal
and again
orignal
you will ban real floodfills during this attack
orignal
see the weakness of your algorithm?
obscuratus
orignal: I see your point, but we need to have something to keep an adversary from setting up multiple real FF routers on a single IP.
orignal
you need to have a way to differentiate real and fake routers
orignal
that's all you need
obscuratus
Hhhhmmm, a different sybil penalty for FF we've actually contacted, and lower penalty (or none) for routers we've never heard from.
orignal
maybe my solution is not prefect but works well now
orignal
I consider router as real once it connects as Alice
orignal
in this case I can verify it's IP and also I verify RI signature in SessionConfirmed
orignal
and I assicuate this router hash with static key
orignal
and drop others with this static key
obscuratus
I'll confess my understanding of the crypto with respect to RI needs work, but we've got to find a way to make sure the Bob we contact is the Bob we intended to contract.
obscuratus
Then we can add Bobs we've contacted to that list also.
obscuratus
s/contract/contact/
orignal
yes, and this is the weakness of current protocol
orignal
you can't now
orignal
that's why I propose to send Bob's ident hash with SessionCreated
eyedeekay
Yes we need a way to do that but it's also a pretty significant change which will take time to carry out correctly IMO. Having a good way to identify the attacker's RI's without collateral damage is something we can do in the meantime
orignal
eyedeekay no, it's just an aextyra block that wouldn't break the protocol
eyedeekay
I'm not saying no, I'm just saying I have to consider certain aspects of such a change in light of what canon I2P has to do re: backward-compatibility, time to think about it is all I need
orignal
please look at PeerTest message
orignal
good example that it has signature of all parties
orignal
I would introduce an addition block type "signature"
eyedeekay
I will, actually I already started looking at it
orignal
we need something similar to what we had in SSU1
not_bob
I think this is a good solutin. A way to test if the host really is the host it says it is.
not_bob
Is there a way to ask the host a question with the current way it works? So we have backwards compatablity?
orignal
well routers send update routerinfos through sessions
orignal
but it you receive routerinfo nobody guarantees it must be peer's
orignal
plus it's not fast
orignal
as I remeber once in 20 minutes or so
not_bob
That's too slow.
orignal
ofc you can always send DatabaseLookup with your peer's ident
orignal
but even if you get a reposponse it doesn't mean it's peer's RI
not_bob
True, would that validate the router?
not_bob
Hmm
orignal
we deinitly need to send it with SessionCreated like we didn in SSU1
RN
what about if the peer has changed IP address?
orignal
depends on if it's SSU2 or NTCP23
snowflakes
hewwo guys. anyone have a waves in stacking? (leasing) antebeot.i2p/wavesnode/wavesnode
RN
you what now?
RN
that link is screwy
xeiaso
it's better to give the b32 in case people don't have your site in their addressbook
RN
I'm also curious about the duble /wavesnode/
not_bob
i2pd is working better now that it had been.
not_bob
But, still nowhere near normal.
not_bob
i2pd tunnel builds are now closer to 20% on average.
not_bob
I2P+ is doing better, but not by much.
not_bob
40-50% currently. Much more usable.
orignal
the network is still full or shit
RN
more attacks, or leftover garbage in netdb?
mesh
RN: something's going on it seems
obscuratus
Everything looks pretty normal on my raouter. What are you guys seeing?
RN
Canon: 65% I2P+ 42%
mesh
obscuratus: bandwidth spikes combined with something else
obscuratus
mesh: OK, thanks.
RN
there was an increase in peerFailedLookupRate some hours ago, but looking normal now
not_bob
Still shit here.
not_bob
Somewhat usable, but not good.
RN
Canon down to 36% and i2p+ 12%
RN
banned around 2k and 1.7k
RN
(I reset at some point yesterday)
dr|z3d
not quite as bad as it was, but not cleansed of the crap fo' sure.
RN
so, restarting clears most of the bans, but doesn't clean the netdb, right?