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

I think you're saying that, if the security document constrains
shared receive queues in the same way it does RDMA Read
queues (i.e. SHOULD NOT be shared among applications),
then the draft is OK as-is.

But doesn't this mean that any shared RQ must be owned by a
privileged consumer? That seems too stringent.

I do agree with the notion that applications that share an RQ
are themselves related. The issue is leveraging this into a
guarantee of system protection.

Tom.

At 09:21 AM 4/15/2004, Culley, Paul wrote:
>> 
>>   (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 protected]
>https://www1.ietf.org/mailman/listinfo/rddp