Subject: RE: [rddp] Security draft issue (5) - Protection for shared RQ

From: "Culley, Paul" <[email-masked]>
Date: Thu, 15 Apr 2004 08:21:15 -0500

> 
>   (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.

Paul R. Culley
HP Fellow
281-514-5543 

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 15 Apr 2004 08:59:44 -0500 (CDT)

> SRQ overrun protection problem is ok as it is.

I agree.

Purely local issues about wise sharing of resources are a local issue,
and in no way related to iWarp specific issues.

The iWarp specific issue directly related to impact of handling out-of-order
untagged messages against a shared receive queue. With a simple receive
queue whatever resources are allocated to deal with a wildly out-of-order
untagged buffer are unique to the QP.

But because RDMA encourages holding out-of-order messages for later
delivery, the claim against the common pool can be both long (because
the attacker picked a very advanced MSN) and invisible (because the
DDP Layer does not bother the high layers with details on messages
that have not yet completed).

With simple receive queues the typical solution is to only accept
untagged messages within the MSN range implied by the number
of receive buffers posted exclusively for that QP.

---

From: John Hufferd <[email-masked]>
Date: Sat, 24 Apr 2004 15:38:25 -0700

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. 

The important item is to permit a specific application to create a Shared 
RQ for use with it own clients.  If a specific application server has 
100s-1000s of clients, it should not have to have separate RQ for each 
Client - Server instance.  So as long as this is permitted, I do not have 
any important feelings about what is done with a generic Shared RQ 
handler. 

Having said the above, I guess I do not feel that a Shared RQ needs to be 
in a privileged application, as long as it is only used by one 
application. 
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email-masked]

"Culley, Paul" <[email-masked]> 
Sent by: [email-masked]
04/15/2004 06:21 AM

To
<[email-masked]>
cc

Subject
RE: [rddp] Security draft issue (5) - Protection for shared RQ

Paul R. Culley
HP Fellow
281-514-5543

---

From: "Caitlin Bestler" <[email-masked]>
Date: Sun, 25 Apr 2004 00:44:11 -0500 (CDT)

> 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/