Security draft issue (5) - Protection for shared RQ

With the expectation that discussion on (4) [IPsec support]
will be lengthy, I'm going to go to (5) and come back to (4).
Issue (5) is our old friend, the Shared Receive Queue protection
problem, but an interesting solution for this was devised in Seoul.
Here is what the minutes have to say on this issue:

  (5) Need to address "protection for shared RQ" problem. The security draft

  makes a "valiant" attempt to make it a ULP issue - but can't. Exhaustion 
  of receive buffers is a key attack. Is this the job of each and every ULP,

  or RDDP's? Probably the latter.  OTOH, there is general discomfort with
  specifying this in a fashion that would require checking it in the fast
  receive path (e.g., in hardware in a hardware-optimized implementation).

  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. 

  The goal is to specify a functionality that is guaranteed to exist, 
  though possibly overridable given sufficient trust.  Absence of any
  required control here doesn't line up with the Partial Mutual Trust
  concept discussed earlier.
 
  Proposed approach: Require a default implementation of this protection,
  as part of the Privileged Resource Manager. Privileged protocols can
  override it, but the base function is always provided.

  Does a similar situation exist for CQs? 
  (Response: yes, with suppressed completions, underprovision is desirable!)

The current approach in Section 7.5.2 (and subsections) of the
security draft that make defending against this class of attacks
entirely the responsibility of all applications, including
non-privileged ones is not going to be acceptable as non-privileged
applications shouldn't have to engage in this sort of defensive
resource management.

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

This would apply to support for shared Receive Queues (7.5.2.1),
and shared Completion Queues (7.5.2.3).  It would not apply to
shared RDMA Read Queues, as 7.5.2.4 already says that RDMA Read
Queues SHOULD NOT be shared in a fashion that can create this
problem.

This is for discussion before I call rough consensus.  Comments?

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 protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------