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

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 protected]



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

To
<[email protected]>
cc

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






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