[rddp] DRAFT Seoul minutes
Black_David@emc.com Mon, 22 March 2004 13:59 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24936 for <rddp-archive@odin.ietf.org>; Mon, 22 Mar 2004 08:59:55 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Pxf-00034Y-9e for rddp-archive@odin.ietf.org; Mon, 22 Mar 2004 08:59:27 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MDxRLl011811 for rddp-archive@odin.ietf.org; Mon, 22 Mar 2004 08:59:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Pxf-00034Q-3n for rddp-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 08:59:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24932 for <rddp-web-archive@ietf.org>; Mon, 22 Mar 2004 08:59:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Pxd-0004Wi-00 for rddp-web-archive@ietf.org; Mon, 22 Mar 2004 08:59:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Pwl-0004SJ-00 for rddp-web-archive@ietf.org; Mon, 22 Mar 2004 08:58:32 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5PwH-0004NJ-00 for rddp-web-archive@ietf.org; Mon, 22 Mar 2004 08:58:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PwG-0002t4-TT; Mon, 22 Mar 2004 08:58:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Pvm-0002ro-76 for rddp@optimus.ietf.org; Mon, 22 Mar 2004 08:57:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24857 for <rddp@ietf.org>; Mon, 22 Mar 2004 08:57:28 -0500 (EST)
From: Black_David@emc.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Pvk-0004LN-00 for rddp@ietf.org; Mon, 22 Mar 2004 08:57:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Puu-0004Ft-00 for rddp@ietf.org; Mon, 22 Mar 2004 08:56:37 -0500
Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1B5Pu8-00044I-00 for rddp@ietf.org; Mon, 22 Mar 2004 08:55:48 -0500
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <H1JWS2MB>; Mon, 22 Mar 2004 08:55:13 -0500
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA7A575C@corpmx14.us.dg.com>
To: rddp@ietf.org
Date: Mon, 22 Mar 2004 08:55:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [rddp] DRAFT Seoul minutes
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60
Please respond to this message *only* to correct mistakes/ omissions about what happened in Seoul or to ask clarifying questions. There are five major issues (numbered in the minutes) about which I will be sending out individual emails. Please wait for them before discussing these issues, as we need to drive most of them to rough consensus on the list well before the San Diego meeting in August, although the IPsec requirements issue may be difficult. Thanks, --David RDDP WG meeting minutes - DRAFT 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). General agreement in room to include this bit. 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. 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. What's new in -01. (Changes listed in the presentation.) 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) new 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. Also, is there an issue to check w/NFSv4 WG? Take to NFSv4 WG meeting next day. 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. Go look at IKEv2 and new "Crypto Suites draft" now entering Last Call. In this case, the section becomes unnecessary, and 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 "Clip and Save" list of MUSTs and SHOULDs, etc. Partial placement text additions are still 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 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. Consumers 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> _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp
- [rddp] DRAFT Seoul minutes Black_David