#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

weko So, I will start adding themes. If I will miss discussion, then skip it or discuss without me.

weko 1. Protocol level profiling rules and recommendations (will we do or not, this is not about specific datails)

weko 2. i2pcontrol - I think we need version 2 with "supported methods" system. Some method will be global (same for every realization, and also realization specific methods).

eyedeekay Hi everyone

orignal hi

eyedeekay Sorry I got disconnected right at meeting time

eyedeekay Hi orignal

obscuratus Hi

eyedeekay Hi obscuratus

orignal I think 1. Post mortern

eyedeekay OK that can be 1

eyedeekay Unless we want to break it up into multiple sections, i.e. i2pd peer selection, I2P block/ban strategies, etc

eyedeekay I'm going to add I2P block/ban strategies as 2 and mysterious exploratory traffic as 3

eyedeekay Anything else?

eyedeekay OK 1 post-mortem

eyedeekay orignal this is your topic, please begin

obscuratus weko has some topics, if they're here.

orignal so we know so far that attacker poisoned the netwrok

orignal with non-existsing floodfills

orignal with IP addresses and properties from real flopdfiils

orignal and due to SSU2 weakness sometimes such fake routers were considred as real

eyedeekay OK I'll try and get us started

orignal yes

orignal that's were we are

eyedeekay my buffer was behind, sorry

weko hi

orignal now we don't accept a floodfill until we have a proof it's real

orignal otherwise we consider it as non-floodfills

weko i will send later

obscuratus Do you make an attempt to connect, or just wait to see if they've ever connected?

orignal also we aways try NTCP2 first for non-confrmede routers

orignal one of 3 think

orignal 1. we got tunnel reply code from it

orignal 2.if it connected to us as Alice

orignal 3. if we connected to it through NTCP2

orignal any of 3 means that a routers is real

weko looks like attack again right now

eyedeekay It's been pretty constant

orignal they have given up for couple days

weko yes

orignal although I don't see any issues on my routers

weko Tunnel creation success rate: 12%

weko was 19-20

weko 5-10 minutes later

eyedeekay for us those kinds of strategies are possible to implement in peer selection

not_bob I'm still having issues with mine, but they don't all have issues at the same time. Though, they tend to.

orignal it's bad idea

orignal you will never recoginze good routers this way

weko orignal: we dont see FFs cout grow because now we have protection

orignal tunnel creation rate is low but who care?

eyedeekay We had some other side-effects, banlists that grow to unreasonable size, and IP blocking having the effect of blocking floodfills, we need to tweak those strategies before the next release

eyedeekay I can go into the details of how our blocking and banning works but it's not really universal to all routers

weko everyone who want 3+ hops care

weko eyedeekay: one of my themes - profiling

weko ban strategies is part of it

orignal do you ban by IP?

not_bob Yes, I have a hard time building tunnels longer than 3 hops.

eyedeekay We block by IP, technically it's a different system and that's part of the problem

weko orignal: I think bans by IP is normal in several specific situation

eyedeekay IP blocklists last until restart where hash bans expire after a cumulative amount of time

orignal and you block IPs of real routers

orignal it's notmal when somebody is trying to ddos your port

eyedeekay Yeah it needs to be fixed, working on it here

weko but better dont ban IP if you dont know what are you doing

weko you need very good reason for IP ban

orignal I will add it

not_bob Yes, my java i2p servers need to bre restarted from time to time due to too many bans.

eyedeekay Yeah that's what it comes down to in Java right now, we're not applying the same level of specificity to IP bans as hash bans and that's a problem

not_bob s/bre/need/

eyedeekay IP *blocks

orignal basically if you see excessive number of failed connection attemtps you should ban by IP

eyedeekay We can tweak that to make it better though

weko we need to do on protocol level

weko recomendation and rules

weko to do iy*

weko it*

weko Protocol level profiling rules and recommendations (will we do or not, this is not about specific datails)

eyedeekay Yes codifying at least general strategies as parts of the relevant specifications should be added

weko so, we need discuss about good/bad router behavior etc

xeiaso orignal: what it those failed connection attempts are caused by the remote router trying to connect to fake RIs?

orignal they will not be excessive

orignal like few throusands a second

weko it will be 4:

