RE: IPsec and RDDP as a transport

Barry Reinhold said:
> I don't think I fully understand the problem yet -
> So for a short summary we are addressing vulnerability when:
>
> 1. IPsec is not in use
> 2. There is a MITM attack (hijacked TCP connection)
> 3. A "long lived" STag (one that is not invalidated after first use) is
> being used.
>

A vulnerability when:

1) There can be unauthenticated DDP Segments (i.e. whenever IPsec
     or an equivalent is not in use, except when the entire network
     is secured against spoofing by controlled switches/etc.)
2)  The Data Sink ULP has received an RDMA Written buffer (that is,
     per the Upper Layer Protocol it understood the completion of
     an untagged message to indicate that said buffer had been written)
     but the buffer is still exposed.

Why would an applicatioh leave a buffer that is "closed" under
the rules of the ULP "open" as far as RDDP is concerned?

a) It trusts its peer and has neglected to consider the possiblity
    of a MITM attack, or even that its peer could have bugs.
b) Properly closing the window may require extra steps with
    the local interface.

The security draft already details the required tools for an application
to protect itself. I do not believe that there is any dispute that these
tools are adequate, merely that they may encourage developers to
take insecure shortcuts.

A strong argument can be made that a local interface that leads
a novice user to the insecure option is a security vulnerability.
For example, most people would condemn an email server that
on installation was configured as an open relay. Merely telling
the user that they should configure their relay policy is not enough,
an open relay is a configuration that should only be enabled by
a sophisticated user who understands the implications of an
open relay.

Essentially, persistent STags are a very poor default, and are
quite likely to lead a novice user into inadvertently leaving
security vulnerabilities in their system.

> And this vulnerability is distinct from the case where:
> 1. IPsec is not in use
> 2. There is a MITM attack (hijacked TCP connection)
> 3. A "short lived" STag is being used.
>

The "short lived" STag is not more secure because it is
short lived, but rather because it is closed at the same
time that the ULP considers the buffer to be closed.

An application that examines an RDMA Writable buffer
while it is "open" according to the Upper Layer Protocol
is not only vulnerable to malicious attack, it is quite likely
unstable and vulnerable to vendor variations and numerous
timing glitches.

But if the application only examines the buffer *after*
both the ULP *and* STag window have been closed is
safe. To be precise: it is as safe as it would have been
running over the LLP directly.

RDDP is not responsible for making ULPs be secure,
but it is responsible for not introducing *new*
security vulnerabilities.

> Two questions:
>
> 1. What exactly is the MITM allowed to do? Obviously they can see the
> traffic flow and they can spoof a packet in the context of a TCP
> connection such that the receiver is happy with that. If they can do
> those two things, I assume they can also drop and source, selectively,
> packets being sent on the connection in either direction. Is this
> correct?
>

All existing LLP attacks (TCP or SCTP) still apply. The application
designer must evaluaate their vulnerability to such attacks, and
the consequences should they be compromised. Certain applications
will rightfully decide that they should only be run over secure connections,
independently of whether RDDP is in use or not.

> 2. The "badness" that we are looking at is undetected corrupt data on
> disk. Is this correct?
>

The "badness" is unauthorized data access that the application is
no longer in a position to detect because RDDP has relieved it of
handling data placement.

The solution is to ensure that applications have reasonalbe tools
to control access to their buffers so that they are never forced to,
or even encouraged to, examine a buffer that is still RDDP exposed
(in the absence of packet-authentication).

> If this is the case, the points that I'm fuzzy on are:
>
> 1. Why does invalidating a STag after first use make a difference? It
> would seem like the vulnerability is introduced when the ULP advertised
> the STag.
>

Ensuring that an STag's exposure matches the ULP defined exposure
is the goal. If the ULP considers a buffer to be "open" for 33 messages,
then there is nothing run with it being open at the RDDP level for 33
messages.

> 2. I also don't understand why the STag, which is an identifier to a
> buffer, is distinct from the ITT which also ends up being an identifier
> to a buffer. One may be under the control of a protocol layer, but how
> does this change the corruption problem?
>

The ITT is a ULP create, therefore I would assume its exposure is
properly controlled by the ULP. If that isn't the case, that should
be discussed in IPS, not here.