RE: IPsec and RDDP as a transport

David, All

I'd like to chime in on this important discussion. I'm sorry, but I do
fail to see the "new" security hole. The response I've seen on 5/9 to
Caitilin's real good discussion, was that a "buffer overflow" is the
risk. I believe this is wrong. The RDMA layer will guarantee with its
checks and bounds this cannot happen (if other layer is used on top of
DDP, it needs to provide similar mechanisms). To take a step back, there
are potentially two types security threats: on the wire and on end
station. 
 
1) Network: A connection + resources are allocated only after the remote
is proven to be trustworthy with mechanisms outside the scope of DDP. So
what if some man-in-the-middle spoofs the STags (no need to deal with
spoofing IP or Transport as this is NOT a DDP issue). The probability is
higher the longer the STag is exposed, hence the discussion about
shingle shot (but note that even single shot doesn't limit the time the
exposure is there...). The key in my mind is that in order to spoof the
STag, you have to hijack the connection, as it is only the combination
of TCP/IP + STag that opens the buffer. Therefore, it seems like this is
no different than TCP/IP hijack and is not a new risk model

2) End station: we probably need a statement about demarcation of
responsibilities between the application and the wire protocol. I
believe, it's the responsibility of the wire protocol not to expose the
end station and any of its other resources  (including other processes
or threads, other devices etc.) except for the resources allocated by
the application or the comm stack. Actually TCP as one example, has the
flexibility to allocate resources to a connection even when no resources
has been allocated by the application. However, TCP guarantees the
application will not be given more data than resources it hands to TCP
stack. DDP is layered on top of a reliable transport (TCP, SCTP etc.)
and is not allocating any resources on its own. So does the DDP wire
protocol bear any additional responsibilities that other transports
never had? In other words, who owns the application resources: the
application or a performance enhancement protocol like RDDP? To me the
answer is clear and the application should have a free hand to expose
its buffers, AS LONG as actions of a single application do not expose
other (which is an OS issue not a wire protocol issue). IPSec will not
solve this problem...
 
 
SO what do I miss? Before this WG subscribes a bitter pill, it better
clarify what illness it is trying to cure.  
 
Uri

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, June 02, 2004 7: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