RE: Security draft issue (5) - Protection for shared RQ

Paul,

> >   (5) Need to address "protection for shared RQ" problem. 
> > 
> >   Scenario - server mis-implements resource management, bug in one
> >   handler drags down others. E.g., a multiprotocol server with busted
> >   filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP
> >   should not impose non-uniform controls. 
> > 
> It should be noted that some of the authors do not expect shared receive
> queues to be shared between applications.  Rather, a single application
> that must talk to many peers or clients might utilize such a queue.  One
> reason this is desirable is to limit the scope of "partial mutual trust"
> to the application, another is that applications using a shared receive
> queue must also have a clear understanding of the size of the buffers on
> the queue.  Users of the SRQ must agree to the size of the largest
> buffer used, or there will be a failure.  Disparate applications would
> be unlikely to need the same general size of buffers, potentially
> leading to an inefficient size of buffers being used.
> 
> If this usage model is agreed upon, I personally believe that the whole
> SRQ overrun protection problem is ok as it is.

We can certainly put in SHOULD NOT text like that for the RDMA READ
queue, but that's not the entire story ...

The problem here is that there are Partial Mutual Trust (or whatever we
wind up calling it) boundaries among clients of a single application using
a shared receive queue.  In the absence of any enforcement of resource
consumption limits among those clients, any client can mount a DoS attack
on the others by exhausting the shared receive buffers, causing termination
of connections to other clients who have done nothing wrong.

Consider the non-RDDP version of the same application coded to a sockets
interface, and suppose the client mounts the same DoS attack (sending
faster than the application can deal with the data).  The result is
that data builds up in socket buffers, and the system will defend its
socket buffer resource by shrinking TCP windows and the like; the
system is likely to slow down under the load, but it won't start
arbitrarily terminating client connections for lack of resources.

The proposed requirement is that the Privileged Resource Manager contain
code sufficient so that a non-RDDP application can be converted to a
Non-Privileged RDDP without enabling a DoS attack that disconnects
clients or having to write inter-client receive resource protection
code.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------