RE: Long-lived Stags: Why?

 

The RDMAP/DDP protocol allows a multi-gigabyte data transfer to occur as
one RDMAP/DDP Message. If we're going over a dial-up line at roughly 8
KB/sec, this means that the "one-shot" approach allows an attack on the
STag to occur for roughly 69 hours (2 gig transfer). Thus I don't see
how one-shot significantly decreases the threat profile.

 

 

 

Additionally, I thought it would be worthwhile to expound a bit on the
reasons for a long(er) lived STag. David Black stated:

 

> 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)Thought it might be worthwhile to expound a bit on
how 

 

In terms of when longer-lived STag could be used, one person on this
thread (I can't find the exact quote) more-or-less stated it comes down
to interpreting when to invalidate the STag and how that maps to the
semantics that the ULP requires. Below are a few examples on how hard
that interpretation can be (and why a simple one-shot RDMAP message
substantially reduces the cases where RDMA has a compeling
differentiation).

 

One example data transfer model is a Data Sink buffer that is huge (say,
2 GB), and the remote entity that is filling the buffer (the Data
Source) wants to slice the transfer into smaller units, say 64 KB (this
also happens to be a transfer model for ISCSI, including the proposed
iSER protocol). Thus when to invalidate? 

-        On first use? This makes slicing the buffer into smaller
transfers from the remote peers perspective impossible. 

-        On nth use? This requires the Data Sink to know how the data
source handles its buffers. In general a bad idea. 

-        Let the sender specify? Already in the protocol with Remote
Invalidate. 

 

In general it seems like there is often data transfer between machines
with very different buffering capabilities. Thus allowing multi-shot
STags is a good thing.

 

Another data transfer model is double buffering of data structures where
latency is important. For example, a remote entity (for example, a
sensor) is updating a central resource, and the central resource would
like the most recent data, but doesn't want to incur the additional
overhead/latency skew of reading the remote sensor. A persistent STag
can dramatically reduce latency skew and quite possibly total latency.

 

Another data transfer example is a shared time server. A central server
keeps a global time count in a cluster, and time skew between nodes in a
cluster is a primary concern. If the server advertises a remote STAG to
allow all cluster clients to RDMA Read its current time, timer skew can
be significantly reduced because there is no work that needs to be
scheduled on the time server if an RNIC is used (for example, receive a
packet, process it, send out the current time). 

 

I think in general you can probably state any algorithm can be
implemented with short-lived STags - but there are several significant
algorithms that take a serious performance hit.

 

Thus I'm not at all in favor of requiring one-shot. It substantially
reduces the benefit of the protocol to provide new capabilities.

 

 

 

 

 

Jim

 

 

 

 

> -----Original Message-----

> From: [email protected] [mailto:[email protected]] On Behalf
Of

> [email protected]

> Sent: Monday, June 07, 2004 9:38 PM

> To: [email protected]

> Subject: [rddp] 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 ...]

> 

> 

> _______________________________________________

> rddp mailing list

> [email protected]

> https://www1.ietf.org/mailman/listinfo/rddp

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