Tero Kivinen <[email protected]> wrote: > 3) Client can also be smartphone, i.e. device which have quite a lot of > CPU power and/or memory, but does not want to use it as it would > increase the power usage so much that the battery life will be > shortened.
Except that client being smartphone/etc. is behind NAT44, and along with
ten thousand other smartphones, all have the same IP address... this matters
because that scenario is probably indistinguishable from:
> 7) Botnets have huge amount of CPU power and lots of memory, but still
> limited number of distinguished IPv4-addresses or IPv6-prefixes (it
> might be millions, but most likely around thousands or tens of
> thousands IP-addresses).
a situation where there is an enterprise of compromised systems behind
the enterprise firewall. (University lab networks come to mind...)
Further, the botnets don't need to present thousands of distinguished IPv4
addresses, they can present a small number of attack nodes, spreading the
work across the botnet?
So this tells me that we are looking for puzzles which are *not*
parallelizable. I know little about this kind of stuff...
> So I think those above make it easier than the captcha problem...
> Also the gateway can blacklist all failed attempts by clients, i.e. do
> not accept new connections from the same IP-address for some amount of
> seconds, or move them to end of queue.
Move them to the end of the queue makes most sense.
> I would expect the processing rules being so that we collect new
> connections for some amount of time, for example 100 ms, then we sort
> the new connection attemps using special rules for that. We would move
> everybody having valid resumption ticket or VIP-pass to the front, then
> we would move everybody with IP-address blacklisted to the end (ordered
> by number of failed attempts), and finally sort rest using some kind of
> sorting order which would include whether they have cookie or not, how
> long puzzle they have solved etc.
> Now after we have the sorted list, we take first connection from the
> list, start processing it, after that take next etc. While we are
> processing current queue, we collect next batch of request. Then after
> interval is passed again (i.e. after 100 ms), we throw the old queue
> away (or keep the resumption and VIP-pass clients still in queue),
> create new queue, and start over.
> So I think the solution is something we can get working, and it will be
> combination of differnet protocols we already have, and some new
> protocols like the puzzle, and then it also includes description how to
> combine all of those.
I think if the gateway has multiple CPUs, that it can collect and process at
the same time, it just has to never commit more than n-2 CPUs towards
processing so that it can have CPU left over for the collecting/sorting, and
of course, for other stuff like, say, IPsec...
I suspect, however, that the simplest machines to DDoS will be the smallest
gateways.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
pgpgz6oPXIkOH.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
