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

[email protected] 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.

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 protected]
http://asomi.com/