RE: [rddp] IPsec and RDDP as a transport

["Somesh Gupta" <[e-mail]>]

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

> -----Original Message-----
> From: Uri Elzur [mailto:uri at broadcom.com]
> Sent: Friday, June 04, 2004 6:56 PM
> To: Somesh Gupta; rddp at ietf.org
> 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: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On Behalf Of
> Somesh Gupta
> Sent: Friday, June 04, 2004 6:28 PM
> To: rddp at ietf.org
> 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
> > -----Original Message-----
> > From: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org]On Behalf Of
> 
> > Black_David at emc.com
> > Sent: Friday, June 04, 2004 5:56 PM
> > To: dwight.barron at hp.com; rddp at ietf.org
> > 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
> > [phone]             FAX: [phone]
> > black_david at emc.com        Mobile: [phone]
> > ----------------------------------------------------
> >
> > > -----Original Message-----
> > > From: Barron, Dwight [mailto:dwight.barron at hp.com]
> > > Sent: Friday, June 04, 2004 7:51 PM
> > > To: Black_David at emc.com; rddp at ietf.org
> > > 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: rddp-bounces at ietf.org [mailto:rddp-bounces at ietf.org] On 
> > > > Behalf Of Black_David at emc.com
> > > > Sent: Wednesday, June 02, 2004 9:32 AM
> > > > To: rddp at ietf.org
> > > > 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
> > > > ----------------------------------------------------
> > > > David L. Black, Senior Technologist
> > > > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > > > [phone]             FAX: [phone]
> > > > black_david at emc.com        Mobile: [phone]
> > > > ----------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > rddp mailing list
> > > > rddp at ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/rddp
> > > >
> > >
> >
> > _______________________________________________
> > rddp mailing list
> > rddp at ietf.org
> > https://www1.ietf.org/mailman/listinfo/rddp
> 
> 
> _______________________________________________
> rddp mailing list
> rddp at ietf.org
> https://www1.ietf.org/mailman/listinfo/rddp
> 
> 

_______________________________________________
rddp mailing list
rddp at ietf.org
https://www1.ietf.org/mailman/listinfo/rddp