Subject: RE: [rddp] STag validation semantics

From: "Mukund, Shridhar" <[email-masked]>
Date: Mon, 30 Sep 2002 10:25:07 -0700

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

-Shridhar Mukund

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 30 Sep 2002 12:50:36 -0500

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