Subject: [P2PSIP] Quotas

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Jun 2011 18:31:51 -0700

Now that version -15 of RELOAD is out, I am able to restart editing
draft-petithuguenin-vipr-reload-usage which is, as its name indicates, a RELOAD
usage for VIPR.  Most of it can now be implemented with standard RELOAD,
excepted for one thing, the quota algorithm.

The quota algorithm in VIPR is interesting because it looks like it can be
applied to other resources than the one handled by VIPR.  This quota works by
using a variable that limits, at a responsible peer, the number of resources
that can be stored by one storing peer.  More precisely, the number of unique
resource (of one kind) that a storing node can store in one responsible peer is
the quota value divided by the fraction of resources this peer is responsible
for (adjusted for the number of replicas and other parameters, but let's forget
this for now).  The two standard quota parameters in RELOAD only limit the
absolute number and or size of the resources that can be stored.

The ideal would be to add the VIPR quota inside the RELOAD base spec. Having
stuff in base is good because in this case any RELOAD implementation could be
used for VIPR (or any other overlay), and - in my opinion - having multiple
implementations of RELOAD inside one overlay is what will help an overlay to
survive a programmer error.

Now I would agree that we should stop adding stuff to base, to have a chance to
see it published as an RFC one day, so perhaps an alternative idea is to do the
same thing for quotas that I did for access control policy:  Use a script in the
configuration file to express the quota algorithm associated to a specific Kind-ID.

Is there any opinions or questions or comments on this?

Note that this email is cross posted with the VIPR working group, but please
follow up only in P2PSIP.

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Jun 2011 09:26:32 -0600

I can't put my finger on why, but I get very nervous about suing downloadable scripts to enforce critical system constraints such as security and quotas. It just seems like a disaster waiting to happen. That said, I can't come up with any specific problem of why it would not work but it makes me feel very uneasy. 

It does seems reasonable to make this type of quota a general purpose extension to reload that could be used by things beyond vipr WG stuff. 

On Jun 6, 2011, at 7:31 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk3tf4UACgkQ9RoMZyVa61f0LwCgm4OkWYDf46pZ7GjfPfu93BBJ
> NcUAnAtLP1kTvzZ51F9jTucTUcTp6f9Y
> =kM4T
> -----END PGP SIGNATURE-----
> _______________________________________________
> VIPR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vipr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 09 Jun 2011 08:48:42 -0700

> I can't put my finger on why, but I get very nervous about suing downloadable scripts to enforce critical system constraints such as security and quotas. It just seems like a disaster waiting to ha…

I'll post a separate response on this, in p2psip only.

> It does seems reasonable to make this type of quota a general purpose extension to reload that could be used by things beyond vipr WG stuff.

OK, so I'll split the quota algorithm in a separate draft (in the P2PSIP WG)
with the same authors list.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 09 Jun 2011 09:49:00 -0700

On 06/09/2011 08:26 AM, Cullen Jennings wrote:
> 
> I can't put my finger on why, but I get very nervous about suing downloadable
> scripts to enforce critical system constraints such as security and quotas.
> It just seems like a disaster waiting to happen. That said, I can't come up
> with any specific problem of why it would not work but it makes me feel very
> uneasy.

Here's what makes me nervous about this mechanism (and the ideas on this text
will probably go into the security section in the next version of
draft-petithuguenin-p2psip-access-control):

Having a script in the configuration file is - in my opinion - not a security
problem by itself.  After all the configuration file is written by the same
entity that will sign it and as long as the implementer follows the rules in the
draft (no side effect when modifying the parameters, only base classes of
ECMAScript implemented, etc...), this should not be a problem.  It is even
possible to deal with less than perfect implementations, as long as they do not
accept a configuration file that is not signed correctly - for example the
signer can have an active role, by deliberately sending in a ConfigUpdate an
incorrectly signed version of the configuration file and blacklisting all the
nodes that accepted it in a newly issued configuration file.

One of the problems was presented at the mike in Prague by EKR[1]:  Because now
we have code inside the configuration file and because there is no way to find
if this code will eventually stop executing in a reasonable time, we need to put
a limit on the CPU used.  Note that this is not so much for programming errors
but because the set of possible inputs is very large there is no way to test
them all.  For example, an implementation written in java could be stuck in an
infinite loop when using 2.2250738585072012e-308[2] in the Javascript code.

Another problem that is not as easy to fix is that having a script in the
configuration file introduces a single point of failure.  One of the great thing
about RELOAD is that it gives a way to design systems that can resist
programmer's errors.  Programmers make errors and - we had some examples of that
recently - these errors can have huge impact.  One way to mitigate that is to
have multiple, separate, implementations of the same product, to have all of
them running in parallel and use one of the implementations that behaves
correctly.  That is obviously extremely costly and is generally reserved to
systems where life can be endangered by a software bug.  What RELOAD brings to
the table is a less expensive way to do the same thing.  If an overlay is
running on 4 or 5 different implementations, running on different OS and on
different places, then the probability of losing it completely will be
infinitesimal.

If each implementation is coding the access control policy, then we still limit
a coding bug to this implementation, but when the code itself is in the
configuration, then an coding bug will impact all the implementations.

And that is what make me nervous about this.

[1] http://www.ietf.org/proceedings/80/minutes/p2psip.txt
[2]
http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

- -- 
Marc Petit-Huguenin