IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2023/05/22
@eyedeekay
+R4SAS
+RN
+RN_
+Xeha
+orignal
FreeRider
Irc2PGuest22478
Irc2PGuest48042
Onn4l7h
Onn4|7h
T3s|4_
aargh3
acetone_
anon4
eyedeekay_bnc
not_bob_afk
profetikla
shiver_1
u5657
weko_
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?
eyedeekay Hi weko, obscuratus
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
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."
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.
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
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?
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
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.
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
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