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

Culley, Paul said:
>>
>>   (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.
>
>


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.