Subject: RE: [rddp] STag validation semantics

From: "Deleganes, Ellen M" <[email-masked]>
Date: Mon, 30 Sep 2002 16:12:32 -0700

Comments within...

- Ellen Deleganes

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Monday, September 30, 2002 10:51 AM
To: Mukund, Shridhar; [email-masked]
Subject: RE: [rddp] STag validation semantics 

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.

<Ellen: This seems to be too open. If an STag can be valid on multiple
connections without any additional protections, it seems like this is too
vulnerable to attacks.>

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

<Ellen: I'd propose that if you want to use the remote invalidate feature
that the STag be valid on only a single connection. If you want an STag that
is valid across multiple connections, then you need to use a different
mechanism to invalidate the STag. It doesn't seem sensible to use the remote
invalidate when multiple connections are potentially using the same STag
since ordering is not guaranteed across multiple connections.>

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

<Ellen: This is exactly what InfiniBand specified.>

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

<Ellen: I really don't like this from an implementation viewpoint, it
requires the RNIC to maintain a table of the valid connections for each
STag. This is additional context and complexity for the hardware and will
have a performance impact on each access to the memory associated with that
STag. The other models only require a QP or PD match, this entails a search
by connection.>

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 21:50:50 -0500

On 9/30/02, Deleganes, Ellen M wrote:

>>requirements for ULPs that use multiple connections within
>>a single session, such as DAFS.
>
><Ellen: I'd propose that if you want to use the remote
>invalidate feature that the STag be valid on only a single
>connection. If you want an STag that is valid across
>multiple connections, then you need to use a different
>mechanism to invalidate the STag. It doesn't seem sensible
>to use the remote invalidate when multiple connections are
>potentially using the same STag since ordering is not
>guaranteed across multiple connections.>
>

I really don't see the remote invalidate as being a specific
problem in this context. Of course I don't like the remote
invalidate -- I'd rather attach the invalidate to the Data
Sink's Receive than the Data Source's Send. If the Data Sink
already has to trust the Data Source to know which
*transaction* to invalidate the STag on, it already knows
what *stream*. Once you introduce the idea that only *some*
Sends invalidate an STag, being selective across multiple
streams is not a problem.

Of course this is all *far* simpler if the invalidation is
moved from the Send to the Recv. It also simplifies the wire
protocol.

Attempting to implement some sort of counting or bit-masked
release of an STag (where it is not totally released until
*all* claims on it are released) makes me nervous. It is
particularly tricky with the Protection Domain approach.
So if we keep invalidation on the wire, I think it does have
to be kept to a flat "this invalidates this STag" unless we
mandate  the full any to any mapping, in which case the
Stream/STag pairing can be deleted very precisely. Of course
making these tables *dynamic* makes your objection to their
complexity (next item) even more telling.

>>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.
>
><Ellen: I really don't like this from an implementation
>viewpoint, it requires the RNIC to maintain a table of the
>valid connections for each STag. This is additional
>context and complexity for the hardware and will have a
>performance impact on each access to the memory associated
>with that STag. The other models only require a QP or PD
>match, this entails a search by connection.>
>

As an application developer I of course want this
flexibility. As an ASIC designer I even more emphatically
agree with you. As an Architect I'd tell the application
developer to take her lumps and work around it. A Protection
Domain like limitation on the scope of STag validity is
essential to efficient hardware.

Caitlin Bestler