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)