Re: IPsec and RDDP as a transport

On Jun 5, 2004, at 3:56 AM, [email protected] wrote:

> 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.

To summarize, the vulnerability occurs when an application trusts its
remote peer to follow the upper layer protocol regarding STag access
rather than using the local interface to enforce compliance.

Or more generally, a buffer that the application intends to use is still
exposed to update from non-authenticated DDP packets.

This is indeed a new security vulnerability, the question is how to
deal with it.

The current drafts take a "well we told you not to do that" approach.
Personally, I still find this valid. But I will concede that others 
might
consider this to be inadequate. But for the record I will point out that
the RDDP layer simply cannot prevent the ULP from doing stupid
things. Consider the fundamental rule that an exposed buffer is
undefined *until* the ULP infers delivery from a untagged message
or RDMA Read completion. An application that attempts to read
smoke signals in partially update RDMA accessible buffers based
only on tagged writes is very vulnerable not only to attack but to
to unstable behavior. I doubt that anyone would propose requiring
the RDDP layer to remove read access for the ULP on undelivered
buffers that it has update access to. And the vulnerability to unstable
behavior would be there even over IPsec.

David has proposed the ULP be able to rely on the availability
of IPsec authentication of DDP packets.

I believe it would be more appropriate to require the local
interface to provide adequate tools so that applications would
neither be forced to overexpose buffers, or even be prone to
do so by the defaults of the local interface. "Defaults" here
would include omission of extra steps that an application
*should* be taking, but the local interface requires additional
steps to invoke.

The proposed restriction to "one shot" STags would be one
such local interface change, but I believe it is also to extreme.

I believe we can determine what local interface requirements
would be appropriate if we examine the current gaps:

- The application can be encouraged to rely upon the remote
    peer to invalidate an STag when the transaction is done.
    If an expected remote invalidation is not performed, the
    application is typically required to invalidate the STag
    ifself. This is typically an asynchronous operation which
    would require the application to add an extra state before
    properly utilizing the buffer only after it had been secured.

-  Some applications advertise an aggregate buffer to be
    used over the span of several untagged messages. Each
    untagged message would indicate what portion of the
    advertised buffer had been used, and at the ULP layer
    pledge not to make further writes to that portion.

    Current local interfaces lack any support for enforcement
    of this model. When the portion used by the remote peer
    on each response is variably sized, there is no way for
    the Data Sink to remove one portion of a window without
    at least momentarily making the entire STag invalid.

To address these problems I would propose the following
local interface enhancements, which could be implemented
as an alternative to authenticating DDP packets with IPsec
or other equivalent transport-layer solutions:

-- The local interface MUST provide an option where a posted
     receive operation will complete in error unless the Send
     successfully invalidated an STag.

-- The local interface MUST provide an option where a posted
     receive operation will not complete until after a specified
     STag has been invalidated.

-- The local interface MUST provide an option to rebind an
     STag to a contiguous subset of its current range without
     taking it through an intermediate invalid state.

With these tools an application can easily ensure that the
DDP exposure of an STag matches the ULP required exposure.
Given the ability to easily remove a buffer's exposure *before*
using it the application will face *no* additional security 
vulnerability
and therefore would *not* require IPsec.

That may also be true with a subset of the above. The last one
is the only requirement that cannot be implemented by a shim
layer over current verbs, and it is admittedly of the least generality.




--
Caitlin Bestler
http://asomi.com/