Data Haven problems

-----BEGIN PGP SIGNED MESSAGE-----


While programming my data haven code, I am wondering how to guard against
spamming the data haven parser.  It is trivial to mount a denial of
service attack by repeatedly mailing large files. which will fill up the 
quota or filesystem of the data haven host, and if you have mail on a 
root partition, will cause hangs or crashes.

Any ideas on how to guard against mailbombs, and to confirm to the sender
that their files are stored successfully?  Perhaps do a mailing with
a test command that validates the existance of the file, and sends a
reply back wether the file is okay or not, or would this result in a
possible security hole?

As to the code, this will have to be my second rewrite as I am going to
do it in perl code, rather than C...  last rewrite was from a daemon to
a program activated by a .forward file.

Lastly, instead of postage (like a remailer would get), how hard would it
be to implement "rent" where if the "rent" is not paid, and a grace period
has elapsed the file would be trashed.  All this while preserving the
anonymity of the sender and the data haven site.



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBLw7KpFLUeLjqSiixAQHs4wf+Mf4CVx77nXjUXug/3q1hINhCyWgWmal7
vY1WeCDXM+qrrdxUgqzIhYRYpCPKChMjeozFltn9T0CcH/YdaD5hx3dB5A0YUPWZ
SpF5oCL3iZzf2veA8BBJEIrFdmts/nFUzWaqMx4+2IcufYb+0kVw/AKi2M5B0ZiT
UoOFFIsySR9hIMMIfHlkGqrnoO8LhlViRBx4u1O0bb0GYAyc+Nv6HvDJOSWuVe9C
g5B4GMLuW1t9e5Qw3W0Qy1VRIC4QbOrd0zbjDrQ38GUemOjALuZ2h4+tr3bR93KU
ZthueqsIzGKlr90PU6AVVZd128mDHLofJO4I4IoOgSPV7XIK4tufyA==
=KZk0
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----

> Any ideas on how to guard against mailbombs, and to confirm to the sender
> that their files are stored successfully?  Perhaps do a mailing with
> a test command that validates the existance of the file, and sends a
> reply back wether the file is okay or not, or would this result in a
> possible security hole?

To solve problem #1, use digital postage of some form. Digicash, FV,
Tacky Tokens, Mountain Dew futures... just require a per-storage-unit
charge _to initially check in the file_. You can of course charge for
storage over time, too.

To solve problem #2, send an MD5 hash of the file back to the sender.
Ideally, you would also provide (in perl, C source, csh, or whatever)
a submission script which outputs an MD5 hash before the file is sent.
As long as the before-sending hash matches the hash returned by the
haven, you can assume that the file is intact.

> Lastly, instead of postage (like a remailer would get), how hard would it
> be to implement "rent" where if the "rent" is not paid, and a grace period
> has elapsed the file would be trashed.  All this while preserving the
> anonymity of the sender and the data haven site.

Not very. Use a dbm database to map "rent due" dates by file, then
periodically sweep through the database.

> As to the code, this will have to be my second rewrite as I am going to
> do it in perl code, rather than C...  last rewrite was from a daemon to
> a program activated by a .forward file.

Perl has the nice property of being fairly portable, too.

- -Paul

- -- 
Paul Robichaux, KD4JZG       | Good software engineering doesn't reduce the 
perobich@ingr.com            | amount of work you put into a product; it just 
Not speaking for Intergraph. | redistributes it differently.
		  ### http://www.intergraph.com ###

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBLxFaRafb4pLe9tolAQH3EwQAmokOebOJtSbny7rAphWBE7n38XvWYbwy
SMFXmctU6DNnM+9oGTtlaROTUy2jbbt6zDf1/1wIOG/p0C6K7BAD8lt0mkrf4OqN
As1yf9JLxtTHgYIKF94aUiGiqCUo5zWe12CB+GwZ9LKma4BxXKqT3iCYrjQL+2Su
us2wL5AVRd4=
=McPN
-----END PGP SIGNATURE-----

From: dfloyd@io.com

   While programming my data haven code, I am wondering how to guard against
   spamming the data haven parser.

Here's an example of where the mechanism/policy distinction helps a
lot.  Mechanism here is how you store data.  Policy is how you decide
whether to accept a particular request.

The suggestions to date have all suggested particular policies to put
into your code (with the exception of Bill Stewart).  In addition,
almost all of these suggestions have been pay-per-use.  As significant
as policies are, they aren't your most important issue right now.

The single thing you need to get right today is the means of
separating the mechanism from the policy.  Different operators will
have different policies.  If it's difficult to change policies, fewer
services will be offered.

The issue of policy separation is a software architecture one.  I
don't know the structure of your code, but I'd suggest that whatever
it looks like, that you make a (1) clean interface and that you (2)
document it.  If you do these two things, you'll have substantially
achieved separation.

I think you should spend more time worrying about the interface than
about the specific policies.  In order to focus on the policy
interface, I'd suggest an extremely simple policy to work with,
namely, an access list.  Anyone listed can use the server; everyone
else is denied.  That will get you started.

I would distribute your first code with a simple policy such as this.
It will allow prototypes to get worked on.  Since a data haven isn't
of much use without clients for it, a simple policy is adequate for a
first release.

Eric

> 
> 
> While programming my data haven code, I am wondering how to guard against
> spamming the data haven parser.  It is trivial to mount a denial of
> service attack by repeatedly mailing large files. which will fill up the 
> quota or filesystem of the data haven host, and if you have mail on a 
> root partition, will cause hangs or crashes.
>
If there is no cost associated with the haven and there are no account
limitations (ie anyone can get an account) then I don't see a means to do
it reliably. However, if you work up a fee based scheme such that you 
charge per M then it is trivial. If the data is larger than the account
balance it bounces. By limiting the availability of accounts you can make
it less enticeing for users to spam the haven because they are hurting
themselves. And it is assumed that since the accounts are limited  that 
there is an assumed web of trust working.

> Any ideas on how to guard against mailbombs, and to confirm to the sender
> that their files are stored successfully?  Perhaps do a mailing with
> a test command that validates the existance of the file, and sends a
> reply back wether the file is okay or not, or would this result in a
> possible security hole?
>
It seems to me that a message should come back only if there is a problem.
 
> As to the code, this will have to be my second rewrite as I am going to
> do it in perl code, rather than C...  last rewrite was from a daemon to
> a program activated by a .forward file.
> 
> Lastly, instead of postage (like a remailer would get), how hard would it
> be to implement "rent" where if the "rent" is not paid, and a grace period
> has elapsed the file would be trashed.  All this while preserving the
> anonymity of the sender and the data haven site.
>
This form of dating files is pretty commen in bbs systems where if a user
doesn't log in for say 30 days the account and its contents are deleted.
To do this doesn't even require knowing anything about the user  other than
how long the files have been there versus how long they are supposed to be
there.