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

zzz thanks for the reminder

zzz will explain in the morning

dr|z3d another unreachable X tier router with a ridiculous amount of introducers and what's being reported as a forged RI: cake.i2p/view/RoiEyx5Fgu_UDJeSKyZqX0rMmCizDKqxAT0haYF6N_AAoiaRwM7Y/RoiEyx5Fgu.txt

orignal but 0.9.56

orignal I thought I see it in new release

orignal *you

orignal I will investigate what might cause 12 interoducers

orignal also 12 looks suspisious, not more not less

orignal I'm wodnering if somebody just changed this constatnt in the code

orignal const size_t SSU2_MAX_NUM_INTRODUCERS = 3;

dr|z3d yeah, someone's tweaked that variable it looks like, and it maybe distributing a modified binary.

dr|z3d *is

dr|z3d If Opicaak is around on ilita, maybe ask him if he's tweaked the code?

zzz so

zzz code 10

zzz jrandom stuff

zzz for starters

zzz not sure it's a good idea

zzz not sure if java has implemented it well

zzz not sure if i2pd should do it

zzz two parts:

zzz 1) when to send 10

zzz 2) what to do if you get a 10

zzz part 1:

zzz we keep avg. number of part. tunnels in 10 minute buckets

zzz and we have a "growth factor" of 1.3.

zzz try to prevent rapid increase, by limiting tunnels to no more than 30% more in current bucket than last bucket

zzz so let p = avg. tunnel count in last bucket

zzz let c = current tunnel count

zzz if (c > 1.3 * p) {

zzz let accept_percent = 100 * ((p * 1.3 / c) ** 2)

zzz let r = random(100)

zzz if (r < accept_percent) then reject code 10 // "probabalistic reject"

zzz }

zzz end part 1

zzz part 2:

zzz ** correction: if (r > accept_percent)

zzz part 2:

zzz the goal is, if we got a code 10 in the last 5 minutes, then downgrade the peer in the profile so we won't send it tunnels

zzz but we only rerun our profiling every 6 minutes

zzz so we might catch it or might not

zzz end part 2

zzz re: introducers and Opicaak, I don't think he's capable of code mods, he's a packager at best

zzz but I suspect the huge RI is overrunning some i2pd buffer, so the sig fails

zzz orignal, please look into bombing-out if the local RI is too big, don't send it out to others

dr|z3d I've tweaked the part tunnel growth factor. For "standard" routers, it'll kick in at 2500 part tunnels, limiting growth to 1.2

dr|z3d re introducers, i2pd and java could probably use a hard limit of 3.

dr|z3d ie if someone thinks it's a good idea to tweak the max introducers variable, subsequent checks prune them.

zzz we only look for 3

dr|z3d my theory is that someone somewhere has determined that their firewalled routers need more introducers for more speed, so instead of fixing their firewall/NAT issue, they've decided to bump up the introducers instead.

zzz I don't really care why, but i2pd should catch it sooner

orignal what does "too big" mean?

orignal guys i2pd publishes not more than 3

zzz overruns your buffer? 3172? or requires too many fragments in SSU2 session confirmed?

orignal 3 introducers

orignal my max buffer size is 3K

zzz right

orignal I suspect signature is not sent

orignal that's why

zzz but if it's too many SSU2 fragments, die, don't even try

orignal so, don't send RI exceeing 3K, right?

orignal I don't send more than 2 fragments

orignal in SessionConfirmed

orignal I even don't have an ability for it

zzz we will send up to 15 I think. If you only support 2, then throw a fatal error, don't send it

orignal ofc I don't

orignal I just drop session

orignal however DatabaseStore is no limited

orignal well probably to 128 fragments I don''t remeber

zzz proto is 4 bits

orignal maybe

zzz maybe it's Databse store, not SSU2, but either way, don't send out garbage

orignal anyway I will check if creation of my RI failes

orignal that's what I meant

orignal code 10

orignal I see it a lot

zzz that way, i2pd will explode, instead of dr|z3d sending me log errors

orignal I never send it, so Java does

orignal yes, I know

orignal and we arte going to relese 2.45.1 next weeks

orignal *week

zzz ok

orignal because there is another bug with crash on termination

orignal causes homebrew's tests fail

zzz yeah I saw that on ilita

zzz you figure it out yet?

orignal fixed

zzz super

orignal about introducers

orignal what is the max number you can see in RI?

