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

From: [email-masked]
Date: Wed, 14 Apr 2004 19:21:26 -0400

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

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

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 15 Apr 2004 00:55:38 -0500 (CDT)

> fast path (e.g., in hardware).

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.

The vulnerability of soft limits is that an asynchronous response
is required to respond to a runaway or "one too many" cheating
peer. The latter is actually a bigger concern, because it could lead
to an arms race if clients feel they *must* cheat by having one extra
message in flight because all of the other clients are doing it too.

Shifting the response from the user to the Privileged Resource
Manager is a step in the correct direction. Presumably the
Privileged Resource Manager can respond more promptly
and more predictably than the ULP.

However, it lacks the discretion of the ULP. If no ULP
discretion is involved I would contend that it is more
appropriate to delegate all the way to hardware and
have the hard limit automatically enforce per-endpoint
credit restrictions.

With proper enforcement of per-endpoint credits (however
synchronous or asynchronous) the end-to-end security
issues are solved, leaving only price/performance issues.

If I understand your recap correctly, the determination
in Seoul was that forcing any ULP that uses shared
resources to provide a deterministic guarantee as to
how quickly it will process an "over-limit" event is
not an acceptable security policy.

Actually I agree, but from a standards approach I was
more inclined to simply require that it be labeled
accurately (with the appropriate euphemism for
'really stupid').

But as long as applications are allowed to be
labelled as 'privileged' then system designes will
retain their full rights to shoot themselves in the foot,
something that all good standards should protect.

The important thing is that *some* mechanism
provide a deterministic response to over-limit.
This mechanism can be automatic disconnect,
asynchronous decision by the Privileged Resource
Manager, or even asynchronous decision by a ULP
that has agreed to guarantee a prompt response.

Once we know that a limits can be placed on how much
a single peer can drain from the pool, it is a purely local
issue on how to provision the pool. The ideal degree
of statistical under-provisioning is very dependent on
the application and deployoment environment.

--
Caitlin Bestler - [email-masked]
http://asomi.com/