IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2023/02/10
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+not_bob
+orignal
+weko
Irc2PGuest21083
Irc2PGuest86132
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon4
eyedeekay_bnc
hk
profetikla
shiver_
u5657
x74a6
zzz please explain question more
dr|z3d zzz: idea: sanity check for published RI caps.
dr|z3d anything there that doesn't meet the current specs gets the router banned.
zzz let him answer, the q was about clocks not caps
zzz or is this a differnt topic
zzz the specs allow unknown caps, we can't do protocol updates if we can't add things
zzz you're also chasing symptoms not causes
dr|z3d different topic.
dr|z3d doing a sanity check doesn't preclude adding caps to the protocol.. you'd just add to the permitted caps in the check.
zzz thats not backward compatible
dr|z3d valid point, so you'd limit the sanity check to the current router version or earlier to address that, allowing for newer routers with additional caps.
zzz still just a symptom not a cause, pointless. you're hunting down yesterday's quirks, not thinking about tomorrow's problems
dr|z3d not sure it's pointless, it's a low cost method to cut off future bogus caps being published. If it's been done once, no reason to suspect it won't be done again.
zzz no caps are bogus, they are to be ignored and we do, it's not a problem. Use your brainpower to think higher level, whats the next real problem
dr|z3d validating the ip in the routerinfo is good, so props for implementing that.
dr|z3d ok, moving on..
zzz that was orignal's idea, yes
zzz speaking of IPs
zzz this guy has exactly the scenario I proposed for the australian router - two IPs:
zzz both w/ upnp
dr|z3d ok, so I'm guessing the tun interface is a vpn.
zzz in java we have an undocumented config to force-ignore a particular upnp device so you would end up using the other
zzz but its so rare we never bothered documenting it or putting it in the ui
zzz and ofc we still don't support publishing multiple IPs
zzz so he wouldn't fare any better on java
dr|z3d should just be able to specify a single address. maybe all he needs is to disable UPnP and do that.
zzz might work
zzz multiple upnp is a real crapshoot because it's random who answers first
zzz plus now you got your rokus and chromecasts and TVs and windows boxes all answering too
dr|z3d yeah, he knows which address he wants the router listening on, so he should disable UPnP, manually specify the ip in the config, and away he goes. UPnP is obviously at fault here.
dr|z3d back to mitigations.. we know there are unresponsive floodfills out there, the ones recently had fake ip addresses so we've gone some way to mitigate that specific issue.
dr|z3d there may be ffs out there with valid ips explictly configured to drop requests, and since we're profiling ffs, what about a cutoff point of x # of failed responses where we ban the ff and/or remove the ff flag.
zzz I'm still classifying fake ips / fake routers as unconfirmed, never saw large numbers caught by that check
zzz unresponsive could just == quickly vanished
zzz I believe all that happens now in FloodfillPeerSelector but it's on my list to review it more closely
orignal did I miss something?
dr|z3d sorry orignal, we ate all the potato chips and drank all the beer.
dr|z3d but no, you didn't miss anything of consequence.
orignal I need an answr from zzz
orignal about worng clock on peer
zzz please explain question more orignal
orignal zzz wehn we connect to peer we check timestamp
orignal and if it's not good we close connection
orignal but what if peer's clock became wrong when connection is established
orignal basiaclly what happens now
orignal connection stays but it drops I2NP messages
orignal the question is
orignal if there a way to test if conntion is still good?
zzz hmm
zzz tunnel testing will eventually discover
orignal discover that a tunnel is dead
orignal but not peer
zzz yes but you use tunnel testing to "blame" peers
orignal but there are 3
zzz right, you "blame" each one 33% (and 33% for each peer in the reply tunnel)
zzz eventually a bad peer will have a lot of blame
zzz so you blame everybody 1/length %
zzz for inbound, we blame the IBGW more, because he's usually the problem
orignal "eventually"
orignal that;s the problem
orignal but we need it faster
orignal what happens peers got stuck quickly
orignal due to the attack
zzz it's not easy to detect quickly
zzz I think the solution is better peer selection in the first place
zzz which is the same fix as for the attack 6 days ago. Pick better peers for your tunnels.
orignal I though there is a btter way to send some dtatime block or similar
orignal or force peer to send datetime back
zzz we send datetime block every 256 SSU2 packets
zzz but we don't check for big skew change. We could, but have to be careful, it could be us that skewed
zzz in NTCP2 we send datetime every 22.5 - 45 minutes
zzz but there's no protocol to ask for a new datetime block
orignal thanks
orignal good to know
zzz if you don't do that you probably should
zzz but I recommend you focus on peer selection :)
orignal that's what hasppens with us we get skewed
zzz you're not updating your clock after you get a new datetime block are you?
orignal during peer test only
zzz then how do you "get skewed"?
orignal got incoorect datetime druing peer test
orignal and adjust my clock
zzz nooooooooo don't do that (((
orignal tell me
orignal right now I asked people to turn it off
zzz once you have connections, use the median clock skew of all peers as the "truth"
orignal well was going to but didn't do it
orignal clock skew from handshake?
zzz only adjust your clock from a single datetime block at startup, and even then, two peers is better
zzz yes, clock skew from handshake, or from later datetime block
orignal every 256 packets?
zzz or even better, just implement SNTP :)
orignal what is sntp?
zzz that's the way we do it now, 256 packets for SSU2, 22.5-45 minutes for NTCP2, but you could do it different
zzz simple NTP
zzz pool.ntp.org
zzz all of this peer time stuff is just backup for us if NTP doesn't work
zzz NTP has "stratums" like 1/2/3, lower is better
zzz we treat peer median time skew like stratum 12
zzz reseed HTTP time in header is like stratum 10
zzz don't believe crappy stratum if you have recent time from better stratum
orignal I have it
orignal but it's off by default
orignal ntp I mean
zzz easy fix then, turn that on by default and disable peer time setting if you have connections or NTP worked
zzz but I almost always run with NTP disabled so I can find any issues with startup and connection-median-skew
zzz sure, if attacker is half your connections, he will skew your clock; but if attacker is half your connections you probably have a lot of other problems
orignal attacker has a lot of nodes with wrong timestamps
zzz good peer selection fixes 0.99% of that
zzz good luck fixes 0.0099% of that
zzz what remains is just bad luck
orignal HidUser has an idea
orignal ntp over i2p
orignal it this case we will always have reliable source
zzz then you have to trust the source
zzz but sure, could be a backup
orignal stats, reg, notbob
orignal same players
orignal ofc configurable
zzz yeah I just wonder if that provides central point to crash the network if wrong or somebody turns evil
zzz but as a backup, might be ok
orignal yes, that's what I think. Just a backup
orignal I detect my clock skew and compare with one of this source
orignal and make a decision if my clokc is worng or I'm under attack
zzz but when you really really need NTP is at startup, so clearnet really the best
zzz we try in order:
zzz [0-2].(country).pool.ntp.org
zzz [0-2].(continent).pool.ntp.org
zzz [0-2].pool.ntp.org
orignal yes, that's another topic
orignal people complained that when they use ygg-only
orignal router stops working after few days
zzz so we'll try up to 9 servers if we have geoip, 3 if we don't
orignal because they don't think clokc and it's NTCP2
orignal so I mean we need to sync once a day
orignal we don't want to use NTP by default
orignal because it might lead to deanon
zzz everybody uses pool.ntp.org, I don't think it's an issue
zzz we also use DoH for DNS for it
orignal no the issue that someone even uses NTP
orignal epecially for windows and android
zzz pfft. every win/mac/linux box does it
orignal only unix system
zzz we sync every 90 minutes
zzz gotta run, back in a couple hours
orignal Transit Tunnels: 20001
orignal hit another limit
orignal guys one more side effect
orignal <polistern> your server try to connect to unrouted IPs
orignal polistern> 5-го числа было, в 20:00 по UTC примерно.
orignal that's when the attack started
orignal zzz, if you have questions to polistern you can ask
orignal because she has some metrics and stats
zzz I'm good, thanks
orignal no I mean more details
weko Again... 16k
zzz java routers hanging in there at 21% expl. build success
zzz same thing as last month or something different now?
dr|z3d ~40% build success here on various routers.
weko Maybe more often
orignal I don't see diference between december
orignal *with
orignal Transit Tunnels: 20400
orignal I have expanded limits
orignal Tunnel creation success rate: 19%
weko Tunnel creation success rate: 14%
weko Total tunnel creation success rate: 16%
weko Transit Tunnels: 17397
orignal fair enoght there
weko ntcp2/ssu2 2900/4100
obscuratus Do we have a way to discuss a possibly exploitable facet of something. I came across something I'm pretty sure is exploitable, and I don't want to publish the details in an open channel.