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

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

Hash: SHA1

On Saturday 17 May 2003 07:16, Sean R. Lynch wrote:
> On Fri, 2003-05-16 at 22:51, Nick Mathewson wrote:
> > So, I put your question back to you, and to the list: *are* these
> > defenses up to the challenge?  What *other* filtering and MTA features
> > do current remops use to prevent abuse and DoS?  We should definitely
> > draw on the experiences of today's operator community, and not enter the
> > arms race undermatched.
> We need untracable electronic cash to use as postage stamps.

How about an implied electronic cost that is server-side rather than client 
generated tokens?

In the past this hasn't been possible as the Remailer has been constrained by 
its reliance on SMTP, however this is no longer the case now that incoming 
messages and inter-Remailer traffic will use MMTP.  I'm afraid I don't have 
an in depth understanding of the MMTP protocol, but perhaps it is possible 
now for the server to dictate how long it will take to acknowledge receipt of 
an incoming message.  This in effect means the client incurs a time cost for 
each message it sends.

In a simple model, this cost could be common for all clients with only other 
Remailers requiring some form of whitelisting to remove (or reduce) the 
implied cost.  Presumably the whitelisting of other servers could be 
automated as each server has awareness of all other servers by means of the 

If this was insufficient flexibility, could there be a means for operators to 
apply a configurable cost to any source they choose, or perhaps an automated 
process that implies an incremental cost on each successive message from a 
single source within a defined period?  In this manner, the client's 
transmission rate is degraded, rather than the servers ability to receive.
Version: GnuPG v1.2.1 (GNU/Linux)