IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2023/05/08
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest5995
Irc2PGuest89954
Leopold_
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon2
eyedeekay_bnc
hk
not_bob_afk
profetikla
shiver_
u5657
x74a6
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
eyedeekay Sorry I got disconnected right at meeting time
eyedeekay Hi orignal
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 that's were we are
eyedeekay my buffer was behind, sorry
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?
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 cd /usr/home/user/.i2p/netDb && grep -a -R -o 'router.version=.*;' | cut -d';' -f 1 | cut -d':' -f 2 | sort | uniq -c | sort -rn
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 I do it for tunnel test
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 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
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 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
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)
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.
dr|z3d Xeha: ah, thanks, looks like I had an irc outage. my bad.