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/