@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
no
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
np
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
zzz
ok
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.