~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83
+cancername
+cumlord
+hk
+poriori
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over
acetone_
anon4
anu3
boonst
mareki2pb
not_bob_afk
plap
shiver_1
simprelay
solidx66
thetia
u5657
weko_
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