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, " <b>➜</b> 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, " <b>➜</b> No network specified", null, null, _context.clock().now() + Banlist.BANLIST_DURATION_NO_NETWORK);
dr|z3d
} else {
dr|z3d
_context.banlist().banlistRouterForever(key, " <b>➜</b> " + "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
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