orignal I mean if 12 introducers is valid

zzz in mine? in my netdb? in the one drz posted?

orignal no, in protocol

zzz we only look at 3. We send up to 4, because the 3rd one may have two IPs

orignal can somebody intenionally use 12?

orignal is it allowed orr not?

zzz spec is 3? or it doesn't say

orignal I check only last digit of "i" properties

orignal no it doesn't

orignal that's why I'm asking if 12 is valid

zzz well, RI spec says you can put whatever you want in there, it's just key=value

orignal failed signature is another problem

zzz so anything is "valid"

orignal how about 100?

orignal so the only wrong thing with that RI is signature

orignal maybe we should limit to 10 in specs?

orignal or 16

zzz only limit is ~64KB I2NP max message size

zzz implementations may ofc impose lower limits

zzz not sure what good that does if somebody is hacking your source code

zzz they don't care what the specs say

orignal but we can check it on receiver side

orignal if we see more than 10 introducers we consider such RIU as maflromed

zzz I'm not going to check for itag999=foo and throw it out, waste of time, it's just another undefined option

zzz no different than yourmom=foo

dr|z3d maybe mod the spec to say max 3, and post something on zzz.i2p so whoever's doing the source hacks gets the message?

dr|z3d orignal can post on 333.i2p just in case it's a russian developer.

zzz please don't ask me to chase down i2pd hackers

dr|z3d ok, disregard the above. :)

dr|z3d orignal: chase down the i2pd hackers!

orignal so 0-9 only?

orignal I will fix to not publish more than 9

zzz spec says 0-2. java only looks at 0-2. java only publishes 0-3.

orignal what if somebody modifies the code

orignal say in I2P++

zzz if you want to publish 0-9, that's fine

zzz dr|z3d, let's be clear

zzz as the network, esp. i2pd, expands rapidly -

zzz my ability to stop or prevent network explosions or abuse is quickly vanishing

zzz either via my code or my communications

dr|z3d if a router's sending a malformed RI, I'm now banning it for the session.

orignal malforumed RI is one thing

orignal many introducers is another thing

dr|z3d we're clear, zzz. the best you can do is publish the occasional advisory when apt.

dr|z3d too many introducers == malformed RI.

orignal that;s my originnal question what "too many introducers" mean'

dr|z3d that said, zzz, I think collectively we've all done pretty well in putting out the latest fires.

dr|z3d <zzz> spec says 0-2. java only looks at 0-2. java only publishes 0-3.

dr|z3d 3, in other words, original.

dr|z3d should be the hard limit.

dr|z3d *orignal

orignal fine if more then 3 just ignore tham

zzz that's my recommendation, yes

dr|z3d maybe add a comment to the max limit to dissuade hackers from modifying the value, origs

zzz dr|z3d, re: banning, if you want, but if you ban on bad sig then an attacker can ban anybody, so I don't recommend that, and canon will not do that

zzz we never ban or block until sig is verified

dr|z3d_ ok, zzz, fair point, short term ban then?

zzz we may already throw it in the short-term ip blocker in ssu2, dunno

dr|z3d_ and not banning on bad sig per se, banning on invalid RI.

zzz banning the router hash for any time sounds wrong

zzz but you do you

dr|z3d shouldn't make much difference, if the RI's invalid, it's effectively banned if not explicitly.

dr|z3d if (!routerInfo.isValid()) {

dr|z3d // throws UnsupportedCryptoException

dr|z3d processStoreFailure(key, routerInfo);

dr|z3d if (_log.shouldWarn())

dr|z3d //_log.warn("Invalid RouterInfo signature detected for [" + routerInfo.toBase64().substring(0,6) + "] -> Malformed RouterInfo");

dr|z3d _log.warn("Banning [" + routerInfo.toBase64().substring(0,6) + "] for duration of session -> Malformed RouterInfo");

dr|z3d _context.banlist().banlistRouter(key, " ➜ Malformed RouterInfo", null, null, _context.clock().now() + Banlist.BANLIST_DURATION_FOREVER);

dr|z3d return "Invalid RouterInfo signature";

dr|z3d }

zzz dr|z3d, see SSU2 IES2.gotRI() comments on when we can ban. Via SSU2, the store() is after the static key verify, so you're safe. But if you ban in store(), you don't have that protection

zzz because it could come in via DSM or NTCP2

