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.