IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2023/02/14
@eyedeekay
+R4SAS
+RN
+RN_
+Xeha
+orignal
FreeRider
Irc2PGuest22478
Irc2PGuest48042
Onn4l7h
Onn4|7h
T3s|4_
aargh3
acetone_
anon4
eyedeekay_bnc
not_bob_afk
profetikla
shiver_1
u5657
weko_
x74a6
weko zzz: did you change something?
weko Looks strange
weko zzz: I think you need decrease ban rate for TBM. On 10-15k transits, I have smaller TCSR, then on 7-9k
zzz weko, I'm always changing things, that's my job
weko zzz: i asked, for verify what it isnt some real changes
weko and also
weko <+weko> zzz: I think you need decrease ban rate for TBM. On 10-15k transits, I have smaller TCSR, then on 7-9k
zzz weko, stats remembers routers for 30 days, so sometimes the graph changes because of something that happened 30 days ago
zzz re: ban rate, please explain more
weko i think java routers ban my router when may transit tunnels
weko 5 sec ago I understood what it maybe by other reason
weko *many
zzz weko, upi dpmt
zzz weko, I'm not changing anything
zzz you don't understand
zzz your router is hurting the network
zzz drop tunnel spam
zzz do not pass spam through to other routers
weko <~zzz> your router is hurting the network
weko it is transit tunne;s
weko tunnels*
weko my router have maximum 200 tunnels
zzz right
weko why hurting then?
zzz but your router is allowing it
zzz stop the spam
zzz don't send it on to me
zzz the transit tunnels through you
zzz drop the tunnel build request
zzz don't send it on to me
zzz protect the network
weko but i want contribute the network... why i shoud drop
zzz because it's an attack. it's spam
weko okay you think it is because i dont verify spam?
zzz right
zzz if you accept every tunnel you hurt the network
zzz that's the problem
zzz so yes I'm dropping your build requests
weko have you confirmation about special tunnel spam? maybe some IPs?
zzz we count how many requests you are making
weko then why you think that this is not real tunnels
weko maybe you need decrease rate really
zzz because we have stats
zzz started december 19, remember?
weko yes
weko but since dec 19 count of routers increased
zzz so if you let spam through your router, then you are a spammer too
zzz and you get blocked
weko <~zzz> so if you let spam through your router, then you are a spammer too
weko yes i understand this
zzz be a "nice" router and your build requests will be accepted
weko but you need confitm what it is not real tunnel, maybe some spammer's IPs
weko or dicrease your rate
weko <+weko> but since dec 19 count of routers increased
weko + some routers have small limit of tunnels and it was reached
zzz you think you are helping the network by accepting everything, but you're wrong. It hurts the network
weko i say about other thing
zzz sure, attacker has a lot of routers
zzz doesn't matter
weko you think what big num of routers since dec 19 is attaker?
weko if it is, i understood what you mean
dr|z3d it's not difficult to differentiate between legit requests and spam. number of requests over a short duration is normally enough, weko.
weko dr|z3d: i understand it
weko but you said what you have not confirmation
zzz we aren't sure the tunnel spam is an attack, but the netdb spam is definitely an attack
zzz we don't have confirmation it's the same attacker but a good guess, don't you think?
weko yes netdb 100& attack
weko zzz: good, but for now tunnel spam dont really hurt network. we can allow such values in any case
weko the problem is, what we dont collect statistic about TBM count for everu router. need some diagram for be clear
weko we cant verify what routers since dec 19 is attacker's routers if rhis routers dont spam more then any normal router
weko maybe attacker, maybe real users.
zzz wrong weko
zzz it hurts the network quite a lot.
weko i dont have problem with 15k or even 20k transits
zzz I've done all I can to fix it on my side but I can't fix the whole network myself
weko sure
zzz so you fix your side
weko we need verify what fix is indeed
weko firstly
weko i understand what you say about detect attacker localy, i had same idea
weko but we need veridy first before setup limits
weko verify*
zzz right
zzz I spent the last two months working on it.
zzz so get to work
weko i can expain why number of tunnels not proportionally of number of new routers. in any case we need stat about TBM count per RI/IP. If we will see anomaly, we will be sure about attack and can setup limit. if not, we cant be sure in attack/no attack (maybe many routers spam like normal routers and maybre real users), but also can setup limit.
zzz do whatever you have to do to figure it out. We did all that two months ago
weko have you plot/diagram?
weko or just stats in plain text
weko okay
zzz it was discussions in #i2p-dev in december
weko <~zzz> it was discussions in #i2p-dev in december
weko i dont found it. in any case without stats we cant be sure in limit.
zzz weko tl;dr no peer in more than 3% of your tunnels (previous + next hop combined), with fixed min/max caps too
weko we should dont check next hop
weko or split check maybe
weko and also atacker can spam via tunnels (anomously)
weko like we build outbound tunnels via out inbound tunnels
weko our*
zzz weko, I can tell you what we do but you have to do your own design
zzz we have about 20 different checks and throttles before we accept a tunnel
zzz this throttle was added in June 2011
zzz all we did was make it more strict last month
zzz one line change
zzz most of our checks were implemented by jrandom in 2004-2005
dr|z3d the time for thinking more is good is gone. :)
weko if your checks is old, it is not mean what it is right
weko <+dr|z3d> the time for thinking more is good is gone. :)
weko sure)
weko and also
weko what you think?
weko <+weko> and also atacker can spam via tunnels (anomously)
weko <+weko> like we build outbound tunnels via out inbound tunnels
weko <+weko> our*
zzz yes weko. I'm just saying we have almost 20 years development time and experience in rejecting/dropping tunnel requests
zzz if you can do better, great
weko but only now we have real issue
weko <+weko> and also atacker can spam via tunnels (anomously)
weko <+weko> like we build outbound tunnels via our inbound tunnels
weko i know how we can implement protection. do you know?
zzz I'm happy with our current design and limits
zzz maybe needs some small adjustment, but we don't need any more ideas
weko your limits is useless, while attacker can spam via inbound tunnels
weko thought*
zzz it's working to block your router spam :)
zzz and the changes in our last release worked very well
zzz so don't tell me it's useless. I can see the stats
weko why attacker cant spam thought inbound tunnels&
zzz but if you have a better idea, go do it
zzz why is it working to stop your router then?
zzz you are the attacker
weko no))
weko because i didnt edit code
zzz if you let the attacker tunnels through, you are an attacker also
zzz I can't tell the difference and I don't care
weko tell me why i cant spam thought inbound tunnels with your limits
zzz tell me why my code isn't working
weko i dont meant working or not
weko i mean useless for attacker, because he can spam thought inbound tunnels
weko if we IBGW we dont know what owner spamming TBMs
weko but your code will ban us
zzz we have this throttle since 2012
zzz it's one of about 20 checks and throttles
zzz it doesn't have to be perfect by itself
zzz it's part of a system
zzz it's not designed to stop every attack
weko but we can change design, right?
weko i have idea how we can make protection
weko but you said what you dont need new ideas
dr|z3d I think what zzz is suggesting is that i2pd needs to implement some throttles and checks all of their own.
weko ofc
dr|z3d that's the best way to persuade him that there's some new defense strategy he hasn't thought of. implement it!
zzz weko, do it however you want, you think you have a better idea, great
zzz just stop spamming the network
weko not better idea; new idea
weko about new topic
weko <~zzz> just stop spamming the network
weko Client Tunnels: 156
zzz if new isn't better, why do it?
weko because this idea for prvent other type of attacks
zzz fine, have fun
weko TBMs spam thought inbound tunnels
zzz you are trying to fix theoretical problems. Fix the actual problems first
weko true
weko but i can suggest solution in any case
zzz I have 99 actual problems to work on first
weko i can add 100 :)
zzz maybe, after you fix your 99
weko we need to not encrypt TBMs when we send it thought tunnel (IBGW must see it, no any critical information there), then IBGW can limit it. Yes, it breaks backward compibality, but we can stop encrypting it now, and use it to stop potential attack in future.
weko this attack can be used for more easier deanon, if all routers will be with your limits
weko we can manipulate with bans => we can do more easier deanon
weko looks like more problematic issue
weko i agree what we can do solution for DoS after/during DoS, but we need prevent deanon attack before deanon attack
weko Example:
weko we want:
weko router A ban router B.
weko we build our tunnels, where B is IBGW. We spam thought this tunnels with TBMs on router A, and router A will ban router B because TBMs limit (source of TBMs for router A).
weko I guess you understand how ban manipulation can be used for deanon
dr|z3d you're preaching to the choir, weko :)
obscuratus What's a TBM?
obscuratus Tunne build message?
weko yes