Subject: RE: [rddp] STag validation semantics

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

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.

8.   If an STag is not valid on a connection, RDMAP provides a mechanism
for terminating the RDMAP Stream (see section 6.8 Terminate Header).

In my view,  #5 states that the RDMAP must provide a mechanism for
associating a RDMAP Stream with a STag.  The Protection Domain mechanism is
certainly one such mechanism.  It seems to me, the PD mechanism does not
need to be described in the RDMAP specification,  because in order to make
the description complete, the RDMAP specification would need to include a
description of verb related concepts (like QP Context).

Bullet #5 also enables a single STag to be used by more than one RDMAP
Stream, but permits the ULP to restrict usage of an STag to just a single
RDMAP Stream.  However (in bullet #8), the RDMAP states that if an STag is
not valid on a connection, the RDMAP provides a mechanism for terminating
the RDMAP Stream.

In my view,  the RDMAP actually specifies a PD mechanism without ever
mentioning the words PD.

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

                      Caitlin Bestler                                                                                   
                      <[email-masked]        To:       "Mukund, Shridhar" <[email-masked]>,              
                      i.net>                    [email-masked]                                                           
                      Sent by:                 cc:                                                                      
                      [email-masked]        Subject:  RE: [rddp] STag validation semantics                           
                      rg                                                                                                

                      09/30/2002 12:50                                                                                  
                      PM                                                                                                

On 9/30/02, Mukund, Shridhar wrote:

>
>>>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
>
> 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.
>

An STag is a handle. How an implementation uses the handle
to translate to local memory is an implementation issue. How
it interacts with the ULP to assign meaning to the STag is a
local interface question.

What is under discussion is the minimal set of local
interface capabilities that the local interface must
providem. In other words, what control is the local ULP
guaranteed to have when it creates STags?

I believe the options discussed  can be summarized as:

-- Unspecified: an STag is only guaranteed to be valid on a
single connection. It may be valid on others. This approach
is potentially vunerable to the guessing attacks you
referred to. The sole benefit is specification minimalism.

-- Exactly one connection: an STag is valid on exactly one
connection. This prevents all accidental over-exposure of
STags on multiple connections, but does so by eliminating
legitimate uses as well. This presents awkward coding
requirements for ULPs that use multiple connections within a
single session, such as DAFS.

-- Protection Domain equivalent: an STag is valid on all
connections that are part of the same Protection Domain
equivalent. This provides ULP control, and is very
compatible with InfiniBand.

-- Explicit: the STag is valid only on those connections
that the ULP has specifically enabled it for. It may enable
it for any set of connections. This provides complete ULP
flexibility. It is also a very simple specification.

The implementation you suggest would be a valid method of
implementing that Explicit option. The protection domain
option could be implemented by a table that took the
Protection Domain and STag as the key, with the Protection
Domain being an attribute of the connection. This is a
simpler table. The obvious corroralaries is that it is
easier to implement but that there are options that cannot
be represented. The fact that the same options could not be
represented under InfiniBand is a strong argument that this
is an acceptable simplification.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
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: Mon, 30 Sep 2002 13:36:59 -0500

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