Protocol Action: 'DDP/RDMAP Security' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce