The IESG has approved the following documents: - 'DDP/RDMAP Security ' <draft-ietf-rddp-security-10.txt> as a Proposed Standard - 'Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) ' <draft-ietf-rddp-applicability-08.txt> as an Informational RFC These documents are products of the Remote Direct Data Placement Working Group. The IESG contact persons are Jon Peterson and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-10.txt Technical Summary The RDDP Applicability document provides a description of why RDDP is needed, what services it supplies, and how it interacts with layers above and below it. It furthermore shows how RDDP compares with the use of traditional RDMA (not over IP) and the use of traditional Internet transport in the absence of RDDP. The RDDP Security document provides guidance on the threats and countermeasuresin the RDDP space, and prescribes normative guidance for RDDP implementations. Working Group Summary The RDDP WG supports the advancement of these documents as primary outputs of the WG. Protocol Quality Jon Peterson performed AD review of these documents. Derek Atkins reviewed the security draft on behalf of the Security Directorate. Joel Halpern reviewed bothdrafts on behalf of GEN-ART. Note to RFC Editor RFC Editor Notes for draft-ietf-rddp-applicability-08.txt (1) Section 1, after: o RDMAP defines RDMA Reads, which allow remote access to advertised buffers. This document will review the advantages of using RDMA Reads as contrasted to alternate solutions. Add the following sentence as a separate paragraph: A more comprehensive introduction to the RDMAP and DDP protocols and discussion of their security considerations can be found in [6]. (2) In section 6.6.1 and 6.7.1 remove usage of RFC 2119 terms as follows. OLD: It is mandatory for MPA/TCP implementations to implement CRC32c, but it is NOT mandatory to use the CRC32c during an RDMA connection. ^^^ Change: not OLD: Applications SHOULD trust that this administrative option will only NEW: Applications should assume that disabling CRC32c will only OLD: Applications SHOULD NOT apply additional protection as a guard against this administrative option being turned on inadvertently. NEW: Applications should not use additional integrity checks based solely on the possibility that CRC32c could be disabled without equivalent integrity checks at a lower level. OLD: Administrators MUST NOT enable CRC32c suppression unless the end-to- end protection is truly equivalent. NEW: CRC32c must not be disabled unless equivalent or better end-to-end integrity protection is provided. OLD: If both ends have been configured NOT to use the CRC, then this is ^^^ Change: not OLD (6.7.1): As covered elsewhere in this document, flow control of untagged messages MUST be provided by the ULP itself. NEW: As covered elsewhere in this document, flow control of untagged messages is the responsibility of the ULP. (3) Section 3.2 OLD: Content access applications are primary examples of applications with both high bandwidth and a high ratio of content transferred per required ULP interaction. NEW: Content access applications are important examples of applications that require high bandwidth and can transfer a significant amount of content between required ULP interactions. (4) Section 4.3 OLD: A ULP where all exchanges would naturally be untagged messages would derive virtually no benefit from the use of RDMAP/DDP as opposed to SCTP directly. NEW: If a ULP cannot effectively use tagged messages, it would derive little benefit from use of RDMAP/DDP by comparison to direct use of SCTP. (5) Section 6.9.1 OLD: However, the same source/destination pair of ports can be re-used sequentially subject to normal TCP rules. NEW: However, the same source/destination pair of ports can be re-used for a subsequent TCP connection, as allowed by TCP. RFC-Editor note for rddp-security: In Section 5.4.2, do the following 1) Change "[RFC 2246]" to "[RFC 4346]" 2) Remove the paragraph starting with "1. The maximum length supported" 3) Make the following change to the resulting text: OLD: If TLS is layered underneath RDMAP, there are at least two limitations that make TLS inappropriate for DDP/RDMA security: 2. TLS is a connection oriented protocol. NEW: If TLS is layered underneath RDMAP, TLS's connection orientation makes TLS inappropriate for DDP/RDMA security. Add the following informative reference: [RFC 4346] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. In Section 5.4.1, make the following change: OLD: 2. Per-packet data source authentication - protects against the following spoofing attacks: network based impersonation (Section 5.1.1), Stream hijacking (Section 5.1.2), and man in the middle (Section 5.1.3). 3. Per-packet integrity - protects against tampering done by network based modification of buffer content (Section 5.2) NEW: 2. Per-packet data source authentication - protects against the following spoofing attacks: network based impersonation (Section 5.1.1) and Stream hijacking (Section 5.1.2). 3. Per-packet integrity - protects against tampering done by network based modification of buffer content (Section 5.2) and when combined with authentication, also protects against man in the middle (Section 5.1.3). IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
