#i2p-dev (irc2p) | 2.7.0-2 | Proposal 168 review Tues. Dec. 3, 8 PM UTC #ls2

eyedeekay Re: CCS proposal yes I think we could, re: domain sockets I was actually working on that one of those piles I mentioned but I was going to start with i2pcontrol because it seemed simpler

StormyCloud Its not much but I can donate 2XMR to the cause

dr|z3d StormyCloud: I don't think you need to, Monero are offering the bounties as I understand it.

zzz eyedeekay, here's a start, edit as you please stats.i2p/docs/monero-i2p-sam.md

zzz eche|off, eche|on, ping re: XMR

orignal zzz, if we receive completelky different SessionRequest and found out that we have a session with that router already what wqe do?

orignal SSU2

orignal looks like we see router multihoming in the netwrok

zzz orignal, what we do, same as ssu1: drop the old session, we assume we didn't get the disconnect for the old one

orignal so drop old one

orignal the problem is it seems they come from different routers with same I2P address

orignal e.g. multhoming

zzz like via tor or a vpn?

orignal not sure

zzz the reason code for the old session disconnect is 22 "replaced by new session" - see spec

orignal from different IPs

zzz there's some site you can check if it's tor, I think dr|z3d knows how to do it

orignal yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=

zzz how long is the old session idle for when the new one comes in?

orignal plenty of connections

orignal they are not idleing they are all active

orignal that's the problem

zzz active as in last second? last minute?

zzz how many IPs per hour or day?

orignal we didn't measure

orignal Vort saw 15 active session simulteniously

orignal I also saw like 10

zzz already caught him, took less than 2 minutes:

zzz 03/15 19:31:54.981 INFO [ handler 1/1] ter.transport.udp.UDPTransport: Peer already connected (PBID): old=85.0.223.58:27813 yQN8Qt IB2 recvAge: 3m sendAge: 3m sendAttemptAge: 3m sendACKAge: 3m lifetime: 3m RTT: 81 RTTdev: 54 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3835 acwin: 3835 SST: 2560 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 1 pkts rcvd OK/Dup: 2/0 pkts sent OK/Dup: 1/0 IBM: 0 OBQ: 0 OBL: 0

zzz weRelayToThemAs: 780851860 new=151.248.142.46:17022 yQN8Qt IB2 recvAge: 0ms sendAge: 54y sendAttemptAge: 0ms sendACKAge: 0ms lifetime: 0ms RTT: 32 RTTdev: 16 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3840 acwin: 3840 SST: 524288 FRTX? false consecFail: 0 msgs rcvd: 0 msgs sent: 0 pkts rcvd OK/Dup: 0/0 pkts sent OK/Dup: 0/0 IBM: 0 OBQ: 0 OBL: 0 weRelayToThemAs: 3634586576

zzz 03/15 19:31:54.981 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 85.0.223.58:27813 TO 151.248.142.46:17022

orignal Vort or that router?

orignal it didn't change IP because both are active

zzz that router. changed IP _and_ port

zzz and again 3 1/2 minutes later, to a THIRD IP:

zzz 03/15 19:35:34.300 INFO [ handler 1/1] ter.transport.udp.UDPTransport: Peer already connected (PBID): old=151.248.142.46:17022 yQN8Qt IB2 recvAge: 3m sendAge: 3m sendAttemptAge: 3m sendACKAge: 3m lifetime: 3m RTT: 75 RTTdev: 51 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3835 acwin: 3835 SST: 2560 FRTX? false consecFail: 0 msgs rcvd: 1 msgs sent: 1 pkts rcvd OK/Dup: 2/0 pkts sent OK/Dup: 1/0 IBM: 0 OBQ: 0 OBL: 0

zzz weRelayToThemAs: 3634586576 new=86.56.77.56:14517 yQN8Qt IB2 recvAge: 0ms sendAge: 54y sendAttemptAge: 0ms sendACKAge: 0ms lifetime: 0ms RTT: 0 RTTdev: 0 RTO: 1000 MTU: 1280 LMTU: 1500 cwin: 3840 acwin: 3840 SST: 524288 FRTX? false consecFail: 0 msgs rcvd: 0 msgs sent: 0 pkts rcvd OK/Dup: 0/0 pkts sent OK/Dup: 0/0 IBM: 0 OBQ: 0 OBL: 0

