Re: Long-lived Stags: Why?

At 09:37 PM 6/7/2004, [email protected] wrote:
>Dwight,
>
> > This compromize includes two components, one a successful spoofing of
> > the transport layer, in which RDDP is no more or less vulernable (same
> > transports) and a second component which is the demarcation point at
> > which the ULP can be assured that the buffer is no longer available for
> > modification by a remote peer. I believe that iSER has correctly
> > addressed this issue (see John Hufferd's clarification). The Stag will
> > be un-allocated before notification/completion of the SCSI command.
>
>iSER is one way to design/implement iSCSI over RDMA - it is not
>the only one, and my posts were based on a different architectural
>approach.  Nonetheless, the fact that iSER considers STag reuse to
>be sufficiently dangerous that it applies several "MUST" requirements
>to STag invalidation ought to be (IMHO) a visible nail in the coffin
>of long-lived STags.
>
>Would someone remind us why long-lived STag support should be retained
>given the security pain and suffering it's causing (e.g., what is the
>compelling use for this functionality)?  The simplest solution here
>is to take it out, especially if there's no compelling use for it ...
>
>Looking back over the list emails, the reasons I think I see for
>long-lived STags are:
>
>(1) Allow storage protocols to stage transfer based on available
>         resources. (John Hufferd)  Also applies to HPC protocols like
>         MPI. (Jim Pinkerton).
>(2) Compatibility with InfiniBand. (John Hufferd)
>(3) Avoid limiting flexibility. (Caitlin Bestler)
>(4) Allow applications to innovate around long-lived STags.
>         (Jim Pinkerton)

Add my name and I'm sure many others who have spoken up about this issue to 
all of these values.


>I believe that staged transfer (1) is compatible with a suitable
>definition of "one-shot" STags - after completion of data transfer,
>the buffer becomes not writable from the network before completion
>is reported to the ULP application (there are details to be worked
>out in the definition of "one-shot" that may impact the protocols).
>
>I have a hard time with InfiniBand compatibility as a motivation
>given the serious incompatibility between iSER and SRP (the native
>SCSI encapsulation on InfiniBand).

There is an effort within an open source group to provide iSCSI and iSCSI / 
iSER over InfiniBand.  These are already well underway.

As for compatibility with InfiniBand, need to keep in mind that much of the 
existing ULP that use RDMA as well as many user applications already 
operate over InfiniBand.  Various OSV already have a solid RDMA 
infrastructure capable of supporting InfiniBand.  Many ISV have products 
already using InfiniBand.  In general, there is a reasonably sized and 
solid ecosystem that supports the InfiniBand operational semantics which 
were used as the basis for RDDP semantics.  The basic RDDP semantics have 
been incorporated back into InfiniBand as well enabling the industry to 
have a single set that semantics that are interconnect independent.  As 
such, it would be very bad for the industry and customers to state 
compatibility with InfiniBand (an interconnect that is recognized and has 
associated IETF specifications) as insufficient motivation based solely on 
SRP / iSER compatibility.

>Flexibility and innovation in the absence of other compelling uses of long 
>lived STag functionality strike me as reasons to put the RDDP protocols 
>(or possibly the long-lived STag extensions to them) on the experimental 
>RFC track rather than the standards track (i.e., publish them as 
>Experimental RFCs rather than Proposed Standard) until the compelling 
>benefits that outweigh the security risks can
>be demonstrated.

This is just coming down to whether to mandate IPSec or not and proceed 
with the existing specifications through the standards track.  I don't 
think we are to the point of just tossing the specs to experimental over 
this one question.

Mike