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

From: [email-masked]
Date: Thu, 15 Apr 2004 08:50:14 -0400

> [email-masked] said:
> 
> >
> > The proposed approach from Seoul is to require implementation of
> > shared resource protection functionality in the privileged resource
> > manager that has to be used by non-privileged apps (e.g., the
> > high-water and low-water notifications would go to the resource
> > manager rather than the application); implementation of this
> > functionality can then be imposed as a responsibility on privileged
> > applications as part of the price of to bypassing/replacing this
> > portion of the privileged resource manager.  This should respond
> > to the major concern about keeping this support out of any receive
> > fast path (e.g., in hardware).
> >
> 
> The security draft should be compatible with what I have termed
> "hard" or per-endpoint limits.

That makes a lot of sense - implementers who want to enforce the
additional limits in a shared pool should be able to do so.

Thanks,
--David

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 15 Apr 2004 07:01:30 -0700

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 
>

---

From: "Talpey, Thomas" <[email-masked]>
Date: Fri, 16 Apr 2004 05:07:18 -0700

At 01:55 AM 4/15/2004, Caitlin Bestler wrote:
>Under this approach, which the RDMAC verbs makes the mistake
>of explicitly forbidding, the RNIC maintains the per-endpoint
>credit count while still using a shared buffer pool.
>
>If an untagged message arrives while the endpoint has no credits
>it is not allowed to tap the pool, even if the pool has buffers. This
>prevents the pool from being drained by a single runaway peer.

I agree that a hard limit should be supported, in addition to the
notification method.

There are many other implementation possibilities, but perhaps
adding the following normative statements to rddp-security 7.5.2.1:

"The implementation MUST enforce per-endpoint limits on drawing
resources from shared receive queues for nonprivileged consumers.
The implementation MAY choose to place these resources under
the control of another local method."

Followed by the informative:

"A simple method to implement the limit, is for the PRM to limit the
size of receive queues of endpoints which are linked to shared RQs
when no suitable local trust is established for the Application. In
this simple method, the endpoint will be terminated if and when
it overdraws its "allocation", due to overflowing its receive queue.

"Implementing this method in the RNIC, however, requires additional
state to be tracked on a per-endpoint basis. Therefore, the PRM
may choose to implement equivalent resource protection via a
default notification method, rather than in the RNIC.

"The PRM may then allow an Application which it deems trustworthy,
to set up its own notification method for a shared queue, thereby
passing control of resource allocation and limits for that queue
to the Application."

Following, there are bunches of text existing in rddp-security 7.5.2.1
which provide further detail.

Note however, that the first preceding paragraph is not compatible
with draft-hilland section 6.3.7, in the nonprivileged case.

Tom.

---

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

Paul R. Culley
HP Fellow
281-514-5543

---

From: [email-masked]
Date: Wed, 28 Apr 2004 13:06:47 -0400

John,

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

I think this is in line with the intent of the proposed requirement
The intent is along the lines of what Caitlin wrote:

	In my opinion, any application that feels it can provide
	deterministic responses to shared-resource alerts should
	have the option of doing so, as long as it is the owner
	of the shared resource.

	The essential requirement is that the Privileged Resource
	Manager (or the RNIC itself) handle these alerts until the
	owner of the Shared Resource enables a different handler.

In other words, the proposed requirement for Shared RQ protection
in the Privileged Resource Manager is "MUST implement", not "MUST
use", not even for Non-Privileged applications. 

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

I would agree, - this needs to be orthogonal to whether the application
is privileged or non-privileged, as there is no realistic way to stop
a non-privileged application that has an RQ from sharing it among multiple
clients, and no strong rationale that I can see for imposing that sort
of restriction.  In the other direction, a privileged app might want to
take advantage of the Privileged Resource Manager's Shared RQ protection
rather than implement it on its own, and there is no good reason to prohibit
that app from doing so.

NB: This requirement would also apply to shared completion queues.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John
Hufferd
Sent: Saturday, April 24, 2004 6:38 PM
To: [email-masked]; [email-masked]
Subject: RE: [rddp] 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-masked] 

"Culley, Paul" <[email-masked]> 
Sent by: [email-masked] 
04/15/2004 06:21 AM To<[email-masked]> 
cc
SubjectRE: [rddp] Security draft issue (5) - Protection for shared RQ

Paul R. Culley
HP Fellow
281-514-5543