#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

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 github.com/PurpleI2P/i2pd/issues/1868

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

zzz agreed stats.i2p/cgi-bin/avg.cgi?a=tunnel.participatingTunnels.60m&s=1&u=d

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.