@eyedeekay
+R4SAS
+RN
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest67564
Onn4l7h
T3s|4_
anon2
eyedeekay_bnc
goose2
goose2_
j6
not_bob_afk
profetikla
qend-irc2p
shiver_
u5657
unwr
x74a6
orignal
I might not attend the meeting today
eyedeekay
Ok. If you want I can reschedule it for later in the week
orignal
not sure
orignal
I'm just busy
eyedeekay
We do have weko's writeup on peer selection and ban/blocklist policy to go over, that's at least common to both projects
orignal
great
orignal
you can do it without me. I will re4ad later
eyedeekay
Meeting time, who all is here today?
weko
:)
obscuratus
hi
eyedeekay
Hi weko, obscuratus
xeiaso
hi
eyedeekay
Hi xeiaso
eyedeekay
OK so we're going to table SSU2 update proposals until next meeting because we kind of need orignal for that, still got a few things to talk about
eyedeekay
Call 1) formalizing peer selection and banlist recommendations and 2) bloom filter changes
eyedeekay
Any other topics for the meeting before we begin?
weko
Not for now
eyedeekay
OK let's start with 1
obscuratus
Update on release schedule?
eyedeekay
3) Release Schedule
eyedeekay
Thanks obscuratus
eyedeekay
1) weko has been nice enough to write up a document with a list of profiling recommendations
weko
But it is not full list.
eyedeekay
It's a start, I don't think any such list could aspire to total completeness
weko
We can and need continue and edit it
eyedeekay
Any given recommendation may apply differently to different implementations
weko
[18:36:38] <eyedeekay> It's a start, I don't think any such list could aspire to total completeness
weko
Yes
eyedeekay
Let's start by introducing the topic, would you prefer to introduce the topic or should I?
eyedeekay
Goals, etc
weko
I let you
xeiaso
And speaking of goals, it would be nice if it could describe the rational for the rules existing. For example, why tunnel spam is an issue.
xeiaso
the link expired too
weko
It was second link
weko
One sec
eyedeekay
OK so our goal here, materially, is to choose good routers better, balance the traffic across those routers better, and minimize or eliminate places where this adversely affects the network
weko
[18:39:10] <xeiaso> And speaking of goals, it would be nice if it could describe the rational for the rules existing. For example, why tunnel spam is an issue.
weko
I agree, TBM not actual problem.
weko
But traffic is actual
xeiaso
yes
eyedeekay
Tunnel spam is an issue because routers have finite resources and tunnel spam is an apparent attempt to exhaust those resources
eyedeekay
Traffic being the means by which they are exhausted
weko
eyedeekay: TBM for spammers requires ~equal power, how network spend on it
weko
Because attacker also need to do asymmetric encryption operation for every router in tunnel
xeiaso
tunnel traffic is symmetric per hop
xeiaso
TBM requires asymmetric
weko
xeiaso: yes. But usually we have many traffic packets, and every packet require operation.
weko
[18:45:34] <xeiaso> tunnel traffic is symmetric per hop
weko
[18:45:51] <xeiaso> TBM requires asymmetric
weko
Yes.
weko
Anyway, we can't limit TBM now
xeiaso
yes because they can be sent via tunnel themselves
eyedeekay
No as you say a smooth introduction is necessary
eyedeekay
weko speaking of tunnel spam, in 1.3.1 of the version I have saved you say "It is possible to identify intruders by counting the number of TBMs from different routers/IPs and find out which routers are being overly active in this regard."
orignal
hi
xeiaso
hi orignal
weko
[18:48:50] <xeiaso> yes because they can be sent via tunnel themselves
weko
Yes. And for now such defection, how I described, should not be released
eyedeekay
hi orignal
orignal
finally here
weko
eyedeekay: I was wrong about it
eyedeekay
Yeah it seemed like there were some potential problems with that strategy
weko
Yes, bad idea
weko
But zzz said what you have something like this
weko
Do you know?
xeiaso
dr|z3d once tried banning router based on tunnel build messages. It didn't go well.
obscuratus
zzz added throttles, right?
eyedeekay
Yeah it's not a statistical thing though it's like a throttle on the total and IIRC it adjusts based on some events but I'll need to look at the code to be sure of what
weko
So, for TBM detection we need to do a fact what we send TBM open for OBEP
weko
Then on OBEP we can limit it and it will work
xeiaso
not if it's garlic wrapped
weko
But I don't sure about risks
eyedeekay
Everything we do on this will need to be tested on testnet and in dev builds before we release it, we can suss out the consequences
weko
Ofc
weko
So, what about traffic spam?
weko
It is actual problem
weko
1) we can do good limit system
weko
2) we can ban "spam" routers (if we will find good strategy)
obscuratus
Per-tunnel bandwidth limits would be nice, but probably difficult to implement.
weko
We can do same what with TBM, but what for outbound tunnels?
weko
[18:58:56] <obscuratus> Per-tunnel bandwidth limits would be nice, but probably difficult to implement.
weko
Orignal said, what answer in garlic have space for it
eyedeekay
obscuratus we could do per-client, that would not be hard, but per-tunnel would be
weko
eyedeekay: per tunnel will be very better then per router
xeiaso
isn't the tunnel bandwidth limit in the caps?
eyedeekay
congestion caps allow us to ask other routers to back off, but presumably spammers would ignore them so we're back at 2 there
weko
[19:00:59] <xeiaso> isn't the tunnel bandwidth limit in the caps?
weko
No. In per-router specifying, we write limit for every transit tunnel on our router
weko
eyedeekay: for start solve 2, we should specify max traffic usage for 1 IP
weko
Or something like this
weko
I mean client tunnels usage, not transit
weko
10 mb/s? 1000 mb/s? Very different values. Maybe 0.1/mb/peer? How we want to define it
xeiaso
frankly it's odd that the cap the per-router limit because we test the cap via passing traffic
eyedeekay
I think I see what you're getting at, ok, for client tunnels it's actually more complicated than I thought but it can still be done
eyedeekay
We have part of a system for doing it already
weko
xeiaso: cap - very very approximate
eyedeekay
We mostly don't believe the cap until we check, very arguably we should just check instead
eyedeekay
very very arguably
eyedeekay
Topic for another time
MiXY
weko " eyedeekay: for start solve 2, we should specify max traffic usage for 1 IP ", ingnore if stupidly irrelevant but that would do away with "router families" right? Is that worth considering, do they matter? AGAIN IGNORE I'M A CHEMIST NOT A PROGRAMMER BUT SOMETIMES SIMPLE SHIT CAN SPARK IDEAS (now I will be silent unless spoken to)
xeiaso
router families are mostly not used
eyedeekay
No that shouldn't affect router families as I understand it MiXY
weko
And per-tunnel limit will help with profiling, and with connection (we can start downloads on max speed), etc
weko
So, ofc, violations of limit from transits (smaller speed or packet drops) should be detected with profilers, and it is not hard
xeiaso
RIs with a family are mostly stormycloud
eyedeekay
Yeah it's an underused system, not enough people onboard
weko
[19:08:24] <xeiaso> router families are mostly not used
weko
Routers families is useless shit and doing backward of its goal
eyedeekay
Well there's the thing with the multihoming of their ouproxy service which we use it for
eyedeekay
But that's also a topic for another time
xeiaso
isn't family in the RI and multihoming different things?
Hikari
does that really require a router family? can't you just load the same eepsite privkey on multiple boxes to get multi-homed routing like you can with Tor hidden services and the privkey?
weko
So, I guess we can do per-tunnel speed limit
not_bob
Multi-homing does note require a router family.
weko
+.
dr|z3d
no, eyedeekay's saying something different.
dr|z3d
he's saying that we use StormyCloud's family designation to ensure we don't blacklist his routers.
eyedeekay
I'll get you the details later, I was just reading it the other day but the details escape me, we specifically use StormyCloud's router family key for something
weko
Router families have another goal, but it doing backward of its goal, and can explain why, if needed.
eyedeekay
thanks dr| zed
dr|z3d
np :)
eyedeekay
weko should we make it 4)?
weko
eyedeekay: okay, let's will be 4
eyedeekay
OK
weko
Okay, let's return to topic
eyedeekay
So, we need to research: per-tunnel traffic measurement and/or limiting and how that should affect when we accept traffic, and when and by what means
weko
Transport and direct i2np pings limitations? Or we dont need it protocol level?
eyedeekay
Not ready to talk pings yet
weko
Okay. What you think about anonymity index idea?
weko
I don't know, have you this research or not, but there link: researchgate.net/profile/Mohsen-Guizani/publication/329007488_Deciding_Your_Own_Anonymity_User-Oriented_Node_Selection_in_I2P/links/61d7f7d0e669ee0f5c8db081/Deciding-Your-Own-Anonymity-User-Oriented-Node-Selection-in-I2P.pdf?origin=publication_detail
eyedeekay
I think it's an interesting proposal, but what are we using it for in the context of peer selection? It seems like it's an analytical feature which ultimately exposes a number of some meaning to the user, or am I misunderstanding?
eyedeekay
Thanks for the link, I will read it and get back to you
weko
It is for long time
obscuratus
We already have profileOrganizer.minFastPeers which lets us tune active peers.
eyedeekay
I believe I've read it before but probably need to refresh my memory
eyedeekay
Anything else on 1)?
xeiaso
"Biometric-based two-level secure access control for implantable medical devices during emergencies"
eyedeekay
2) bloom filter changes
xeiaso
what?
orignal
where?
xeiaso
Look at citation 29
eyedeekay
In the citations
eyedeekay
Wild
orignal
I don't use bloom filers at all
eyedeekay
Yeah this is Java-specific
weko
[19:25:21] <eyedeekay> I think it's an interesting proposal, but what are we using it for in the context of peer selection? It seems like it's an analytical feature which ultimately exposes a number of some meaning to the user, or am I misunderstanding?
weko
It numbered value of balance anonymity/quality.
weko
More routers for tunnels - better quality (we chose best routers), but less anonimity (because smaller amount of routers)
weko
For user it can be, for example, number from 0 to 1, where 0 - best quality, worst anonimity, and 1 - best anonimity, wosr quality
xeiaso
orignal: I guess you can't exploit code that doesn't exist.
orignal
lol
weko
Oh, I wrote it long time, sorry.
eyedeekay
No problem, thank you for explaining weko
eyedeekay
So it would be a value a user could adjust and build tunnels when they meet it
weko
eyedeekay: and maybe, even, set specific value for every tunnel/proxy/etc
eyedeekay
very interesting idea
xeiaso
of course the problem is nobody changes the defaults
weko
For example, for very secret proxy I want setup 1, for light clearnet walks - 0.25.
eyedeekay
xeiaso reported an interesting shortcoming of our bloom filter, which is that if you replayed a message with a messageID it would cause it to be dropped by anything that used the same filter, leaking information across contexts. We've got a patch out which addresses the basic issue that was reported, but it has also spurred review of every place where we pass a message through the bloom filter
xeiaso
> creating a point of evidence that a client and a transport were hosted on the same router.
xeiaso
> no way from the attackers POV to determine with certainty
xeiaso
They can sample as many points of evidence as they want, and use statistics to determine to a high certainty. I model that even if the chance of packet loss was 25% (and I don't think it's that high), the chance of receiving a reply back is 15% vs 56%.
eyedeekay
So it will take some time to test each and every possible place and how and when it affects the router
eyedeekay
Agreed, which is why we want to make sure we get the patch right
eyedeekay
As you and I discussed we have more cases to review
xeiaso
yes
weko
So, if orignal here, let's add SSU2 topic.
eyedeekay
We can make that 5)
MiXY
well you guys kick ass, this is way above my head (if they can send request to stop congesting already, idk why that can't be enumerated and used as the ban/refuse metric, like clearly someone who ingnores a dozen a day is more trouble then they are worth; but you guys have surely already considered something so simple.) i2p kicks ass and I appriciate all you guys do. [no reply please, I don't want to derail,
MiXY
just wanted to say thanxs and I rant uncontrollably!!!!!!!!!!!!!!!!!!!!!!!!!!!!]
xeiaso
I noticed the patch mentioned the local netdb, that isn't really relevant because they could collect >95% of netdb by running 10 nodes or something like that
xeiaso
the metrics guy did a paper on that
eyedeekay
Your point is well taken
eyedeekay
Which I guess brings us to 3) release timeline(I'm trying to speed this up)
orignal
eyedeekay so what's your [lan about SSU2?
orignal
good point about release
orignal
I'm going to make new release soon
weko
Let's go on according plan:)
eyedeekay
Yeah us as well, we have 2 tasks to complete before we can, we need to review the remaining cases where we pass a message through the bloom filter and we need to test those changes on the live net
eyedeekay
originally we had planned to do a release in mid-June, that puts it somewhere between 2-4 weeks from now
eyedeekay
Low end of that would be 2, I would need to freeze strings almost right away to do a proper release
xeiaso
freeze strings?
eyedeekay
For translations
eyedeekay
I could go as early as the 5th for a 2.3.0 release
eyedeekay
Earlier for a 2.2.2
eyedeekay
orignal, obscuratus, dr|zed any thoughts? Sooner, later?
dr|z3d
eyedeekay: why not settle on Mon 12th June. Plenty of breathing space between now and then :)
eyedeekay
That would make my time easier
dr|z3d
that fits in with the mid-June planning.
dr|z3d
well let's do that then, if everyone else is ok with the date..
eyedeekay
timeout 1m
weko
orignal:
eyedeekay
OK 12th it is
weko
Are we ready for 4?
eyedeekay
Yup fire away with 4) weko
weko
4) Goal of routers families - make more anonimity because some good owners will specify our routes in same family, and we will not use routers in same family in one tunnel.
weko
So, problem is what, that bad owners will not set family, and in this situation, better do tunnel with "family-routers", then with "no-family-routers". But we do backward of it. So, families doing backward of its goal.
weko
our routers*
dr|z3d
weko: if I got that right, you're proposing a router mode whereby you can specifically opt to use routers in designated families and prioritize their usage?
eyedeekay
Fair enough, but isn't it paradoxical? Don't you need to encourage router family use to even have enough potential router families to build a tunnel through without using same-family-owned routers?
weko
dr|z3d: I think we should not use families at all
eyedeekay
Also, and this may have been proposed before, what if you favor family routers for a specific hop? sort of like bridges?
eyedeekay
Right now the fact is that more-or-less, they aren't
eyedeekay
except for one or two specific things
eyedeekay
But if there's a better way to use the system then I'm open to considering it
orignal
what?
orignal
12 is fine
eyedeekay
family keys
eyedeekay
Thanks orignal ack on 12
weko
Hm. You mean something like "first hop - family A, second hop - family B, etc"?
obscuratus
I always thought one of the main uses for family keys was when someone had multiple routers at the same IP?
eyedeekay
Yeah obscuratus it is
weko
[19:57:38] <eyedeekay> Fair enough, but isn't it paradoxical? Don't you need to encourage router family use to even have enough potential router families to build a tunnel through without using same-family-owned routers?
weko
Sound paradoxical, but in really we should not.
eyedeekay
What those decisions are, on the other hand, can be adjusted based on evidence or need or whatever, or if it's intrinsically harmful phased out
eyedeekay
In general it's a way of saying "I own all these routers, let that inform your decisions about when to use them"
weko
Because, as I said, families doing backward . Owners, who ready to set family, dont want deanonimize, why then we can't use it?
eyedeekay
I see your point
obscuratus
Speaking only for myself... Because I don't trust them.
xeiaso
obscuratus: but do you trust them less then someone who wouldn't declare a family?
weko
[20:04:10] <eyedeekay> In general it's a way of saying "I own all these routers, let that inform your decisions about when to use them"
weko
Okay. How about write something about this in docs? Some warning
weko
[20:05:34] <obscuratus> Speaking only for myself... Because I don't trust them.
weko
Yes! We should use if how another routers (=ignore families)
eyedeekay
The family is just an identifier, the decisions we make based on it are what affect the outcome
xeiaso
isn't there a family penalty?
eyedeekay
I think we can consider it non-urgent for now, the existing system is barely used, but yes I will work on the details of how families work in the docs
eyedeekay
Warning and all
eyedeekay
Depends on which system xeiaso
eyedeekay
Unless anyone else has something on 4) I'd like to move on to 5)
weko
eyedeekay: question: java ignore families now?
eyedeekay
Not entirely, we use them in the sybil analysis tool and we exclude routers in the same family from being in the same tunnel
eyedeekay
But there are hardly any router families
MiXY
" eyedeekay> Fair enough, but isn't it paradoxical? Don't you need to encourage router family use to even have enough potential router families to build a tunnel through without using same-family-owned routers? " As a "normal" user I simply follow the wiki and news, I think many do likewise, if you explained how to join a dev's family and said it will help with pseudonimity I think you'd be surprised by the
MiXY
effect. [again, sorry if useless but this one actually seemes relevent, I am really not trying to disrupt and will gladly really stfu at anyones request]
weko
"we exclude routers in the same family from being in the same tunnel" maybe better to disable it
eyedeekay
I'll look into it, pretty sure there's already a config setting for it
weko
Then better to set default false for it. Anyway, it is on your hand
eyedeekay
1) add a signature block to the SessionCreated message which is signed by the static key of Bob
eyedeekay
2) Send the routerIdent... somewhere. I'm going over my notes and I don't think you ever told me where
eyedeekay
In either case, the goal is to authenticate Bob so he can't send spam
eyedeekay
orignal can you tell us more about the routerIdent proposal or should we table that for another time
eyedeekay
OK looks like we're running late and maybe lost orignal along the way, not a big deal, he's busy, we'll talk later
orignal
next time
eyedeekay
Oh there you are
orignal
I'm busy
eyedeekay
OK thanks orignal talk soon
eyedeekay
Thanks everybody for coming to yet another 2-hour long meeting, take care, see you around IRC