Subject: [rddp] STag validation semantics

From: Caitlin Bestler <[email-masked]>
Date: Thu, 19 Sep 2002 11:35:50 -0500

There are some aspects of STag validation semantics that are
unclear between the rdma and ddp drafts. Additionally, I
believe it is incorrect to address those semantics in the
RDDP document, I believe STag semantics belong as part of
the DDP layer as that it is the DDP layer that executes data
placement.

The specific questions are:

    How is an STag made valid in association with a stream?
    
    If an STag is valid on multiple streams, what is the
    meaning of an invalidation received on one stream?
    
The language between the two drafts seems to be consistent
with any of the following interpretations:

    An STag may be associated with exactly one Stream.
    An Invalidation therefore totally invalidates the STag.
    
    An STag may be associated with exactly one Stream, or it
    may be "unbound". Only an associated STag may be
    invalidated.
    
    An STag may be associated with any set of Streams
    (either explicitly or through a local interface object
    such as  an InfiniBand Protection Domain).
    An invalidation invalidates the STag only on that
    specific stream, the STag remains valid on any other
    streams that is has been associated with.
    
    An STag may be associated with any set of Streams
    (either explicitly or through a local interface object
    such as  an InfiniBand Protection Domain).
    An invalidation invalidates the STag.
    
The first option will not work for DAFS, an STag can be
delivered on the primary channel and used on the RDMA Read
channel. Least effort ports of many existing protocols will
similarly use multile streams and communicate STags that may
be used on multiple streams within the sesssion.

My recomendation is that the method of interfacing be local,
or that we suggest something along the model of a InfiniBand
Protection Domain. It implements easily, already has
solutions and is capable of meeting application
requirements.

I believe these semantics should be clarified, and moved to
the rddp document. I'll volunteer to do the drafting once a
concensus is reached on the reflector and the editability of
the drafts has been established.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: [email-masked]
Date: Fri, 20 Sep 2002 09:18:26 -0400

> I agree with you that specifying the scope of the STag is not
> a protocol issue, but a local policy. The PD is an excellent
> approach to this.

That depends on how narrowly one scopes the meaning of "protocol
issue".  Even if STag invalidation is not part of the protocol,
the scope of STags has direct bearing on the security properties
of the protocols and hence has to be covered in the Security
Considerations portion of the protocol specifications.  This
could well result in restrictions on Stag validity and/or
requirements for on implementation support of validity scopes
to enable ULP implementers to control the resulting security
properties.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 22 Sep 2002 08:37:38 +0300

STag scope (not only for invalidation) is a serious security concern.
The most conservative approach  - STag scope is connection or a group of 
connections - a session, or the even more restrictive iSCSI view - STag 
valid for a commad might be too restrictive for other applications but 
extending it will require carefull scrutiny and will involve some form of 
authentication envelope.

Julo

[email-masked]
Sent by: [email-masked]
20/09/02 16:18

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        RE: [rddp] STag validation semantics

Thanks,
--David

---

From: "Renato Recio" <[email-masked]>
Date: Mon, 30 Sep 2002 13:30:54 -0500

Shridhar,

  In terms of security exposure, the STag has a similar exposure as the
iSCSI Initiator Task Tag.  If a ULP is concerned about a rogue endpoint
essentially hijacking a connection and injecting rogue segments into the
fabric (e.g. DDP Segments that target a valid DDP Stream), then the ULP
really needs to use a secure protocol under RDMA/DDP to close the hole.

  However, in some environments, the network used to interconnect the nodes
will be physically secure and will not be exposed to such network
break-ins.  In these cases, the ULP would not need to use the secure
protocol.

Thanks,

Renato J Recio
Distinguished Engineer
IBM I/O Architecture and Technology
Tel 512-838-3685, T/L 678-3685

                      "Mukund, Shridhar"                                                                                 
                      <Shridhar_Mukund@a        To:       "[email-masked]'" <[email-masked]>        
                      daptec.com>               cc:       "[email-masked]'" <[email-masked]>                              
                      Sent by:                  Subject:  RE: [rddp] STag validation semantics                           
                      [email-masked]                                                                                 
                      g                                                                                                  

                      09/30/2002 12:25                                                                                   
                      PM                                                                                                 

>>The most conservative approach - STag scope is connection or a group
>>of connections - a session, or the even more restrictive iSCSI view -
STag

>>valid for a >>commad might be too restrictive for other applications but
extending
>>it will require carefull scrutiny and will involve some form of
authentication envelope.

>>Julo

From what I understand(about STag and PD), it seems like we should *not*
expose STags on the wire. If an iSCSI/RDMA session chooses IPSec protection
on all it's (TCP)connections, it's STag-set should not be visible from
other
unprotected connections even thru' guess work or accident.

Does it make sense to have a level of indirection as follows?
Define BPI(Buffer Parameter Index, kind of like SPI), such that the 5-tuple
<Source IP Addr,Dest. IP Addr, Source Port, Dest. Port, BPI> points to a
valid
STag only if defined apriori for that connection.

-Shridhar Mukund

---

From: "Renato Recio" <[email-masked]>
Date: Mon, 30 Sep 2002 14:38:51 -0500

Caitlin,

  In IB terms,  the STag=R_Key.  The RDMAP must provide a mechanism for
associating a STag to a RDMA Stream.  The association may be 1 STag to 1,
and only 1,  RDMA Stream  or  it may be 1 STag to Multiple RDMA Streams.
We've left that semantic up to the ULP.  The main reason being that
specifying that semantic in more detail would have caused us, in my view,
to describe PDs and QP Contexts.

  However, I guess we could:
- Add in the definition of a PD;
- Describe how it must be associated with a RDMA Stream and a STag;
- Describe how one STag can be used on more than one RDMA Stream if the PDs
are the same on both RDMA Streams.

  In my view, it is not necessary to document the above three semantics in
the RDMAP specification.  However, if most folks feel it is absolutely
necessary for completeness/correctness,  I will not object.

Renato J Recio
Distinguished Engineer

                      Caitlin Bestler                                                                                   
                      <[email-masked]        To:       Renato Recio/Austin/IBM@IBMUS                                  
                      i.net>                   cc:       [email-masked]                                                  
                                               Subject:  RE: [rddp] STag validation semantics                           
                      09/30/2002 01:36                                                                                  
                      PM                                                                                                

On 9/30/02, Renato Recio wrote:

>
>Caitlin,
>
>Regarding the options discussed for dealing with the STag
>scope,  the RDMAP specification actually outlines quite a
>bit more than Unspecified.  The text that I'm referring to
>is in section 10.3 (bullets #5 and #8):
>
>5.   RDMAP allows and encourages local interactions to
> restrict the usage of STags to specific Streams and/or
> user processes. RDMAP MUST provide a mechanism for
> associating a RDMAP Stream with a STag.
>

I do not believe it is currently explicit that the STag MUST
NOT be valid on streams that it was not enabled for.

I also do not believe that it currently guarantees that the
ULP MUST (or even SHOULD) be able to enable the same STag on
multiple streams.

These changes would be simple, but I believe would require
an implementation that is more inclusive than PDs. In IB
terms, it would require the ability to specify the R-Key
value desired.

Other than that, the spec is indeed very PD compatible.

Caitlin Bestler

---

From: "Mukund, Shridhar" <[email-masked]>
Date: Mon, 30 Sep 2002 16:22:36 -0700

Renato,

I do not think that iSCSI ITT has similar exposure as the STag.
The "Command Connection Allegiance" and related MUSTs make the 
iSCSI ITT usage seem like IPSec SPI in this regard.

-Shridhar Mukund