RE: 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
> 
> > -----Original Message-----
> > From: Uri Elzur [mailto:[email protected]]
> > Sent: Friday, June 04, 2004 6: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
> > > -----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
> > > > > ----------------------------------------------------
> > > > > 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
> > > > > ----------------------------------------------------
> > > > >
> > > > > _______________________________________________
> > > > > rddp mailing list
> > > > > [email protected] https://www1.ietf.org/mailman/listinfo/rddp
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > rddp mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/rddp
> > 
> > 
> > _______________________________________________
> > rddp mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/rddp
> > 
> > 
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>