Remote Direct Data Placement

headers Hemal Shah | 3 Jul 2006 04:18

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

Here's a report on the status of our drafts, coming near the
end of the Montreal IETF meeting week:

The Security and Applicability drafts are close to approval.
There is one outstanding Discuss against the Security draft
that should be cleared shortly, and there are a number of
RFC Editor Notes that will appear as clarifications.

The RDMAP and DDP drafts are close to IETF Last Call.  The
remaining step is that the authors of the RDMAP draft need
to send a note to the list containing the comments that were
considered in the revision and how they were dealt with, ASAP.
The corresponding email for the DDP draft was:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02445.html

The SCTP draft is basically done, and is likely to go to IETF
Last Call with the RDMAP and DDP drafts.

The MPA draft is going to need another significant revision,
in accordance with what I explained in:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02442.html

I was able to talk to Joe Touch (the primary TCPM) reviewer,
and worked out an approach - the approach is documented in
these slides, which were used at the TCPM meeting today,
and engendered no objection:

http://www3.ietf.org/proceedings/06jul/slides/tcpm-4.pdf

A couple of important notes that go with this approach:
- The Appendix is free to use whatever language is necessary
	to explain how to optimize MPA with TCP, but needs
	to avoid RFC 2119 requirements words (e.g., MUST,
	SHOULD).
- The Appendix needs to contain a sentence saying that if
	any of its implementation optimization guidance appears
	to contradict any of the RFCs that specify TCP, the
	TCP RFCs are the authority.
With that, MPA is essentially finished with Expert Review,
but does require fairly extensive revision.

I will work directly with the MPA draft authors on that revision
as there's a fair amount to be done, and it's important to get
it right, but the path forward is now clear.

Thanks,
--David (rddp WG chair) 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

The IESG has received a request from the Remote Direct Data Placement WG to 
consider the following documents:

- 'A Remote Direct Memory Access Protocol Specification '
   <draft-ietf-rddp-rdmap-06.txt> as a Proposed Standard
- 'Direct Data Placement over Reliable Transports '
   <draft-ietf-rddp-ddp-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-08-02.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rddp-rdmap-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-rddp-ddp-06.txt

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)

The IESG has received a request from the Remote Direct Data Placement WG to 
consider the following document:

- 'Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) 
   Adaptation '
   <draft-ietf-rddp-sctp-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2006-08-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rddp-sctp-06.txt

Update:

The Applicability and Security drafts have been approved for
publication as RFCs and should be in the RFC Editor's Queue
shortly.

The RDMAP and DDP drafts are in IETF Last Call, ending August 2nd.

The SCTP draft is in IETF Last Call, ending August 9th.

The MPA draft should be revised in the next few weeks.

We're making progress.

Thanks,
--David

-----Original Message-----
From: Black_David <at> emc.com [mailto:Black_David <at> emc.com] 
Sent: Thursday, July 13, 2006 7:37 PM
To: rddp <at> ietf.org
Subject: [rddp] Draft status report

Here's a report on the status of our drafts, coming near the
end of the Montreal IETF meeting week:

The Security and Applicability drafts are close to approval.
There is one outstanding Discuss against the Security draft
that should be cleared shortly, and there are a number of
RFC Editor Notes that will appear as clarifications.

The RDMAP and DDP drafts are close to IETF Last Call.  The
remaining step is that the authors of the RDMAP draft need
to send a note to the list containing the comments that were
considered in the revision and how they were dealt with, ASAP.
The corresponding email for the DDP draft was:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02445.html

The SCTP draft is basically done, and is likely to go to IETF
Last Call with the RDMAP and DDP drafts.

The MPA draft is going to need another significant revision,
in accordance with what I explained in:

http://www1.ietf.org/mail-archive/web/rddp/current/msg02442.html

I was able to talk to Joe Touch (the primary TCPM) reviewer,
and worked out an approach - the approach is documented in
these slides, which were used at the TCPM meeting today,
and engendered no objection:

http://www3.ietf.org/proceedings/06jul/slides/tcpm-4.pdf

A couple of important notes that go with this approach:
- The Appendix is free to use whatever language is necessary
	to explain how to optimize MPA with TCP, but needs
	to avoid RFC 2119 requirements words (e.g., MUST,
	SHOULD).
- The Appendix needs to contain a sentence saying that if
	any of its implementation optimization guidance appears
	to contradict any of the RFCs that specify TCP, the
	TCP RFCs are the authority.
With that, MPA is essentially finished with Expert Review,
but does require fairly extensive revision.

I will work directly with the MPA draft authors on that revision
as there's a fair amount to be done, and it's important to get
it right, but the path forward is now clear.

Thanks,
--David (rddp WG chair) 
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

2	December 2011
8	June 2009
3	May 2009
3	April 2009
25	March 2009
7	February 2009
4	January 2009
10	December 2008
1	October 2008
1	September 2008
2	November 2007
7	October 2007
3	September 2007
2	June 2007
7	May 2007
1	April 2007
8	January 2007
5	October 2006
6	September 2006
4	August 2006
6	July 2006
31	June 2006
7	May 2006
18	April 2006
6	March 2006
1	February 2006
1	January 2006
3	December 2005
3	November 2005
12	October 2005
11	September 2005
8	August 2005
2	July 2005
2	June 2005
5	May 2005
12	April 2005
32	March 2005
12	February 2005
10	January 2005
29	December 2004
36	November 2004
39	October 2004
22	September 2004
37	August 2004
19	July 2004
60	June 2004
32	May 2004
59	April 2004
26	March 2004
31	February 2004
59	January 2004
4	December 2003
22	November 2003
34	October 2003
7	September 2003
22	August 2003
121	July 2003
97	June 2003
133	May 2003
98	April 2003
15	March 2003
122	February 2003
58	January 2003
233	December 2002
151	November 2002
91	October 2002
50	September 2002
5	August 2002
20	July 2002

Summary of AD comments addressed in draft-ietf-rddp-ddp-06.txt

Draft status report

Last Call: 'Direct Data Placement over Reliable Transports' to Proposed Standard (draft-ietf-rddp-ddp)

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

Last Call: 'Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation' to Proposed Standard (draft-ietf-rddp-sctp)

Draft status report - update