zzz so if you ban in KNDF.store() an attacker could rapidly send you 10000 spoofed RIs from afar and kill you

dr|z3d ok, thanks, will rectify.

zzz "you do you" is great and all but let's not be injecting vulnerabilities into our outproxies

zzz who are uniquely vulnerable because their IPs and router hashes are known

dr|z3d well, according to your logic, the vuln already exists in KNDF.

dr|z3d what's to stop an attacker from afar sending 1000s of RI's with the wrong network id and killing your router?

dr|z3d if (id != _networkID) {

dr|z3d if (id == -1) {

dr|z3d // old i2pd bug, possibly at startup, don't ban forever

dr|z3d _context.banlist().banlistRouter(key, " ➜ No network specified", null, null, _context.clock().now() + Banlist.BANLIST_DURATION_NO_NETWORK);

dr|z3d } else {

dr|z3d _context.banlist().banlistRouterForever(key, " ➜ " + "Not in our network: " + id);

dr|z3d }

dr|z3d if (_log.shouldWarn())

dr|z3d _log.warn("BAD Network detected for [" + routerInfo.toBase64().substring(0,6) + "]");

dr|z3d return "Not in our network";

dr|z3d }

zzz is that before sig check?

dr|z3d straight after my malformed RI ban.

dr|z3d this block: private String validate(Hash key, RouterInfo routerInfo) throws IllegalArgumentException {

zzz is the id ban before or after the sig check ?

dr|z3d pass, it's earlier in the source, but I'm not sure how the pipeline's processing stuff.

dr|z3d let me hand you a reference to your source, 1 sec.

zzz RI.isValid() checks the sig, ID ban is after, it's fine

dr|z3d that's kinda what I figured, in which case banning for an invalid/malformed RI should be fine, too.

zzz no, because the reason it was invalid was the sig check failed

dr|z3d ok

orignal if (len > m_Buffer->size ()) len = m_Buffer->size ();

orignal that's how I shrink

orignal long RI

orignal dr|z3d do you know actual size of that RI?

orignal it doesn't seem it exceeds 3K

orignal because I check it

dr|z3d you got all I have, orignal

orignal do you have actual routerinfo file?

dr|z3d no, it doesn't get written to disk if it's invalid.

orignal I thought it was huge

orignal thet's why zzz asked me to limit RI size

zzz itag+ih+iexp ~= 100 bytes, there were two addrs, one with 12 and one with 11 introducers, so 23 * 100 is 2300 bytes extra

zzz so I think that would push you over 3072

orignal acccording to my code no, it would be created

orignal if (len + signatureLen < MAX_RI_BUFFER_SIZE)

orignal I saw only one address with 12 introducers

orignal ipv6 was with real address

zzz still got the pastebin link drz?

orignal I mean last one

dr|z3d cake links are dead, but I still have the log entries here, let me paste them both into one url.

orignal however they might also change max RI size

dr|z3d oh, maybe cake link's not yet dead, the last one. if you need the earlier one, let me know, I'll repost. cake.i2p/view/RoiEyx5Fgu_UDJeSKyZqX0rMmCizDKqxAT0haYF6N_AAoiaRwM7Y/RoiEyx5Fgu.txt

zzz if the earlier one had two problematic addresess, yes

dr|z3d cake.i2p/view/oM6LS2ACcw_1oVAJya6syHUuF36UCmsd7vo4ZQ16f_VIA4Kyus2O/oM6LS2ACcw.txt

orignal anyway I will make sure it's not published

orignal unless they changed max buffer size

zzz thanks

orignal zzz, we have another question

orignal do you drop peer tests if your router is overloaded?

orignal people complain the see Unknown or Firewalled too often

zzz no, we don't have any overload checks

zzz general advice:

zzz 1) retest soon if result is UNKNOWN

zzz 2) Don't change state unless two tests from different peers say the same thing

orignal we run 5

zzz lots of peer test fixes in this release for me

weko Hello!

weko zzz: what you think about this problem: my node recive many packets with invalid port from another nodes, and my router sometimes set Firewalled status. Somewhere my port changes. I thinked maybe problem in my hardware/config/ISP, but today we find another person with same problem. But this behavour not a problem, i did have almost 19K trasint tunnels recently and have many inbound connections.

weko Is it some Internet misconfig issue maybe?

weko Say me if you dont understand

weko As temp solution, i just remove code with this check

weko and rebuild i2pd