From exim@www1.ietf.org Sat May 1 14:50:09 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18829 for ; Sat, 1 May 2004 14:50:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzWw-0006iC-O7 for rddp-archive@odin.ietf.org; Sat, 01 May 2004 14:48:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41Im6AU025800 for rddp-archive@odin.ietf.org; Sat, 1 May 2004 14:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzOX-0002sr-2b for rddp-web-archive@optimus.ietf.org; Sat, 01 May 2004 14:39:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18333 for ; Sat, 1 May 2004 14:39:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJzOU-00020i-EW for rddp-web-archive@ietf.org; Sat, 01 May 2004 14:39:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJzNR-0001jk-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 14:38:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJzMW-0001XR-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 14:37:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJz9d-0005Nn-Lj; Sat, 01 May 2004 14:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJz6J-0002g8-4b for rddp@optimus.ietf.org; Sat, 01 May 2004 14:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14520 for ; Sat, 1 May 2004 14:20:28 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJz4w-0004mj-QC for rddp@ietf.org; Sat, 01 May 2004 14:19:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJz2O-0003ma-00 for rddp@ietf.org; Sat, 01 May 2004 14:16:33 -0400 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 1BJyx4-0002EU-00 for rddp@ietf.org; Sat, 01 May 2004 14:11:02 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 May 2004 14:10:29 -0400 Message-ID: To: rddp@ietf.org Date: Sat, 1 May 2004 14:10:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] issue (5) - Protection for shared RQ, closure 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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 One more attempt at restating the requirement: The proposed requirement is that the Privileged Resource Manager contain code sufficient so that a non-RDDP application can be converted to an RDDP application without enabling a denial of service attack that disconnects innocent clients or having to write inter-client receive resource protection code. This is a "MUST implement" requirement, so that the functionality is available to any RDDP application; applications MAY use this protection, but are not required to do so. As noted previously: a) With my WG chair hat on, I'm going to say that solving this shared RQ resource protection problem is a requirement on the rddp WG's output. This is a fairly fundamental system robustness issue, even within a single application. And on this basis, I believe the above restatement of the requirement represents rough consensus of the rddp WG. This requirement will also apply to shared completion queue protection. Any further objections to this should be posted to the list, but please be clear about whether the objection is to the obligation to solve this problem (a), or to the solution (Privileged Resource Manager MUST implement Shared RQ protection). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat May 1 15:22:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20872 for ; Sat, 1 May 2004 15:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzpE-0003tJ-4q for rddp-archive@odin.ietf.org; Sat, 01 May 2004 15:07:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41J705x014952 for rddp-archive@odin.ietf.org; Sat, 1 May 2004 15:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzfi-0001ad-Gf for rddp-web-archive@optimus.ietf.org; Sat, 01 May 2004 14:57:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19092 for ; Sat, 1 May 2004 14:57:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJzff-0005Xh-NK for rddp-web-archive@ietf.org; Sat, 01 May 2004 14:57:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJzeh-0005Ma-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 14:56:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJzeB-0005C2-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 14:55:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzXp-0007BA-IH; Sat, 01 May 2004 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJzOK-0002q3-2O for rddp@optimus.ietf.org; Sat, 01 May 2004 14:39:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18189 for ; Sat, 1 May 2004 14:39:06 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJzJM-0000x1-Sk for rddp@ietf.org; Sat, 01 May 2004 14:34:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJzIN-0000kK-00 for rddp@ietf.org; Sat, 01 May 2004 14:33:04 -0400 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 1BJzHN-0000Mo-00 for rddp@ietf.org; Sat, 01 May 2004 14:32:01 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 May 2004 14:31:32 -0400 Message-ID: To: rddp@ietf.org Date: Sat, 1 May 2004 14:31:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] Security draft issue (4) - IPsec 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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 On to the last, and most difficult open issue from Seoul - what should RDDP (specifically the security draft) have to say about a mandatory-to-implement security mechanism. Here's an extract from the minutes: 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?) I have heard a couple of comments on this that deserve some further elaboration. - Q: RDDP is part of the transport, can't we defer the security requirements to whatever the ULP above the transport requires? - A: Yes, but that would only cover the payloads, as the ULP won't know anything about RDDP headers. To follow this approach, either we have to have a way to protect the RDDP headers or to make their protection unnecessary (e.g., as SSL/TLS makes protection of TCP headers unnecessary). The latter approach will have to deal with RDDP enabling direct placement of network data into ULP/application memory, which seems to be a resource that deserves protection. - Q: Isn't IKEv2 a lot to ask of implementers? - A: Possibly - the discussion in Seoul was around the fact that IKEv2 should clean up a lot of IKEv1's interoperability problems, possibly obviating the need to profile IKEv1. OTOH, IKEv2 is a relatively new protocol. This is for discussion. I observe that the IESG will insist on a solid answer to "What is the mandatory-to-implement security for RDDP?". Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat May 1 17:30:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25863 for ; Sat, 1 May 2004 17:30:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK22T-0004j1-Gd for rddp-archive@odin.ietf.org; Sat, 01 May 2004 17:28:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41LSnFt018159 for rddp-archive@odin.ietf.org; Sat, 1 May 2004 17:28:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK200-000327-2X for rddp-web-archive@optimus.ietf.org; Sat, 01 May 2004 17:26:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25780 for ; Sat, 1 May 2004 17:26:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK1zx-0003D8-P1 for rddp-web-archive@ietf.org; Sat, 01 May 2004 17:26:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK1yy-00030w-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 17:25:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BK1y2-0002or-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 17:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK1qK-00088N-C4; Sat, 01 May 2004 17:16:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK1jU-00052x-P7 for rddp@optimus.ietf.org; Sat, 01 May 2004 17:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25284 for ; Sat, 1 May 2004 17:09:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK1jS-0007hk-Il for rddp@ietf.org; Sat, 01 May 2004 17:09:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK1iD-0007Hh-00 for rddp@ietf.org; Sat, 01 May 2004 17:07:54 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BK1fW-0006j9-00 for rddp@ietf.org; Sat, 01 May 2004 17:05:06 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 897E911E60C; Sat, 1 May 2004 17:05:02 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93922-01; Sat, 1 May 2004 17:05:01 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 3946911E698; Sat, 1 May 2004 17:05:01 -0400 (EDT) Received: from [192.168.122.32] (unknown [212.143.154.147]) by host52a.simplicato.com (Postfix) with ESMTP id 8E07311E67E; Sat, 1 May 2004 17:04:56 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <27012E16-9BB3-11D8-B0D0-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: Black_David@emc.com From: Caitlin Bestler Subject: Re: [rddp] Security draft issue (4) - IPsec Date: Sun, 2 May 2004 00:04:36 +0300 To: RDDP X-Mailer: Apple Mail (2.613) X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On May 1, 2004, at 9:31 PM, Black_David@emc.com wrote: > On to the last, and most difficult open issue from Seoul - what > should RDDP (specifically the security draft) have to say about > a mandatory-to-implement security mechanism. Here's an extract > from the minutes: > > 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?) > > I have heard a couple of comments on this that deserve some further > elaboration. > > - Q: RDDP is part of the transport, can't we defer the security > requirements to whatever the ULP above the transport requires? > - A: Yes, but that would only cover the payloads, as the ULP won't > know anything about RDDP headers. To follow this approach, > either we have to have a way to protect the RDDP headers or to > make their protection unnecessary (e.g., as SSL/TLS makes > protection of TCP headers unnecessary). The latter approach > will have to deal with RDDP enabling direct placement of network > data into ULP/application memory, which seems to be a resource > that deserves protection. > - Q: Isn't IKEv2 a lot to ask of implementers? > - A: Possibly - the discussion in Seoul was around the fact that IKEv2 > should clean up a lot of IKEv1's interoperability problems, > possibly obviating the need to profile IKEv1. OTOH, IKEv2 is > a relatively new protocol. > > This is for discussion. I observe that the IESG will insist on a > solid answer to "What is the mandatory-to-implement security for > RDDP?". > > Actually, I have the opposite question/objection. RDDP rides on top of standard reliable IP Transports (SCTP and TCP). So why should a problem solved at those layers also be solved by RDDP? The one sense that RDDP is "transport layer" is that it is below the application layer. As such, it should not be making any presumption that RDDP applications need more security or authentication than the transport layer itself would provide. Until IPsec is mandatory-to-implement for IP hosts I see no justification for making it mandatory tor RDDP endpoints. And of course if it were mandatory-to- implement for IP Hosts, RDDP would not have to implement it. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat May 1 17:35:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26064 for ; Sat, 1 May 2004 17:35:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK23p-00057M-Qe for rddp-archive@odin.ietf.org; Sat, 01 May 2004 17:30:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41LUDCp019668 for rddp-archive@odin.ietf.org; Sat, 1 May 2004 17:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK22x-0004je-Rz for rddp-web-archive@optimus.ietf.org; Sat, 01 May 2004 17:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25858 for ; Sat, 1 May 2004 17:29:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK22v-0003oC-FH for rddp-web-archive@ietf.org; Sat, 01 May 2004 17:29:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK21y-0003cK-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 17:28:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BK21j-0003Qr-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 17:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK1qM-000894-I5; Sat, 01 May 2004 17:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK1jh-00053V-0V for rddp@optimus.ietf.org; Sat, 01 May 2004 17:09:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25347 for ; Sat, 1 May 2004 17:09:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK1je-000013-O3 for rddp@ietf.org; Sat, 01 May 2004 17:09:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK1iZ-0007PZ-00 for rddp@ietf.org; Sat, 01 May 2004 17:08:16 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BK1fx-0006oF-00 for rddp@ietf.org; Sat, 01 May 2004 17:05:33 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id C072011E35E; Sat, 1 May 2004 17:05:29 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94075-01; Sat, 1 May 2004 17:05:28 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 6994B11E685; Sat, 1 May 2004 17:05:28 -0400 (EDT) Received: from [192.168.122.32] (unknown [212.143.154.147]) by host52a.simplicato.com (Postfix) with ESMTP id 4A87011E334; Sat, 1 May 2004 17:05:21 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <325FC0BB-9BB3-11D8-B0D0-000393814604@asomi.com> Content-Transfer-Encoding: 7bit Cc: Black_David@emc.com From: Caitlin Bestler Subject: Re: [rddp] Security draft issue (4) - IPsec Date: Sun, 2 May 2004 00:04:55 +0300 To: RDDP X-Mailer: Apple Mail (2.613) X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On May 1, 2004, at 9:31 PM, Black_David@emc.com wrote: > On to the last, and most difficult open issue from Seoul - what > should RDDP (specifically the security draft) have to say about > a mandatory-to-implement security mechanism. Here's an extract > from the minutes: > > 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?) > > I have heard a couple of comments on this that deserve some further > elaboration. > > - Q: RDDP is part of the transport, can't we defer the security > requirements to whatever the ULP above the transport requires? > - A: Yes, but that would only cover the payloads, as the ULP won't > know anything about RDDP headers. To follow this approach, > either we have to have a way to protect the RDDP headers or to > make their protection unnecessary (e.g., as SSL/TLS makes > protection of TCP headers unnecessary). The latter approach > will have to deal with RDDP enabling direct placement of network > data into ULP/application memory, which seems to be a resource > that deserves protection. > - Q: Isn't IKEv2 a lot to ask of implementers? > - A: Possibly - the discussion in Seoul was around the fact that IKEv2 > should clean up a lot of IKEv1's interoperability problems, > possibly obviating the need to profile IKEv1. OTOH, IKEv2 is > a relatively new protocol. > > This is for discussion. I observe that the IESG will insist on a > solid answer to "What is the mandatory-to-implement security for > RDDP?". > > Actually, I have the opposite question/objection. RDDP rides on top of standard reliable IP Transports (SCTP and TCP). So why should a problem solved at those layers also be solved by RDDP? The one sense that RDDP is "transport layer" is that it is below the application layer. As such, it should not be making any presumption that RDDP applications need more security or authentication than the transport layer itself would provide. Until IPsec is mandatory-to-implement for IP hosts I see no justification for making it mandatory tor RDDP endpoints. And of course if it were mandatory-to- implement for IP Hosts, RDDP would not have to implement it. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat May 1 18:33:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28924 for ; Sat, 1 May 2004 18:33:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK2tp-0007ma-7E for rddp-archive@odin.ietf.org; Sat, 01 May 2004 18:23:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i41MNvmE029911 for rddp-archive@odin.ietf.org; Sat, 1 May 2004 18:23:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK2cw-0005lC-Hn for rddp-web-archive@optimus.ietf.org; Sat, 01 May 2004 18:06:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27320 for ; Sat, 1 May 2004 18:06:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK2ct-00038s-Ra for rddp-web-archive@ietf.org; Sat, 01 May 2004 18:06:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK2c0-0002wR-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 18:05:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BK2bZ-0002il-00 for rddp-web-archive@ietf.org; Sat, 01 May 2004 18:05:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK2Ul-0007Xn-JI; Sat, 01 May 2004 17:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BK2P7-0004Un-Vd for rddp@optimus.ietf.org; Sat, 01 May 2004 17:52:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26587 for ; Sat, 1 May 2004 17:52:11 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BK2P5-0000OM-F6 for rddp@ietf.org; Sat, 01 May 2004 17:52:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BK2O6-0000CR-00 for rddp@ietf.org; Sat, 01 May 2004 17:51:11 -0400 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by ietf-mx with esmtp (Exim 4.12) id 1BK2N5-0007cq-00 for rddp@ietf.org; Sat, 01 May 2004 17:50:07 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 May 2004 17:49:33 -0400 Message-ID: To: cait@asomi.com, rddp@ietf.org Subject: RE: [rddp] Security draft issue (4) - IPsec Date: Sat, 1 May 2004 17:49:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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 Caitlin, > Until IPsec is mandatory-to-implement for IP hosts I see no > justification for making it mandatory for RDDP endpoints. And > of course if it were mandatory-to-implement for IP Hosts, RDDP > would not have to implement it. IPsec is mandatory-to-implement for IPv6 hosts, FWIW. The IESG will not approve standards-track RFCs that lack mandatory-to- implement security measures, although it's possible to reference measures that already exist elsewhere in the environment. If RDDP introduced no new risks above and beyond TCP or SCTP over IPv4, then falling back to the security requirements of those underlying protocols might be acceptable - I don't believe this to be the case, though (i.e., there are new RDDP-specific security risks). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Saturday, May 01, 2004 5:05 PM > To: RDDP > Cc: Black_David@emc.com > Subject: Re: [rddp] Security draft issue (4) - IPsec > > > > On May 1, 2004, at 9:31 PM, Black_David@emc.com wrote: > > > On to the last, and most difficult open issue from Seoul - what > > should RDDP (specifically the security draft) have to say about > > a mandatory-to-implement security mechanism. Here's an extract > > from the minutes: > > > > 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?) > > > > I have heard a couple of comments on this that deserve some further > > elaboration. > > > > - Q: RDDP is part of the transport, can't we defer the security > > requirements to whatever the ULP above the transport requires? > > - A: Yes, but that would only cover the payloads, as the ULP won't > > know anything about RDDP headers. To follow this approach, > > either we have to have a way to protect the RDDP headers or to > > make their protection unnecessary (e.g., as SSL/TLS makes > > protection of TCP headers unnecessary). The latter approach > > will have to deal with RDDP enabling direct placement of network > > data into ULP/application memory, which seems to be a resource > > that deserves protection. > > - Q: Isn't IKEv2 a lot to ask of implementers? > > - A: Possibly - the discussion in Seoul was around the fact > that IKEv2 > > should clean up a lot of IKEv1's interoperability problems, > > possibly obviating the need to profile IKEv1. OTOH, IKEv2 is > > a relatively new protocol. > > > > This is for discussion. I observe that the IESG will insist on a > > solid answer to "What is the mandatory-to-implement security for > > RDDP?". > > > > > > Actually, I have the opposite question/objection. > > RDDP rides on top of standard reliable IP Transports (SCTP and TCP). > > So why should a problem solved at those layers also be solved by RDDP? > > The one sense that RDDP is "transport layer" is that it is below the > application > layer. As such, it should not be making any presumption that RDDP > applications > need more security or authentication than the transport layer itself > would provide. > > Until IPsec is mandatory-to-implement for IP hosts I see no > justification for > making it mandatory tor RDDP endpoints. And of course if it were > mandatory-to- > implement for IP Hosts, RDDP would not have to implement it. > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sun May 9 04:22:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23133 for ; Sun, 9 May 2004 04:22:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjWz-0001Ve-1i for rddp-archive@odin.ietf.org; Sun, 09 May 2004 04:19:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i498JSVX005802 for rddp-archive@odin.ietf.org; Sun, 9 May 2004 04:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjTA-0001Dl-Ab for rddp-web-archive@optimus.ietf.org; Sun, 09 May 2004 04:15:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22903 for ; Sun, 9 May 2004 04:15:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjT7-0006kU-Ig for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:15:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjS7-0006MR-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:14:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMjR0-0005fs-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:13:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjPm-0000pd-3R; Sun, 09 May 2004 04:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjON-0000ey-39 for rddp@optimus.ietf.org; Sun, 09 May 2004 04:10:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22660 for ; Sun, 9 May 2004 04:10:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjOK-0004rj-H6 for rddp@ietf.org; Sun, 09 May 2004 04:10:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjNL-0004S1-00 for rddp@ietf.org; Sun, 09 May 2004 04:09:32 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BMjMD-0003oc-00 for rddp@ietf.org; Sun, 09 May 2004 04:08:21 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id AE20711E5B3; Sun, 9 May 2004 04:08:21 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87945-05; Sun, 9 May 2004 04:08:20 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 0E61711ED05; Sun, 9 May 2004 04:08:19 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 5739111ECF1; Sun, 9 May 2004 04:08:19 -0400 (EDT) Received: from 82.166.251.29 (proxying for 82.166.251.29) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Sun, 9 May 2004 03:08:19 -0500 (CDT) Message-ID: <61710.82.166.251.29.1084090099.squirrel@mail52a.simplicato.com> In-Reply-To: References: Date: Sun, 9 May 2004 03:08:19 -0500 (CDT) Subject: RE: [rddp] Security draft issue (4) - IPsec From: "Caitlin Bestler" To: Black_David@emc.com Cc: cait@asomi.com, rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David@emc.com said: > Caitlin, > >> Until IPsec is mandatory-to-implement for IP hosts I see no >> justification for making it mandatory for RDDP endpoints. And >> of course if it were mandatory-to-implement for IP Hosts, RDDP >> would not have to implement it. > > IPsec is mandatory-to-implement for IPv6 hosts, FWIW. The IESG > will not approve standards-track RFCs that lack mandatory-to- > implement security measures, although it's possible to reference > measures that already exist elsewhere in the environment. > > If RDDP introduced no new risks above and beyond TCP or SCTP > over IPv4, then falling back to the security requirements of > those underlying protocols might be acceptable - I don't > believe this to be the case, though (i.e., there are new > RDDP-specific security risks). > > Thanks, > --David I do not see any RDDP specific vulnerabilities that are relevant to the use of IPsec. A non-RDDP application enables reception of peer messages into application buffers. Given the nature of non-RDDP LLPs, use of intermediate system buffering is likely. Once received, the Application judges the applicability of transport layer security to its needs. It may determine that the transport has provided sufficient authentication of the remote peer to allow acting upon the received messages without further validation, or it may decide to apply its own validation. So what changes with RDDP? Nothing, except that the intermediate system buffering is far less likely. That *improves* security, not worsens it. Whether or not IPsec is in use, the Application already has full control of which of its buffers are exposed, to what extent, and for how long. Procedures to precisely control that exposure are already documented in the security draft and are not dependent on the use of IPsec or other transport layer security. There are also several problems with mandating IPsec implemenetation. First, what is the meaning of the mandate when the RDDP implementation is cleanly layered over the LLP (or even when it is integrated with the LLP, but they are cleanly layered over IP)? Surely we are not going to require that an RDDP implementation refuse to use a valid TCP or IP stack because it lacks IPsec support. Secondly, we need to recognize that authentication and privacy can be fully achieved in many IP networks without any support for IPsec in the host through physical security, managed switches and in-network IPsec devices. In fact there are strong arguments why network implemented security is superior to host implemented security. Further, many RDDP deployments will be in precisely these sort of controlled environments. Lastly, requiring RDDP vendors to implement IPsec will in merely force mediocre implementations to be integrated and pre-empt the use of superior IPsec implemetnations that are not integrated. For all of these reasons, I strongly believe that RDDP should remain oblivious to LLP provided security, and merely use whatever is there. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sun May 9 04:26:47 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23216 for ; Sun, 9 May 2004 04:26:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjdG-0003mL-1o for rddp-archive@odin.ietf.org; Sun, 09 May 2004 04:25:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i498PvEu014523 for rddp-archive@odin.ietf.org; Sun, 9 May 2004 04:25:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjaz-0003eI-Ka for rddp-web-archive@optimus.ietf.org; Sun, 09 May 2004 04:23:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23174 for ; Sun, 9 May 2004 04:23:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjaw-0001ny-Pq for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:23:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjZx-0001SO-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:22:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMjZg-00016r-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 04:22:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjVZ-0001OD-S7; Sun, 09 May 2004 04:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMjSI-000186-AD for rddp@optimus.ietf.org; Sun, 09 May 2004 04:14:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22893 for ; Sun, 9 May 2004 04:14:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMjSF-0006Nd-JS for rddp@ietf.org; Sun, 09 May 2004 04:14:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMjRO-00061T-00 for rddp@ietf.org; Sun, 09 May 2004 04:13:43 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BMjQr-0005eg-00 for rddp@ietf.org; Sun, 09 May 2004 04:13:09 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 5CFE311E8C6; Sun, 9 May 2004 04:13:10 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92626-03; Sun, 9 May 2004 04:13:09 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 5030C11E8F5; Sun, 9 May 2004 04:13:09 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 6A34511E64A; Sun, 9 May 2004 04:13:08 -0400 (EDT) Received: from 82.166.251.29 (proxying for 82.166.251.29) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Sun, 9 May 2004 03:13:08 -0500 (CDT) Message-ID: <12755.82.166.251.29.1084090388.squirrel@mail52a.simplicato.com> Date: Sun, 9 May 2004 03:13:08 -0500 (CDT) Subject: RE: [rddp] Security draft issue (4) - IPsec From: "Caitlin Bestler" To: Black_David@emc.com Cc: cait@asomi.com, rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.7 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David@emc.com said: > Caitlin, > >> Until IPsec is mandatory-to-implement for IP hosts I see no >> justification for making it mandatory for RDDP endpoints. And >> of course if it were mandatory-to-implement for IP Hosts, RDDP >> would not have to implement it. > > IPsec is mandatory-to-implement for IPv6 hosts, FWIW. The IESG > will not approve standards-track RFCs that lack mandatory-to- > implement security measures, although it's possible to reference > measures that already exist elsewhere in the environment. > > If RDDP introduced no new risks above and beyond TCP or SCTP > over IPv4, then falling back to the security requirements of > those underlying protocols might be acceptable - I don't > believe this to be the case, though (i.e., there are new > RDDP-specific security risks). > > Thanks, > --David I do not see any RDDP specific vulnerabilities that are relevant to the use of IPsec. A non-RDDP application enables reception of peer messages into application buffers. Given the nature of non-RDDP LLPs, use of intermediate system buffering is likely. Once received, the Application judges the applicability of transport layer security to its needs. It may determine that the transport has provided sufficient authentication of the remote peer to allow acting upon the received messages without further validation, or it may decide to apply its own validation. So what changes with RDDP? Nothing, except that the intermediate system buffering is far less likely. That *improves* security, not worsens it. Whether or not IPsec is in use, the Application already has full control of which of its buffers are exposed, to what extent, and for how long. Procedures to precisely control that exposure are already documented in the security draft and are not dependent on the use of IPsec or other transport layer security. There are also several problems with mandating IPsec implemenetation. First, what is the meaning of the mandate when the RDDP implementation is cleanly layered over the LLP (or even when it is integrated with the LLP, but they are cleanly layered over IP)? Surely we are not going to require that an RDDP implementation refuse to use a valid TCP or IP stack because it lacks IPsec support. Secondly, we need to recognize that authentication and privacy can be fully achieved in many IP networks without any support for IPsec in the host through physical security, managed switches and in-network IPsec devices. In fact there are strong arguments why network implemented security is superior to host implemented security. Further, many RDDP deployments will be in precisely these sort of controlled environments. Lastly, requiring RDDP vendors to implement IPsec will in merely force mediocre implementations to be integrated and pre-empt the use of superior IPsec implemetnations that are not integrated. For all of these reasons, I strongly believe that RDDP should remain oblivious to LLP provided security, and merely use whatever is there. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sun May 9 17:37:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23145 for ; Sun, 9 May 2004 17:37:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMvyB-0005wJ-11 for rddp-archive@odin.ietf.org; Sun, 09 May 2004 17:36:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i49LaMjU022831 for rddp-archive@odin.ietf.org; Sun, 9 May 2004 17:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMvoR-0005S2-Jp for rddp-web-archive@optimus.ietf.org; Sun, 09 May 2004 17:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22910 for ; Sun, 9 May 2004 17:26:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMvoP-000150-9U for rddp-web-archive@ietf.org; Sun, 09 May 2004 17:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMvnL-0000kK-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 17:25:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BMvmP-0000R4-00 for rddp-web-archive@ietf.org; Sun, 09 May 2004 17:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMvlE-00059d-Kv; Sun, 09 May 2004 17:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BMvjP-00052E-F4 for rddp@optimus.ietf.org; Sun, 09 May 2004 17:21:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22705 for ; Sun, 9 May 2004 17:21:04 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BMvjN-0007K0-5Y for rddp@ietf.org; Sun, 09 May 2004 17:21:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BMviV-00072H-00 for rddp@ietf.org; Sun, 09 May 2004 17:20:11 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BMvhb-0006RP-00 for rddp@ietf.org; Sun, 09 May 2004 17:19:15 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Sun, 9 May 2004 17:18:37 -0400 Message-ID: To: cait@asomi.com Cc: rddp@ietf.org Subject: RE: [rddp] Security draft issue (4) - IPsec Date: Sun, 9 May 2004 17:18:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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 Caitlin, > I do not see any RDDP specific vulnerabilities that are relevant > to the use of IPsec. > > A non-RDDP application enables reception of peer messages into > application buffers. Given the nature of non-RDDP LLPs, use > of intermediate system buffering is likely. > > Once received, the Application judges the applicability of > transport layer security to its needs. It may determine that > the transport has provided sufficient authentication of the > remote peer to allow acting upon the received messages without > further validation, or it may decide to apply its own validation. > > So what changes with RDDP? > > Nothing, except that the intermediate system buffering is > far less likely. That *improves* security, not worsens it. > > Whether or not IPsec is in use, the Application already > has full control of which of its buffers are exposed, > to what extent, and for how long. Procedures to precisely > control that exposure are already documented in the security > draft and are not dependent on the use of IPsec or other > transport layer security. I think this misses the point by focusing on data instead of control. The thing that has changed is that RDDP exposes a new functional interface for use over the network, providing more opportunities for abuse by a rogue peer who misuses the interface or an attacker who modifies the headers in transit - the security exposure here involves the headers and the additional functionality they enable. In contrast to other new functionality, the application has no possibility to perform "its own validation" on use of the RDDP placement interface because the application never sees the RDDP headers. > There are also several problems with mandating IPsec > implemenetation. > > First, what is the meaning of the mandate when the RDDP > implementation is cleanly layered over the LLP (or > even when it is integrated with the LLP, but they > are cleanly layered over IP)? > > Surely we are not going to require that an RDDP implementation > refuse to use a valid TCP or IP stack because it lacks > IPsec support. That's correct. If the RFCs that define RDDP require that IPsec be implemented, and an implementation that lacks IPsec nonetheless claims to meet the requirements of the RFCs, that claim is false. How a customer chooses to deal with a vendor who makes false claims is up to the customer. I would not foresee a requirement for RDDP to check for IPsec support. > Secondly, we need to recognize that authentication and > privacy can be fully achieved in many IP networks without > any support for IPsec in the host through physical security, > managed switches and in-network IPsec devices. In fact there > are strong arguments why network implemented security is > superior to host implemented security. > > Further, many RDDP deployments will be in precisely these > sort of controlled environments. That is why an IPsec requirement would be "MUST implement" not "MUST use" - so that IPsec would be available outside such controlled environments without its usage being mandated in such controlled environments. > Lastly, requiring RDDP vendors to implement IPsec will > in merely force mediocre implementations to be integrated > and pre-empt the use of superior IPsec implemetnations that > are not integrated. I'll take not of your view that mediocre IPsec implementations will result from an IPsec implementation requirement, but I don't understand your "pre-empt" point, unless you were mistakenly assuming a "MUST use" requirement for IPsec. Thanks, --David > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Sunday, May 09, 2004 4:08 AM > To: Black_David@emc.com > Cc: cait@asomi.com; rddp@ietf.org > Subject: RE: [rddp] Security draft issue (4) - IPsec > > > > Black_David@emc.com said: > > Caitlin, > > > >> Until IPsec is mandatory-to-implement for IP hosts I see no > >> justification for making it mandatory for RDDP endpoints. And > >> of course if it were mandatory-to-implement for IP Hosts, RDDP > >> would not have to implement it. > > > > IPsec is mandatory-to-implement for IPv6 hosts, FWIW. The IESG > > will not approve standards-track RFCs that lack mandatory-to- > > implement security measures, although it's possible to reference > > measures that already exist elsewhere in the environment. > > > > If RDDP introduced no new risks above and beyond TCP or SCTP > > over IPv4, then falling back to the security requirements of > > those underlying protocols might be acceptable - I don't > > believe this to be the case, though (i.e., there are new > > RDDP-specific security risks). > > > > Thanks, > > --David > > I do not see any RDDP specific vulnerabilities that are relevant > to the use of IPsec. > > A non-RDDP application enables reception of peer messages into > application buffers. Given the nature of non-RDDP LLPs, use > of intermediate system buffering is likely. > > Once received, the Application judges the applicability of > transport layer security to its needs. It may determine that > the transport has provided sufficient authentication of the > remote peer to allow acting upon the received messages without > further validation, or it may decide to apply its own validation. > > So what changes with RDDP? > > Nothing, except that the intermediate system buffering is > far less likely. That *improves* security, not worsens it. > > Whether or not IPsec is in use, the Application already > has full control of which of its buffers are exposed, > to what extent, and for how long. Procedures to precisely > control that exposure are already documented in the security > draft and are not dependent on the use of IPsec or other > transport layer security. > > > There are also several problems with mandating IPsec > implemenetation. > > First, what is the meaning of the mandate when the RDDP > implementation is cleanly layered over the LLP (or > even when it is integrated with the LLP, but they > are cleanly layered over IP)? > > Surely we are not going to require that an RDDP implementation > refuse to use a valid TCP or IP stack because it lacks > IPsec support. > > Secondly, we need to recognize that authentication and > privacy can be fully achieved in many IP networks without > any support for IPsec in the host through physical security, > managed switches and in-network IPsec devices. In fact there > are strong arguments why network implemented security is > superior to host implemented security. > > Further, many RDDP deployments will be in precisely these > sort of controlled environments. > > Lastly, requiring RDDP vendors to implement IPsec will > in merely force mediocre implementations to be integrated > and pre-empt the use of superior IPsec implemetnations that > are not integrated. > > For all of these reasons, I strongly believe that RDDP should > remain oblivious to LLP provided security, and merely use > whatever is there. > > > > -- > Caitlin Bestler > http://asomi.com/ > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon May 10 01:47:08 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11112 for ; Mon, 10 May 2004 01:47:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3aH-0008Ml-HJ for rddp-archive@odin.ietf.org; Mon, 10 May 2004 01:44:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A5iDrh032157 for rddp-archive@odin.ietf.org; Mon, 10 May 2004 01:44:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3Xj-00089J-0z for rddp-web-archive@optimus.ietf.org; Mon, 10 May 2004 01:41:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10914 for ; Mon, 10 May 2004 01:41:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3Xf-0004mP-Sv for rddp-web-archive@ietf.org; Mon, 10 May 2004 01:41:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3X0-0004UV-00 for rddp-web-archive@ietf.org; Mon, 10 May 2004 01:40:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN3WK-0004Bv-00 for rddp-web-archive@ietf.org; Mon, 10 May 2004 01:40:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3VH-0007rM-GN; Mon, 10 May 2004 01:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN3Sm-0007D7-7q for rddp@optimus.ietf.org; Mon, 10 May 2004 01:36:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10616 for ; Mon, 10 May 2004 01:36:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN3Sj-0003E6-1R for rddp@ietf.org; Mon, 10 May 2004 01:36:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN3Rl-0002v8-00 for rddp@ietf.org; Mon, 10 May 2004 01:35:26 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BN3Qq-0002dI-00 for rddp@ietf.org; Mon, 10 May 2004 01:34:28 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 843CC11E213; Mon, 10 May 2004 01:34:27 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08272-07; Mon, 10 May 2004 01:34:26 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id CB84911E251; Mon, 10 May 2004 01:34:26 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 73B2F11E236; Mon, 10 May 2004 01:34:26 -0400 (EDT) Received: from 82.166.251.29 (proxying for 82.166.251.29) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Mon, 10 May 2004 00:34:26 -0500 (CDT) Message-ID: <33623.82.166.251.29.1084167266.squirrel@mail52a.simplicato.com> In-Reply-To: References: Date: Mon, 10 May 2004 00:34:26 -0500 (CDT) Subject: RE: [rddp] Security draft issue (4) - IPsec From: "Caitlin Bestler" To: Black_David@emc.com Cc: cait@asomi.com, rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David@emc.com said: > Caitlin, > >> I do not see any RDDP specific vulnerabilities that are relevant >> to the use of IPsec. >> >> A non-RDDP application enables reception of peer messages into >> application buffers. Given the nature of non-RDDP LLPs, use >> of intermediate system buffering is likely. >> >> Once received, the Application judges the applicability of >> transport layer security to its needs. It may determine that >> the transport has provided sufficient authentication of the >> remote peer to allow acting upon the received messages without >> further validation, or it may decide to apply its own validation. >> >> So what changes with RDDP? >> >> Nothing, except that the intermediate system buffering is >> far less likely. That *improves* security, not worsens it. >> >> Whether or not IPsec is in use, the Application already >> has full control of which of its buffers are exposed, >> to what extent, and for how long. Procedures to precisely >> control that exposure are already documented in the security >> draft and are not dependent on the use of IPsec or other >> transport layer security. > > I think this misses the point by focusing on data instead of > control. The thing that has changed is that RDDP exposes > a new functional interface for use over the network, providing > more opportunities for abuse by a rogue peer who misuses the > interface or an attacker who modifies the headers in transit > - the security exposure here involves the headers and the > additional functionality they enable. In contrast to other > new functionality, the application has no possibility to > perform "its own validation" on use of the RDDP placement > interface because the application never sees the RDDP headers. > What has not changed is that no matter what is in the network packet, the exposure of application buffers to those packets is under control of the application -- not of the network packet. How precisely the application control the exposure of its buffer space, relative to its security requirements, is the real issue. The vulnerability of network packets is not an RDDP specific issue. If the application has tailored its exposure, the attacker can modify the headers endlessly. They will still only be able to deposit the payload in the buffers the Data Sink ULP intended them to be deposited into. Again, the only change from non-RDDP applications is that the use of intermediate system buffering has been eliminated. This represents *improved* security, not heightened risk. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue May 11 19:48:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07069 for ; Tue, 11 May 2004 19:48:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgnC-0000AF-TY for rddp-archive@odin.ietf.org; Tue, 11 May 2004 19:36:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BNaAbm000632 for rddp-archive@odin.ietf.org; Tue, 11 May 2004 19:36:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgic-00078I-Op for rddp-web-archive@optimus.ietf.org; Tue, 11 May 2004 19:31:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06116 for ; Tue, 11 May 2004 19:31:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgib-0000IO-6q for rddp-web-archive@ietf.org; Tue, 11 May 2004 19:31:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNghb-0007e4-00 for rddp-web-archive@ietf.org; Tue, 11 May 2004 19:30:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNggY-0007Cb-00 for rddp-web-archive@ietf.org; Tue, 11 May 2004 19:29:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgbR-00064O-L1; Tue, 11 May 2004 19:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNgQE-0003uU-Vw for rddp@optimus.ietf.org; Tue, 11 May 2004 19:12:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05276 for ; Tue, 11 May 2004 19:12:23 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNgQD-0007aT-G9 for rddp@ietf.org; Tue, 11 May 2004 19:12:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNgPB-00078E-00 for rddp@ietf.org; Tue, 11 May 2004 19:11:21 -0400 Received: from mxic2.corp.emc.com ([128.221.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1BNgOk-0006bs-00 for rddp@ietf.org; Tue, 11 May 2004 19:10:54 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 May 2004 19:08:45 -0400 Message-ID: To: cait@asomi.com Cc: rddp@ietf.org Subject: RE: [rddp] Security draft issue (4) - IPsec Date: Tue, 11 May 2004 19:10:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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 Caitlin, Could you explain a couple of things: > Nothing, except that the intermediate system buffering is > far less likely. That *improves* security, not worsens it. How does this improve security? What is(are) the threat(s) whose risk is reduced by eliminating intermediate buffering? > What has not changed is that no matter what is in the network > packet, the exposure of application buffers to those packets > is under control of the application -- not of the network > packet. > > How precisely the application control the exposure of its > buffer space, relative to its security requirements, is the > real issue. The vulnerability of network packets is not > an RDDP specific issue. > > If the application has tailored its exposure, the attacker > can modify the headers endlessly. They will still only be > able to deposit the payload in the buffers the Data Sink > ULP intended them to be deposited into. What are the implications of that "If"? What does an application have to do to match the buffer exposure of TCP or SCTP via the sockets interface? Under what circumstances is that reasonable (e.g., what other usage patterns does RDDP intend to enable)? What are the potential consequences of allowing more buffer exposure? Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed May 12 02:02:45 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26428 for ; Wed, 12 May 2004 02:02:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmoF-0006wA-Tw for rddp-archive@odin.ietf.org; Wed, 12 May 2004 02:01:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4C61dIK026666 for rddp-archive@odin.ietf.org; Wed, 12 May 2004 02:01:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmmI-0005wC-Qt for rddp-web-archive@optimus.ietf.org; Wed, 12 May 2004 01:59:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23457 for ; Wed, 12 May 2004 01:59:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNmmF-0006kI-HE for rddp-web-archive@ietf.org; Wed, 12 May 2004 01:59:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNmlI-0006Jz-00 for rddp-web-archive@ietf.org; Wed, 12 May 2004 01:58:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNmkl-0005tf-00 for rddp-web-archive@ietf.org; Wed, 12 May 2004 01:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmeu-0004o6-US; Wed, 12 May 2004 01:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNmdk-0004UA-9B for rddp@optimus.ietf.org; Wed, 12 May 2004 01:50:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23108 for ; Wed, 12 May 2004 01:50:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNmdg-0002hy-Um for rddp@ietf.org; Wed, 12 May 2004 01:50:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNmcj-0002FP-00 for rddp@ietf.org; Wed, 12 May 2004 01:49:46 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BNmbv-0001lF-00 for rddp@ietf.org; Wed, 12 May 2004 01:48:55 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id CD7CC11E05B; Wed, 12 May 2004 01:48:53 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58870-03; Wed, 12 May 2004 01:48:52 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 4CCB111E05A; Wed, 12 May 2004 01:48:52 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id CEE7911E055; Wed, 12 May 2004 01:48:51 -0400 (EDT) Received: from 82.166.249.161 (proxying for 82.166.249.161) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Wed, 12 May 2004 00:48:51 -0500 (CDT) Message-ID: <11080.82.166.249.161.1084340931.squirrel@mail52a.simplicato.com> In-Reply-To: References: Date: Wed, 12 May 2004 00:48:51 -0500 (CDT) Subject: RE: [rddp] Security draft issue (4) - IPsec From: "Caitlin Bestler" To: Black_David@emc.com Cc: cait@asomi.com, rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David@emc.com said: > Caitlin, > > Could you explain a couple of things: > >> Nothing, except that the intermediate system buffering is >> far less likely. That *improves* security, not worsens it. > > How does this improve security? What is(are) the threat(s) whose > risk is reduced by eliminating intermediate buffering? > Getting a code snippet into a user mode data buffer almost never does an attacker any good. >> What has not changed is that no matter what is in the network >> packet, the exposure of application buffers to those packets >> is under control of the application -- not of the network >> packet. >> >> How precisely the application control the exposure of its >> buffer space, relative to its security requirements, is the >> real issue. The vulnerability of network packets is not >> an RDDP specific issue. >> >> If the application has tailored its exposure, the attacker >> can modify the headers endlessly. They will still only be >> able to deposit the payload in the buffers the Data Sink >> ULP intended them to be deposited into. > > What are the implications of that "If"? What does an application > have to do to match the buffer exposure of TCP or SCTP via the > sockets interface? Under what circumstances is that reasonable > (e.g., what other usage patterns does RDDP intend to enable)? > What are the potential consequences of allowing more buffer > exposure? > There is no need to achieve an exact match for TCP or SCTP placement. What matters is that when the application is ready to respond to a single "exchange" from its peer (consisting of zero or more RDMA transfers and a single untagged message) it merely has to ensure that it has ended remote accessiblity of the associated buffers. One-shot STags, whether invalidated remotely or locally, fully achieve this goal -- independently of whether transport layer authentication services are in use. Once STag invalidation is confirmed, and before the target buffers have been acted upon, the ULP has just as much confidence in the contents of those buffers as if they had been delivered by TCP or SCTP alone using the classic sockets interface. The only difference is that there were probably fewer intermediate application states. From the application's viewpoint the data went from "not there" to "there" in a single completion event. It was not aware of when "100 KB out of 300 KB" had been transferred. An application may *choose* to leave STags enabled on a wider basis, if it believes that there is no real vulnerability from the extended exposure. For example an application may have determined that an "attack" on an over-exposed buffer would at worst cause the current session to be aborted with no false results being committed to permanent memory. In my opinion the security draft provides clear and sufficient advise to application designers to enable them to tailor their STag exposure to meet their application specific needs. Even when an application wishes to have proof that all packets originated from the machine that its peer is running on, there are many ways to achieve that. I do no see any benefit from having the DDP layer insist on a specific method of solving a transport layer problem. Those should be solved at the transport layer. For example, source authentication can be achieved at the network layer with a variety of tools including managed switches in addition to IPsec. Ideally the application only knows that IP spoofing has been prevented. It does not need to know, and should not care, how. I could see requiring that the DDP layer invoke any existing interface of the IP layer to request anti-spoofing services be used, but I do not believe it is appropriate to require RDDP to insist that the IP layer it is using support IPsec (or any other specific anti-spoofing method). In any event, how would the RDDP layer confirm that capability? If the application does not request the sevice, is it obligated to do a test IPsec connection first just to make sure that it could have? If there are 10 existing connections before RDDP discovers that the dastardly IP layer it is using does not really support IPsec, is is required to terminate the existing connections? RDDP implemenations are likely to ride on top of the LLP, be rototilled with the TCP or SCTP layer and ride on top of the IP layer, or rototilled thru the IP layer and ride on top of the Ethernet layer. Only in the latter case is the RDDP implementation able to enforce IPsec availability. For the others to do so, there would have to be a *standard* interface between RDDP and the next lower layer that included such a query capability. And if we are going to spend the efforts definining the requirements for local interfaces I believe that the ULP to RDMAP layer is much more worthwhile. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri May 14 09:13:27 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20141 for ; Fri, 14 May 2004 09:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcTf-0008DX-36 for rddp-archive@odin.ietf.org; Fri, 14 May 2004 09:11:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4EDBpJ8031587 for rddp-archive@odin.ietf.org; Fri, 14 May 2004 09:11:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcQ4-0007Nn-MN for rddp-web-archive@optimus.ietf.org; Fri, 14 May 2004 09:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19848 for ; Fri, 14 May 2004 09:08:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOcQ3-0002k6-6b for rddp-web-archive@ietf.org; Fri, 14 May 2004 09:08:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOcPC-0002FJ-00 for rddp-web-archive@ietf.org; Fri, 14 May 2004 09:07:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BOcOD-0001kI-00 for rddp-web-archive@ietf.org; Fri, 14 May 2004 09:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcJB-00062v-Dk; Fri, 14 May 2004 09:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BOcDO-0004mo-7c for rddp@optimus.ietf.org; Fri, 14 May 2004 08:55:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19172 for ; Fri, 14 May 2004 08:54:59 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BOcDM-000460-OE for rddp@ietf.org; Fri, 14 May 2004 08:55:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BOcCN-0003Zu-00 for rddp@ietf.org; Fri, 14 May 2004 08:54:00 -0400 Received: from maho3msx2.isus.emc.com ([128.221.11.32] helo=MAHO3MSX2.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1BOcBK-0002cP-00 for rddp@ietf.org; Fri, 14 May 2004 08:52:54 -0400 Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 May 2004 08:50:52 -0400 Message-ID: To: cait@asomi.com Cc: rddp@ietf.org Subject: RE: [rddp] Security draft issue (4) - IPsec Date: Fri, 14 May 2004 08:52:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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 Caitlin, > >> Nothing, except that the intermediate system buffering is > >> far less likely. That *improves* security, not worsens it. > > > > How does this improve security? What is(are) the threat(s) whose > > risk is reduced by eliminating intermediate buffering? > > > Getting a code snippet into a user mode data buffer almost > never does an attacker any good. That's unfortunately not true. Buffer overflow exploits usually target privileged demons running in user mode (e.g., ftp). > >> What has not changed is that no matter what is in the network > >> packet, the exposure of application buffers to those packets > >> is under control of the application -- not of the network > >> packet. > >> > >> How precisely the application control the exposure of its > >> buffer space, relative to its security requirements, is the > >> real issue. The vulnerability of network packets is not > >> an RDDP specific issue. > >> > >> If the application has tailored its exposure, the attacker > >> can modify the headers endlessly. They will still only be > >> able to deposit the payload in the buffers the Data Sink > >> ULP intended them to be deposited into. > > > > What are the implications of that "If"? What does an application > > have to do to match the buffer exposure of TCP or SCTP via the > > sockets interface? Under what circumstances is that reasonable > > (e.g., what other usage patterns does RDDP intend to enable)? > > What are the potential consequences of allowing more buffer > > exposure? > > > There is no need to achieve an exact match for TCP or SCTP > placement. > > What matters is that when the application is ready to respond > to a single "exchange" from its peer (consisting of zero or > more RDMA transfers and a single untagged message) it > merely has to ensure that it has ended remote accessiblity > of the associated buffers. > > One-shot STags, whether invalidated remotely or locally, > fully achieve this goal -- independently of whether > transport layer authentication services are in use. > > Once STag invalidation is confirmed, and before the target > buffers have been acted upon, the ULP has just as much > confidence in the contents of those buffers as if they > had been delivered by TCP or SCTP alone using the > classic sockets interface. If that's correct, it would suggest that implementations that restrict *all* STags to one-shot usage may not need to implement IPsec or anything similar. > The only difference is that there were probably fewer > intermediate application states. From the application's > viewpoint the data went from "not there" to "there" > in a single completion event. It was not aware of when > "100 KB out of 300 KB" had been transferred. > > An application may *choose* to leave STags enabled > on a wider basis, if it believes that there is no real > vulnerability from the extended exposure. For example > an application may have determined that an "attack" > on an over-exposed buffer would at worst cause > the current session to be aborted with no false > results being committed to permanent memory. Or undesirable side effects being inflicted on unrelated clients. > In my opinion the security draft provides clear and > sufficient advise to application designers to enable > them to tailor their STag exposure to meet their > application specific needs. If proper/intended use of RDDP (STags enabled on a wider basis) creates security issues, the IETF view is likely to be that the security countermeasures for those issues have to be mandatory to implement. I've recently run into a situation with another draft where the IESG viewed "don't use this in situations where there's a risk of it causing security problems" as insufficient. > Even when an application wishes to have proof that > all packets originated from the machine that its peer > is running on, there are many ways to achieve that. > I do no see any benefit from having the DDP layer > insist on a specific method of solving a transport > layer problem. Those should be solved at the > transport layer. The DDP layer would not "insist" - any requirement for IPsec would be "MUST implement", not "MUST use". > For example, source authentication can be > achieved at the network layer with a variety > of tools including managed switches in addition > to IPsec. Ideally the application only knows that > IP spoofing has been prevented. It does not need > to know, and should not care, how. > > I could see requiring that the DDP layer invoke > any existing interface of the IP layer to request > anti-spoofing services be used, but I do not believe > it is appropriate to require RDDP to insist that the > IP layer it is using support IPsec (or any other > specific anti-spoofing method). > > In any event, how would the RDDP layer confirm > that capability? If the application does not request > the sevice, is it obligated to do a test IPsec connection > first just to make sure that it could have? If there > are 10 existing connections before RDDP discovers > that the dastardly IP layer it is using does not really > support IPsec, is is required to terminate the > existing connections? It would not be necessary to confirm this at runtime. As I said earlier, this is a matter of what the implementer must do in order to honestly claim that an implementation meets the requirements of the specification. Thanks, --David > RDDP implemenations are likely to ride on top of > the LLP, be rototilled with the TCP or SCTP layer > and ride on top of the IP layer, or rototilled thru > the IP layer and ride on top of the Ethernet layer. > > Only in the latter case is the RDDP implementation > able to enforce IPsec availability. For the others > to do so, there would have to be a *standard* > interface between RDDP and the next lower layer > that included such a query capability. And if > we are going to spend the efforts definining > the requirements for local interfaces I believe > that the ULP to RDMAP layer is much more > worthwhile. > > > > -- > Caitlin Bestler > http://asomi.com/ > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon May 17 01:44:22 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16030 for ; Mon, 17 May 2004 01:44:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPatr-0002Nm-NG for rddp-archive@odin.ietf.org; Mon, 17 May 2004 01:42:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H5gts1009158 for rddp-archive@odin.ietf.org; Mon, 17 May 2004 01:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPaom-0001Rl-Sv for rddp-web-archive@optimus.ietf.org; Mon, 17 May 2004 01:37:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15815 for ; Mon, 17 May 2004 01:37:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPaoj-0000BA-Mj for rddp-web-archive@ietf.org; Mon, 17 May 2004 01:37:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPanr-0007gp-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 01:36:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPan0-0007P0-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 01:35:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPalF-0000ys-Ig; Mon, 17 May 2004 01:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPahw-0000dl-Tp for rddp@optimus.ietf.org; Mon, 17 May 2004 01:30:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15575 for ; Mon, 17 May 2004 01:30:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPaht-0005xq-Lw for rddp@ietf.org; Mon, 17 May 2004 01:30:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPagu-0005fQ-00 for rddp@ietf.org; Mon, 17 May 2004 01:29:33 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BPafs-00058e-00 for rddp@ietf.org; Mon, 17 May 2004 01:28:28 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id CC26911E177 for ; Mon, 17 May 2004 01:28:26 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44644-07 for ; Mon, 17 May 2004 01:28:23 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 8D77811E0FC; Mon, 17 May 2004 01:28:23 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id AB67811E0B2 for ; Mon, 17 May 2004 01:28:22 -0400 (EDT) Received: from 82.166.249.161 (proxying for 82.166.249.161) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Mon, 17 May 2004 00:28:22 -0500 (CDT) Message-ID: <56848.82.166.249.161.1084771702.squirrel@mail52a.simplicato.com> In-Reply-To: References: Date: Mon, 17 May 2004 00:28:22 -0500 (CDT) From: "Caitlin Bestler" To: rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [rddp] legality of interleaving untagged message segments 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The current RDDP draft requires that messages be submitted to the LLP in order. It also requires that when a message is segmented, that the final segment MUST be the last one submitted to the LLP. It does not, however, define what is meant by submitting "a message" when in fact the DDP layer submits *segments* to the LLP. I believe this could allow a very strained interpretation that would allow interleaving of untagged segments to the LLP, as long as the *final* segments were submitted in order. For example, it might allow the following submission order: Untagged MSN 7 segment 0 (not final) Untagged MSN 8 segment 0 (not final) Untagged MSN 7 segment 1 (final) Untagged MSN 8 segment 1 (final) A typical out-of-order receiver would not even notice anything unusual about this sequence of untagged segments. However, it has a major impact on in-order receivers. It requires that multiple RQ (or S-RQ) entries be 'current' for the packet processor. If the in-order packet-processor is on the RNIC and the RQ/S-RQ is in host memory this is a totally unnecessary complication. I still believe that the sender should be free to re-order segments within a message (but SHOULD NOT unless it gains some advantage in doing so, such as sending data that is already cached), but I cannot come up with any benefit for the sender to interleave message segments. The complexity of doing so is simply too great for any potential additional caching gains. The fact that such sequences are so unlikely means that it is highly likely that there will be implementations that will not properly handle this case, whether or not the specification explicitly forbids it. This makes any theoretical advantages even more remote. Customers seldom care that your esoteric optimization is "legal", they just know that *your* RNIC is the one that isn't working with everyone else. So I believe the draft should be clarified to require that all segments for untagged message N MUST be submitted to the LLP before any segments for untagged message N+1 are submitted to the LLP. Doing so will have no impact on unordered receivers. I doubt it will have any impact on any existing senders, and it eliminates one corner condition that would require extra resources and testing for in-order receivers. >> >> Several months ago I raised a query as to whether DDP could/should >> mandate that the process of segmenting DDP Messages MUST NOT >> result in interleaving of messages. That is *all* segments for DDP >> Message N must be submitted to the transmitting LLP: before any >> segment of DDP Message N+1 is submitted. >> >> I believe the current draft could, in a very strained malicious way, >> be interpreted to only require: >> >> that the segment with the L bit for each message be the last >> segment for that message. >> >> that the segments with L bits are themselves submitted in order. >> >> The only real response on the list, as I recall, was from Mike Krause >> who pointed out that such interleaving would not even be noticed >> by an out-of-order receiver. And that is completely correct. >> >> It does have an impact on in-order receivers, and particular on >> how many untagged buffers an in-order RNIC has to have looked >> up from the host-side receive queues (or worse SRQs). >> >> I doubt very much whether anyone will ever produce a sender >> with a segmentation algorithm that will violate this rule, and I >> am one of the strong advocates of allowing senders to use >> creative ordering *within* a message to optimize for sending >> data that is already in the RNICs cache. >> >> But it would be handy to have something firm to justify coding >> an RNIC based on this assumption. >> >> Do you feel that the current language already forbids interleaving >> of message segments (in terms of the order they are submitted >> to the LLP, and hence their LLP sequence numbers)? >> >> If so, it is probably enough to just have that stated on the >> reflector. >> >> Otherwise, as one of the principal advocates of having the protocols >> be friendly to *both* ordered and unordered implementations, would >> you support such a change? >> >> In my evaluation, the drafters are firmly in the "out of order" camp >> and hence do not see any need for this clarification. >> > -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon May 17 03:40:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04600 for ; Mon, 17 May 2004 03:40:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPccI-0006eo-AR for rddp-archive@odin.ietf.org; Mon, 17 May 2004 03:32:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4H7Ws90025590 for rddp-archive@odin.ietf.org; Mon, 17 May 2004 03:32:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcYE-00064X-I1 for rddp-web-archive@optimus.ietf.org; Mon, 17 May 2004 03:28:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04065 for ; Mon, 17 May 2004 03:28:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcYC-000365-9A for rddp-web-archive@ietf.org; Mon, 17 May 2004 03:28:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcXG-0002lz-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 03:27:43 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPcWN-0002R2-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 03:26:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcRn-0005NB-Bu; Mon, 17 May 2004 03:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPcJg-0004SX-OU for rddp@optimus.ietf.org; Mon, 17 May 2004 03:13:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03515 for ; Mon, 17 May 2004 03:13:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPcJe-0006Fb-Hg for rddp@ietf.org; Mon, 17 May 2004 03:13:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPcIh-0005vd-00 for rddp@ietf.org; Mon, 17 May 2004 03:12:40 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BPcHk-0005NY-00 for rddp@ietf.org; Mon, 17 May 2004 03:11:40 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 3D24211E220; Mon, 17 May 2004 03:11:31 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65355-08; Mon, 17 May 2004 03:11:29 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id CC79311E16F; Mon, 17 May 2004 03:11:29 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 0E3E311E175; Mon, 17 May 2004 03:11:28 -0400 (EDT) Received: from 82.166.249.161 (proxying for 82.166.249.161) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Mon, 17 May 2004 02:11:28 -0500 (CDT) Message-ID: <15001.82.166.249.161.1084777888.squirrel@mail52a.simplicato.com> In-Reply-To: References: Date: Mon, 17 May 2004 02:11:28 -0500 (CDT) Subject: RE: [rddp] Security draft issue (4) - IPsec From: "Caitlin Bestler" To: Black_David@emc.com Cc: cait@asomi.com, rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Black_David@emc.com said: > Caitlin, > >> >> Nothing, except that the intermediate system buffering is >> >> far less likely. That *improves* security, not worsens it. >> > >> > How does this improve security? What is(are) the threat(s) whose >> > risk is reduced by eliminating intermediate buffering? >> > >> Getting a code snippet into a user mode data buffer almost >> never does an attacker any good. > > That's unfortunately not true. Buffer overflow exploits usually > target privileged demons running in user mode (e.g., ftp). > >> >> What has not changed is that no matter what is in the network >> >> packet, the exposure of application buffers to those packets >> >> is under control of the application -- not of the network >> >> packet. >> >> >> >> How precisely the application control the exposure of its >> >> buffer space, relative to its security requirements, is the >> >> real issue. The vulnerability of network packets is not >> >> an RDDP specific issue. >> >> >> >> If the application has tailored its exposure, the attacker >> >> can modify the headers endlessly. They will still only be >> >> able to deposit the payload in the buffers the Data Sink >> >> ULP intended them to be deposited into. >> > >> > What are the implications of that "If"? What does an application >> > have to do to match the buffer exposure of TCP or SCTP via the >> > sockets interface? Under what circumstances is that reasonable >> > (e.g., what other usage patterns does RDDP intend to enable)? >> > What are the potential consequences of allowing more buffer >> > exposure? >> > >> There is no need to achieve an exact match for TCP or SCTP >> placement. >> >> What matters is that when the application is ready to respond >> to a single "exchange" from its peer (consisting of zero or >> more RDMA transfers and a single untagged message) it >> merely has to ensure that it has ended remote accessiblity >> of the associated buffers. >> >> One-shot STags, whether invalidated remotely or locally, >> fully achieve this goal -- independently of whether >> transport layer authentication services are in use. >> >> Once STag invalidation is confirmed, and before the target >> buffers have been acted upon, the ULP has just as much >> confidence in the contents of those buffers as if they >> had been delivered by TCP or SCTP alone using the >> classic sockets interface. > > If that's correct, it would suggest that implementations > that restrict *all* STags to one-shot usage may not need > to implement IPsec or anything similar. > If one-shot STags are available for use, then it is the ULP that chooses to use longer lasting STags. That is the same ULP that would be free to decide not to use IPsec. It would make sense to require IPsec support for any implementation that did not offer a local interface support for one-shot STags (for example, one that supported only heavy-weight Memory Regions as opposed to Memory Windows). >> The only difference is that there were probably fewer >> intermediate application states. From the application's >> viewpoint the data went from "not there" to "there" >> in a single completion event. It was not aware of when >> "100 KB out of 300 KB" had been transferred. >> >> An application may *choose* to leave STags enabled >> on a wider basis, if it believes that there is no real >> vulnerability from the extended exposure. For example >> an application may have determined that an "attack" >> on an over-exposed buffer would at worst cause >> the current session to be aborted with no false >> results being committed to permanent memory. > > Or undesirable side effects being inflicted on unrelated > clients. > >> In my opinion the security draft provides clear and >> sufficient advise to application designers to enable >> them to tailor their STag exposure to meet their >> application specific needs. > > If proper/intended use of RDDP (STags enabled on a wider > basis) creates security issues, the IETF view is likely > to be that the security countermeasures for those issues > have to be mandatory to implement. I've recently run > into a situation with another draft where the IESG viewed > "don't use this in situations where there's a risk of it > causing security problems" as insufficient. > I have posted before in defense of these application models and I am clearly on record as wanting these capabilities supported by the protocol and the local interface. However, I have also pointed out that typical applications will only need one-shot STags. I believe the security draft is clear that STags should be used such that the exposure is no larger than what the ULP requires, and that excess exposure should be examined by the application designer. Should we go farther and mandate that one-shot STags be the *default* interface, so that the ULP could not inadvertently over-expose its memory? But such a requirement would only apply to the iWarp-specific local interface. In my estimation, most applications will be developed using transport neutral APIs designed to work over iWarp or InfiniBand (such as the APIs defined by DAT and the ITWG). >> Even when an application wishes to have proof that >> all packets originated from the machine that its peer >> is running on, there are many ways to achieve that. >> I do no see any benefit from having the DDP layer >> insist on a specific method of solving a transport >> layer problem. Those should be solved at the >> transport layer. > > The DDP layer would not "insist" - any requirement for > IPsec would be "MUST implement", not "MUST use". > But it would be insisting that the underlying IP layer MUST have this capability. Bottom line, should an RDDP implementation *refuse* to operate over a separately packaged IP layer because it fails to implement IPsec (or IPv6 for that matter). I still see no justification for requiring RDDP to somehow enforce something that is technically outside of its scope, especially when the ULP already has adequate tools to ensure that an RDDP application over unauthenticated transport can be just as secure as a TCP or SCTP application over the same unauthenticated transport. -- Caitlin Bestler http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon May 17 13:35:39 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07418 for ; Mon, 17 May 2004 13:35:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlyL-0007pf-57 for rddp-archive@odin.ietf.org; Mon, 17 May 2004 13:32:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HHWH2p030108 for rddp-archive@odin.ietf.org; Mon, 17 May 2004 13:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlfn-0005I3-Lg for rddp-web-archive@optimus.ietf.org; Mon, 17 May 2004 13:13:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05981 for ; Mon, 17 May 2004 13:13:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlfl-0006HI-Q0 for rddp-web-archive@ietf.org; Mon, 17 May 2004 13:13:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlem-0005wX-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 13:12:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPldg-0005Kc-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 13:10:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlX2-0003QL-EQ; Mon, 17 May 2004 13:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPlJe-0001aQ-HL for rddp@optimus.ietf.org; Mon, 17 May 2004 12:50:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04552 for ; Mon, 17 May 2004 12:50:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPlJc-00063n-OJ for rddp@ietf.org; Mon, 17 May 2004 12:50:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPlIl-0005jf-00 for rddp@ietf.org; Mon, 17 May 2004 12:49:20 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1BPlIC-0005PI-00 for rddp@ietf.org; Mon, 17 May 2004 12:48:44 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id 4DABC1C105B4 for ; Mon, 17 May 2004 09:48:39 -0700 (PDT) Received: from MK731916.cup.hp.com (ftc1nai161109.msr.hp.com [15.236.161.109]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with SMTP id JAA03352 for ; Mon, 17 May 2004 09:37:29 -0700 (PDT) Message-Id: <6.1.0.6.2.20040517094058.032f8c60@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Mon, 17 May 2004 09:47:55 -0700 To: rddp@ietf.org From: Michael Krause Subject: Re: [rddp] legality of interleaving untagged message segments In-Reply-To: <56848.82.166.249.161.1084771702.squirrel@mail52a.simplicat o.com> References: <56848.82.166.249.161.1084771702.squirrel@mail52a.simplicato.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.0 required=5.0 tests=none autolearn=no version=2.60 Within a given LLP stream, you are correct that the optimization benefits may be minimal if I/O device is somewhat "distant" (read as relatively high latency) from the memory controller. However, as we see the industry move towards PCI Express (PCIe) and with the potential to create more integrated memory controller chipsets, there may be greater benefit over time (especially with some architectures moving to be more NUMA oriented). Given this may take time to occur and validate, would you be willing to make this a SHOULD NOT instead of a MUST NOT thus allowing leeway for future development while providing strong guidance that such interleaving is strongly discouraged? Mike At 10:28 PM 5/16/2004, Caitlin Bestler wrote: >The current RDDP draft requires that messages be submitted >to the LLP in order. > >It also requires that when a message is segmented, that the >final segment MUST be the last one submitted to the LLP. > >It does not, however, define what is meant by submitting >"a message" when in fact the DDP layer submits *segments* >to the LLP. > >I believe this could allow a very strained interpretation >that would allow interleaving of untagged segments to the >LLP, as long as the *final* segments were submitted in order. >For example, it might allow the following submission order: > > Untagged MSN 7 segment 0 (not final) > Untagged MSN 8 segment 0 (not final) > Untagged MSN 7 segment 1 (final) > Untagged MSN 8 segment 1 (final) > >A typical out-of-order receiver would not even notice >anything unusual about this sequence of untagged segments. >However, it has a major impact on in-order receivers. It >requires that multiple RQ (or S-RQ) entries be 'current' >for the packet processor. If the in-order packet-processor >is on the RNIC and the RQ/S-RQ is in host memory this is >a totally unnecessary complication. > >I still believe that the sender should be free to re-order >segments within a message (but SHOULD NOT unless it gains >some advantage in doing so, such as sending data that is >already cached), but I cannot come up with any benefit >for the sender to interleave message segments. The complexity >of doing so is simply too great for any potential additional >caching gains. > >The fact that such sequences are so unlikely means that it >is highly likely that there will be implementations that >will not properly handle this case, whether or not the >specification explicitly forbids it. This makes any theoretical >advantages even more remote. Customers seldom care that >your esoteric optimization is "legal", they just know that >*your* RNIC is the one that isn't working with everyone else. > >So I believe the draft should be clarified to require that >all segments for untagged message N MUST be submitted to >the LLP before any segments for untagged message N+1 are >submitted to the LLP. > >Doing so will have no impact on unordered receivers. I doubt >it will have any impact on any existing senders, and it >eliminates one corner condition that would require extra >resources and testing for in-order receivers. > > > >> > >> Several months ago I raised a query as to whether DDP could/should > >> mandate that the process of segmenting DDP Messages MUST NOT > >> result in interleaving of messages. That is *all* segments for DDP > >> Message N must be submitted to the transmitting LLP: before any > >> segment of DDP Message N+1 is submitted. > >> > >> I believe the current draft could, in a very strained malicious way, > >> be interpreted to only require: > >> > >> that the segment with the L bit for each message be the last > >> segment for that message. > >> > >> that the segments with L bits are themselves submitted in order. > >> > >> The only real response on the list, as I recall, was from Mike Krause > >> who pointed out that such interleaving would not even be noticed > >> by an out-of-order receiver. And that is completely correct. > >> > >> It does have an impact on in-order receivers, and particular on > >> how many untagged buffers an in-order RNIC has to have looked > >> up from the host-side receive queues (or worse SRQs). > >> > >> I doubt very much whether anyone will ever produce a sender > >> with a segmentation algorithm that will violate this rule, and I > >> am one of the strong advocates of allowing senders to use > >> creative ordering *within* a message to optimize for sending > >> data that is already in the RNICs cache. > >> > >> But it would be handy to have something firm to justify coding > >> an RNIC based on this assumption. > >> > >> Do you feel that the current language already forbids interleaving > >> of message segments (in terms of the order they are submitted > >> to the LLP, and hence their LLP sequence numbers)? > >> > >> If so, it is probably enough to just have that stated on the > >> reflector. > >> > >> Otherwise, as one of the principal advocates of having the protocols > >> be friendly to *both* ordered and unordered implementations, would > >> you support such a change? > >> > >> In my evaluation, the drafters are firmly in the "out of order" camp > >> and hence do not see any need for this clarification. > >> > > > > >-- >Caitlin Bestler >http://asomi.com/ > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon May 17 15:01:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14822 for ; Mon, 17 May 2004 15:01:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPnCf-0004z7-Ux for rddp-archive@odin.ietf.org; Mon, 17 May 2004 14:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HIp90T019158 for rddp-archive@odin.ietf.org; Mon, 17 May 2004 14:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPn5s-0003bn-PU for rddp-web-archive@optimus.ietf.org; Mon, 17 May 2004 14:44:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13505 for ; Mon, 17 May 2004 14:44:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPn5q-0007SV-5s for rddp-web-archive@ietf.org; Mon, 17 May 2004 14:44:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPn4e-0006xK-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 14:42:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPn3a-0006WM-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 14:41:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmtP-0000vK-DD; Mon, 17 May 2004 14:31:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPmjL-0007Vj-RA for rddp@optimus.ietf.org; Mon, 17 May 2004 14:20:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10816 for ; Mon, 17 May 2004 14:20:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPmjJ-0006kx-7l for rddp@ietf.org; Mon, 17 May 2004 14:20:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPmhX-0005yP-00 for rddp@ietf.org; Mon, 17 May 2004 14:19:00 -0400 Received: from amdext3.amd.com ([139.95.251.6]) by ietf-mx with esmtp (Exim 4.12) id 1BPmgD-0005O8-00 for rddp@ietf.org; Mon, 17 May 2004 14:17:37 -0400 Received: from ssvlgw01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id i4HIHLPv003726 for ; Mon, 17 May 2004 11:17:24 -0700 Received: from 139.95.250.1 by ssvlgw02.amd.com with ESMTP (AMD SMTP Relay (MMS v5.5.3)); Mon, 17 May 2004 11:17:54 -0700 Received: from cmdmail.amd.com (cmdmail.amd.com [172.28.9.121]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id i4HIGpsT014674 for ; Mon, 17 May 2004 11:16:51 -0700 (PDT) Received: from lx-desk84.amd.com.amd.com (lx-desk84.amd.com [172.28.12.106]) by cmdmail.amd.com (8.11.6/8.11.6) with ESMTP id i4HIGok01800 for ; Mon, 17 May 2004 11:16:51 -0700 (PDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 From: "Jeff Dwork" MIME-Version: 1.0 Message-ID: <16553.403.189040.644523@lx-desk84.amd.com> Date: Mon, 17 May 2004 11:16:51 -0700 To: rddp@ietf.org Subject: Re: [rddp] legality of interleaving untagged message segments In-Reply-To: <6.1.0.6.2.20040517094058.032f8c60@15.13.130.73> References: <56848.82.166.249.161.1084771702.squirrel@mail52a.simplicato.com> <6.1.0.6.2.20040517094058.032f8c60@15.13.130.73> X-WSS-ID: 6CB7DE58936564-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A receiver capable of tracking out-of-order messages is more complex than one which requres in-order submission. Support of out-of-order message submission must be negotiated prior to stream initialization. A possible implementation: The receiver declares the maximum number of simultaneous messages it will accept, possible values being an integer greater than 0 or the special value "NO_LIMIT" (perhaps represented as 0). A value of "1" means that all segments of message N must be submitted before any segments of message N+1. A value of "NO_LIMIT" means that the receiver will accept any number of out-of-order messages up to the size of the RQ/S_RQ. Jeff Michael Krause writes: > To: rddp@ietf.org > Subject: Re: [rddp] legality of interleaving untagged message segments > Date: Mon, 17 May 2004 09:47:55 -0700 > > > Within a given LLP stream, you are correct that the optimization benefits > may be minimal if I/O device is somewhat "distant" (read as relatively high > latency) from the memory controller. However, as we see the industry move > towards PCI Express (PCIe) and with the potential to create more integrated > memory controller chipsets, there may be greater benefit over time > (especially with some architectures moving to be more NUMA oriented). > > Given this may take time to occur and validate, would you be willing to > make this a SHOULD NOT instead of a MUST NOT thus allowing leeway for > future development while providing strong guidance that such interleaving > is strongly discouraged? > > Mike > > > At 10:28 PM 5/16/2004, Caitlin Bestler wrote: > >The current RDDP draft requires that messages be submitted > >to the LLP in order. > > > >It also requires that when a message is segmented, that the > >final segment MUST be the last one submitted to the LLP. > > > >It does not, however, define what is meant by submitting > >"a message" when in fact the DDP layer submits *segments* > >to the LLP. > > > >I believe this could allow a very strained interpretation > >that would allow interleaving of untagged segments to the > >LLP, as long as the *final* segments were submitted in order. > >For example, it might allow the following submission order: > > > > Untagged MSN 7 segment 0 (not final) > > Untagged MSN 8 segment 0 (not final) > > Untagged MSN 7 segment 1 (final) > > Untagged MSN 8 segment 1 (final) > > > >A typical out-of-order receiver would not even notice > >anything unusual about this sequence of untagged segments. > >However, it has a major impact on in-order receivers. It > >requires that multiple RQ (or S-RQ) entries be 'current' > >for the packet processor. If the in-order packet-processor > >is on the RNIC and the RQ/S-RQ is in host memory this is > >a totally unnecessary complication. > > > >I still believe that the sender should be free to re-order > >segments within a message (but SHOULD NOT unless it gains > >some advantage in doing so, such as sending data that is > >already cached), but I cannot come up with any benefit > >for the sender to interleave message segments. The complexity > >of doing so is simply too great for any potential additional > >caching gains. > > > >The fact that such sequences are so unlikely means that it > >is highly likely that there will be implementations that > >will not properly handle this case, whether or not the > >specification explicitly forbids it. This makes any theoretical > >advantages even more remote. Customers seldom care that > >your esoteric optimization is "legal", they just know that > >*your* RNIC is the one that isn't working with everyone else. > > > >So I believe the draft should be clarified to require that > >all segments for untagged message N MUST be submitted to > >the LLP before any segments for untagged message N+1 are > >submitted to the LLP. > > > >Doing so will have no impact on unordered receivers. I doubt > >it will have any impact on any existing senders, and it > >eliminates one corner condition that would require extra > >resources and testing for in-order receivers. > > > > > > >> > > >> Several months ago I raised a query as to whether DDP could/should > > >> mandate that the process of segmenting DDP Messages MUST NOT > > >> result in interleaving of messages. That is *all* segments for DDP > > >> Message N must be submitted to the transmitting LLP: before any > > >> segment of DDP Message N+1 is submitted. > > >> > > >> I believe the current draft could, in a very strained malicious way, > > >> be interpreted to only require: > > >> > > >> that the segment with the L bit for each message be the last > > >> segment for that message. > > >> > > >> that the segments with L bits are themselves submitted in order. > > >> > > >> The only real response on the list, as I recall, was from Mike Krause > > >> who pointed out that such interleaving would not even be noticed > > >> by an out-of-order receiver. And that is completely correct. > > >> > > >> It does have an impact on in-order receivers, and particular on > > >> how many untagged buffers an in-order RNIC has to have looked > > >> up from the host-side receive queues (or worse SRQs). > > >> > > >> I doubt very much whether anyone will ever produce a sender > > >> with a segmentation algorithm that will violate this rule, and I > > >> am one of the strong advocates of allowing senders to use > > >> creative ordering *within* a message to optimize for sending > > >> data that is already in the RNICs cache. > > >> > > >> But it would be handy to have something firm to justify coding > > >> an RNIC based on this assumption. > > >> > > >> Do you feel that the current language already forbids interleaving > > >> of message segments (in terms of the order they are submitted > > >> to the LLP, and hence their LLP sequence numbers)? > > >> > > >> If so, it is probably enough to just have that stated on the > > >> reflector. > > >> > > >> Otherwise, as one of the principal advocates of having the protocols > > >> be friendly to *both* ordered and unordered implementations, would > > >> you support such a change? > > >> > > >> In my evaluation, the drafters are firmly in the "out of order" camp > > >> and hence do not see any need for this clarification. > > >> > > > > > > > > >-- > >Caitlin Bestler > >http://asomi.com/ > > > >_______________________________________________ > >rddp mailing list > >rddp@ietf.org > >https://www1.ietf.org/mailman/listinfo/rddp > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp -- Jeff Dwork | jeff.dwork@amd.com 408-307-2496 (cell) Advanced Micro Devices, M/S 362| 408-749-5216 (desk) 408-774-7811 (fax) PO Box 3453 |---------------------------------------- Sunnyvale, Ca 94088-3453 | _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon May 17 18:13:52 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07797 for ; Mon, 17 May 2004 18:13:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPq9N-00016Q-8M for rddp-archive@odin.ietf.org; Mon, 17 May 2004 17:59:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4HLxvVI004239 for rddp-archive@odin.ietf.org; Mon, 17 May 2004 17:59:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpzF-0003Q5-Ra for rddp-web-archive@optimus.ietf.org; Mon, 17 May 2004 17:49:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04164 for ; Mon, 17 May 2004 17:49:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPpzD-0007gH-A2 for rddp-web-archive@ietf.org; Mon, 17 May 2004 17:49:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPptz-0006FN-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 17:44:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPpoR-0004rJ-00 for rddp-web-archive@ietf.org; Mon, 17 May 2004 17:38:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPpTE-00036j-6y; Mon, 17 May 2004 17:16:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPoXx-0001Du-SJ for rddp@optimus.ietf.org; Mon, 17 May 2004 16:17:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22113 for ; Mon, 17 May 2004 16:17:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPoXw-0002nV-3a for rddp@ietf.org; Mon, 17 May 2004 16:17:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPoVo-0001z7-00 for rddp@ietf.org; Mon, 17 May 2004 16:15:01 -0400 Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx with esmtp (Exim 4.12) id 1BPoU4-00016D-00 for rddp@ietf.org; Mon, 17 May 2004 16:13:12 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.35]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 2963A40 for ; Mon, 17 May 2004 15:12:43 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 17 May 2004 15:12:42 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] legality of interleaving untagged message segments Date: Mon, 17 May 2004 15:12:40 -0500 Message-ID: <4D027986353D1341ADA4F2A4F8A170762DBF984C@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] legality of interleaving untagged message segments Thread-Index: AcQ8PqaiVsHQZOz6TKWKxtgOOLr76gACPrPA From: "Culley, Paul" To: X-OriginalArrivalTime: 17 May 2004 20:12:42.0913 (UTC) FILETIME=[4F9D2910:01C43C4B] Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I hope you are missing the point; all RDDP/MPA receivers MUST be able to deal with out of order segments caused by lost or delayed TCP segments. So there is no need for a receiver to negotiate this. Out of order RDDP segments within a single message, as sent by the transmitter (but in order as far as TCP is concerned) does not appear to be any harder. Out of order messages (segments with the last bit) must also be handled when caused by network issues. We are talking about allowing some (probably minor) optimizations at the transmitter to send some segments out of order and whether to allow them. I personally believe that actually taking advantage of allowable out of order segments at the transmitter will be difficult and of very little actual performance or buffering gain at the transmitter. But a receiver that has to handle this routinely might lose some performance if it tried to use spatial caching for Page table lookups or buffer stores. I for one, think that requiring everything to be in order out of the sender will probably save more at the receiver than would ever be lost at the sender; as such I would be in favor of MUST on always in order. Or just leave the spec as it is (with some textual clarification as suggested by Caitlin. I would absolutely object to negotiating out of order activities, just to allow these minor transmitter optimizations. Paul R. Culley HP Fellow 281-514-5543 =20 > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On=20 > Behalf Of Jeff Dwork > Sent: Monday, May 17, 2004 1:17 PM > To: rddp@ietf.org > Subject: Re: [rddp] legality of interleaving untagged message segments >=20 > A receiver capable of tracking out-of-order messages is more=20 > complex than one which requres in-order submission. Support=20 > of out-of-order message submission must be negotiated prior=20 > to stream initialization. =20 >=20 > A possible implementation: The receiver declares the maximum=20 > number of simultaneous messages it will accept, possible=20 > values being an integer greater than 0 or the special value=20 > "NO_LIMIT" (perhaps represented as 0). >=20 > A value of "1" means that all segments of message N must be=20 > submitted before any segments of message N+1. A value of=20 > "NO_LIMIT" means that the receiver will accept any number of=20 > out-of-order messages up to the size of the RQ/S_RQ. >=20 > Jeff >=20 > Michael Krause writes: > > To: rddp@ietf.org > > Subject: Re: [rddp] legality of interleaving untagged=20 > message segments > Date: Mon, 17 May 2004 09:47:55 -0700 > =20 > > > Within a given LLP stream, you are correct that the=20 > optimization benefits > may be minimal if I/O device is=20 > somewhat "distant" (read as relatively high > latency) from=20 > the memory controller. However, as we see the industry move =20 > > towards PCI Express (PCIe) and with the potential to create=20 > more integrated > memory controller chipsets, there may be=20 > greater benefit over time > (especially with some=20 > architectures moving to be more NUMA oriented). > > > > Given this may take time to occur and validate, would you=20 > be willing to > make this a SHOULD NOT instead of a MUST NOT=20 > thus allowing leeway for > future development while=20 > providing strong guidance that such interleaving > is=20 > strongly discouraged? > > > > Mike > > > > > > At 10:28 PM 5/16/2004, Caitlin Bestler wrote: > > >The current RDDP draft requires that messages be=20 > submitted > >to the LLP in order. > > > > > >It also requires that when a message is segmented, that=20 > the > >final segment MUST be the last one submitted to the LLP. > > > > > >It does not, however, define what is meant by submitting =20 > > >"a message" when in fact the DDP layer submits *segments* =20 > > >to the LLP. > > > > > >I believe this could allow a very strained interpretation=20 > > >that would allow interleaving of untagged segments to the=20 > > >LLP, as long as the *final* segments were submitted in order. > > >For example, it might allow the following submission order: > > > > > > Untagged MSN 7 segment 0 (not final) > > > Untagged MSN 8 segment 0 (not final) > > > Untagged MSN 7 segment 1 (final) > > > Untagged MSN 8 segment 1 (final) > > > > > >A typical out-of-order receiver would not even notice >=20 > >anything unusual about this sequence of untagged segments. > > >However, it has a major impact on in-order receivers. It =20 > > >requires that multiple RQ (or S-RQ) entries be 'current' > > >for the packet processor. If the in-order=20 > packet-processor > >is on the RNIC and the RQ/S-RQ is in=20 > host memory this is > >a totally unnecessary complication. > > > > > >I still believe that the sender should be free to=20 > re-order > >segments within a message (but SHOULD NOT unless=20 > it gains > >some advantage in doing so, such as sending data=20 > that is > >already cached), but I cannot come up with any=20 > benefit > >for the sender to interleave message segments.=20 > The complexity > >of doing so is simply too great for any=20 > potential additional > >caching gains. > > > > > >The fact that such sequences are so unlikely means that=20 > it > >is highly likely that there will be implementations=20 > that > >will not properly handle this case, whether or not=20 > the > >specification explicitly forbids it. This makes any=20 > theoretical > >advantages even more remote. Customers seldom=20 > care that > >your esoteric optimization is "legal", they=20 > just know that > >*your* RNIC is the one that isn't working=20 > with everyone else. > > > > > >So I believe the draft should be clarified to require=20 > that > >all segments for untagged message N MUST be=20 > submitted to > >the LLP before any segments for untagged=20 > message N+1 are > >submitted to the LLP. > > > > > >Doing so will have no impact on unordered receivers. I=20 > doubt > >it will have any impact on any existing senders,=20 > and it > >eliminates one corner condition that would require=20 > extra > >resources and testing for in-order receivers. > > > > > > > > > >> > > > >> Several months ago I raised a query as to whether DDP=20 > could/should > > >> mandate that the process of segmenting=20 > DDP Messages MUST NOT > > >> result in interleaving of=20 > messages. That is *all* segments for DDP > > >> Message N=20 > must be submitted to the transmitting LLP: before any > > >>=20 > segment of DDP Message N+1 is submitted. > > > >> > > > >> I believe the current draft could, in a very strained=20 > malicious way, > > >> be interpreted to only require: > > > >> > > > >> that the segment with the L bit for each message=20 > be the last > > > >> segment for that message. > > > >> > > > >> that the segments with L bits are themselves=20 > submitted in order. > > > >> > > > >> The only real response on the list, as I recall, was=20 > from Mike Krause > > >> who pointed out that such=20 > interleaving would not even be noticed > > >> by an=20 > out-of-order receiver. And that is completely correct. > > > >> > > > >> It does have an impact on in-order receivers, and=20 > particular on > > >> how many untagged buffers an in-order=20 > RNIC has to have looked > > >> up from the host-side receive=20 > queues (or worse SRQs). > > > >> > > > >> I doubt very much whether anyone will ever produce a=20 > sender > > >> with a segmentation algorithm that will=20 > violate this rule, and I > > >> am one of the strong=20 > advocates of allowing senders to use > > >> creative=20 > ordering *within* a message to optimize for sending > > >>=20 > data that is already in the RNICs cache. > > > >> > > > >> But it would be handy to have something firm to=20 > justify coding > > >> an RNIC based on this assumption. > > > >> > > > >> Do you feel that the current language already forbids=20 > interleaving > > >> of message segments (in terms of the=20 > order they are submitted > > >> to the LLP, and hence their=20 > LLP sequence numbers)? > > > >> > > > >> If so, it is probably enough to just have that stated=20 > on the > > >> reflector. > > > >> > > > >> Otherwise, as one of the principal advocates of=20 > having the protocols > > >> be friendly to *both* ordered=20 > and unordered implementations, would > > >> you support such=20 > a change? > > > >> > > > >> In my evaluation, the drafters are firmly in the "out=20 > of order" camp > > >> and hence do not see any need for this=20 > clarification. > > > >> > > > > > > > > > > > > >-- > > >Caitlin Bestler > > >http://asomi.com/ > > > > > >_______________________________________________ > > >rddp mailing list > > >rddp@ietf.org > > >https://www1.ietf.org/mailman/listinfo/rddp > > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp >=20 > --=20 > Jeff Dwork | jeff.dwork@amd.com =20 > 408-307-2496 (cell) > Advanced Micro Devices, M/S 362| 408-749-5216 (desk)=20 > 408-774-7811 (fax) > PO Box 3453 =20 > |---------------------------------------- > Sunnyvale, Ca 94088-3453 |=20 >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue May 18 02:24:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17264 for ; Tue, 18 May 2004 02:24:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxsn-0000T2-VA for rddp-archive@odin.ietf.org; Tue, 18 May 2004 02:15:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I6FLRX001791 for rddp-archive@odin.ietf.org; Tue, 18 May 2004 02:15:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxoN-0006wc-ER for rddp-web-archive@optimus.ietf.org; Tue, 18 May 2004 02:10:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13693 for ; Tue, 18 May 2004 02:10:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPxoK-00053M-1p for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:10:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPxnO-0004gh-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:09:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPxmW-0004KB-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:08:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxd1-000192-PB; Tue, 18 May 2004 01:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPxa4-00007f-7s for rddp@optimus.ietf.org; Tue, 18 May 2004 01:56:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02552 for ; Tue, 18 May 2004 01:55:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPxa0-0007As-RK for rddp@ietf.org; Tue, 18 May 2004 01:55:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPxYy-0006o8-00 for rddp@ietf.org; Tue, 18 May 2004 01:54:53 -0400 Received: from amdext3.amd.com ([139.95.251.6]) by ietf-mx with esmtp (Exim 4.12) id 1BPxYR-0006Pp-00 for rddp@ietf.org; Tue, 18 May 2004 01:54:19 -0400 Received: from ssvlgw01.amd.com (ssvlgw01.amd.com [139.95.250.169]) by amdext3.amd.com (8.12.11/8.12.11/AMD) with ESMTP id i4I5s32W001424 for ; Mon, 17 May 2004 22:54:03 -0700 Received: from 139.95.250.1 by ssvlgw02.amd.com with ESMTP (AMD SMTP Relay (MMS v5.5.3)); Mon, 17 May 2004 22:54:38 -0700 Received: from cmdmail.amd.com (cmdmail.amd.com [172.28.9.121]) by amdint.amd.com (8.12.8/8.12.8/AMD) with ESMTP id i4I5rYsT010418 for ; Mon, 17 May 2004 22:53:35 -0700 (PDT) Received: from lx-desk84.amd.com.amd.com (lx-desk84.amd.com [172.28.12.106]) by cmdmail.amd.com (8.11.6/8.11.6) with ESMTP id i4I5rXk09322 for ; Mon, 17 May 2004 22:53:34 -0700 (PDT) X-Mailer: emacs 21.2.1 (via feedmail 8 I); VM 7.18 under Emacs 21.2.1 From: "Jeff Dwork" MIME-Version: 1.0 Message-ID: <16553.42205.972544.449520@lx-desk84.amd.com> Date: Mon, 17 May 2004 22:53:33 -0700 To: rddp@ietf.org Subject: RE: [rddp] legality of interleaving untagged message segments In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762DBF984C@cceexc18.americas.cpqcorp.net> References: <4D027986353D1341ADA4F2A4F8A170762DBF984C@cceexc18.americas.cpqcorp.net> X-WSS-ID: 6CB77A9414910-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Acceptance of out of order segments is a MAY, not a MUST: "The LLP MAY provide the incoming segments out of order for Placement..." [DDP, sec 5.5] A TCP receiver may drop segments beyond the left edge of the window even if they have been SACK'd: "The data receiver MAY elect not to keep data which it has reported in a SACK option." [rfc2018, sec 8] so DDP can renege on out-of-order data already placed and wait for retransmission. It is certainly true that DDP has been designed to facilitate out of order placement, but not all systems will benefit equally. A small system with excess interconnect bandwidth, such as a rack with eight cluster nodes and a storage processor connected with 10G ethernet through a single switch, might never drop a segment and has no need for out of order placement. If the sender MUST submit the segments to the LLP in order, the receiver is free to implement as much or as little out of order placement capability as is appropriate for the application. Personally, I see no benefit to allowing out of order submission, but I don't have a crystal ball, so I suggested a mechanism to make it possible. Jeff Culley, Paul writes: > To: rddp@ietf.org > Subject: RE: [rddp] legality of interleaving untagged message segments > Date: Mon, 17 May 2004 15:12:40 -0500 > > I hope you are missing the point; all RDDP/MPA receivers MUST be able to > deal with out of order segments caused by lost or delayed TCP segments. > So there is no need for a receiver to negotiate this. Out of order RDDP > segments within a single message, as sent by the transmitter (but in > order as far as TCP is concerned) does not appear to be any harder. Out > of order messages (segments with the last bit) must also be handled when > caused by network issues. > > We are talking about allowing some (probably minor) optimizations at the > transmitter to send some segments out of order and whether to allow > them. I personally believe that actually taking advantage of allowable > out of order segments at the transmitter will be difficult and of very > little actual performance or buffering gain at the transmitter. But a > receiver that has to handle this routinely might lose some performance > if it tried to use spatial caching for Page table lookups or buffer > stores. > > I for one, think that requiring everything to be in order out of the > sender will probably save more at the receiver than would ever be lost > at the sender; as such I would be in favor of MUST on always in order. > Or just leave the spec as it is (with some textual clarification as > suggested by Caitlin. I would absolutely object to negotiating out of > order activities, just to allow these minor transmitter optimizations. > > Paul R. Culley > HP Fellow > 281-514-5543 > > > > -----Original Message----- > > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On > > Behalf Of Jeff Dwork > > Sent: Monday, May 17, 2004 1:17 PM > > To: rddp@ietf.org > > Subject: Re: [rddp] legality of interleaving untagged message segments > > > > A receiver capable of tracking out-of-order messages is more > > complex than one which requres in-order submission. Support > > of out-of-order message submission must be negotiated prior > > to stream initialization. > > > > A possible implementation: The receiver declares the maximum > > number of simultaneous messages it will accept, possible > > values being an integer greater than 0 or the special value > > "NO_LIMIT" (perhaps represented as 0). > > > > A value of "1" means that all segments of message N must be > > submitted before any segments of message N+1. A value of > > "NO_LIMIT" means that the receiver will accept any number of > > out-of-order messages up to the size of the RQ/S_RQ. > > > > Jeff > > > > Michael Krause writes: > > > To: rddp@ietf.org > > > Subject: Re: [rddp] legality of interleaving untagged > > message segments > Date: Mon, 17 May 2004 09:47:55 -0700 > > > > > Within a given LLP stream, you are correct that the > > optimization benefits > may be minimal if I/O device is > > somewhat "distant" (read as relatively high > latency) from > > the memory controller. However, as we see the industry move > > > towards PCI Express (PCIe) and with the potential to create > > more integrated > memory controller chipsets, there may be > > greater benefit over time > (especially with some > > architectures moving to be more NUMA oriented). > > > > > > Given this may take time to occur and validate, would you > > be willing to > make this a SHOULD NOT instead of a MUST NOT > > thus allowing leeway for > future development while > > providing strong guidance that such interleaving > is > > strongly discouraged? > > > > > > Mike > > > > > > > > > At 10:28 PM 5/16/2004, Caitlin Bestler wrote: > > > >The current RDDP draft requires that messages be > > submitted > >to the LLP in order. > > > > > > > >It also requires that when a message is segmented, that > > the > >final segment MUST be the last one submitted to the LLP. > > > > > > > >It does not, however, define what is meant by submitting > > > >"a message" when in fact the DDP layer submits *segments* > > > >to the LLP. > > > > > > > >I believe this could allow a very strained interpretation > > > >that would allow interleaving of untagged segments to the > > > >LLP, as long as the *final* segments were submitted in order. > > > >For example, it might allow the following submission order: > > > > > > > > Untagged MSN 7 segment 0 (not final) > > > > Untagged MSN 8 segment 0 (not final) > > > > Untagged MSN 7 segment 1 (final) > > > > Untagged MSN 8 segment 1 (final) > > > > > > > >A typical out-of-order receiver would not even notice > > > >anything unusual about this sequence of untagged segments. > > > >However, it has a major impact on in-order receivers. It > > > >requires that multiple RQ (or S-RQ) entries be 'current' > > > >for the packet processor. If the in-order > > packet-processor > >is on the RNIC and the RQ/S-RQ is in > > host memory this is > >a totally unnecessary complication. > > > > > > > >I still believe that the sender should be free to > > re-order > >segments within a message (but SHOULD NOT unless > > it gains > >some advantage in doing so, such as sending data > > that is > >already cached), but I cannot come up with any > > benefit > >for the sender to interleave message segments. > > The complexity > >of doing so is simply too great for any > > potential additional > >caching gains. > > > > > > > >The fact that such sequences are so unlikely means that > > it > >is highly likely that there will be implementations > > that > >will not properly handle this case, whether or not > > the > >specification explicitly forbids it. This makes any > > theoretical > >advantages even more remote. Customers seldom > > care that > >your esoteric optimization is "legal", they > > just know that > >*your* RNIC is the one that isn't working > > with everyone else. > > > > > > > >So I believe the draft should be clarified to require > > that > >all segments for untagged message N MUST be > > submitted to > >the LLP before any segments for untagged > > message N+1 are > >submitted to the LLP. > > > > > > > >Doing so will have no impact on unordered receivers. I > > doubt > >it will have any impact on any existing senders, > > and it > >eliminates one corner condition that would require > > extra > >resources and testing for in-order receivers. > > > > > > > > > > > > >> > > > > >> Several months ago I raised a query as to whether DDP > > could/should > > >> mandate that the process of segmenting > > DDP Messages MUST NOT > > >> result in interleaving of > > messages. That is *all* segments for DDP > > >> Message N > > must be submitted to the transmitting LLP: before any > > >> > > segment of DDP Message N+1 is submitted. > > > > >> > > > > >> I believe the current draft could, in a very strained > > malicious way, > > >> be interpreted to only require: > > > > >> > > > > >> that the segment with the L bit for each message > > be the last > > > > >> segment for that message. > > > > >> > > > > >> that the segments with L bits are themselves > > submitted in order. > > > > >> > > > > >> The only real response on the list, as I recall, was > > from Mike Krause > > >> who pointed out that such > > interleaving would not even be noticed > > >> by an > > out-of-order receiver. And that is completely correct. > > > > >> > > > > >> It does have an impact on in-order receivers, and > > particular on > > >> how many untagged buffers an in-order > > RNIC has to have looked > > >> up from the host-side receive > > queues (or worse SRQs). > > > > >> > > > > >> I doubt very much whether anyone will ever produce a > > sender > > >> with a segmentation algorithm that will > > violate this rule, and I > > >> am one of the strong > > advocates of allowing senders to use > > >> creative > > ordering *within* a message to optimize for sending > > >> > > data that is already in the RNICs cache. > > > > >> > > > > >> But it would be handy to have something firm to > > justify coding > > >> an RNIC based on this assumption. > > > > >> > > > > >> Do you feel that the current language already forbids > > interleaving > > >> of message segments (in terms of the > > order they are submitted > > >> to the LLP, and hence their > > LLP sequence numbers)? > > > > >> > > > > >> If so, it is probably enough to just have that stated > > on the > > >> reflector. > > > > >> > > > > >> Otherwise, as one of the principal advocates of > > having the protocols > > >> be friendly to *both* ordered > > and unordered implementations, would > > >> you support such > > a change? > > > > >> > > > > >> In my evaluation, the drafters are firmly in the "out > > of order" camp > > >> and hence do not see any need for this > > clarification. > > > > >> > > > > > > > > > > > > > > > > >-- > > > >Caitlin Bestler > > > >http://asomi.com/ > > > > > > > >_______________________________________________ > > > >rddp mailing list > > > >rddp@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/rddp > > > > > > > > > _______________________________________________ > > > rddp mailing list > > > rddp@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rddp > > > > -- > > Jeff Dwork | jeff.dwork@amd.com > > 408-307-2496 (cell) > > Advanced Micro Devices, M/S 362| 408-749-5216 (desk) > > 408-774-7811 (fax) > > PO Box 3453 > > |---------------------------------------- > > Sunnyvale, Ca 94088-3453 | > > > > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > > > > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp -- Jeff Dwork | jeff.dwork@amd.com 408-307-2496 (cell) Advanced Micro Devices, M/S 362| 408-749-5216 (desk) 408-774-7811 (fax) PO Box 3453 |---------------------------------------- Sunnyvale, Ca 94088-3453 | _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue May 18 03:03:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19270 for ; Tue, 18 May 2004 03:03:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyNM-0003Rm-QV for rddp-archive@odin.ietf.org; Tue, 18 May 2004 02:46:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I6kuMb013251 for rddp-archive@odin.ietf.org; Tue, 18 May 2004 02:46:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyHU-0001JJ-SE for rddp-web-archive@optimus.ietf.org; Tue, 18 May 2004 02:40:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18295 for ; Tue, 18 May 2004 02:40:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyHR-0001W4-5l for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:40:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyGZ-00018y-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:39:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPyG2-0000ls-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:39:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy9t-0008HT-Hj; Tue, 18 May 2004 02:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy3t-0006qi-Do for rddp@optimus.ietf.org; Tue, 18 May 2004 02:26:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17458 for ; Tue, 18 May 2004 02:26:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPy3p-0003cM-HG for rddp@ietf.org; Tue, 18 May 2004 02:26:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPy2l-0003Dd-00 for rddp@ietf.org; Tue, 18 May 2004 02:25:39 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BPy1j-0002hX-00 for rddp@ietf.org; Tue, 18 May 2004 02:24:35 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id 3FD0311E26B; Tue, 18 May 2004 02:24:36 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11197-05; Tue, 18 May 2004 02:24:35 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id 246D011E24E; Tue, 18 May 2004 02:24:35 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id C739B11E246; Tue, 18 May 2004 02:24:34 -0400 (EDT) Received: from 82.166.249.161 (proxying for 82.166.249.161) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Tue, 18 May 2004 01:24:34 -0500 (CDT) Message-ID: <7241.82.166.249.161.1084861474.squirrel@mail52a.simplicato.com> In-Reply-To: <6.1.0.6.2.20040517094058.032f8c60@15.13.130.73> References: <56848.82.166.249.161.1084771702.squirrel@mail52a.simplicato.com> <6.1.0.6.2.20040517094058.032f8c60@15.13.130.73> Date: Tue, 18 May 2004 01:24:34 -0500 (CDT) Subject: Re: [rddp] legality of interleaving untagged message segments From: "Caitlin Bestler" To: "Michael Krause" Cc: rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Michael Krause said: > > Within a given LLP stream, you are correct that the optimization benefi= ts > may be minimal if I/O device is somewhat "distant" (read as relatively > high > latency) from the memory controller. However, as we see the industry m= ove > towards PCI Express (PCIe) and with the potential to create more > integrated > memory controller chipsets, there may be greater benefit over time > (especially with some architectures moving to be more NUMA oriented). > > Given this may take time to occur and validate, would you be willing to > make this a SHOULD NOT instead of a MUST NOT thus allowing leeway for > future development while providing strong guidance that such interleavi= ng > is strongly discouraged? > > Mike > There is already a SHOULD that segment SHOULD be submitted in ascending order. So no further SHOULD clause is required. Or for that matter useful. A "SHOULD NOT 'X'" clause does not truly allow the receiver to optimize = on the assumption that senders will not do X. It just discourages testing of 'X', so in a sense it's worse than doing nothing. Receivers are not free to optimize, and senders are discouraged from whatever optimization there might be. My assumption is that the MUST NOT I am proposing will not preclude any achievable optimization on the sender side. If that assumption is correc= t then benefit to the receiver is clearly preferable. But if anyone had an algorithm that really would optimize across message boundaries and gain actual benefits from it then the tradeoff is indeed more complex. The benefit at the receiver side, for an implementation that defers place= ment processing of DDP segments until they can be processed in order, is that there would be at most one active untagged buffer per DDP Stream. This is a major benefit, which I believe outweighs the theoretical benefits th= at some unidentified sender algorithm *might* achieve in the future. Of course I am willing to be convinced to the contrary if someone were to present a contemplated optimization that this restriction would interfere with. Or for that matter, even assert that they are researching such an algorit= hm that they are unwilling to disclose. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue May 18 03:15:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19996 for ; Tue, 18 May 2004 03:15:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPycp-0007We-3Q for rddp-archive@odin.ietf.org; Tue, 18 May 2004 03:02:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4I72tDs028911 for rddp-archive@odin.ietf.org; Tue, 18 May 2004 03:02:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyOL-0003es-4Y for rddp-web-archive@optimus.ietf.org; Tue, 18 May 2004 02:47:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18637 for ; Tue, 18 May 2004 02:47:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPyOH-0004Gx-F2 for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:47:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPyNG-0003t0-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:46:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BPyMX-0003W3-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 02:46:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPyGh-0001Bu-RK; Tue, 18 May 2004 02:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BPy9o-0008HD-9y for rddp@optimus.ietf.org; Tue, 18 May 2004 02:32:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17818 for ; Tue, 18 May 2004 02:32:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BPy9k-0006DP-Fh for rddp@ietf.org; Tue, 18 May 2004 02:32:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BPy8i-0005nH-00 for rddp@ietf.org; Tue, 18 May 2004 02:31:48 -0400 Received: from system60.simplicato.com ([207.99.47.60] helo=host52a.simplicato.com) by ietf-mx with esmtp (Exim 4.12) id 1BPy7q-0005Nl-00 for rddp@ietf.org; Tue, 18 May 2004 02:30:54 -0400 Received: from localhost (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with ESMTP id C321E11E353; Tue, 18 May 2004 02:30:55 -0400 (EDT) Received: from host52a.simplicato.com ([127.0.0.1]) by localhost (host52a.simplicato.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12220-06; Tue, 18 May 2004 02:30:54 -0400 (EDT) Received: by host52a.simplicato.com (Postfix, from userid 15001) id A6F0611E339; Tue, 18 May 2004 02:30:54 -0400 (EDT) Received: from mail.asomi.com (localhost.simplicato.com [127.0.0.1]) by host52a.simplicato.com (Postfix) with SMTP id 5A3F411E329; Tue, 18 May 2004 02:30:54 -0400 (EDT) Received: from 82.166.249.161 (proxying for 82.166.249.161) (SquirrelMail authenticated user cait@asomi.com) by mail52a.simplicato.com with HTTP; Tue, 18 May 2004 01:30:54 -0500 (CDT) Message-ID: <24322.82.166.249.161.1084861854.squirrel@mail52a.simplicato.com> In-Reply-To: <16553.403.189040.644523@lx-desk84.amd.com> References: <56848.82.166.249.161.1084771702.squirrel@mail52a.simplicato.com><6.1.0.6.2.20040517094058.032f8c60@15.13.130.73> <16553.403.189040.644523@lx-desk84.amd.com> Date: Tue, 18 May 2004 01:30:54 -0500 (CDT) Subject: Re: [rddp] legality of interleaving untagged message segments From: "Caitlin Bestler" To: "Jeff Dwork" Cc: rddp@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at simplicato.com Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jeff Dwork said: > A receiver capable of tracking out-of-order messages is more complex > than one which requres in-order submission. Support of out-of-order > message submission must be negotiated prior to stream initialization. > > A possible implementation: The receiver declares the maximum number of > simultaneous messages it will accept, possible values being an integer > greater than 0 or the special value "NO_LIMIT" (perhaps represented as > 0). > > A value of "1" means that all segments of message N must be submitted > before any segments of message N+1. A value of "NO_LIMIT" means that > the receiver will accept any number of out-of-order messages up to the > size of the RQ/S_RQ. > > Jeff > The potential optimizations to an "in-order receiver" are real, but they definitely would not justify more session parameters negotiated on the wi= re. What is proposed is far simpler, that untagged messages behave as though their segments are submitted to the LLP atomically. For example, SCTP has such a restriction on SCTP layer segmentation of user messages. >From the RDMAP layer this is entirely transparent. It is only an issue to the implementation of the DDP layer. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue May 18 15:07:46 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06469 for ; Tue, 18 May 2004 15:07:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9sb-0002A5-NA for rddp-archive@odin.ietf.org; Tue, 18 May 2004 15:03:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4IJ3vXh008307 for rddp-archive@odin.ietf.org; Tue, 18 May 2004 15:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9o3-0005ZB-Qz for rddp-web-archive@optimus.ietf.org; Tue, 18 May 2004 14:59:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05717 for ; Tue, 18 May 2004 14:59:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9o1-0007Jq-4m for rddp-web-archive@ietf.org; Tue, 18 May 2004 14:59:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9nE-0007HO-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 14:58:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9mc-0007EO-00 for rddp-web-archive@ietf.org; Tue, 18 May 2004 14:57:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9g6-0004WU-L1; Tue, 18 May 2004 14:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQ9Yn-0003El-8E for rddp@optimus.ietf.org; Tue, 18 May 2004 14:43:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04736 for ; Tue, 18 May 2004 14:43:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQ9Yk-0006LT-H2 for rddp@ietf.org; Tue, 18 May 2004 14:43:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQ9Xk-0006GH-00 for rddp@ietf.org; Tue, 18 May 2004 14:42:24 -0400 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1BQ9Wn-0006CB-00 for rddp@ietf.org; Tue, 18 May 2004 14:41:25 -0400 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel12.hp.com (Postfix) with ESMTP id D5045423146 for ; Tue, 18 May 2004 11:41:24 -0700 (PDT) Received: from MK731916.cup.hp.com (mk731916.cup.hp.com [15.8.80.134]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id LAA25132 for ; Tue, 18 May 2004 11:30:14 -0700 (PDT) Message-Id: <6.1.0.6.2.20040518113323.01d06250@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 18 May 2004 11:34:24 -0700 To: rddp@ietf.org From: Michael Krause Subject: Re: [rddp] legality of interleaving untagged message segments In-Reply-To: <7241.82.166.249.161.1084861474.squirrel@mail52a.simplicato .com> References: <56848.82.166.249.161.1084771702.squirrel@mail52a.simplicato.com> <6.1.0.6.2.20040517094058.032f8c60@15.13.130.73> <7241.82.166.249.161.1084861474.squirrel@mail52a.simplicato.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: IETF Remote Direct Data Placement (rddp) WG List-Post: List-Help: List-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.0 required=5.0 tests=none autolearn=no version=2.60 At 11:24 PM 5/17/2004, Caitlin Bestler wrote: >Michael Krause said: > > > > Within a given LLP stream, you are correct that the optimization benefits > > may be minimal if I/O device is somewhat "distant" (read as relatively > > high > > latency) from the memory controller. However, as we see the industry move > > towards PCI Express (PCIe) and with the potential to create more > > integrated > > memory controller chipsets, there may be greater benefit over time > > (especially with some architectures moving to be more NUMA oriented). > > > > Given this may take time to occur and validate, would you be willing to > > make this a SHOULD NOT instead of a MUST NOT thus allowing leeway for > > future development while providing strong guidance that such interleaving > > is strongly discouraged? > > > > Mike > > > >There is already a SHOULD that segment SHOULD be submitted in ascending >order. So no further SHOULD clause is required. > >Or for that matter useful. > > A "SHOULD NOT 'X'" clause does not truly allow the receiver to optimize on >the assumption that senders will not do X. It just discourages testing of >'X', >so in a sense it's worse than doing nothing. Receivers are not free to >optimize, >and senders are discouraged from whatever optimization there might be. > >My assumption is that the MUST NOT I am proposing will not preclude any >achievable optimization on the sender side. If that assumption is correct >then benefit to the receiver is clearly preferable. But if anyone had an >algorithm that really would optimize across message boundaries and gain >actual benefits from it then the tradeoff is indeed more complex. > >The benefit at the receiver side, for an implementation that defers placement >processing of DDP segments until they can be processed in order, is that >there would be at most one active untagged buffer per DDP Stream. This >is a major benefit, which I believe outweighs the theoretical benefits that >some unidentified sender algorithm *might* achieve in the future. > >Of course I am willing to be convinced to the contrary if someone were to >present a contemplated optimization that this restriction would interfere >with. >Or for that matter, even assert that they are researching such an algorithm >that they are unwilling to disclose. I willing to make this a MUST NOT and address this in a future version of the spec should the optimizations be publicized. Mike _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp