Subject: Re: [rddp] verbs draft - STag validation error in 7.10.6.2

From: Michael Krause <[email-masked]>
Date: Mon, 07 Jul 2003 09:20:40 -0700

At 10:39 PM 7/3/2003 -0500, Caitlin Bestler wrote:
>Section 7.10.6.2 of the verbs draft has a mistake. In specifying the
>validation that must be done for received STags it states:
>
> >   *   The RNIC MUST check and enforce that the QP ID associated with
> >       the Memory Window is equal to the QP ID associated with the
> >       incoming remote operation that is accessing the Memory Window.
>
>If a Memory Window has "a" QP ID associated with it then it can never
>be valid on multiple QPs (DDP Streams).
>
>But the protocol specifically states:
>
> >   Protection Domain (PD) - A Mechanism used to associate a DDP Stream
> >       and an STag. Under this mechanism, the use of an STag is valid
> >       on a DDP Stream if the STag has the same Protection Domain
> >       Identifier (PD ID) as the DDP Stream.
>
>
>An STag with the "wrong" QP ID nevertheless has the correct PD ID.
>Therefore the STag is valid.

I believe Jeff's response on MW and QP association should answer this 
question.  MW should be viewed as a narrowing of scope of a STag and does 
not invalidate the statement in the protocol since a MW is part of a PD.

Mike

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 7 Jul 2003 12:15:35 -0500

On Monday, July 7, 2003, [email-masked] wrote:

>> > *   The RNIC MUST check and enforce that the QP ID
>> > associated with the Memory Window is equal to the QP ID
>> > associated with the incoming remote operation that is
>> > accessing the Memory Window.
>>
>>> Protection Domain (PD) - A Mechanism used to associate a DDP
>>> Stream and an STag. Under this mechanism, the use of an STag
>>> is valid on a DDP Stream if the STag has the same Protection
>>> Domain Identifier (PD ID) as the DDP Stream.
>>
>>
>I believe Jeff's response on MW and QP association should
>answer this question.  MW should be viewed as a narrowing of
>scope of a STag and does not invalidate the statement in the
>protocol since a MW is part of a PD.
>
>Mike

Viewing the MW as a "supplemental" feature would only work
if the MR was adequate. Any review of the draft will clearly
indicate that it is not.

More importantly, it violates what was always an implicit
capability - that the ULP can dynamically bind an STag
to have precisely the boundaries that the ULP desires.

A local interface that does not provide this capability,
or provides it in a way that is effectively not usable,
would be creating a major security concern.

The key issue remains: exactly what is the "Protection
Domain" referenced in the DDP draft?

I maintain that it should *only* be a ULP created holder
for STags and Endponts. Or more precisely, if it should
hold anything else, then that should not interfere with
its externally defined mission to hold STags and Endpoints.

With that definition, a Protection Domain is

a) lightweight.
b) easy for consumers to use.
c) easy for hardware to implement.
d) imposes no barriers to defining the exact set of STags
   that are valid on a specific set of Streams, and what
   the boundaries and permissions for each of those STags are.
e) creates no new security concerns

It was specifially the fact that the security draft made
incorrect statements about security vunerabilities of
"DDP" that were really only security vunerabilities of
*these* verbs that brought this all into focus.

There are vague assertions being made that the restrictions
on the application model are somehow necessary. I do not
see them. The above interpretation is *totally* consistent
with the DDP draft and with the discussion of Protection Domains
on the reflector.

Neither the verbs draft nor the assumptions made in the security
draft can make that claim. If the proponents of those drafts
feel that the ddp draft needs to refine its defintion of
a Protection Domain then they should explicitly make the
case for doing so on the reflector.

---

From: Michael Krause <[email-masked]>
Date: Tue, 08 Jul 2003 06:58:13 -0700

>if the MR was adequate. Any review of the draft will clearly

I guess we are in disagreement then.

>to have precisely the boundaries that the ULP desires.

A MW does allow the ULP to bind the STag to precise boundaries.

>would be creating a major security concern.

The verbs allows this to occur so I'm not sure where you are finding fault.

>its externally defined mission to hold STags and Endpoints.

I don't believe anyone would disagree in this high-level view.

>case for doing so on the reflector.