weko i2pcontrol - I think we need version 2 with "supported methods" system (server send supported methods). Some method will be global (same for every realization, and also realization specific methods).

orignal I would start from 100/sec

eyedeekay weko OK that's topic 4, right? profiling mitigations?

weko oh

eyedeekay orignal I think we already have that as part of (yet another) system but I'll need to read to check

weko I think who want can prepare some thoughts about profiling

weko for next meeting

orignal we need to fix SSU2

orignal as you know

eyedeekay weko we should all think about profiling

weko yes

weko okay, 4 - i2pcontrol, 5 - SSU2 fix. okay?

weko 1 on next meeting - profiling

eyedeekay Yes about that, can you remind me of what proposals we have so far? SSU2 signature block I remember, and thusfar I've spent most of my time working on the implications of that for canon. What were some of the others?

orignal either signature block or just RouterIdent bllock

orignal like RouterInfo but 32 bytes only

eyedeekay What about handling for each of them, in the case of the signature in SessionCreated we just check the sig, and older routers will ignore the new block

eyedeekay but like I said I haven't looked at the RouterIdent idea, where does it go, and do you have an idea of the trade-offs?

orignal we must make it mandatory since some particular version

orignal and don't trust older version for floodfiils

orignal RouterIdent just breif version of RouterInfo that's all

weko ot trust with NTCP2

orignal no worth to send RouterInfo with SessionCreated

orignal might be SSU2-only router

eyedeekay OK we've spent almost an hour on 1 already, I don't want to rush us but we'll never get done if we don't move on

weko so. if has ident and it is correct - trust. in another case we do nothing

weko so. lets go on 3

eyedeekay Yes that's the basic idea

eyedeekay We can skip 2 because I skimmed our ban/block shortcomings unless there are more questions

eyedeekay 3 is more a "please investigate, we don't know what this is yet" thing

not_bob It is amazing that there are old routers still on the network.

eyedeekay It really is not_bob, it's amazing how old too

weko eyedeekay: so, is 3 about?

eyedeekay I get the 0.9.48 ones

eyedeekay but the 0.9.23 ones are a real mystery

orignal when do you plan to make a new release?

not_bob eyedeekay: Exactly.

RN (oops sorry)

weko <+not_bob> It is amazing that there are old routers still on the network.

weko any backward compability should have limits.

eyedeekay obscuratus first noticed this about 3 days ago IIRC, we've seen a significant increase in the traffic volume of exploratory tunnels, increasing from an average volume of 150KiB to 3MiB

eyedeekay NP RN, useful script

weko so we can set specific version for support

xeiaso speaking of backwards compatibility, is DeliveryStatusMessage ever sent to a destination these days?

eyedeekay I'm going to try and continue as many of the existing policies as possible in canon weko, that includes backward-compatibility until there is a truly shattering reason to do so

eyedeekay *to break it

orignal yes

orignal I do it for tunnel test

xeiaso ok

weko eyedeekay: how you detect exploratory tunnels? ot do you analisys locally?

obscuratus In retrospect, I think the increased exploratory traffic was a side-effect of the RI spam. Java-I2P had an increased flow of database lookup messages it was sending out over exploratory turnnels from the onslaught of fake RI.

eyedeekay This is from local analysis, it can be gleaned from the /tunnels page

eyedeekay Thanks obscuratus

weko next is 4

eyedeekay That begs the question I think, though, is there a way to safely control the flood of DatabaseLookupMessage on the attacked router?

xeiaso what is the attacked router in this situation? the spoofed one?

xeiaso s/spoofed/copied/

eyedeekay Interesting question, in the context of what I asked the one receiving the lookup messages

eyedeekay If there's nothing else on 3 then we can move on to 4, i2pcontrol

eyedeekay weko please begin

weko so

weko for now i2pcontrol protol look ugly

weko very small amount of available methods

obscuratus I'm not there yet, but I'd like to have a better idea of when were being more directly targeted, and when we just receiving everyone else's newly discovered fake RI.

obscuratus Oops, sorry, next topic...

weko we want to add very many methods for statistic and etc

weko I think better do "supported methods" system. we do hanshake, server return list of supported methods, and client will know what it can do

weko so, some method should be general for all realization

weko but for now, i2pd has realization-specific methods and it is normal

