Security Concern: RDMA Read Data Sink STag

Caitlin Bestler <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
There is an additional security vulnerability dealing
with RDMA Reads that should be added to the security
draft. This one deals with deliberate abuse on the
part of the remote peer.


A common security practice for servers that deal with
multiple clients from a single daemon will be to
simply refrain from advertising server buffers. The
DAFS protocol is one example of this  strategy.
However, the strategy is likely to be common.
Advertising a tagged buffer is a resource commitment.
Making precise resource commitments to many transient
clients in parallel will tie up any server's resources
quickly.

Under this strategy, the server instead accepts
advertisements of tagged buffers in each client
request (delivered as an untagged message). The server
then performs the necessary data transfers to/from the
client's buffers before sending the response via a
RDMA Send with Invalidate.

Because the daemon is supporting many clients, and
because it is not advertising buffers, it is likely
that it will create only a single Protection Domain.

Under most RDMA-enabled local interfaces, the Data
Sink STag is provided by the consumer in the work
request for the RDMA Read. It is a general purpose
STag.

This is not a vulnerability to any form of accidental
or benign attack. The Data Sink STag given in a RDMA
Read Request should never be exposed to the peer ULP.
It should be seen no higher than the Data Source RDMAP
layer.

A deliberate attacker, however, could eavesdrop on
traffic to determine the value of a currently exposed
RDMA Read STag.

That STag could then be used on a different DDP
Stream.

Neither the RDMAP or DDP drafts require an RDMA Read
Data Sink STag be valid for any purpose other than a
single RDMA Read Reply. However, neither requires that
the STag be invalid for other purposes.

Indeed, clearly it is acceptable for the local
interface to place responsibility for managing the
scope and duration of Data Sink STags on the ULP.

The ULP needs to consider the scope of the Data Sink
STag that will be used in RDMA Reads when RDMA Reads
will be used in an environment where hostile attacks
are possible. Options offered by the local interface
to limit the scope and/or duration of the STag should
be employed as appropriate.




Caitlin Bestler - [email protected] - http://asomi.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.