The only assertion made that is a point of potential disagreement is what 
does one validate against when a MW is being accessed.  The verbs state 
this should be against the QP and not the PD per the logic that Jeff 
presented.  Where is the problem?   The list for PDs applies equally to MW 
and thus this validation process was chosen as it meets the same list of 
requirements.

Mike

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 8 Jul 2003 09:44:08 -0500

On Tuesday, July 8, 2003, [email-masked] wrote:

>The only assertion made that is a point of potential
>disagreement is what does one validate against when a MW is
>being accessed.  The verbs state this should be against the QP
>and not the PD per the logic that Jeff presented.  Where is the
>problem?   The list for PDs applies equally to MW and thus this
>validation process was chosen as it meets the same list of
>requirements.

The verbs draft creates a lightweight mechanism to dynamically
bind an STag that only works for single-stream sessions.

The act of binding an MW using a QP, narrows the scope of the
QP to less than the Protection Domain.

This has serious implications:

-- It complicates the model. In fact, for all the claims that
   this was a deliberate decision, I'll point out that it is
   not reflected in *much* of the verbs draft. For example
   a queery on a MW does *not* return any QP ID. This is a
   strange omission for a major piece of data on a well
   reasoned "feature".
   
-- It creates an incentive for multi-stream sessions to NOT
   engage in dynamic binding and tailoring of STags. The implicit
   assumption seems to be that all multi-stream session ULPs
   are exposing their entire memory willy-nilly and no longer
   feel any need to do dynamic binding.
   
-- The verbs mis-define the PD in a way that is likely to confuse
   application developers and minimize its proper usage. This is
   reflected in the poor advice given in the security draft.
   
   Specifically, the Protection Domain as defined in the DDP draft
   is something that serves the ULP needs. When viewing that definintion
   there is no doubt that the best advice is simply "make no Protection
   Domain wider than the ULP requires".
   
   The verbs draft entangles the DDP's Protection Domain with OS
   concepts of memory access authority. Those concepts probably should
   exist, but they are different objects. The net effect is to imply
   that creation of multiple Protection Domains that access the same
   memory is an expensive, or even wasteful, process.
   
This is a false tradeoff. External validation does not have to
be driven by the internal memory map data structures. If you
merely seperate the two "Protection Domains" into the
remote/protocol specified one, and the local memory-map/OS one,
you get a very simple solution that imposes no artificial
constraints or performance penalties on multi-stream
applications.

Specifically:
    The Local PD ID is checked to validate that an MW bind is legal,
    i.e. that the OS/whatever has pre-validated the poster's authority
    to reference memory in this mode in the target MR / memory map.
    
    The Remote PD ID is checked just as specified in the DDP draft.
    A local interface could even make it dynamic, so that an MW
    automatically assumed the Remote PD ID of the QP it was bound
    with, allowing MWs (as a resource) to float between sessions.
    
I am not necessarily proposing that as a standard. Personally I
think a "local interface requirements" draft is required first.
But I believe that it is sufficient to show that a local
interface *can* be designed that allows the full intent of the
Protection Domains in the DDP draft to be supported without
forcing the ULP designer to compromise security.

Specifically, the local interface for binding STags

-- MUST allow the tag to be bound to any contiguous subset of an
   eligible memory map (i.e, a registered memory region that the
   caller has legal access to, or that interface's equivalent).
-- SHOULD be lightweight enough to encourage single-use STags.
-- MUST be valid on the set of DDP Streams that the user has
   assigned the same Protection Domain too.

A "Protection Domain" object that is independent of Page
Translation Tables clearly meets these objectives. When the
Protection Domain is tied directly to the OS/privilege granting
authority, you end up with a choice between single-stream
lightwight binds and heavyweight MR creation in order to keep an
STag valid on multiple streams.

To turn it around the other way, why are you defending the QP
check? Why is it acceptable to block multi-stream applications
from doing a lightweight bind? It is a restriction that can be
shown to be unnecessary.

At the minimum, security advice based upon a restriction in
*one* local interface that is not inherent to the protocol has
no place in the security draft.

If we agree that this is a valid development strategy, then it
would have to be prefaced as such. For example: "some DDP stacks
may be optimized on the assumption that the Protection Domain
has the same scope as a user process. On such stacks, there may
be tradeoffs in supporint multiple multi-stream sessions from a
single user process."

But for that language to be included, a case would have to be
made that optimizing the PD to match the user process made
sense. I have not seen such an analysis, only an *assumption*
that they were linked.