Subject: RE: [rddp] Security Draft issues - STag / PDs.

From: "Culley, Paul" <[email-masked]>
Date: Wed, 2 Jul 2003 11:44:51 -0500

I think the issue would be clarified by taking some examples from the
"verbs" draft (draft-hilland-rddp-verbs-00).

That draft says that each DDP stream (identified with a QP ID) is also
always assigned a "Protection Domain" or PD on request of the ULP.  Some
trusted component makes sure that the ULP is allowed to use that PD,
either by assigning a new one, or otherwise checking that the ULP is
allowed to reuse an already present one (possibly via a process ID).

A QP is only in a single PD, but many QPs may be assigned to a PD,
allowing certain cross QP remote access possibilities.

When an STag is allocated, it is initially assigned to a PD as well on
request of the ULP; the ULP is only allowed to assign a PD that it
"owns" (this is to be enforced by a trusted and protected component,
typically a module associated with the OS).

When the STag is "registered" by the ULP to allow remote access, it may
continue to use the PD (allowing access by any QP with the same PD), or
be further "bound" to a specific QP (which thereafter limits access to
the single QP referenced DDP stream).  The registration procedure also
enforces that the ULP is accessing memory it owns (again, typically done
with a trusted component, associated with the OS).  When the STag is
invalidated, it reverts to PD level protection, allowing binding on any
QP in the same PD the next time it is "Bound".

We should perhaps adjust our language in the security draft to tighten
our requirements so that this type of confusion does not occur.

Paul R. Culley
HP Senior Fellow
281-514-5543

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Wednesday, July 02, 2003 9:50 AM
> To: Deleganes, Ellen M; [email-masked]
> Subject: RE: [rddp] Security Draft issues - STag / PDs.
> 
> 
> If I'm following what you are saying, a minimal compliant 
> implementation would work like this:
> 
> 
>     All DDP Streams have a unique DDP Stream Identifier.
>     
>     This also serves as their "Protection ID" by default.
>     
>     If the ULP assigns a Protection Domain to a DDP Stream
>     then the Protection Domain ID becomes the Protection ID.
>     
>     If the local interface allows a Protection Domain to
>     be *removed* (something that has not traditionally
>     been allowed) then the "Protection ID" would revert
>     to the DDP Stream Identifier.
>     
>     An STag must have a Protection ID associated with it,
>     but it can be either form.
>     
>     An incoming STag is checked by one of the following
>     algorithms:
>     
>         simple compare: STag.Protection ID == DDP Stream.Protection ID
>         scoped lookup: exists(Protection ID + STag)
>         
> Further, a local interface MAY allow multiple Protection IDs
> to be associated with a DDP Stream. For example it could
> allow the DDP Stream Identifier to remain valid even after
> a Protection Domain was assigned, or it could even allow 
> multiple Protection Domains to be assigned.
> 
> Extra local interface capabilities have no impact on the
> wire protocol. The end-to-end semantics remain that the
> local interface must be used to enable a STag on the set
> of DDP Streams that the ULP says it may be used upon.
> The other end only cares about the result.
> 
> If this is correct, then the DDP draft might want to clarify 
> the relationship between the two mechanisms. I would also say 
> that if the above understanding is correct, that the 
> reference in the security-draft is incorrect. It would be 
> more appropriate to note what the required capability is 
> while noting that a local interface MAY offer the ULP more 
> flexibility. It is only a security concern to the extent that 
> offering the ULP more rope could allow it to hang itself, but 
> I think we can all agree that the standard capabilities 
> already allow a ULP sufficient rope to hang itself if it 
> *wants* to be careless.
> 
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 2 Jul 2003 12:55:20 -0500

>"verbs" draft (draft-hilland-rddp-verbs-00).

Well they would be, but they shouldn't be.

The verbs draft, by its own description, covers *one* style of
local interface that *may* be used. Explanations on the definition
of an STag, discussions of applicability and security should all
be valid across the full set of possible local interfaces.

>That draft says that each DDP stream (identified with a QP ID)
>is also always assigned a "Protection Domain" or PD on request
>of the ULP.  Some trusted component makes sure that the ULP is
>allowed to use that PD, either by assigning a new one, or
>otherwise checking that the ULP is allowed to reuse an already
>present one (possibly via a process ID).
>
>When the STag is "registered" by the ULP to allow remote
>access, it may continue to use the PD (allowing access by any
>QP with the same PD), or be further "bound" to a specific QP
>(which thereafter limits access to the single QP referenced DDP
>stream).  The registration procedure also enforces that the ULP
>is accessing memory it owns (again, typically done with a
>trusted component, associated with the OS).  When the STag is
>invalidated, it reverts to PD level protection, allowing
>binding on any QP in the same PD the next time it is "Bound".
>

The above discussion mixes internal concepts with external ones.

"Protection Domain" is being used as both a "local memory access
authorization mechanism" and with its external meaning.

I prefer to work from the external definition only.

Hence the ULP creates one or more Protection Domains, enabling
that Protection Domain with some subset of the memory access
rights that it itself has.

Endpoints and STags can be created/associated with Protection Domains.

With these externally-oriented definitions, certain things become
obvious:

-- you should never place multiple STags or Endpoints in the same
   Protection Domain unless there is a ULP need to do so. The security
   draft seems to assume that a Protection Domain is matches the scope
   of the user process by default and provides complex advice on when
   to narrow it. With the external definition the advice is simple,
   don't make a Protection Domain any wider than the ULP requires.
-- The "stream identifier" is really just a degenerate subset of a
   default Protection Domain encompassing a single Endpoint and STags 
   that can only be used on that Endpoint.
   
Now the local interface definitely should have a "Memory Regitration
Domain" or "Local Memory Region" that can encompass multiple Remote
Protection Domains. But that is a *local interface* optimization, it
allows the ULP to register memory *locally* once and enable it for
multiple Protection Domains. It simplifies coding logic, and makes
it easier for the RDMA stack to minimize address mapping resources.

But is it really relevant to the protocol, applicability or security?

I remain uncertain as to whether this is an "optional" feature that
is not being adequately described, or mere fumbling with terminology
because of presumptions about internal architectures.

I thought it had been settled that a remotely visible STag (the only
type that exists in the protocol) is defined by *one* "Protection ID"
and that *all* STags valid on the same DDP Stream would have to have
the *same* "Protection ID". Early language that implied that the
local interface would simply enable valid STag/Stream pairings
was specifically *rejected* because it implied that the RNIC
would have to search a list in order to validate, rather than
perform a single comparison.

If we're not doing *one*, we should revert to the simplicity of
"many". This "one except when maybe it might be two" is confusing.