Opened 7 years ago
Last modified 3 years ago
#1055 assigned defect
Router-side incoming message dropping and blacklist for clients
Reported by: | zzz | Owned by: | zzz |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | router/general | Version: | 0.9.7.1 |
Keywords: | performance scalability anti-censorship | Cc: | |
Parent Tickets: | Sensitive: | no |
Description
Streaming has conn limits and will drop incoming conns, but the router may continue to get incoming messages and will do the garlic decryption and unwrapping, store the tags, store the leaseset, and return the small tag receipt.
Need a way for streaming or options to pass hashes to the router for dropping at that level. And cancelling the drops. All of this would be per-client-dest. There's also no per-session limit on tags or tagsets now? Also perhaps use the streaming "global" blacklist or equivalent.
I2CP defines a "report abuse" message but it is not fully implemented and does not contain a hash field.
Subtickets
Change History (6)
comment:3 Changed 7 years ago by
comment:4 Changed 7 years ago by
Other ideas to make this easier:
1) update global streaming blacklist via i2pcontrol plugin (could then be hooked in to fail2ban)
2) UI to update blacklist - where to put it? router internals tab I guess. Or i2ptunnel but that's not quite right either.
and 3) the router can't drop by desthash as it doesn't have visibility for that. But a new report-abuse-by-hash message could be sent to the router to save it in the config. And/or the router could distribute it out to all the other clients (otherwise only in-jvm clients would see it)
4) there's no way to have an external API to update a per-tunnel blacklist, is there? Even i2pcontrol can't get to it.
5) simplest API to update per-tunnel (or even router.config) is just to edit it wait for the router to reread. But i2ptunnel doesn't reread.
comment:5 Changed 6 years ago by
Keywords: | performance scalability added |
---|---|
Milestone: | 0.9.11 |
comment:6 Changed 6 years ago by
Keywords: | anti-censorship added |
---|
comment:7 Changed 5 years ago by
Status: | new → open |
---|
comment:8 Changed 3 years ago by
Owner: | set to zzz |
---|---|
Status: | open → assigned |
This will be a pain as the SKM does not know peer destinations. The router (I2CP and/or SKM) would have to keep a LRU map of message ID to session key.