zzz 03/15 19:35:34.300 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 151.248.142.46:17022 TO 86.56.77.56:14517

orignal why do you think it changed rather than 3 different routers?

zzz I'm not saying either way

zzz look to see if same RI values like "i" and "s"

orignal I suspect that some moron cloned whole router

orignal wigh all keys

orignal maybe using docker

orignal so, what should we do with such "multihomed" routers

orignal ban?

zzz sure, why not

zzz but if you're allowing multiple sessions with same router you better fix that asap ))

orignal ofc, that's a bug in our code

orignal but what to do it general?

zzz so far the "i" and "s" values are not changing

zzz now up to 7 IPs in 10 minutes:

zzz 03/15 19:31:54.981 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 85.0.223.58:27813 TO 151.248.142.46:17022

zzz 03/15 19:35:34.300 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 151.248.142.46:17022 TO 86.56.77.56:14517

zzz 03/15 19:36:27.937 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 86.56.77.56:14517 TO 95.233.49.32:19209

zzz 03/15 19:37:00.439 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 95.233.49.32:19209 TO 2.201.145.207:21569

zzz 03/15 19:38:21.443 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 2.201.145.207:21569 TO 91.51.96.242:9233

zzz 03/15 19:42:39.284 INFO [ handler 1/1] ter.transport.udp.UDPTransport: [Hash: yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=] changed address FROM 91.51.96.242:9233 TO 104.158.233.108:22791

orignal why shoukd they change?

zzz if it was really different routers?

orignal why would they have dofferent s and i?

orignal if they are all clones

zzz well, if it's stored in the config I guess it wouldn't

orignal if it's i2pd that they cpoied whole .i2pd folder

orignal I store in ntcp2.keys and ssu2.keys files

zzz ok

orignal let's discuss how we should detect and ban such idiots

zzz if it is a botnet, it's the easiest one ever to ban ))

zzz if eyedeekay is up for it we can ban it today

zzz thanks for the heads up

zzz i do see him banned already on one router, not sure why

zzz maybe unreachable

zzz or peer test mismatch

zzz you could do any heuristic you wanted, if you want to spend the memory to count IP changes

zzz here's one where the "old" session was only 213ms old:

zzz 03/15 19:56:59.423 INFO [ handler 1/1] ter.transport.udp.UDPTransport: Peer already connected (PBID): old=69.206.152.24:23457 yQN8Qt IB2 recvAge: 96ms sendAge: 107ms sendAttemptAge: 89ms sendACKAge: 89ms lifetime: 213ms

orignal I don't think it's a botnet

orignal I think some idiot distributes a prebuilt docker image or packet

zzz well, count how many unique IPs

orignal Vort says there are few more

orignal routers

zzz MogB is a candidate, 3 IPs in 6 minutes

zzz what's vort's list?

zzz f~Uz 14 changes in 20 minutes

orignal <Vort> DtQsGzkbeR3nilr6ZvywR2O7-f0XaaV~YfHXohqwjgI=

orignal <Vort> F~UzS1mTN3XYlnOfidMBv5Z4lHI7dsCZ8N5mxpyc-OU=

zzz I recognize DtQs. It's an absolutely terrible terrible router. We banned it over a year ago!

orignal we don't have a ban list yet

zzz > 1 ip changes in last 50 minutes:

zzz 27 yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=]

zzz 17 F~UzS1mTN3XYlnOfidMBv5Z4lHI7dsCZ8N5mxpyc-OU=]

zzz 4 ~SN8k6Hid107ighTnxRSiwTwwPMjEpPbDEyEY--zD~U=]

zzz 3 MogB-V71uOsLBu5z9gW5sa3zzUfI5GD43selaYiOy4U=]

zzz 2 6NMfknVMawT~baK0VanEkbXvO2hJCLJ5rreieysRrNE=]

