[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

RE: Anti-DoS prevention [was Re: Comments on minion-spec.txt]

Nick wrote:
> In the future (post 0.0.4, maybe some for 0.0.5), we'll have 
> filtering incoming MMTP by incoming IP address, pushing back 
> on message delivery when our disk is full, and more 
> sophisticated behavior about dropping undeliverable messages 
> when we're under heavy load.

Given the DoS attacks currently seen in the wild and the effects they
have the servers that host the remailer network, I believe that at least
the following requirements exist:

1) Containment
A DoS against mixminion should have minimal impact on the rest of the
server on which mixminion runs.

Currently, a "flood" against Mixmaster remailer also performs a DoS
against the remailer's MTA. Since remailers typically run on personal
machines that serve as remailers, the individual's MTA, and perhaps even
as the individual's NAT box, a DoS against the remailer causes more pain
to the admin than watching his remailer node drop in the stats. That's
unacceptable. You should not be able to DoS a system by DoS'ing an
application. To DoS the system, the attacker should have to DoS the
TCP/IP  stack.

Some resources that should be limited from within mixminion or by a
watchdog are:
- disk
- memory
- handles (both file and socket)

If the installer is not sufficiently sophisticated (it should be) to
determine sane defaults for the local system, conservative defaults
should be set in the default config file.

Yes, these resources can be controlled from within the OS, but if the
use of mixminion is limited to those that both know and have the time,
to tune various kernel, FS, and process limits, you've lost.

2) The unusual "the application shall degrade gracefully under excessive

3) Dropping a message should be the last resort, since reliability is
critical to market acceptance of mixminion.

4) Since at present an individual attacker can selectively DoS, or at
least significantly slow down, particular remailers at will, the
attacker at work must be considered an active attacker.

The attack that the attacker is currently performing falls into the
"Delaying Messages" category of attacks mentioned in Section 9 of the
Mixminion specs. There, delaying attacks are said to be poorly
understood, but potentially quite damaging. Given that delaying attacks
are taking place today, it appears that more research into the efficacy
of this attacks is required before any statements about the security
about future deployed Mixminion remailer network can be made. I have a
hunch that that the results of this research may have significant impact
on design, potentially even breaking protocol compatibility with the
current specs. The potential impact of such a break should be analyzed.

--Lucky Green