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

"Talpey, Thomas" <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
At 01:55 AM 4/15/2004, Caitlin Bestler wrote:
>The security draft should be compatible with what I have termed
>"hard" or per-endpoint limits.
>
>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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.