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

From: "Deleganes, Ellen M" <[email-masked]>
Date: Tue, 1 Jul 2003 08:11:07 -0700

My comments are interspersed.

Ellen Deleganes

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Monday, June 30, 2003 6:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rddp] Security Draft issues - STag / PDs.

On Monday, June 30, 2003, [email-masked] wrote:

>Caitlin Bestler wrote:
>
>> My reading of the DDP spec is that setting the Protection Domain
>> is *the* way to control the scope of an STag.
>
>I don't think so.  Section 10.3 of the DDP draft describes both
>the Protection Domain and stream association mechanisms and then says:
>
>   DDP MUST support 
>   Protection Domain association and DDP stream association mechanisms 
>   for associating an STag and a DDP Stream.  
>
>IMHO, that implies that the functionality of using stream association
>within a Protection Domain (as envisioned by the security draft) is
>REQUIRED.  IIRC, this topic was discussed in Atlanta, but I'm not
>going to object too strenuously to reopening it in the context of
>the security draft; keep in mind that both models were felt to be
>useful at the time.

<ellen: The intent is that either is allowed. One could associate an
STag with a Protection Domain and the buffer would be accessible across
multiple streams, or associate the STag with a single DDP stream.>

Funny, I read that section as describing two different interfaces
to the same mechanism. Specifically:

>10.3 Association of an STag and a DDP Stream 
>
>   There are several mechanisms for associating an STag and a DDP 
>   Stream. Two reasonable mechanisms for this association are a 
>   Protection Domain (PD) association and a DDP Stream association. 
>
>   Under the Protection Domain (PD) association, a unique Protection 
>   Domain Identifier (PD ID) is created and used locally to associate 
>   an STag with a set of DDP Streams. Under this mechanism, the use of 
>   the STag is only permitted on the DDP Streams that have the same PD 
>   ID as the STag. For an incoming DDP Segment of a Tagged DDP Message 
>   on a DDP Stream, if the PD ID of the DDP Stream is not the same as 
>   the PD ID of the STag targeted by the Tagged DDP Message, then the 
>   DDP Segment is not placed and the DDP layer MUST surface a local 
>   error to the ULP. Note that the PD ID is locally defined, and cannot

>   be directly manipulated by the Remote Peer. 
> 
>   Under the DDP Stream association, a DDP Stream is identified locally

>   by a unique DDP Stream identifier (ID).
>
Which is really the same thing as a Protection Domain Identifier, except
that the Consumer does not have to generate it.

<ellen: The DDP Stream identifier is not the same as a Protection Domain
identifier because it is possible for multiple DDP Streams to have the
same Protection Domain identifier, yet have an STag only valid on a
single DDP Stream.>

>   An STag is associated with a 
>   DDP Stream by using a DDP Stream ID. In this case, for an incoming 
>   DDP Segment of a Tagged DDP Message on a DDP Stream, if the DDP 
>   Stream ID of the DDP Stream is not the same as the DDP Stream ID of 
>   the STag targeted by the Tagged DDP Message, then the DDP Segment is

>   not placed and the DDP layer MUST surface a local error to the ULP. 
>   Note that the DDP Stream ID is locally defined, and cannot be 
>   directly manipulated by the Remote Peer. 
>
So that in either case the "Protection Identifier" of the DDP Stream
is compared with the STag's "Protection Identifier".

<ellen: In the case where the Protection Domain association is used, the
Protection Domain identifiers are checked. In the case where the STag is
associated with only one DDP Stream, it is only necessary to check
against the DDP Stream ID.>

>   A ULP SHOULD associate an STag and a DDP Stream. DDP MUST support 
>   Protection Domain association and DDP Stream association mechanisms 
>   for associating an STag and a DDP Stream.  

And *nowhere* does it imply that a single DDP Stream needs to be
associated with *two* "Protection Identifiers", or that an STag
ever has to be associated with *two* "Protection Identifiers".

<ellen: Agreed. An STag only needs to be associated with one Protection
identifier. Either it is associated with the Protection Domain ID, or it
is associated with the DDP Stream ID. It does not have to be associated
with both, but an implementation is not prevented from doing so.>

In any event, I interpreted the security-draft text as specifically
implying that you could have both methods active on the *same* stream
or the same STag.

<ellen: One could have both methods active on the same stream. Each STag
is independent. However, only one method is active for the same STag.
Note that, the association to the DDP Stream ID is more restrictive than
the association to the Protection Domain ID.

My interpretation of the "DDP Stream ID" was to the effect of "each
DDP Stream should have a default Protection ID that is unique to it
and will be used if the ULP does not explicitly assign it to a
Protection Domain."

<ellen: An API could be designed that way, but the architecture is such
that it is possible to have multiple DDP Streams associated with the
same Protection Domain ID, but still be able to associate an STag with
only one of those DDP Streams.>

Personally, I'm working on a software implementation, so a quick OR
that isn't going to make that much difference in performance, especially
if optimizated tso that the matching id more often the first one. But
if that was meant to imply checking two values then it clearly needs
to be reworded.

<ellen: As mentioned earlier, it is possible for an implementation to
check only one id.>

But my recomendation is for a single check. It's simple. It's quick,
and its adequate.

_______________________________________________
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 09:50:03 -0500

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.