2.7.11 Remote Direct Data Placement (rddp)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-05

Chair(s):
David Black <black_david@emc.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Jon Peterson <jon.peterson@neustar.biz>
Technical Advisor(s):
Allyn Romanow <allyn@cisco.com>
Stephen Bailey <steph@cs.uchicago.edu>
Mailing Lists:
General Discussion: rddp@ietf.org
To Subscribe: rddp-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/rddp/current/maillist.html
Description of Working Group:
The purpose of this WG is to enable Remote Direct Data Placement (rddp) capabilities with IP transport protocols, in particular with SCTP. RDDP capabilities refer to the ability to place data directly from the NIC into application buffers, without intensive CPU usage. This strategy avoids the costs of data copying and enables using IP as a method for high speed buffer to buffer transfer, allowing IP to replace special purpose networks currently in use. Remote Direct Memory Access (RDMA) is an example of this concept.

Conceptually, RDDP functionality can be viewed as consisting of two layers. First the direct data placement capability, which is accomplished through a tag and a lookup table on the NIC. Above this core functionality, an RDDP control protocol is needed to specify how the direct data placement can be used, for example READ and WRITE commands.

The work of the WG is to accomplish four items:

1) A (transport independent) protocol core to support direct data placement from the NIC into specified memory, usually application buffers.

2) A (transport independent) protocol core layered on top of the direct data placement protocol that specifies control of RDDP.

3) A mapping of the direct data placement protocol onto SCTP, for standards track, including a clear applicability statement of the expected service from the mapping.

4) A mapping of the direct data placement protocol onto TCP, for informational, because TCP's service is a less good match to RDDP, including an applicability statement of the issues regarding the service available from the mapping.

The working group will ensure that the resulting technology will be secure and will not enable new attacks on systems supporting RDDP. The WG will not modify existing Internet transport protocols, but may forward issues it discovers in such transport protocols that are not full Internet Standards to the appropriate IETF WGs for their consideration.

