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
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
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
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.