weko because some unique fueatues

weko so, with "supported methods" system it will works fine

weko And we can call it version 2. and then, we will not need new version in future, because we can add new method in suppored list.

weko somethink like this

eyedeekay Lost a bit of the scrollback when I disconnected but I caught most of it on my phone, weko let's get simpler, what kinds of things do you *want* from i2pcontrol, i.e. what methods are you looking for

weko we have plans to add very many methods

eyedeekay obscuratus no apology necessary, thanks for the information, let us know about your progress

weko for statistic

eyedeekay You should be able to query any of these already: geti2p.net/en/misc/ratestats

eyedeekay i2p-projekt.i2p/en/misc/ratestats

weko hmm

eyedeekay It's fairly extensive and quite poorly documented(at least that part is) so we could work on that

weko why this is not part of i2pcontrol?

eyedeekay It is, these are the "Stat" you pass in the json params when you use the RateStat method

weko hmm

weko I will think about it

eyedeekay Please do, we can pretty easily add more stats there, but a proposal to extend i2pcontrol is also an option if it needs to happen

eyedeekay Anything else on 4?

weko so, part of it anyway is realization specific

weko eyedeekay: okay for now I will think

eyedeekay realization- what do you mean by this, seems like a language barrier thing, would this be a synonym for implementation?

weko oh yes

eyedeekay as in I2P is an implemenation, I2P+ is an implementation, i2pd is an implementation, etc?

eyedeekay OK thanks for clarifying

weko ye

weko russian stuff lol

eyedeekay topics got a bit confused today, do we still have a 5 for this meeting?

not_bob I also have a proposal, whenever a good time for that is.

eyedeekay Now's as good a time as any, go ahead

not_bob Currently 3 hops is default for tunnels. It would be better if it was 3+1 random.

not_bob So, some tunnels are slightly longer sometimes.

not_bob i2pcp supports it out of the box.

not_bob lengthVariance

not_bob Feel free to tell me that I'm insane.

eyedeekay That's simple enough to change but would affect performance, is this related to the research divaexchange hosted?

not_bob eyedeekay: Yes, as the network stands most tunnels will be 3 hops, but sometimes they will be longer.

not_bob In my testing.

xeiaso not_bob: what's the argument for 4 hops sometimes vs just 3 hops?

not_bob I have spent quite a bit of time testing various tunnel lenghts, and adding random hops. And, you are right, it does not help performance. But, it might be worth the cost.

not_bob xeiaso: The argument is for not the same number of hops all the time.

not_bob Not for 4 per say.

eyedeekay xeiaso it is intended to make it more difficult for the attacker to know critical details about their position in a tunnel

not_bob It's likely an edge case.

eyedeekay We'll need to think about it

eyedeekay for people not familiar with what not_bob is referring to, please see: diva.exchange/en/privacy/research-results-as-video-i2p-de-anonymisation-and-diva

xeiaso eyedeekay: If 4 hops is only *sometimes*, say 20%, then the attacker could still guess that they are in a 3 hops tunnel correctly 80% of the time.

eyedeekay That is part of why we need to think about it

not_bob In my testing it's close to 20%, yes, with the option enabled. To get closer 50% you have to bump the number of random hops up.

eyedeekay We should table this for discussion again next meeting because I'll need to re-read some stuff to form a better opinion

xeiaso ok

not_bob It's not urgent.

xeiaso Is there any status change on issue 397?

eyedeekay Yes we've merged obscuratus's commit for improved handling in the IBMD(sorry about the abbrev but we've been here for a while)

xeiaso good

eyedeekay We were never able to produce an attack that worked but the opportunity was taken to make the code clearer and make it more difficult to attempt to game the system

eyedeekay Thanks very much obscuratus for helping with that

obscuratus Glad to help.

eyedeekay Anything else for the meeting today?

eyedeekay OK everybody thanks for coming and staying with us so long. next one will be in 2 weeks on Monday the 22nd

dr|z3d rumor has it there's meant to be a meeting here today, an hour and a half ago :)

not_bob Possibly.

Xeha dr|z3d: major.i2p/irc2p/ls2/2023/05/08

dr|z3d Xeha: ah, thanks, looks like I had an irc outage. my bad.