#ls2 (irc2p) | #ls2 Proposal 168 review here 8 PM UTC Tues. Dec. 3

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

zzz no

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

weko ?*

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