Goals and Milestones:
Done  Submit Internet-Draft including problem statement and architecture
Done  Submit Initial draft of Remote Direct Data Placement protocol (RDDP)
Done  Submit Initial draft of RDMA control protocol, to be named.
Done  Initial draft mapping the RDDP core and control onto SCTP including A/S
Done  Submit problem statement and architecture drafts to IESG for consideration as informational publications
Done  Initial draft of security considerations for RDDP
Done  Initial draft of informational mapping of the RDDP core and control onto TCP
Done  Initial draft of applicability statement covering both the SCTP and TCP mappings
Mar 04  Submit RDMA control protocol (named TBD) to IESG for consideration as a Proposed Standard
Mar 04  Submit Remote Data Placement Protocol (RDDP) to IESG for consideration as a Proposed Standard
Mar 04  Submit RDDP security considerations draft to IESG
Sep 04  Submit mapping of the RDDP core and RDMA control protocols onto SCTP to IESG for consideration as proposed standard
Sep 04  Submit mapping of the RDDP core and RDMA control protocols onto TCP for consideration as an informational publication
Sep 04  Submit applicability statement for RDDP core and RDMA control protocols over both SCTP and TCP for consideration as an informational publication
Oct 04  Consult Area Directors about any additional work the WG should undertake
Internet-Drafts:
  • - draft-ietf-rddp-arch-04.txt
  • - draft-ietf-rddp-problem-statement-03.txt
  • - draft-ietf-rddp-rdmap-01.txt
  • - draft-ietf-rddp-ddp-02.txt
  • - draft-ietf-rddp-applicability-01.txt
  • - draft-ietf-rddp-sctp-00.txt
  • - draft-ietf-rddp-mpa-00.txt
  • - draft-ietf-rddp-security-01.txt
  • No Request For Comments

    Current Meeting Report

    RDDP WG meeting minutes
    IETF-59, Seoul
    March 3, 15:30-17:30
    -----------------------
    
    
    Many thanks to Tom Talpey for taking these minutes.
    
    
    The agenda was: 
    
    
    - Agenda Bashing and Administrivia (5 min) 
            - Blue Sheets 
            - NOTE WELL 
    
    
    - Status of drafts (5 min) 
    
    
    - Applicability Statement (5 min) 
            
    (draft-ietf-rddp-applicability-01.txt) 
    
    
            Mostly a status update. 
    
    
    - DDP and RDMAP drafts (10 min) 
            (draft-ietf-rddp-ddp-02.txt, 
    draft-ietf-rddp-rdmap-01.txt) 
    
    
            Mostly a status update. 
    
    
    - SCTP Mapping (5 min) 
            (draft-ietf-rddp-sctp-00.txt) 
    
    
            Despite the -00 version number, this is the fourth version of this 
    draft, and it is relatively mature. 
    
    
    - TCP mapping (30 min) 
            (draft-ietf-rddp-mpa-00.txt, 
            
    draft-culley-mpa-issueresponses-00.txt) 
    
    
            The mpa-issueresponses draft is a separate draft from the 
            MPA authors describing issues raised in MPA and proposed 
    approaches.
    
    
    
    - Security (60 min) 
            (draft-ietf-rddp-security-01.txt) 
    
    
            Time allocated reflects the importance of progress on this draft. 
    
    
    ----- 
    
    
    Agenda bashed - no changes 
    Blue sheets, Note Wells, etc. 
    
    
    - Status of drafts (David Black, WG chair): 
    
    
      Problem Statement, architecture documents are in IESG discussion. 
      Feedback from IESG is in-progress and docs will be revised. 
    
    
      Main protocols (DDP, RDMAP): No open issues. Changes are expected in the 
    Security Considerations, however. 
    
    
      Applicability Statement: Probably in good shape, but please take a new 
    look in light of current progress. 
    
    
      SCTP mapping: One open issue - need for active/active startup?
      The plan is to discuss this in context of MPA, and provide the same 
    functionality via TCP and SCTP for consistency. This document will be a 
    Proposed Standard RFC. 
    
    
      MPA (TCP mapping): Open issues revolve completely around startup, not 
    operation. To be discussed today. This document will be an 
    Informational RFC. 
    
    
      Security mapping: WG chair has consulted with Area Director - this will be a 
    Proposed Standard RFC.  Because it covers endpoint behavior, it's 
    appropriate for a standards draft. Also, the IPsec mapping is 
    applicable to multiple transport protocols, so its text can and should be 
    shared in a single RFC. 
    
    
    - TCP Mapping (MPA) discussion. (David Black presenting for Paul Culley) 
      (see presentation C-MPA update040225.ppt) 
    
    
      (1) Fast FPDU return (responder need not wait for first pdu). 
      Tentative proposal: leave as-is (responder must wait). 
      No dissension in room.  This is not needed for client/server, as the 
    server expects to wait for the client.  Need to take proposal to the list. 
    
    
      (2) Active/Active startup. Tentative proposal: leave as-is (no support for 
    active/active). No dissension in room.  Note, no known applications 
    require it.  Need to take proposal to the list.
    
    
      (3) Rejected Connection bit. Dissension expressed, this leads to 
    interoperability issues because it forces a ULP to interpret private data to 
    figure out that the connection setup failed, and requires MPA to handle TCP 
    close specially (more detail in mail to list).
    
      Further discussion: 
    
      Q: If MPA does not do "teardown", why is the bit needed to free 
    resources at MPA layer? 
      A: Practically speaking, implementations will allocate and free 
    resources in MPA (e.g. connection model in kernel), this enables 
    layering and better control. 
      A: The bit will prevent some timed-wait resource consumption issues, if 
    used properly (this is about cooperating systems, not malicious 
    resource consumption attacks).
    
    
      Rough consensus in room to include the bit. Take to list. 
    
    
      See presentation for other nits in-progress (will be taken care of in 
    next revision of draft).
    
    
      NOTE: separate list consensus call emails will be sent to start and 
    focus discussion on issues (1) thru (3).  Please wait for them!
    
    
    - Security discussion (Ellen Deleganes): 
      (see presentation D-RDDP Security presentation 040302.ppt) 
    
    
      New author, Sara Bitan, joins Jim Pinkerton and Ellen. 
    
    
      Main change, the document has been reorganized. This is in response to 
    comments, and all feedback is welcomed. 
    
    
      The term "Partial Trust" was changed - needed a crisper meaning. Now 
    called "Partial Mutual Trust". Defines a cooperative set of  streams.  
    Discussion: what does this mean? Concept seems better but the name is 
    still problematic. Basically, it seems to define a set of 
    assumptions that can allow simplification (efficiency) for 
    cooperative streams. Trusting that they will not attack one another - but 
    still protecting the server. 
    
    
      "Queue"-level granularity is new (and useful) text. But, the word 
    "queue" may have to go, because the doc will be normative. We can't 
    assume a queue in normative text. Or, add text such as "the use of the word 
    'queue' does not imply that this implementation actually contains a 
    queue"... 
    
    
      New section - "security services for RDDP" - has a list of attacks 
    listed - good progress. 
    
    
      One issue in Security section - now mentions SSL. This will require more 
    text because of ordering issues. SSL is a bad match because of its stream 
    orientation.
    
    
      Section 9 - Should we require IPsec, and therefore implement this 
    section, or make it optional? Suggestion that it be made 
    "mandatory-to-implement, optional-to-use." It was observed that IPS had a 
    similar section because it needed it. Also, now that there is the IKEv2 
    specification to refer to, the problem is no longer so difficult to 
    document.  Look at IKEv2 and new "Cryptographic Algorithms for IKEv2" 
    draft.  If these are used this section in the RDDP security draft may not be 
    necessary, as an IKEv2 reference will be adequate. 
    
    
      (4) Core question: Should we say that IPsec is mandatory for RDDP? 
      Secondary question: What parts do we actually require? (IKEv2?) 
      Take to list! Also, take to NFSv4 WG the next day. (NFS has no such 
    requirement currently, and has its own RPCSEC_GSS security support). 
    
    
      The mandatory security item generated significant discussion but was 
    highly inconclusive. It was observed that 
    mandatory-to-implement would be a significant enhancement to the review 
    approval process. 
    
    
      Appendix A - remove or keep? No conclusion, but possibly best to 
    remove? 
      May want to keep some of it - taxonomy, etc., which contains useful raw 
    material for a revised Summary section. Summary section: perhaps have a 
    summarized list of MUST and SHOULD requirements, etc. 
    
    
      Partial placement text additions are an open issue. (e.g. place code, via 
    RDMA into a buffer, then attack the server in some other fashion to run 
    that code) Draft should note these as a risk and state that buffer 
    overflow protection is actually stronger with RDMA, and why 
    (byte-level protection with bounds).
    
    
      (5) Need to address "protection for shared RQ" problem. The security 
    draft
    
    
      makes a "valiant" attempt to make it a ULP issue - but can't. 
    Exhaustion of receive buffers is a key attack. Is this the job of each and 
    every ULP,
    
    
      or RDDP's? Probably the latter.  OTOH, there is general discomfort with 
    specifying this in a fashion that would require checking it in the fast 
    receive path (e.g., in hardware in a hardware-optimized 
    implementation). 
    
    
      Scenario - server mis-implements resource management, bug in one 
    handler drags down others. E.g., a multiprotocol server with busted 
    filesystem component kills HTTP, etc. "Unsafe by design", i.e. RDDP 
    should not impose non-uniform controls. 
    
    
      The goal is to specify a functionality that is guaranteed to exist, 
    though possibly overridable given sufficient trust.  Absence of any 
    required control here doesn't line up with the Partial Mutual Trust 
    concept discussed earlier.
     
      Proposed approach: Require a default implementation of this 
    protection, as part of the Privileged Resource Manager. Privileged 
    protocols can override it, but the base function is always provided.
    
    
      Does a similar situation exist for CQs? 
      (Response: yes, with suppressed completions, underprovision is 
    desirable!)
    
    
      NOTE: separate list consensus call emails will be sent to start and 
    focus discussion on issues (4) and (5).  Please wait for them!
    
    
    ---- 
    
    
    At the end of the session, the Area Director commented he was glad to see 
    significant work being done in meeting, and was pleased with the 
    progress. 
    
    
    <adjourns 17:05> 

    Slides

    Agenda
    IETF RDDP WG Draft Status
    MPA update (-00) (Marker PDU Aligned Framing for TCP)
    RDMAP/DDP Security Draft