@RN
@RN_
@StormyCloud
@T3s|4
@not_bob_afk
@orignal
@postman
@zzz
%acetone
+Onn4l7h
+Sh0ck
+bak83_
+bpb
+leopold
+r00tobo
+uop23ip
+xHarr
Arch
BubbRubb
Danny
DeltaOreo
H20
Irc2PGuest16752
Irc2PGuest33667
Liorar
Maylay
Meow
Over1
ac9f_
anontor
b4dab00m
dr|z3d
duck
halloy13412
john231
makoto
mareki2p_
nZDoYBkF__
nilbog-
ntty`
poriori_
profetik1
r00tobo[2]
shiver_
simprelay
solidx66
thetia
tmg86
u5657
vivid_reader56
zer0bitz
T3s|4
reboot
T3s|4
ouch
orignal
guys, what you do if you dest receive too many leasesets
orignal
like hundreds of thousands
orignal
zzz
orignal
I see new attack now
dr|z3d
you monitoring how many leasesets you're currently storing, orignal?
orignal
yes
dr|z3d
what you got there?
orignal
as I said I see few hundreds thousands
orignal
on that dest
dr|z3d
a few thousand? jeebus.
orignal
hundreds thousands
orignal
like 200K+
dr|z3d
nothing amiss here.
dr|z3d
all looks normal, 3-400 leasesets on a couple of routers I just checked.
orignal
my question to zzz
orignal
if he comraes static key
orignal
when received LS
dr|z3d
how are you handling unsolicited db search replies?
orignal
drop them
orignal
but this is not reply
orignal
just LS block in Gralic
dr|z3d
well, we must be doing something to prevent this, otherwise I'd be seeing a huge amount of leasesets on my floodfills, which I'm not.
orignal
so if zzz checks static key in LS and drop those not matching the session
orignal
I can do the same
orignal
no you will not see at FF
orignal
those are client LeaseSets
dr|z3d
it's a no-brainer to drop fake LS's, no?
orignal
not sure because sometimes we lookup
orignal
we need zzz
dr|z3d
ok, let's wait for zzz to alight from his spaceship.
orignal
for me we need accept only twi types of leasesets
orignal
requested or received from session
dr|z3d
/**
dr|z3d
* Final remove for a leaseset.
dr|z3d
* For a router info, will look up in the network before dropping.
dr|z3d
*/
dr|z3d
public void fail(Hash dbEntry) {
dr|z3d
if (!_initialized) {return;}
dr|z3d
DatabaseEntry o = _ds.get(dbEntry);
dr|z3d
if (o == null) {
dr|z3d
if (_kb != null) {_kb.remove(dbEntry);} // if we dont know the key, let's make sure it isn't a now-dead peer
dr|z3d
_context.peerManager().removeCapabilities(dbEntry);
dr|z3d
return;
dr|z3d
}
dr|z3d
if (o.getType() == DatabaseEntry.KEY_TYPE_ROUTERINFO) {
dr|z3d
lookupBeforeDropping(dbEntry, (RouterInfo)o);
dr|z3d
return;
dr|z3d
}
dr|z3d
// we always drop leaseSets that are failed [timed out], regardless of how many routers we have.
dr|z3d
// this is called on a lease if it has expired *or* its tunnels are failing and we want to see if there
dr|z3d
// are any updates
dr|z3d
if (_log.shouldInfo()) {
dr|z3d
_log.info("Dropping LeaseSet [" + dbEntry.toBase32().substring(0,8) + "] -> Lookup / tunnel failure");
dr|z3d
}
dr|z3d
if (!isClientDb()) {_ds.remove(dbEntry, false);}
dr|z3d
else {
dr|z3d
// if this happens it's because we're a TransientDataStore instead,
dr|z3d
// so just call remove without the persist option.
dr|z3d
_ds.remove(dbEntry);
dr|z3d
}
dr|z3d
}
orignal
so what we do?
orignal
I don't see that we chack static key
dr|z3d
there might be other code to handle drops, but that was the most obvious, not entirely sure it covers your scenario.
orignal
an advesary sends bunch of fake LeaseSets in Garlic messages