RE: 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
>