@eyedeekay
&eche|on
&zzz
+R4SAS
+RN
+T3s|4
+acetone
+dr|z3d
+hottuna
+orignal
+postman
+weko
An0nm0n
Arch
FreefallHeavens
Hidenet
Irc2PGuest12643
Irc2PGuest19856
Irc2PGuest2827392
Irc2PGuest33877
Irc2PGuest95543
Leopold
Minogami
Onn4l7h
Onn4|7h
Palimpsest
ProRu
Sleepy
Soni
T3s|4_
Teeed
aargh3
admin
anon2
b3t4f4c3__
cheddah
eyedeekay_bnc
itsjustme
limak
not_bob_afk
profetikla
qend-irc2p
rapidash
tbqdrn
theglitch
w8rabbit
x74a6
zer0bitz
zzz
ping eyedeekay
eyedeekay
pong zzz, if it's about the news I am working on it
zzz
no, more generally
zzz
can we do some high-level coordination here?
zzz
details may need to be taken offline
zzz
but who's doing what and when
eyedeekay
Yeah OK
zzz
so what are you working on?
eyedeekay
I am doing a news, blog, forum update as we speak, with some difficulty but will be done soon
zzz
what about fixes?
eyedeekay
I am observing the effect on i2pgit.org for suggesting some mitigations for services hosted on floodfills
eyedeekay
I am also looking into how to exempt pre-contacted floodfills from IP checks in sybil tool
eyedeekay
Which may overlap with my understanding of 165.1
eyedeekay
I am not working in 165.2/3 or signed RIs yet
zzz
well
eyedeekay
Right now multihoming on a non-floodfill seems to be improving i2pgit.org's reachability
zzz
prop. 165 is nothing now but a bag of ideas and alternatives, and we have no ETA for a 2nd draft
zzz
options 2 and 3 are not specified fully and not currently implementable
zzz
option 1 isn't either, but we could fake our way through it
eyedeekay
\/RI/DSM/
eyedeekay
Yeah 1 is at least close to something orignal's already done sort of
eyedeekay
But 2/3 require more decision making
zzz
signed RI discussion is in saltr now, again, just the beginning of an idea
eyedeekay
Which one and more importantly why that particular solution
eyedeekay
Since roughly 5 have been floated so far
zzz
until there's a 2nd draft of prop 165 there's nothing to be done
zzz
the attacks touch a number of functional areas that may require fixes
zzz
let me first list them, from my notes:
zzz
- sybil
zzz
- ff peer selection
zzz
- tunnel peer selection
zzz
- ssu2 (prop 165)
zzz
- netdb clogging
zzz
- HFDSMJ
zzz
- NTCP2
zzz
- throttlers all over
zzz
- banning/blocking
zzz
eot
zzz
I have a suite of changes covering about 5 of the above
eyedeekay
That mostly agrees with what I am looking at but I didn't have NTCP2 on my list at all, and given the stalemate on 165 was focusing on block/ban mechanics and peer selection
zzz
you have fixes for any of that?
zzz
any particulars we need to coordinate on?
eyedeekay
Not ready yet but I am trying to tame the threat-point inflation in the sybil tool with a couple approaches, partly by capping the total penalty for same-IP threats and partly by applying a bonus for being precontacted
zzz
did you see what i said in saltr (yesterday?) about sybil IP checks can't be salvaged?
zzz
my conclusion is they can't be fixed, at least not short term
zzz
I can tune them for today's attack but not tomorrow's or the next day
zzz
but open to hear something different
dr|z3d
never got any feedback on my suggestion to assign a random family to every router if it's not already part of an existing family. nuts?
eyedeekay
I think that most of the stuff the sybil tool looks at is ambiguously meaningful, which is why it assigns threat points and bans at a threshold
eyedeekay
but the current problem with the IP checks is that it's super easy to inject a thousand threat points by putting out fake RI's on the same IP
eyedeekay
So what I'm trying to figure out is how to make sure that IP addresses are still meaningful to the sybil tool, but not so meaningful as to override all sense
eyedeekay
To me that seems like there could be either a "cap" on the same-IP penalty, or a "scale" of diminishing penalties
eyedeekay
Which is general
eyedeekay
"Not clones" isn't the same as "not sybil" so maybe the bonus scales to the same-IP penalty
zzz
yeah I went down that road too
zzz
sybil is by definition heuristic-based
zzz
so almost by definition it can be gamed / worked around
zzz
my thesis is that sybil was our downfall
zzz
our throttles and peer selections were actually working pretty well, and need only minor tweaks
eyedeekay
I can definitely agree with that, our most glaring and impactful problem for this attack is the attacker gaming the sybil tool
zzz
I have sybil code to check for same ip/port, and check for which one we actually talked to before, etc etc
zzz
not happy with any of it
zzz
longer-term, maybe, but I'm quite wary of any of it as a short-term fix
eyedeekay
So do we just disable it?
zzz
yeah, so my proposal is:
eyedeekay
There are some Redditors asking for threat point recommendations, I am tempted to tell them to do so
zzz
hold that thought
eyedeekay
Ok
zzz
1) disable all ip checks in sybil
zzz
2) one-time delete of the sybil blocklist on disk, as it's currently clogged with badness
zzz
3) package of minor tweaks to other subsystems listed above
zzz
4) cut that as a release relatively soon, don't wait for anything requiring a proposal
zzz
eot
zzz
alternative would be a more ambitious set of changes, possibly including proposals, on a longer schedule
dr|z3d
re 2), a button to remove all sybil bans would be handy.
eyedeekay
Let's start with your stated proposal
dr|z3d
re 4), if getting the release out as soon as possible is a consideration, maybe forego the formal release process and just push an update via the su3 servers.
zzz
for the redditors, disabling sybil and deleting the file and restarting is better than tweaking threat points
eyedeekay
That's what I'll relay to them
zzz
so how I suggest we proceed is:
zzz
- I check in 1) and 2), with a bump to -3, because I need a bump to know when to delete the file
zzz
- send you a WIP patch for 3) privately for you to review/test
zzz
that might put us on a path to get a release out in a couple weeks
zzz
FYI the file is ~/.i2p/sybil-analysis/blocklist-sybil.txt
zzz
the sybil page button is hidden behind advanced config but they can get to it with a direct link
eyedeekay
That plan works for me, 2.5.1 could happen second week of may if all goes well
orignal
so new release in may?
eyedeekay
Point release, 2.5.1 for us
eyedeekay
Not an API bump
zzz
I do not suggest putting sybil disable stuff in the news, just tell them to hang tight
orignal
then we will make 2.51.1 too
zzz
but keep working on sybil tweak ideas, maybe we'll come up with something
zzz
I'll share more of my concerns about sybil gaming privately
zzz
orignal, maybe. You have an ETA on a 2nd draft of prop. 165? That may factor into our plans
zzz
eyedeekay, you want a MR for 1) and 2) ?
eyedeekay
Yes please
zzz
ok I'll work on that
orignal
not sure
zzz
and then on cleaning up the collection of tweaks for 3), which I'll get to you privately with some explanations
zzz
email is pretty broken but I'll figure something out
zzz
if this plan holds, I'll want to push susimail search to tx for translation, but that can wait a few days
zzz
and the big-changes-in deadline would be over
zzz
ofc if there's no proposals implemented and no API bump, there's no need for release coordination between the two projects, go for it when ready
zzz
eyedeekay, please don't make any promises in news or on reddit, just say we're working on it
eyedeekay
I won't commit us to anything
not_bob
I'll poke RTP to post something on his social media when it's time to urge people to upgrade.