Re: IPsec and RDDP as a transport

I view the iSCSI/iSER/iWARP vulnerability qualitatively no different 
from that of iSCSI+sync-and-steering/TCP, under a given set of operating 
assumptions (IPSec, threat assumptions, attacker smarts, "tag" recycling 
frequency etc.).  In the former, the placement is done based on STags 
and in the latter, the placement is done based on ITTs.  In the former, 
the "tag" is the STag and in the latter, it's the ITT.  Neither can 
provide absolute guarantees.

More description of the exact scenario of concern/vulnerability will 
help me see the problem.  Thanks.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


Somesh Gupta wrote:

> 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
> 
>>-----Original Message-----
>>From: [email protected] [mailto:[email protected]]On Behalf Of
>>[email protected]
>>Sent: Friday, June 04, 2004 5:56 PM
>>To: [email protected]; [email protected]
>>Subject: RE: [rddp] IPsec and RDDP as a transport
>>
>>
>>Dwight,
>>
>>
>>>Sorry to be dense, but I'm still having trouble visualizing the attack
>>>that makes DDP more vulnerable. I think it has been relegated to a man
>>>in the middle attack scenario, as bogus data from the real peer always
>>>gets through, even with IPSEC enabled. The transport layer behavior is
>>>the same with/without DDP headers; a packet with an appropriate
>>>transport sequence number gets ACKed and passed upstream to be placed
>>>in a buffer. The buffer eventually gets passed to the application.
>>
>>The difference happens here.  If the STag is 'long-lived' or 'persistent'
>>and has not been invalidated, the buffer can still be modified remotely
>>*after* being passed to the application.  Such modification is not
>>possible in the absence of DDP.  If the STag is 'one-shot' (in whatever
>>sense that restriction is defined), the important property is that the
>>application can rely on the data not being changed by remote access
>>after the buffer has been passed to the application.  If the WG
>>is prepared to restrict all STags to be 'one-shot' so that at the point
>>where the buffer is passed to the application, the STag used to deliver
>>the data MUST be invalid (and the RDDP implementation is responsible
>>for ensuring this), then it should be possible to avoid additional
>>security requirements in this area.
>>
>>[... snip ...]
>>
>>
>>>Why is DDP being asked to implement a mandatory
>>>solution that protects the transport from MITM attacks?
>>
>>Protection of the transport is not being required.  What is being
>>required is to be able to protect the application from exploitation of
>>memory exposure enabled by RDDP functionality that is beyond that of
>>the underlying transport.  If RDDP is willing to forego that additional
>>functionality, there should no longer be a problem that needs a
>>mandatory solution.
>>
>>
>>>I acknowledge
>>>that DDP is in a gray area between transport and ULP, but either way,
>>>there should be consistency for all new ULPs and/or transports. Where is
>>>the cry for mandatory IPSEC on SCTP?
>>
>>The ULP can choose how it wants to secure its data.  TLS is among the
>>possibilities and can be used over SCTP.  Beyond this, if SCTP runs over
>>IPv6, IPsec is mandatory, and I would expect that if any of the IP
>>Storage protocols (iSCSI, FCIP, iFCP) are defined over SCTP, IPsec
>>will remain mandatory for them.  In any case, IPsec is sufficient,
>>but not necessary for RDDP.  A mechanism that prevents MITM misuse
>>of RDDP headers is a possible alternative.
>>
>>
>>>BTW - my recollection of the year old Stag security issue was related to
>>>the necessary isolations/associations of an Stag with each transport
>>>stream, a local peer security issue.
>>
>>That was a related, but different issue.  The ability to control
>>STag association with transport streams is still necessary.
>>
>>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: Barron, Dwight [mailto:[email protected]]
>>>Sent: Friday, June 04, 2004 7:51 PM
>>>To: [email protected]; [email protected]
>>>Subject: RE: [rddp] IPsec and RDDP as a transport
>>>
>>>
>>>Sorry to be dense, but I'm still having trouble visualizing the attack
>>>that makes DDP more vulnerable. I think it has been relegated to a man
>>>in the middle attack scenario, as bogus data from the real peer always
>>>gets through, even with IPSEC enabled. The transport layer behavior is
>>>the same with/without DDP headers; a packet with an appropriate
>>>transport sequence number gets ACKed and passed upstream to be placed in
>>>a buffer. The buffer eventually gets passed to the application. The only
>>>difference I see is in the buffer model, random access within the scope
>>>of an Stag vs. being put in a pre-posted buffer. Either way, the wrong
>>>data gets passed to the upper layer because of spoofing that got past
>>>the transport layer. Why is DDP being asked to implement a mandatory
>>>solution that protects the transport from MITM attacks? I acknowledge
>>>that DDP is in a gray area between transport and ULP, but either way,
>>>there should be consistency for all new ULPs and/or transports. Where is
>>>the cry for mandatory IPSEC on SCTP?
>>>
>>>BTW - my recollection of the year old Stag security issue was related to
>>>the necessary isolations/associations of an Stag with each transport
>>>stream, a local peer security issue.
>>>
>>>Regards,
>>>Dwight
>>>
>>>
>>>>-----Original Message-----
>>>>From: [email protected] [mailto:[email protected]] On
>>>>Behalf Of [email protected]
>>>>Sent: Wednesday, June 02, 2004 9:32 AM
>>>>To: [email protected]
>>>>Subject: RE: [rddp] IPsec and RDDP as a transport
>>>>
>>>>
>>>>Caitlin Bestler writes:
>>>>
>>>>
>>>>>That would only be true if the DDP header posed a new
>>>>
>>>>security risk,
>>>>
>>>>>one not faced by an equivalent LLP-only application.
>>>>>
>>>>>I do not believe that this analysis is shared by the WG.
>>>>>I certainly do not accept it.
>>>>>
>>>>>A DDP Header has no magic access to user memory. Just as any
>>>>>above-transport-header, it only has access to user memory to the
>>>>>extent authorized by the ULP.
>>>>>
>>>>>I do not believe that you, or anyone else, has disputed that
>>>>>assertion.
>>>>
>>>>The latter assertion is correct, but it does not imply that
>>>>a DDP header creates no risks beyond an equivalent LLP-only
>>>>application.  For an LLP-only application transport buffers
>>>>are always one-shot and receive addresses in memory are
>>>>determined by the receiver, not the sender.  If the WG were
>>>>prepared to limit itself to this behavior by requiring that
>>>>all STags be one-shot, then the position that there are no
>>>>new security risks should be defensible.  The WG does not
>>>>appear to be prepared to make this restriction.
>>>>
>>>>More importantly, relying on the "authorized by the ULP"
>>>>assertion is not acceptable to the IESG.  That approach
>>>>amounts to an instruction to ULP developers not to use
>>>>long-lived STags if they are a potential cause of security
>>>>problems and also an instruction to users not to use ULPs
>>>>that employ long-lived STags if long-lived STags will cause
>>>>security problems on their network(s).  I've recently had to
>>>>deal with another draft that tried this sort of "don't use
>>>>feature <X> if it will cause security problems" approach; the
>>>>IESG rejected that approach, and the security considerations
>>>>section of the draft had to be revised.
>>>>
>>>>The bottom line is that long-lived STags create additional
>>>>memory exposure that is not present in an equivalent LLP-only
>>>>application.  The fact that the ULP chose to create the
>>>>exposure does not absolve RDDP of providing security measures
>>>>to deal with it.  IETF requires that protocols which create
>>>>security issues deal with those security issues and not palm
>>>>them off on other protocols (e.g., by asserting that all
>>>>security issues created by long-lived RDDP STags are ULP
>>>>problems because the ULP chose to use them).
>>>>
>>>>I've just updated and resubmitted
>>>>draft-ietf-rddp-rdma-concerns (will appear shortly as a -01
>>>>version) - it contains nearly 2-year-old text in its security
>>>>considerations section pointing out this memory exposure issue.
>>>>
>>>>Thanks,
>>>>--David