Re: RDDP-enabled iSCSI "hole"

David,
I have tried to make some clarifications/extensions to your note below, 
with respect to iSCSI on RDMA - which is called iSCSI/iSER (iSCSI 
Extensions for RDMA).

First the Buffer is advertized to the Target (storage controller) as an 
STag (in an iSER header that is pre-pended onto the normal iSCSI PDU -- 
e.g. a Write PDU in the example case.  There may or my not be Immediate 
data within the same iSCSI PDU. 

On the target side the STag is used in possibly multiple RDMA Read 
operations, to extract the Write data from the Host buffers to the Target 
buffers.  The number and size of the RDMA reads is dependent on how much 
data is left to be extracted from the Host, and how much Cache Space is 
available at any one time at the target.  So it might take one RDMA Read 
or it might take 100+ RDMA reads.  All the RDMA reads use the same STag 
that was advertised with the iSCSI/iSER Write PDU (SCSI Write Command) but 
use different displacements. 

At the completion of the operation, the Target MUST return the status of 
the operation (in this case the status of the Write Command) in a "Send 
with Invalidate" type message that includes the STag to be invalidated.

The RNIC at the Host system is suppose to invalidate the subject STag, and 
when the status message is delivered to the iSCSI/iSER Host Initiator it 
is required to check the STag that was invalidated by the RNIC, and if for 
some reason it was not the STag associated with the I/O operation, 
iSCSI/iSER is supposed to overtly cause the STag that was advertised, to 
be invalidated.
So either the RNIC does the invalidate automatically, or the application 
performs the invalidate.  But NO STag is suppose to live beyond the Actual 
SCSI I/O operation. 

It was expected that subsequent SCSI I/O operations would use another 
STag. 

The important point, however, is that multiple RDMA Read operations can be 
done by the Target back to the Host initiator using the same STag.  But 
the STag is always invalidated after any specific transaction (SCSI I/O 
operation). 

This then has perhaps lead to some confusion in our interchange here, 
where I an others wanted to be sure that the term "Single Shot STag" 
limitation was not used to prevent the multiple RDMA Read operations done 
to complete a SCSI Write.  Yet we are probably content to state that the 
invalidate is done after every transaction where a SCSI type transaction 
is completed by the returned Status in a Send (with invalidate) type 
message.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/System Group, San Jose CA
Main Office: (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688
Alt Office: (408) 997-6136, Cell: (408) 499-9702
Internet Address: [email protected]



[email protected] 
Sent by: [email protected]
06/06/2004 01:40 PM

To
[email protected], [email protected]
cc

Subject
[rddp] RDDP-enabled iSCSI "hole"






Uri,

> I'd like to chime in on this important discussion. I'm sorry,
> but I do fail to see the "new" security hole. 

Here's a scenario where long-lived RDDP STags cause a potential
iSCSI security "hole" that can't occur with single-shot STags or
in the absence of RDDP.  I'm going one step beyond Somesh and
assuming that the iSCSI data CRC is still being used with RDDP
(in contrast to Somesh's assumption that the RDDP CRC(s)
replace(s) the iSCSI data CRC - that assumption opens the "hole"
wider because the RDDP CRC is checked earlier):

(1) An STag is used to transfer data for an iSCSI write.
                 The STag is left valid after the data is transfer so
                 that the initiator and target can reuse this buffer
                 and its STag for the next write (a fairly obvious and
                 desirable optimization).
(2) The iSCSI target checks the received data against the
                 iSCSI CRC.  The check succeeds, so the target code
                 requests a local disk write operation from the buffer
                 that is still exposed via the STag
(3) Before the write operation takes place, a TCP packet from
                 the MITM attacker (e.g., connection hijacker) shows up
                 and uses the STag to overwrite part of the write buffer.

At this point, there is corrupt data headed for the disk.  In
the absence of long-lived STags, the TCP packet at step (3)
gets rejected by RDDP.  In the absence of RDDP, that TCP packet
gets through, but won't corrupt the iSCSI write data.  Hence
RDDP's long-lived STags have opened up a new security problem.

This problem appears to be generic to any reuse of a write
buffer and its associated STag.  If an application protocol
uses RDDP to transfer data that is actually interpreted by 
the application protocol, there are versions of this attack
that target protocol functionality if the implementation
contains code that assumes the contents of the receive
buffer don't change.

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 Uri Elzur
> Sent: Friday, June 04, 2004 9:56 PM
> To: Somesh Gupta; [email protected]
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> Somesh
> 
> If a packet is hijacked, what will prevent the CRC match??!! 
> So why will
> the iSCSI over TCP data not be accepted? CRC has no cryptographic
> value...
> 
> Uri
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of
> Somesh Gupta
> Sent: Friday, June 04, 2004 6:28 PM
> To: [email protected]
> Subject: RE: [rddp] IPsec and RDDP as a transport
> 
> 
> It seems that for iSCSI specifically, RDMA writes icrease the
> possibility of data corruption, even with 'one-shot' STags. Consider
> iSCSI over TCP, with header and data CRC. If a random TCP 
> packet is used
> to attack the connection, and the packet is accepted (large windows
> etc), the CRC checks will fail and the problem detected before a
> corruption occurs.
> 
> Now consider iSCSI using iSER over RDDP. iSCSI depends on RDDP for CRC
> checks. An attack on the connection (out of order RDMA writes) could
> place data in the write buffers and if this happens, the attack will
> never be detected.
> 
> Maybe this problem is iSCSI specific only.
> 
> Somesh

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

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