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

John Hufferd said:
> I think that Paul has stated the point very well (in the attached note and
> his subsequent note), the purpose of Shared RQ was intended to be used by
> an application server that had a set of similar clients.  This was assumed
> because of the need to post buffers that were of some optimum size for the
> Client to Server interaction.  Because of the probability of very
> different buffering requirements --  I, for one, had not envisioned a
> privileged resource manager that Shared an RQ as a general facility for
> "all comers".   However, I guess that having a particular implementation
> like that is OK, though I am not convinced of its importance.
>

I think you are misunderstanding the intent of the requirement David
has proposed. There are at least four different scenarios that seem
to be behind the assumptions of various statements:


1) A sophisticated server application uses an SRQ rather than setting
   up an RQ for each connection. While the server specific ULP states
   a nominal credit level for each connection, the server application
   actually under-provisions the SRQ to conserve resources. This is
   totally hidden from the clients, who each believe there are N
   buffers waiting for them -- much as each customer of a bank believes
   they can withdraw their funds at any time even though the bank
   does not actually have that much cash on hand.

2) An SRQ is used over the scope of a multi-connection session, to
   allow ULP directed failover/load-balancing/striping/whatever
   across the connections. Flow control is managed at the session
   layer however, so per-stream credit tracking would not make sense.

3) An SRQ is offered as a general facility for multiple applications
   that merely share an approximate buffer size.

4) A server application uses an SRQ rather than an RQ for each
   connection, but is not necessarily sophisticated enough to
   guarantee deterministic responses to SRQ-alarms.

I believe that Paul and John are mostly thinking of the first two
scenarios, and think that the proposed change is intended to support
the third option.

I would agree that the third option is not a viable scenario, but
I believe the last one is. Basically it allows a server to use
Shared Resources with only the overhead of calculating the degree
of under-provisioning that is appropriate. It does not have to
develop a real-time guaranteed-response mechanism for dealing
with denial-of-service attacks.

Requiring such capabilities from any application that wants to
use shared resources is not realistic, and will most likely result
in the application designer saying "yeah, I've taken care of that"
when in fact they haven't. Setting up applications to fail like
that is poor security design.

What the language clarification needs to be clear on is that for
the first two scenarios that there is nothing wrong with an
application controlling its own exception handling -- even if
it is not have privilege at the same scope as the Privileged
Resource Manager.

It should also be clear that there is no expectation that an
iWarp Provider SHOULD provide a multi-application shared receive
queue capability. In fact you could almost state that they
SHOULD NOT do so. One of the nice security feautes of RDMA
is that it uses application supplied buffering, leaving all
the holes associated with system buffers out of the picture.

But I believe that SRQs should be enabled in a way that is
ULP transparent. That is, the server deals with each session
as it always had. It just primes the pump with receive buffers
into the SRQ rather than into each RQ. With proper per-stream
credit monitoring (or even per-stream credit counting) the
application only needs to properly determine how many buffers
it needs to place in the SRQ. No special alarm handling is
required. I believe this is a far more realistic goal for
application developers, and hence will lead to more robust
and secure systems.


--
Caitlin Bestler
http://asomi.com/