zzz DtQs not on the list because it's already banned

zzz sounds like you have some work to do )) Vort+++++ as usual

zzz orignal, if they are copying config, why do they all have different ports?

orignal because port is not in config

orignal they are all U, right?

dr|z3d identify tor relays here: metrics.torproject.org/rs.html

orignal U routers don't persist port

orignal unless it's specified in config

zzz ok

dr|z3d If you want to check an exit, you can also use check.torproject.org/torbulkexitlist if you're happy grepping for ips.

dr|z3d fwiw, MogB isn't using a Tor exit.

zzz I eyeballed a few for F~Uz and yQN8, didn't see any matches

zzz thanks

zzz new contender ~SN8

zzz here's the change counts after an hour:

zzz 42 yQN8Qt0K0yi89DrMaMa0LhHpQkxj2X3zS0SATe5QAXI=]

zzz 19 F~UzS1mTN3XYlnOfidMBv5Z4lHI7dsCZ8N5mxpyc-OU=]

zzz 8 ~SN8k6Hid107ighTnxRSiwTwwPMjEpPbDEyEY--zD~U=]

zzz 5 6NMfknVMawT~baK0VanEkbXvO2hJCLJ5rreieysRrNE=]

zzz 3 MogB-V71uOsLBu5z9gW5sa3zzUfI5GD43selaYiOy4U=]

zzz I'll let the logging run overnight and then holler at eyedeekay in the morning so we can drop the hammer

dr|z3d MogB was LR, orignal.

zzz I think MogB is now under whatever threshold I'd draw

dr|z3d was LR last I looked, now it's U. that's in the space of 5m.

orignal false positive I guess

dr|z3d was swiss, now italian.

dr|z3d so why don't we set a ceiling for ip changes within an hour or whatever and temp ban routers exceed the limit?

zzz because we'd need a data structure to store that

dr|z3d ok, is it worth the effort?

zzz not just effort but memory

zzz how many routers you see an hour? figure 200 bytes per

dr|z3d so we can't just tag the routerinfo with an additional field for the ip count/hr?

zzz we don't store internal data with the RI, it would get lost whenever we get a new RI, which is every time he connects to us

dr|z3d ok, thought that was probably a dumb idea.

dr|z3d so it would need to go in the profile then.

zzz not dumb, just not the way we do it. I believe i2pd does it that way

dr|z3d except I don't like the idea of using the profile, I'm pretty selective about what exactly I bother to profile.

zzz yup

zzz a stateless heuristic is better

zzz e.g. incoming && has old session && old session was incoming && ip different && port different && old session idle < 30 sec

zzz it's keeping long-lived stats that's expensive

dr|z3d yeah, so a window that's reasonable to things fairly tight sounds good.

dr|z3d as long as it manages to snag the offenders, obviously :)

dr|z3d words keep going missing when I type. there was a "keep" in the penultimate sentence when I thought it :)

zzz stateless isn't the right word, I mean based on current state, not requiring any stored history/stats

zzz because that reduces any mitigation to basically a one-liner

dr|z3d yeah, I got what you meant. in-memory, essentially.

zzz not just in-memory but zero-memory-added

zzz if you can make decisions based on what you already know, it's a thousand times simpler

dr|z3d ok

dr|z3d sounds like you got something cooking, in your mind at least :)

zzz not really. the problem with heuristics is you have to guess where to draw the line and tradeoff false positives and negatives

zzz barring new data, I'd just hammer yQN8 and F~Uz and call it a day

dr|z3d well, that's the simplest solution, but I suspect this isn't the last time we'll see this behavior.

dr|z3d the other way to deal with constantly cycling ips _without_ a heuristic is to prevent it on the offending routers.

dr|z3d do a count of ip changes on the router itself, and if it exceeds some ceiling, print a nice big critical class message to the logs and shut it down :)

dr|z3d "You have exceeded the maximum number of IP address changes permitted per hour, your router will now shutdown."

dr|z3d there's probably a selection of "issues" that could/should force an immediate shutdown, excessive clow skew being another.