IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/05/21
~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest2974
Leopold
Liorar_
Nausicaa_
Onn4l7h
StormyCloudInc
admin
anon
anontor
anu
cheddah
itsjustme_
limak
not_bob_afk
onon_
poriori_
qend-irc2p_
u5657
xeiaso orignal: Here's an interesting scenario. Send an unsolicited DatabaseSearchReply to a destination via a tunnel. It should flow through the i2pd code like this:
xeiaso TunnelEndpoint::HandleNextMessage Line 330
xeiaso i2p::HandleI2NPMessage Line 817
xeiaso NetDb::PostI2NPMsg -> m_Queue -> NetDb::Run Line 130
xeiaso NetDb::HandleDatabaseSearchReplyMsg Line 967
xeiaso NetDb::RequestDestination (direct = true by default) Line 731
xeiaso The code sends a DatabaseLookup directly to the floodfill specified in the DatabaseSearchReply. So if I send a bunch of DatabaseSearchReply packets with fake floodfill entries that are nearby to my real floodfill in the daily keyspace, I should observe lots of lookups coming directly from a single router. And then I know that router hosts that destination. Is this correct?
eyedeekay It sounds plausible, given some preparation and some luck
eyedeekay Xeha check git
eyedeekay orignal can you check^
xeiaso eyedeekay: where in git?
xeiaso oh wait you meant s/Xeha/orignal/
xeiaso weko: What exactly is the goal of the writeup? When I read it I'm not sure what it's aimed at solving.
weko In last discuss we said what we will prepare some thoughts about profiling
weko I can and will write more, if needed
xeiaso I can understand what is written, it's just that I don't understand the motivation.
xeiaso Take bad ping for example: why would we want to block routers with high ping? they should have no transit traffic through them because nobody would want a high ping tunnel. And even if someone decided to use them in a tunnel, how does that hurt us in any way?
weko xeiaso: yes I agree
weko I didn't describe about ban types
xeiaso I bring this up because buffer bloat can cause high ping, and we wouldn't want an adversary to weaponize the bans via that.
weko We need to make several test
weko tests
xeiaso We still have yet to see if tunnel spam is an actual issue. And for traffic speed throttling/limiting doesn't make sense if a tunnel is anonymous. We can't tie them to a single owner.
xeiaso Same thing with tunnel build messages. They can be sent not just via other routers but also via tunnels.
xeiaso I look at these thoughts and they seem like solutions to an ill-defined problem.
RN I believe that is weko's point. to better define the problems so they are dealt with the same by all implementations
RN and in ways that don't adversely impact legetimate traffic
weko [20:08:06] <xeiaso> Same thing with tunnel build messages. They can be sent not just via other routers but also via tunnels.
weko Yes it is. I knew it, but forgot for now. I have some idea, but I dont sure about security risks of this change...
weko Traffic limiting about another, not just about bans...
obscuratus weko's profiling write-up had me curious about what seemed like a simple question:
obscuratus What is the current Java "canon" I2P banlist/blocklist policy?
obscuratus I made a quick survey of the existing docs, but didn't run across an explicit policy.
obscuratus I started pawing through the code to see if a rough policy could be quickly thrown together.
obscuratus After scatching around for an hour or so, I came to the conclusion that documenting our current banlist/blocklist policy is more complex that I thought.
obscuratus It's like a house that has had a massive amount of rooms, additions, and renovations added on.
obscuratus There's stuff scattered around several spots, with varying degrees of documentation and explaination.
obscuratus It's going to be difficult to address a proposal like weko's until the existing policy is documented and summarized.
xeiaso it is indeed quite byzantine