Long-lived Stags: Why?

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)

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

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Barron, Dwight
> Sent: Monday, June 07, 2004 4:27 PM
> To: Somesh Gupta; Uri Elzur; [email protected]
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> 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. 
> 
> Regards,
> Dwight
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> > Behalf Of Somesh Gupta
> > Sent: Monday, June 07, 2004 12:58 PM
> > To: Uri Elzur; [email protected]
> > Subject: RE: [rddp] IPsec and RDDP as a transport
> > 
> > 
> > Uri,
> > 
> > With iSCSI, there is a delineation process on the byte
> > stream before processing the data. In other words,
> > if one packet or sequence of packets is injected by
> > the rogue, it will be detected because the delineation
> > process or CRC check or both will fail. There is one
> > exception to this which is if the attacker can also
> > predict the location of PDU header or data boundary in the 
> > byte stream at the same time.
> > 
> > However RDMA writes offers no such protection. Out of
> > order RDMA writes can be completed, corrupting data.
> > Even when the holes are filled and if there are mechanisms
> > to detect that there was mis-alignment of data,
> > the user is still Out of luck because the data may already
> > have been consumed.
> > 
> > Somesh

[.. remainder snipped ...]