The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols
draft-ietf-rddp-arch-07

Note: This ballot was opened for revision 07 and is now closed.

(Steven Bellovin; former steering group member) Discuss

I"m not convinced the security considerations is adequate.

I see several threat issues.  The first is the tension between direct copy and packet authentication.  In many cases, it is not possible to authenticate a packet until the entire thing has been read.  But here, the data is being copied to a receiving buffer directly from the wire, before authentication takes place.  This is especially a challenge to a multi-threaded interface --- ATM where the cells for some packet are not consecutive, perhaps -- where you might get interleaving.

More generally, authorization for access to storage has to be dependent on the connection as well as the steering tag.  Otherwise, you introduce new vulnerabilities.  This is especially problematic given that receive buffers may (according to the document) be used for data from a different socket.

Aside: I think that many of these issues, as well as the multiple receiver problem (and I do not accept the argument that requiring many different clients to use the same address is in any way comparable to any existing problem in that space), would go away if the steering tag sent over the wire to the receiver were not just opaque, but by intent a random 64- or 128-bit tag to a local buffer descriptor.  That permits easy local revocation of capabilities, as well as a defense against remote contamination attempts if the value were communicated previously over an encrypted channel.

(Allison Mankin; former steering group member) Yes

(Jon Peterson; former steering group member) Yes

(Bert Wijnen; former steering group member) No Objection

(Margaret Cullen; former steering group member) No Objection

(Ned Freed; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

  The use of TLS (as discussed briefly in the security considerations) or 
  any other protocol that provides authentication will not fit well into
  the proposed architecture.  The integrity check cannot be performed until
  the entire packet (or record in the case of TLS) is available in memory.
  So, the data must be copied from the I/O interface to memory, which may
  involve some reassembly, before the integrity check can be performed.
  This issue should be discussed in the security considerations.

(Ted Hardie; former steering group member) (was Discuss) No Objection

(Sam Hartman; former steering group member) Abstain

I did not find this document clear at all.  I was unable to easily
tell whether Steve Bellovin's discuss text had been addressed because
I found the document too confusing.  I suspect that at some technical
level the text has been address in that you could find changes in the
document and understand how they address Steve's comments.  However
I'm not convinced that anyone who read the document without Steve's
comments would be aware of the issues.