From exim@www1.ietf.org Tue Feb 3 13:37:08 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 NAA23584 for ; Tue, 3 Feb 2004 13:37:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5Pc-00034i-0b for rddp-archive@odin.ietf.org; Tue, 03 Feb 2004 13:36:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Iadsw011814 for rddp-archive@odin.ietf.org; Tue, 3 Feb 2004 13:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5Pb-00034T-RA for rddp-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 13:36:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23558 for ; Tue, 3 Feb 2004 13:36:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5PZ-0003y7-00 for rddp-web-archive@ietf.org; Tue, 03 Feb 2004 13:36:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5Og-0003sU-00 for rddp-web-archive@ietf.org; Tue, 03 Feb 2004 13:35:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5OC-0003mH-00 for rddp-web-archive@ietf.org; Tue, 03 Feb 2004 13:35:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5O3-0002w5-Hg; Tue, 03 Feb 2004 13:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao5Nl-0002vJ-VL for rddp@optimus.ietf.org; Tue, 03 Feb 2004 13:34:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23481 for ; Tue, 3 Feb 2004 13:34:43 -0500 (EST) From: pat_thaler@agilent.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5Nj-0003l0-00 for rddp@ietf.org; Tue, 03 Feb 2004 13:34:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5Mr-0003ex-00 for rddp@ietf.org; Tue, 03 Feb 2004 13:33:51 -0500 Received: from msgbas1tx.cos.agilent.com ([192.25.240.37] helo=msgbas2x.cos.agilent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao5MI-0003Xs-00 for rddp@ietf.org; Tue, 03 Feb 2004 13:33:14 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas2x.cos.agilent.com (Postfix) with ESMTP id 3A5FF7C68; Tue, 3 Feb 2004 11:33:14 -0700 (MST) Received: from wcosbh23.cos.agilent.com (wcosbh23.cos.agilent.com [130.29.152.145]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 1CC3178D; Tue, 3 Feb 2004 11:33:14 -0700 (MST) Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh23.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 3 Feb 2004 11:33:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EA84.2E84EE77" Subject: RE: [rddp] Removing Trust Models and including "Mutual Trust" Date: Tue, 3 Feb 2004 11:33:13 -0700 Message-ID: Thread-Topic: [rddp] Removing Trust Models and including "Mutual Trust" Thread-Index: AcPmrj3i2/gNH28YStaU5jQsQW+G8QAGC+QQAADl3ZAA7lN44A== To: , Cc: X-OriginalArrivalTime: 03 Feb 2004 18:33:13.0906 (UTC) FILETIME=[2ED8F920:01C3EA84] 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.5 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EA84.2E84EE77 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm really having trouble parsing the sentence with the clause in the = commas.=20 =20 "A collection of ... Streams, which ... the Stream, ...."=20 What is "the Stream" and how do a collection of streams represent "the = Stream".=20 =20 I think you mean something like "The word Stream in this sentence = represents the local and remote end points of the stream." =20 How about -=20 =20 Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing to = assume that the local and remote end points of Streams from the = collection will not perform malicious attacks against any of the Streams = in the collection. =20 Regards, Pat -----Original Message----- From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org]On Behalf Of Jim = Pinkerton Sent: Thursday, January 29, 2004 4:44 PM To: Jim Pinkerton; Caitlin Bestler Cc: rddp@ietf.org Subject: RE: [rddp] Removing Trust Models and including "Mutual Trust" =20 How about this to resolove the use of "Streams"?? =20 Partial Mutual Trust - a collection of RDMAP/DDP Streams, which = represent the local and remote end points of the Stream, are willing to = assume that the Streams from the collection will not perform malicious = attacks against any of the Streams in the collection. =20 =20 _____ =20 From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim = Pinkerton Sent: Thursday, January 29, 2004 4:22 PM To: Caitlin Bestler Cc: rddp@ietf.org Subject: RE: [rddp] Removing Trust Models and including "Mutual Trust" =20 =20 I'm not trying to make any statement about ULP behavior - just RDDP = behavior. I.e. that the two ends of a Stream will not try to perform = malicious RDMAP/DDP attacks on each other. Thus "full compliance with = the ULP" would be out of scope (i.e. doesn't matter for this security = document). =20 On the use of "Streams", I used "Streams" as short hand - the sentence = now repeats the word multiple times - and the equivalent end point text = is "the Local and Remote Peer". I don't see any loss of clarity in using = Streams, and believe it to be more readable. =20 Separately, I got feedback to change the wording slightly to (change is = in bold, if it gets through the reflector): =20 =20 Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing to = assume that the Streams from the collection will not perform malicious = attacks against any of the Streams in the collection. =20 Would it make it clearer if I changed "malicious attacks" to "malicious = RDMAP/DDP attacks"? =20 =20 =20 Jim =20 =20 =20 > -----Original Message----- > From: Caitlin Bestler [mailto:cait@asomi.com] > Sent: Thursday, January 29, 2004 12:58 PM > To: Jim Pinkerton > Cc: rddp@ietf.org > Subject: Re: [rddp] Removing Trust Models and including "Mutual Trust" >=20 >=20 > On Jan 29, 2004, at 12:24 PM, Jim Pinkerton wrote: >=20 > > > > > > Per the last IETF meeting, the Trust Model concept has now been = moved > > to the Appendix. The document now focuses on whether a resource is > > shared or not, and assumes the Remote Peer is untrusted. An > > interesting side-effect of this is that the definition for "Partial > > Trust" goes with it. And the document in general assumes the Remote > > Peer (and Unprivileged Local Peer) are simply "untrusted". > > > > > > > > This semantic is unfortunately not rich enough, however. I've = started > > editing the > > document to more directly address security concerns in a = client/server > > environment. > > As part of that editing, it seems worthwhile to introduce a new > > concept Sara Bitan > > and I are calling "partial mutual trust" (Sara is now an author on = the > > document, > > specifically working on the Security Services for RDMAP/DDP = section). > > This more > > acurately describes the "session" concept that some applications = have. > > And then > > one can talk about how two Streams do not share "mutual trust" and > > thus are subject > > to a specific attack and need X countermeasure - so we can now = define > > a server that > > has multiple sessions (each with potentially multiple Streams) to > > individual clients, > > and individual clients do not trust each other. > > > > > > > > Feedback on this model would be appreciated. > > > > > > > > Here's my tentative definition of "partial mutual trust": > > > > > > > > Partial Mutual Trust - a collection of RDMAP/DDP Streams are willing > > to assume that > > the other Streams will not perform malicious attacks against any of > > the Streams in > > the collection. > > > > >=20 >=20 > On a purely semantic basis I'm not sure I like assigning intent to the > Streams, > to the endpoints of the stream yes, but not the streams themselves. >=20 > Aside from that, is the intent here to distinguish between absence of > malice > from "full compliance with the ULP"? Where the latter would be Full > Mutual Trust? > ("Full compliance with the ULP" implies compliance with all *rules* of > the > ULP, not just the packet formats. Hence a properly filled out = withdrawal > request with a forged signature is not truly "ULP compliant" even if = the > syntax checks all pass because the packet is not submitted in = compliance > with the full ULP). =20 ------_=_NextPart_001_01C3EA84.2E84EE77 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm = really having=20 trouble parsing the sentence with the clause in the commas. =
 
"A = collection of=20 ... Streams, which ... the Stream, ...."
What = is "the Stream"=20 and how do a collection of streams represent "the Stream". =
 
I = think you mean=20 something like "The word Stream in this sentence represents the local = and remote=20 end points of the stream."
 
How = about -=20
 
Partial Mutual=20 Trust – a collection of RDMAP/DDP Streams are willing to assume = that the local=20 and remote end points of Streams from the collection will not perform = malicious=20 attacks against any of the Streams in the = collection.
 
Regards,
Pat
-----Original Message-----
From: = rddp-admin@ietf.org=20 [mailto:rddp-admin@ietf.org]On Behalf Of Jim = Pinkerton
Sent:=20 Thursday, January 29, 2004 4:44 PM
To: Jim Pinkerton; = Caitlin=20 Bestler
Cc: rddp@ietf.org
Subject: RE: [rddp] = Removing=20 Trust Models and including "Mutual Trust"

 

How about = this to=20 resolove the use of “Streams”??

 

Partial Mutual Trust – a collection of = RDMAP/DDP=20 Streams, which represent the local and remote end points of the = Stream, are=20 willing to assume that the Streams from the collection will not = perform=20 malicious attacks against any of the Streams in the=20 collection.

 

 

From:=20 rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim = Pinkerton
Sent: Thursday, January 29, = 2004 4:22=20 PM
To: Caitlin=20 Bestler
Cc:=20 rddp@ietf.org
Subject: RE:=20 [rddp] Removing Trust Models and including "Mutual=20 Trust"

 

 

I'm not trying to make any statement about = ULP=20 behavior - just RDDP behavior. I.e. that the two ends of a Stream will = not try=20 to perform malicious RDMAP/DDP attacks on each other. Thus "full = compliance=20 with the ULP" would be out of scope (i.e. doesn't matter for this = security=20 document).

 

On the use of "Streams", I used "Streams" as = short=20 hand - the sentence now repeats the word multiple times - and the = equivalent=20 end point text is "the Local and Remote Peer". I don't see any loss of = clarity=20 in using Streams, and believe it to be more = readable.

 

Separately, I got feedback to change the = wording=20 slightly to (change is in bold, if it gets through the=20 reflector):

 

 

Partial Mutual Trust – = a collection of=20 RDMAP/DDP Streams are willing to assume that the Streams from the collection will not = perform=20 malicious attacks against any of the Streams in the=20 collection.

 

Would it make it clearer if I changed = “malicious=20 attacks” to “malicious RDMAP/DDP = attacks”?

 

 

 

Jim

 

 

 

> -----Original = Message-----

> From: Caitlin Bestler=20 [mailto:cait@asomi.com]

> Sent: Thursday, January 29, 2004 12:58=20 PM

> To: Jim Pinkerton

> Cc: rddp@ietf.org

> Subject: Re: [rddp] Removing Trust = Models and=20 including "Mutual Trust"

>

>

> On Jan 29, 2004, at 12:24 PM, Jim = Pinkerton=20 wrote:

>

> >

> >

> > Per the last IETF meeting, the = Trust Model=20 concept has now been moved

> > to the Appendix. The document now = focuses on=20 whether a resource is

> > shared or not, and assumes the = Remote Peer=20 is untrusted. An

> > interesting side-effect of this is = that the=20 definition for “Partial

> > Trust” goes with it. And the = document in=20 general assumes the Remote

> > Peer (and Unprivileged Local Peer) = are=20 simply “untrusted”.

> >

> >

> >

> > This semantic is unfortunately not = rich=20 enough, however. I’ve started

> > editing the

> > document to more directly address = security=20 concerns in a client/server

> > environment.

> > As part of that editing, it seems = worthwhile=20 to introduce a new

> > concept Sara = Bitan

> > and I are calling “partial = mutual trust”=20 (Sara is now an author on the

> > document,

> > specifically working on the = Security=20 Services for RDMAP/DDP section).

> > This more

> > acurately describes the = “session” concept=20 that some applications have.

> > And then

> > one can talk about how two Streams = do not=20 share “mutual trust” and

> > thus are subject

> > to a specific attack and need X=20 countermeasure – so we can now define

> > a server that

> > has multiple sessions (each with = potentially=20 multiple Streams) to

> > individual = clients,

> > and individual clients do not = trust each=20 other.

> >

> >

> >

> > Feedback on this model would be=20 appreciated.

> >

> >

> >

> > Here’s my tentative = definition of “partial=20 mutual trust”:

> >

> >

> >

> > Partial Mutual Trust – a = collection of=20 RDMAP/DDP Streams are willing

> > to assume that

> > the other Streams will not perform = malicious=20 attacks against any of

> > the Streams in

> > the collection.

> >

> >

>

>

> On a purely semantic basis I'm not sure = I like=20 assigning intent to the

> Streams,

> to the endpoints of the stream yes, but = not the=20 streams themselves.

>

> Aside from that, is the intent here to=20 distinguish between absence of

> malice

> from "full compliance with the ULP"? = Where the=20 latter would be Full

> Mutual Trust?

> ("Full compliance with the ULP" implies = compliance with all *rules* of

> the

> ULP, not just the packet formats. Hence = a=20 properly filled out withdrawal

> request with a forged signature is not = truly "ULP=20 compliant" even if the

> syntax checks all pass because the = packet is not=20 submitted in compliance

> with the full ULP).

 

------_=_NextPart_001_01C3EA84.2E84EE77-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Feb 3 21:08:17 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 VAA17149 for ; Tue, 3 Feb 2004 21:08:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCSC-0001lu-Nd for rddp-archive@odin.ietf.org; Tue, 03 Feb 2004 21:07:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1427mdO006803 for rddp-archive@odin.ietf.org; Tue, 3 Feb 2004 21:07:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCSB-0001lN-Ux for rddp-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 21:07:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17145 for ; Tue, 3 Feb 2004 21:07:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoCS9-0006dR-00 for rddp-web-archive@ietf.org; Tue, 03 Feb 2004 21:07:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoCRF-0006Yw-00 for rddp-web-archive@ietf.org; Tue, 03 Feb 2004 21:06:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoCQS-0006UR-00 for rddp-web-archive@ietf.org; Tue, 03 Feb 2004 21:06:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCQT-0001P9-Vz; Tue, 03 Feb 2004 21:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoCPZ-0001NW-9c for rddp@optimus.ietf.org; Tue, 03 Feb 2004 21:05:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17100 for ; Tue, 3 Feb 2004 21:05:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoCPW-0006Op-00 for rddp@ietf.org; Tue, 03 Feb 2004 21:05:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoCOU-0006Jk-00 for rddp@ietf.org; Tue, 03 Feb 2004 21:03:59 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1AoCO1-0006EQ-00 for rddp@ietf.org; Tue, 03 Feb 2004 21:03:29 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 18:02:56 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Feb 2004 18:02:59 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Feb 2004 18:02:59 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Feb 2004 18:03:00 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Feb 2004 18:03:12 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 3 Feb 2004 18:03:03 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3EAC3.0308C269" Date: Tue, 3 Feb 2004 18:02:45 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: I-D ACTION:draft-pinkerton-iwarp-sdp-00.txt,.pdf Thread-Index: AcPqmgkIF0eM+C77SUWZKu+PqWiu0gAKJ6JA From: "Jim Pinkerton" To: X-OriginalArrivalTime: 04 Feb 2004 02:03:03.0645 (UTC) FILETIME=[05FC50D0:01C3EAC3] Subject: [rddp] FW: I-D ACTION:draft-pinkerton-iwarp-sdp-00.txt,.pdf 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.2 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EAC3.0308C269 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Sockets Direct Protocol ID has finally been published. Apologies to those that were looking for it for the long delay. I had originally submitted it back in November, but it apparently was never published. I resubmitted it on Monday, and it was out the next day. I'd be willing to present on this (if there is sufficient interest) at the next IETF. Jim -----Original Message----- From: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 03, 2004 12:46 PM Subject: I-D ACTION:draft-pinkerton-iwarp-sdp-00.txt,.pdf A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Sockets Direct Protocol (SDP) for iWARP over TCP Author(s) : J. Pinkerton Filename : draft-pinkerton-iwarp-sdp-00.txt,.pdf Pages : 106 Date : 2004-2-3 =09 This document is an Internet-Draft and is subject to all provisions=20 of Section 10 of RFC2026. Internet-Drafts are working documents of=20 the Internet Engineering Task Force (IETF), its areas, and its=20 working groups. Note that other groups may also distribute working=20 documents as Internet-Drafts. Internet-Drafts are draft documents=20 valid for a maximum of six months and may be updated, replaced, or=20 obsoleted by other documents at any time. It is inappropriate to=20 use Internet-Drafts as reference material or to cite them other than=20 as 'work in progress.' A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-pinkerton-iwarp-sdp-00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-pinkerton-iwarp-sdp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-pinkerton-iwarp-sdp-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C3EAC3.0308C269 Content-Type: application/octet-stream; name="draft-pinkerton-iwarp-sdp-00.URL" Content-Description: draft-pinkerton-iwarp-sdp-00.URL Content-Disposition: attachment; filename="draft-pinkerton-iwarp-sdp-00.URL" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1waW5rZXJ0b24taXdhcnAtc2RwLTAwLnR4dA0K ------_=_NextPart_001_01C3EAC3.0308C269-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Feb 4 15:46:07 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 PAA25900 for ; Wed, 4 Feb 2004 15:46:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTty-0005M5-Pd for rddp-archive@odin.ietf.org; Wed, 04 Feb 2004 15:45:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14KjcTu020581 for rddp-archive@odin.ietf.org; Wed, 4 Feb 2004 15:45:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTtx-0005Ls-Om for rddp-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:45:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25868 for ; Wed, 4 Feb 2004 15:45:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTtw-0001tv-00 for rddp-web-archive@ietf.org; Wed, 04 Feb 2004 15:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTsw-0001mx-00 for rddp-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTsR-0001gb-00 for rddp-web-archive@ietf.org; Wed, 04 Feb 2004 15:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTsR-0004ox-BH; Wed, 04 Feb 2004 15:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTrx-0004mU-N8 for rddp@optimus.ietf.org; Wed, 04 Feb 2004 15:43:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25719; Wed, 4 Feb 2004 15:43:31 -0500 (EST) Message-Id: <200402042043.PAA25719@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rddp@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 04 Feb 2004 15:43:31 -0500 Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-01.txt 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.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : DDP/RDMAP Security Author(s) : J. Pinkerton Filename : draft-ietf-rddp-security-01.txt Pages : 58 Date : 2004-2-4 This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into spoofing, tampering, information disclosure, denial of service, and elevation of privilege. Finally, the document concludes with a summary of security services for RDDP, such as IPSec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-security-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-security-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-4160252.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-security-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-4160252.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Feb 5 16:24:17 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 QAA09824 for ; Thu, 5 Feb 2004 16:24:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqyT-0001Ub-Ab for rddp-archive@odin.ietf.org; Thu, 05 Feb 2004 16:23:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15LNnEP005736 for rddp-archive@odin.ietf.org; Thu, 5 Feb 2004 16:23:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqyT-0001UR-6T for rddp-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 16:23:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09818 for ; Thu, 5 Feb 2004 16:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqyR-0002lu-00 for rddp-web-archive@ietf.org; Thu, 05 Feb 2004 16:23:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqxG-0002b1-00 for rddp-web-archive@ietf.org; Thu, 05 Feb 2004 16:22:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqwl-0002T0-00 for rddp-web-archive@ietf.org; Thu, 05 Feb 2004 16:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqwj-0001Bt-DV; Thu, 05 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqvy-00019g-MG for rddp@optimus.ietf.org; Thu, 05 Feb 2004 16:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09509 for ; Thu, 5 Feb 2004 16:21:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqvw-0002Ps-00 for rddp@ietf.org; Thu, 05 Feb 2004 16:21:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoqv1-0002KE-00 for rddp@ietf.org; Thu, 05 Feb 2004 16:20:16 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqu7-00029O-00 for rddp@ietf.org; Thu, 05 Feb 2004 16:19:19 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 13:18:20 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Feb 2004 13:18:47 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 13:18:47 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 5 Feb 2004 13:18:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 5 Feb 2004 13:18:17 -0800 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7165.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] I-D ACTION:draft-ietf-rddp-security-01.txt Date: Thu, 5 Feb 2004 13:18:47 -0800 Message-ID: Thread-Topic: [rddp] I-D ACTION:draft-ietf-rddp-security-01.txt Thread-Index: AcPrX7x8EkrSRGMTT6+RsVJ4DL/glQAr1mDA From: "Jim Pinkerton" To: X-OriginalArrivalTime: 05 Feb 2004 21:18:17.0463 (UTC) FILETIME=[92A75870:01C3EC2D] 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Note that the .pdf version was also submitted. The pdf version has change-bars turned on, for those that want to see the detailed differences. To access it use the link below, but replace the ".txt" extension with ".pdf". Jim > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, February 04, 2004 12:44 PM > Cc: rddp@ietf.org > Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Remote Direct Data Placement Working > Group of the IETF. >=20 > Title : DDP/RDMAP Security > Author(s) : J. Pinkerton > Filename : draft-ietf-rddp-security-01.txt > Pages : 58 > Date : 2004-2-4 >=20 > This document analyzes security issues around implementation and > use of the Direct Data Placement Protocol(DDP) and Remote Direct > Memory Access Protocol (RDMAP). It first defines an architectural > model for an RDMA Network Interface Card (RNIC), which can > implement DDP or RDMAP and DDP. The document reviews various > attacks against the resources defined in the architectural model > and the countermeasures that can be used to protect the system. > Attacks are grouped into spoofing, tampering, information > disclosure, denial of service, and elevation of privilege. > Finally, the document concludes with a summary of security > services for RDDP, such as IPSec. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-01.txt >=20 > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-rddp-security-01.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-rddp-security-01.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Feb 5 16:37:54 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 QAA12228 for ; Thu, 5 Feb 2004 16:37:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorBe-0002Xi-IR for rddp-archive@odin.ietf.org; Thu, 05 Feb 2004 16:37:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15LbQhu009765 for rddp-archive@odin.ietf.org; Thu, 5 Feb 2004 16:37:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorBe-0002XL-8d for rddp-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 16:37:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12198 for ; Thu, 5 Feb 2004 16:37:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AorBc-0005rb-00 for rddp-web-archive@ietf.org; Thu, 05 Feb 2004 16:37:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AorAm-0005lk-00 for rddp-web-archive@ietf.org; Thu, 05 Feb 2004 16:36:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aor9J-0005P7-00 for rddp-web-archive@ietf.org; Thu, 05 Feb 2004 16:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aor9K-0002H1-M5; Thu, 05 Feb 2004 16:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aor9E-0002Fu-Pq for rddp@optimus.ietf.org; Thu, 05 Feb 2004 16:34:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11595 for ; Thu, 5 Feb 2004 16:34:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aor9C-0005NX-00 for rddp@ietf.org; Thu, 05 Feb 2004 16:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aor6z-0004qz-00 for rddp@ietf.org; Thu, 05 Feb 2004 16:32:39 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1Aor4f-00049w-00 for rddp@ietf.org; Thu, 05 Feb 2004 16:30:13 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id E5B6324F6FB for ; Thu, 5 Feb 2004 16:01:20 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <49987C33-581E-11D8-90DA-003065D48EE0@asomi.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'RDDP'" From: Caitlin Bestler Date: Thu, 5 Feb 2004 15:00:11 -0600 X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [rddp] RE: MPA Responses - Connection Startup Ordering Requirements 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 The response draft does clarify the rationale on when the respondent can send the first DDP Segment, but I am still not convinced that there is a need for the restriction. To recap: Prior to this response, there was an assertion that the responding side must wait for the first message from the initiator before it could send its first message because without the response there was no way to know that there was an RDMA endpoint enabled yet. That is not the case, which is why the SCTP adaptation is not required. Basically, unless the ULP has a specific reason to postpone the assignment of an endpoint, an endpoint will have been assigned as soon as the initiating side requests the connection. This is how both the DAT and IT-API interfaces work. The initiating side (typically the client) knows all of its endpoint requirements in advance, it only needs to know if they are acceptable to the responding side. But there is a difference between SCTP and TCP that *might* justify this restriction: SCTP Data Chunks containing DDP Segments received out-of-order can still be placed, because not only is the RDMA endpoint already enabled but the DDP Segments cannot be identified. With TCP, however, DDP Segments cannot be extracted from the TCP stream until after the MPA Reply Frame is received (or technically the first segment, since that would include the length, but realistically the MPA Reply Frame is almost certain to fit within the first segment). That means that once the ULP has signaled the intent to enter MPA mode, the receiving stack knows how to process any TCP segment received. If TCP segments are received out of order, it can hold them until they can be processed, or it can drop them and let them retransmit. The response talks about "transferring data", as though prior to fully enabling RDMA over MPA the connection were still being managed as a conventional TCP connection. That is one possible decision, but it is not a protocol requirement. The stack, however it is structured, has been clearly instructed that it will be receiving a single MPA Reply Frame followed by a series of MPA framed DDP Segments. The existence of this intermediate state make it feasible for the receiving stack to either hold or drop out-of-order segments in a way that would not normally be done for a normal TCP connection. So the receiving stack already has the information required to handle these out-of-order segments properly. There is no reason to mistake them for conventional TCP stream payload. This makes deferred processing (by holding the buffers or waiting for the retransmit) simple. And given that the probability of delivery for any one TCP Segment is extremely high in any environment where RDMA should be used, the cost of properly handling these out of order segments is very low. Keep in mind that during this intermediate state the receiver is NOT required to process these out-of-order segments, the only thing it MUST do is that it MUST NOT process them as part of a conventional TCP stream -- but it already knows not to do that. By contrast, the benefit of removing this restriction can be very high for a class of application that tends to have short lived sessions. Such applications could piggy-back the first request in the MPA Request Frame's private data. This would allow the first DDP Segment in the response to be piggy-backed in the same TCP segment as the MPA Reply Frame. This can eliminate an entire round-trip from the exchange. This is a potential major benefit to at least one class of applications, and it only requires that the receiver properly use information that it already possesses. No additional context data is required. Also consider that any ULP that wishes to require the initiator to send the first message is still able to do so. The fact that the respondent's stack is not enforcing this restriction will in no way impact any ULP. If a non-compliant respondent sent its message early, *and* they were received out of order, it *might* have an impact of causing an artificial packet drop. This is an *extremely* minor cost compared to the benefit that "quick response" applications could gain. Also, it should be noted that if a ULP dictated the size of the private data in the response then the initiating size would actually be able to process out-of-order segments immediately. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Feb 6 10:37: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 KAA01514 for ; Fri, 6 Feb 2004 10:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap82I-0003Oo-NI for rddp-archive@odin.ietf.org; Fri, 06 Feb 2004 10:36:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16FasN8013066 for rddp-archive@odin.ietf.org; Fri, 6 Feb 2004 10:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap82I-0003Of-Jh for rddp-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 10:36:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01470 for ; Fri, 6 Feb 2004 10:36:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap82G-0005Bl-00 for rddp-web-archive@ietf.org; Fri, 06 Feb 2004 10:36:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap81F-000596-00 for rddp-web-archive@ietf.org; Fri, 06 Feb 2004 10:35:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap80S-00056P-00 for rddp-web-archive@ietf.org; Fri, 06 Feb 2004 10:35:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap80T-00037k-JH; Fri, 06 Feb 2004 10:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap80E-000379-Fd for rddp@optimus.ietf.org; Fri, 06 Feb 2004 10:34:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01311 for ; Fri, 6 Feb 2004 10:34:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap80C-000552-00 for rddp@ietf.org; Fri, 06 Feb 2004 10:34:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7zH-00051r-00 for rddp@ietf.org; Fri, 06 Feb 2004 10:33:48 -0500 Received: from ztxmail05.ztx.compaq.com ([161.114.1.209]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7yO-0004wg-00 for rddp@ietf.org; Fri, 06 Feb 2004 10:32:52 -0500 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.28]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 9A05CA834; Fri, 6 Feb 2004 09:32:19 -0600 (CST) Received: from cceexc18.americas.cpqcorp.net ([16.81.1.4]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Feb 2004 09:32:19 -0600 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] RE: MPA Responses - Connection Startup Ordering Requirements Date: Fri, 6 Feb 2004 09:32:16 -0600 Message-ID: <4D027986353D1341ADA4F2A4F8A170762CC6A2E9@cceexc18.americas.cpqcorp.net> Thread-Topic: [rddp] RE: MPA Responses - Connection Startup Ordering Requirements Thread-Index: AcPsMO1xy6Q0AmKvQXauPPRjXEeb0QAj/kAg From: "Culley, Paul" To: "Caitlin Bestler" , "RDDP" X-OriginalArrivalTime: 06 Feb 2004 15:32:19.0241 (UTC) FILETIME=[6833C990:01C3ECC6] 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Embedded... Paul R. Culley HP Fellow 281-514-5543 > -----Original Message----- > From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On=20 > Behalf Of Caitlin Bestler > Sent: Thursday, February 05, 2004 3:00 PM > To: 'RDDP' > Subject: [rddp] RE: MPA Responses - Connection Startup=20 > Ordering Requirements >=20 >=20 > The response draft does clarify the rationale on when the=20 > respondent can send the first DDP Segment, but I am still not=20 > convinced that there is a need for the restriction. >=20 > To recap: >=20 > Prior to this response, there was an assertion that the=20 > responding side must wait for the first message from the=20 > initiator before it could send its first message because=20 > without the response there was no way to know that there was=20 > an RDMA endpoint enabled yet. >=20 > That is not the case, which is why the SCTP adaptation is not=20 > required. Basically, unless the ULP has a specific reason to=20 > postpone the assignment > of an endpoint, an endpoint will have been assigned as soon=20 > as the initiating side requests the connection. This is how=20 > both the DAT and IT-API interfaces work. The initiating side=20 > (typically the client) knows all of its endpoint requirements=20 > in advance, it only needs to know if they are acceptable to=20 > the responding side. [prc] The initiating side DOES NOT know if markers are to be used until the MPA Response Frame is received. As such it cannot begin processing FPDUs until after the frame has been processed. In addition, it may not know the size of Send messages, the RDMA Read resources required and some application values. Of course these can be "known" by design, or the responder application can voluntarily delay the first message until the initiator sends an FPDU. >=20 > But there is a difference between SCTP and TCP that *might*=20 > justify this restriction: SCTP Data Chunks containing DDP=20 > Segments received out-of-order can still be placed, because=20 > not only is the RDMA endpoint already enabled but the DDP=20 > Segments cannot be identified. >=20 > With TCP, however, DDP Segments cannot be extracted from the=20 > TCP stream until after the MPA Reply Frame is received (or=20 > technically the first segment, since that would include the=20 > length, but realistically the MPA Reply Frame is almost=20 > certain to fit within the first segment). [prc] at the moment, the MPA Reply frame length can be up to 64k long, potentially quite a bit longer than a segment. >=20 > That means that once the ULP has signaled the intent to enter=20 > MPA mode, the receiving stack knows how to process any TCP=20 > segment received. If TCP segments are received out of order,=20 > it can hold them until they can be processed, or it can drop=20 > them and let them retransmit. [prc]If we implement this way, the MPA/DDP stack must now implement the following functionality that was not required previously (it could have been done with legacy stack and ULP code): 1: accept TCP segments, re-ordering if necessary to find the beginning of the MPA Response frame. 2: accept TCP segments, re-ordering if necessary to get the entire MPA Response frame, 3: Decode the Marker, CRC, and other bit fields, setting up the MPA/DDP "engine" to process FPDUs. 4: Deliver the Private data to the ULP. 5: Hold off processing FPDUs until the ULP has indicated that it is ready to do so (posted receive buffers of appropriate size, set RDMA Read resources etc.). 6: Process any already delivered or out of order FPDUs that were received prior to the MPA Reply frame completion. Alternately, we could not require the last two steps, and just let FPDUs arrive, potentially not matching the buffer sizes etc.; thus requiring the initiator ULP to insert a response FPDU anyway, in at least some ULPs. >=20 > The response talks about "transferring data", as though prior=20 > to fully enabling RDMA over MPA the connection were still=20 > being managed as a conventional TCP connection. [prc]The idea of managing the MPA startup over a conventional TCP connection was more easily enabled if we do not allow "early" FPDU sending by the responder. Admittedly, the extension of this concept when allowing the "early" FPDUs was the idea we analyzed, and there are other possible implementations. >=20 > That is one possible decision, but it is not a protocol=20 > requirement. The stack, however it is structured, has been=20 > clearly instructed that it will be receiving a single MPA=20 > Reply Frame followed by a series of MPA framed DDP Segments. >=20 > The existence of this intermediate state make it feasible for=20 > the receiving stack to either hold or drop out-of-order=20 > segments in a way that would not normally be done for a=20 > normal TCP connection. >=20 > So the receiving stack already has the information required=20 > to handle these out-of-order segments properly. There is no=20 > reason to mistake them for conventional TCP stream payload.=20 > This makes deferred processing (by holding the buffers or=20 > waiting for the retransmit) simple. >=20 > And given that the probability of delivery for any one TCP=20 > Segment is extremely high in any environment where RDMA=20 > should be used, the cost of properly handling these out of=20 > order segments is very low. >=20 > Keep in mind that during this intermediate state the receiver=20 > is NOT required to process these out-of-order segments, the=20 > only thing it MUST do is that it MUST NOT process them as=20 > part of a conventional TCP stream -- but it already knows not=20 > to do that. >=20 > By contrast, the benefit of removing this restriction can be=20 > very high for a class of application that tends to have short=20 > lived sessions. >=20 > Such applications could piggy-back the first request in the=20 > MPA Request Frame's private data. This would allow the first=20 > DDP Segment in the response to be piggy-backed in the same=20 > TCP segment as the MPA Reply Frame. This can eliminate an=20 > entire round-trip from the exchange. >=20 > This is a potential major benefit to at least one class of=20 > applications, and it only requires that the receiver properly=20 > use information that it already possesses. No additional=20 > context data is required. >=20 > Also consider that any ULP that wishes to require the=20 > initiator to send the first message is still able to do so.=20 > The fact that the respondent's stack is not enforcing this=20 > restriction will in no way impact any ULP. If a non-compliant=20 > respondent sent its message early, *and* they were received=20 > out of order, it *might* have an impact of causing an=20 > artificial > packet drop. This is an *extremely* minor cost compared to=20 > the benefit that "quick response" applications could gain. >=20 > Also, it should be noted that if a ULP dictated the size of=20 > the private data in the response then the initiating size=20 > would actually be able to process out-of-order segments immediately. >=20 [prc] I think we agree that it is possible to implement your "early" response FPDU rule in any number of ways. I think we are primarily disagreeing on the cost, not of run time processing, but in implementation design/debug/verification time. It seems that you believe the cost is low (or perhaps you think the benefits outweigh any possible costs) while some of us believe that the cost is high and benefits are limited enough not to be worth it. As for short lived sessions; I suspect that if the session is sufficiently short lived that the time savings you describe becomes an issue, that RDMA/DDP over TCP may not be the best choice. It is a bit early in product life cycles to tell, but I suspect that various setup overheads may make short lived sessions perform no better than straight TCP, SCTP, or even datagrams. The real win for RDMA/DDP is when LOTS of data must be moved directly to application buffers; that is when the copy, interrupt and kernel processing overheads of legacy stacks is eliminated or reduced enough to make the use of RDMA/DDP worth it. I think it is time for some other voices to say something about this issue; the current discussion (several months now) has been limited to Caitlin and myself. I think I am proxying for a significant list of other authors and implementers, but it is not clear to me that anyone other than Caitlin cares much about this issue. Thanks;=20 Paul C. >=20 > --=20 > Caitlin Bestler - cait@asomi.com - http://asomi.com/ >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Feb 6 11:42:15 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 LAA03688 for ; Fri, 6 Feb 2004 11:42:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap936-0000n4-1b for rddp-archive@odin.ietf.org; Fri, 06 Feb 2004 11:41:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16Gfmni003038 for rddp-archive@odin.ietf.org; Fri, 6 Feb 2004 11:41:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap935-0000mv-Q3 for rddp-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 11:41:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03685 for ; Fri, 6 Feb 2004 11:41:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap934-0001RR-00 for rddp-web-archive@ietf.org; Fri, 06 Feb 2004 11:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap92B-0001PG-00 for rddp-web-archive@ietf.org; Fri, 06 Feb 2004 11:40:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap91Z-0001Mk-00 for rddp-web-archive@ietf.org; Fri, 06 Feb 2004 11:40:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap91Q-0000j7-M4; Fri, 06 Feb 2004 11:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap91A-0000h4-QC for rddp@optimus.ietf.org; Fri, 06 Feb 2004 11:39:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03647 for ; Fri, 6 Feb 2004 11:39:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap919-0001LG-00 for rddp@ietf.org; Fri, 06 Feb 2004 11:39:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap90G-0001ID-00 for rddp@ietf.org; Fri, 06 Feb 2004 11:38:54 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap8zX-0001Bc-00 for rddp@ietf.org; Fri, 06 Feb 2004 11:38:08 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 02A912457A4; Fri, 6 Feb 2004 11:38:35 -0500 (EST) In-Reply-To: <4D027986353D1341ADA4F2A4F8A170762CC6A2E9@cceexc18.americas.cpqcorp.net> References: <4D027986353D1341ADA4F2A4F8A170762CC6A2E9@cceexc18.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "RDDP" From: Caitlin Bestler Subject: Re: [rddp] RE: MPA Responses - Connection Startup Ordering Requirements Date: Fri, 6 Feb 2004 10:37:24 -0600 To: "Culley, Paul" X-Mailer: Apple Mail (2.612) 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 Feb 6, 2004, at 9:32 AM, Culley, Paul wrote: > Embedded... > > Paul R. Culley > HP Fellow > 281-514-5543 > > >> -----Original Message----- >> From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On >> Behalf Of Caitlin Bestler >> Sent: Thursday, February 05, 2004 3:00 PM >> To: 'RDDP' >> Subject: [rddp] RE: MPA Responses - Connection Startup >> Ordering Requirements >> >> >> The response draft does clarify the rationale on when the >> respondent can send the first DDP Segment, but I am still not >> convinced that there is a need for the restriction. >> >> To recap: >> >> Prior to this response, there was an assertion that the >> responding side must wait for the first message from the >> initiator before it could send its first message because >> without the response there was no way to know that there was >> an RDMA endpoint enabled yet. >> >> That is not the case, which is why the SCTP adaptation is not >> required. Basically, unless the ULP has a specific reason to >> postpone the assignment >> of an endpoint, an endpoint will have been assigned as soon >> as the initiating side requests the connection. This is how >> both the DAT and IT-API interfaces work. The initiating side >> (typically the client) knows all of its endpoint requirements >> in advance, it only needs to know if they are acceptable to >> the responding side. > [prc] The initiating side DOES NOT know if markers are to be used until > the MPA Response Frame is received. As such it cannot begin processing > FPDUs until after the frame has been processed. Any receiver knows whether or not *it* is insisting on markers, and hence can process it's own incoming DDP Segments for placement even before completing the MPA Response Frame. Obviously, you cannot *send* a DDP Segment until you receive the peer's MPA Request/Response Frame. That is the essential minimal rule. > In addition, it may not know the size of Send messages, the RDMA Read > resources required and some application values. Of course these can be > "known" by design, or the responder application can voluntarily delay > the first message until the initiator sends an FPDU. > These factors are agreed via ULP specific methods. If these are included in the private data, then for *that* application protocol you would indeed have to wait for the first FPDU. The question is whether the standard will *forbid* any application from sending a first message even when all information needed to support that message is already present at both ends -- and in doing so adding an additional round-trip delay. The ULP remains free to dictate which end will talk first. But by having the respondent talk first an application could eliminate a round-trip delay for simple fetch-oriented protocols. Why should the MPA specification block this optimization? The information required to support this feature is already available to the receiver, it merely has to use it. >> >> But there is a difference between SCTP and TCP that *might* >> justify this restriction: SCTP Data Chunks containing DDP >> Segments received out-of-order can still be placed, because >> not only is the RDMA endpoint already enabled but the DDP >> Segments cannot be identified. >> >> With TCP, however, DDP Segments cannot be extracted from the >> TCP stream until after the MPA Reply Frame is received (or >> technically the first segment, since that would include the >> length, but realistically the MPA Reply Frame is almost >> certain to fit within the first segment). > [prc] at the moment, the MPA Reply frame length can be up to 64k long, > potentially quite a bit longer than a segment. Even if it is 64K long, the length is in the very first segment. There are two reasons why it will tend to fit in one segment: a) most applications will only send the data that is required before the RDMA connection is established. Credits and session identifying information will almost certainly fit within a single segment. Even an immediate command ("get /xyz/abc.html") will probably still fit. b) Transport-neutral applications will be motivated to keep the private data length compatible with the InfiniBand CM protocol -- which would almost always keep it in a single segment. c) ULPs are quite likely to place a limit on the private data size for their application, because doing so limits the pre-committed buffering required to accept connections. Just as applications do not want to commit 64KB for each possible untagged message, they do not want to lock down 64KB for each possible connection request. >> >> That means that once the ULP has signaled the intent to enter >> MPA mode, the receiving stack knows how to process any TCP >> segment received. If TCP segments are received out of order, >> it can hold them until they can be processed, or it can drop >> them and let them retransmit. > [prc]If we implement this way, the MPA/DDP stack must now implement the > following functionality that was not required previously (it could have > been done with legacy stack and ULP code): > 1: accept TCP segments, re-ordering if necessary to find the beginning > of the MPA Response frame. > 2: accept TCP segments, re-ordering if necessary to get the entire MPA > Response frame, > 3: Decode the Marker, CRC, and other bit fields, setting up the MPA/DDP > "engine" to process FPDUs. > 4: Deliver the Private data to the ULP. > 5: Hold off processing FPDUs until the ULP has indicated that it is > ready to do so (posted receive buffers of appropriate size, set RDMA > Read resources etc.). > 6: Process any already delivered or out of order FPDUs that were > received prior to the MPA Reply frame completion. > You are taking the weaknesses of implementing MPA Start Frame processing via the conventional stack and making them requirements. The Start Frame allows the ULP to transition to MPA mode without revocation at a known point. When this request is made, it is known that all packets further in the stream will be part of the MPA Start Frame or FPDUs. You do indeed have to place and deliver the Private Data to the ULP, but the data can be placed out of order once the first segment is received and the buffer length is known. You are also assuming that the ULP is not assigning the RDMA Endpoint on the initiating side until after receiving the MPA Response Frame. That is not a requirement, in fact that option is not even supported in the DAT or IT-API protocols. So at the minimum we can say that there will be numerous applications where the initiating-side's RDMA Endpoint is selected *before* the TCP connection is initiated. In that case, the only requirement is that out-of-order TCP Segments received before the private data size is known must be held for later delivery or dropped. Just as importantly, any implementation built on top of a TCP stack will have *zero* problem with supporting quick responses. Again, the same issue comes up. The benefit of allowing quick responses can be very substantial for some applications. A receiver can process this by either re-delivering the payload or by dropping segments received out-of-order before the private data size is known. If DDP Segments are received before an RDMA Endpoint is assigned, then the respondent side is not in compliance with the ULP and there is no harm in dropping the connection. There are distinct scenarios where this type of packet COULD be processed with MAJOR benefits. Why should this practice be forbidden? > Alternately, we could not require the last two steps, and just let > FPDUs > arrive, potentially not matching the buffer sizes etc.; thus requiring > the initiator ULP to insert a response FPDU anyway, in at least some > ULPs. > >> >> The response talks about "transferring data", as though prior >> to fully enabling RDMA over MPA the connection were still >> being managed as a conventional TCP connection. > [prc]The idea of managing the MPA startup over a conventional TCP > connection was more easily enabled if we do not allow "early" FPDU > sending by the responder. Admittedly, the extension of this concept > when allowing the "early" FPDUs was the idea we analyzed, and there are > other possible implementations. >> >> That is one possible decision, but it is not a protocol >> requirement. The stack, however it is structured, has been >> clearly instructed that it will be receiving a single MPA >> Reply Frame followed by a series of MPA framed DDP Segments. >> >> The existence of this intermediate state make it feasible for >> the receiving stack to either hold or drop out-of-order >> segments in a way that would not normally be done for a >> normal TCP connection. >> >> So the receiving stack already has the information required >> to handle these out-of-order segments properly. There is no >> reason to mistake them for conventional TCP stream payload. >> This makes deferred processing (by holding the buffers or >> waiting for the retransmit) simple. >> >> And given that the probability of delivery for any one TCP >> Segment is extremely high in any environment where RDMA >> should be used, the cost of properly handling these out of >> order segments is very low. >> >> Keep in mind that during this intermediate state the receiver >> is NOT required to process these out-of-order segments, the >> only thing it MUST do is that it MUST NOT process them as >> part of a conventional TCP stream -- but it already knows not >> to do that. >> >> By contrast, the benefit of removing this restriction can be >> very high for a class of application that tends to have short >> lived sessions. >> >> Such applications could piggy-back the first request in the >> MPA Request Frame's private data. This would allow the first >> DDP Segment in the response to be piggy-backed in the same >> TCP segment as the MPA Reply Frame. This can eliminate an >> entire round-trip from the exchange. >> >> This is a potential major benefit to at least one class of >> applications, and it only requires that the receiver properly >> use information that it already possesses. No additional >> context data is required. >> >> Also consider that any ULP that wishes to require the >> initiator to send the first message is still able to do so. >> The fact that the respondent's stack is not enforcing this >> restriction will in no way impact any ULP. If a non-compliant >> respondent sent its message early, *and* they were received >> out of order, it *might* have an impact of causing an >> artificial >> packet drop. This is an *extremely* minor cost compared to >> the benefit that "quick response" applications could gain. >> >> Also, it should be noted that if a ULP dictated the size of >> the private data in the response then the initiating size >> would actually be able to process out-of-order segments immediately. >> > [prc] I think we agree that it is possible to implement your "early" > response FPDU rule in any number of ways. I think we are primarily > disagreeing on the cost, not of run time processing, but in > implementation design/debug/verification time. It seems that you > believe the cost is low (or perhaps you think the benefits outweigh any > possible costs) while some of us believe that the cost is high and > benefits are limited enough not to be worth it. > You are proposing a permanent protocol restriction that is not justified by complexity for the problem space, only of certain early implementation strategies. > As for short lived sessions; I suspect that if the session is > sufficiently short lived that the time savings you describe becomes an > issue, that RDMA/DDP over TCP may not be the best choice. It is a bit > early in product life cycles to tell, but I suspect that various setup > overheads may make short lived sessions perform no better than straight > TCP, SCTP, or even datagrams. The real win for RDMA/DDP is when LOTS > of > data must be moved directly to application buffers; that is when the > copy, interrupt and kernel processing overheads of legacy stacks is > eliminated or reduced enough to make the use of RDMA/DDP worth it. A single large file would benefit from RDMA, and adding an extra round-trip over a long-haul connection is still an unnecessary delay. > > I think it is time for some other voices to say something about this > issue; the current discussion (several months now) has been limited to > Caitlin and myself. I think I am proxying for a significant list of > other authors and implementers, but it is not clear to me that anyone > other than Caitlin cares much about this issue. > David was the one who raised the issue about the extra round-trip delay. This issue was also discussed within the DAT Collaborative, and the consensus there was that the requirement was without benefit. When viewed from the point of an end-to-end application design, any additional restriction is an added cost in validation/qa/etc. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Feb 11 07:52:11 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 HAA29408 for ; Wed, 11 Feb 2004 07:52:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqtq9-00079r-GE for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 07:51:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BCpfQv027509 for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 07:51:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqtq8-00079a-V4 for rddp-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 07:51:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29402 for ; Wed, 11 Feb 2004 07:51:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqtq7-0007lX-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 07:51:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqtpD-0007gP-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 07:50:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqtoa-0007av-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 07:50:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqtoZ-00071l-M5; Wed, 11 Feb 2004 07:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiaP-0000uM-Id for rddp@optimus.ietf.org; Tue, 10 Feb 2004 19:50:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06214 for ; Tue, 10 Feb 2004 19:50:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiaN-0002u4-00 for rddp@ietf.org; Tue, 10 Feb 2004 19:50:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiZV-0002li-00 for rddp@ietf.org; Tue, 10 Feb 2004 19:49:50 -0500 Received: from [192.55.52.30] (helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AqiYo-0002Yv-00 for rddp@ietf.org; Tue, 10 Feb 2004 19:49:03 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1B0jsWL006549; Wed, 11 Feb 2004 00:45:54 GMT Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1B0oFow020185; Wed, 11 Feb 2004 00:50:15 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.135]) by fmsmsxv041-1.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004021016481628161 ; Tue, 10 Feb 2004 16:48:16 -0800 Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Feb 2004 16:48:15 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F038.BB624DC4" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 10 Feb 2004 16:48:14 -0800 Message-ID: <6315617889C99D4BA7C14687DEC8DB4E052188C7@fmsmsx402.fm.intel.com> Thread-Topic: Re: Clause 4 comments Thread-Index: AcPwOLZVrrZl3u3zRAaoJCHYEb3AHQ== From: "Shah, Hemal" To: Cc: X-OriginalArrivalTime: 11 Feb 2004 00:48:15.0414 (UTC) FILETIME=[BBAEDD60:01C3F038] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [rddp] Re: Clause 4 comments 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.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F038.BB624DC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barry, Below is my response to editorial comments on CLAUSE 4 that you posted to the reflector in late Nov. Hemal * To: "RDDP" =20 * Subject: [rddp] Clause 4 comments to draft-ietf-rddp-ddp-01=20 * From: "Barry Reinhold" =20 * Date: Mon, 17 Nov 2003 13:33:37 -0500=20 * Importance: Normal=20 * List-help: =20 * List-id: IETF Remote Direct Data Placement (rddp) WG =20 * List-post: =20 * List-subscribe: ,=20 * List-unsubscribe: ,=20 * Sender: rddp-admin@ietf.org=20 _____ =20 CLAUSE 4 =20 Below are comments on clause 4. There are 32 editorial comments, most are nits, but there are some rewordings that are significantly different. Most of the rewording was made in an effort to improve the clarity of the concept being defined. None of the rewording is believed to be a technical change. =20 =20 1, Editorial, Low, 4.1 under Advertisement =20 Is: the act =20 Suggest: The act =20 Change is: Capitalize "the" [hvs] Change accepted. =20 2, Editorial, low, 4.1 under Data Delivery =20 Is: Delivery is defined as the process of informing the ULP or consumer that a particular Message is available for use. =20 Suggest: Delivery is defined as the process of informing the ULP or consumer that a particular message is available for use. =20 Change: capitalization of "message" removed [hvs] Change accepted. 3, Editorial, low, 4.1 under Data Delivery =20 Is: This is specifically different from "Placement", which may generally occur in any order, while the order of "Delivery" is strictly defined. =20 Suggest: Delivery is distinct from "placement". Placement of data into ULP buffers may occur in any order, whereas the order of message "delivery" to the ULP is strictly defined. =20 Change: Reword [hvs] Change not accepted. I would rather keep the text as it is. =20 4, Editorial, low, 4.1 under Data Sink =20 Is: Note that the Data Sink can be required to both send and receive RDMA/DDP Messages to transfer a data payload. =20 Suggest: Note that the Data Sink can be required to both send and receive RDMA/DDP messages to transfer a data payload. =20 Change: capitalization of "message" removed [hvs] Change not accepted. Stick with the convention. =20 5, Editorial, low, 4.1 under Data Sink =20 Is: Note that the Data Source can be required to both send and receive RDMA/DDP Messages to transfer a data payload. =20 Suggest: Note that the Data Source can be required to both send and receive RDMA/DDP messages to transfer a data payload. =20 Change: capitalization of "message" removed [hvs] Change not accepted. Stick with the convention. =20 6, Editorial, low, 4.1 under Node =20 Is: A computing device attached to one or more links of network. =20 Suggest: A computing device attached to a network by one or more links. =20 Change: Reword [hvs] Change not accepted. Added a before the network =20 =20 7. Editorial, low, 4.1 under ULP =20 Is: The ULP for RDMA/DDP is expected to be an OS, Application, adaptation layer, or proprietary device. =20 Suggest: The ULP for RDMA/DDP is expected to be an OS, application, adaptation layer, or proprietary device. =20 Change: capitalization of application removed [hvs] Change accepted. =20 8. Editorial, low 4.1 under ULP Message =20 Is: the ULP data that is handed to a specific protocol layer for transmission. =20 Suggest: The ULP data that is handed to a specific protocol layer for transmission. =20 Change: Capitalize the first word in the sentence [hvs] Change accepted. =20 9. Editorial, low 4.1, 4.2 =20 Consistency of sections - The current draft has three sub sections, General, LLP, and DDP. Given that framework it appears that there should be a sub section for ULP containing (ULP, ULP message, ULP payload, ULP buffer, and ULP message length). However, the way a glossary is used is to quickly identify the meaning of a term. Given the size of the glossary a single level alphabetical organization is probably better. =20 Suggest: Removing sub sections in the glossary. [hvs] Change not accepted. =20 10. Editorial, medium, 4.2 & 4.3 under LLP Connection and LLP Stream, also relates to 4.3 DDP Stream. =20 The definitions of stream and connection could be more precise. Currently defined are DDP stream, LLP stream, and LLP connection.=20 =20 Within the draft document connection is used five times without a LLP qualification (clause 3.2 page 6, clause 4.1 under local peer, remote peer, and LLP stream, clause 10.4), stream is used four times (8.2, 9.1 item 1, 9.1 item 1 under non-zero case, and 10.4 item 3) without qualification. =20 Suggest: Defining DDP stream, and DDP connection in terms of concepts significant to DDP. Define LLP connection and LLP stream by reference to LLP protocol specifications. Possible wording below: =20 DDP stream - A logical channel between a local peer and a remote peer in which the ordering of a sequence of DDP messages is maintained. There is no guarantee of message ordering when a sequence of DDP messages is sent over more then one stream. =20 DDP connection - An association between two DDP peers that provides a context for DDP streams. DDP streams can not exist outside the context of a DDP connection. If supported by the LLP, more then one DDP stream may exist within a single DDP connection as in SCTP.=20 =20 LLP connection - A connection as defined by the lower layer protocol. See [SCTP], [TCP]. =20 LLP stream - The logical channel provided by the LLP that allows the ordered delivery of DDP messages between DDP peers. For SCTP the LLP stream is the SCTP stream (see [SCTP]). For TCP the ordered delivery service is provided by the TCP connection (see [TCP]). Note that TCP supports no more than one DDP stream per TCP connection. =20 [hvs] Change not accepted. The current definitions of LLP connection, LLP Stream, and DDP Stream are fine. I do see a need to have a DDP connection definition. =20 11. Editorial, medium, 4.2 under ULPDU =20 Is: Upper Layer Protocol Data Unit. The data record defined by=20 the layer above MPA. =20 Suggest: Upper Layer Protocol Data Unit. The data record defined by=20 the layer above DDP. =20 Change: Replaced MPA with DDP. [hvs] Replaced MPA with LLP. =20 12. Editorial, low, 4.3 under Data Placement =20 Is: Placement (Placement, Placed, Places) - For DDP, this term is=20 specifically used to indicate the process of writing to a data=20 buffer by a DDP implementation. DDP Segments carry Placement=20 information, which may be used by the receiving DDP=20 implementation to perform Data Placement of the DDP Segment ULP=20 Payload. See "Data Delivery". =20 Suggest: Placement (Placement, Placed, Places) - The process of writing the ULP payload of a DDP segment to the data buffer specified in the header of the DDP segment. Placement and delivery have specific and distinct meaning in DDP. See "Data Delivery" and "Direct Data Placement". =20 Change: Reword and simplify, reference Direct Data Placement for additional details. [hvs] Added "Direct Data Placement" at the end. Other text is still the same. =20 13. Editorial, low, 4.3 under DDP Control Field =20 Is: a fixed 8-bit field in the DDP Header. =20 Suggested: A fixed 8-bit field in the DDP header. =20 Change: Capitalize "a", remove capitalization of header [hvs] Change accepted. =20 14. Editorial, low, 4.3 under DDP Header =20 Is: The header present in all DDP Segments. The DDP Header=20 contains control and Placement fields that are used to define=20 the final Placement location for the ULP Payload carried in a=20 DDP Segment. =20 Suggest: The header present in all DDP segments. The DDP header contains control and placement information. (See clause 6) =20 Change: Reword and added reference. [hvs] Change not accepted. I am fine with the current text. =20 15. Editorial, low, 4.3 under DDP Message =20 Is: A ULP defined unit of data interchange, which is=20 subdivided into one or more DDP Segments. This segmentation may=20 occur for a variety of reasons, including segmentation to=20 respect the maximum segment size of the underlying transport=20 protocol. =20 Suggest: A ULP defined unit of data interchange, which is=20 subdivided into one or more DDP segments. This segmentation may=20 occur for a variety of reasons, including segmentation to=20 respect the maximum segment size of the underlying transport=20 protocol. =20 Change: Changed capitalization of DDP Segments... (nice definition BTW) [hvs] Change not accepted. Sticking with the convention. =20 16. Editorial, low 4.3 under DDP Segment =20 Is: The smallest unit of data transfer for the DDP=20 protocol. It includes a DDP Header and ULP Payload (if present).=20 A DDP Segment should be sized to fit within the Lower Layer=20 Protocol MULPDU. =20 Suggest: The smallest unit of data transfer for the DDP=20 protocol. It includes a DDP header and ULP payload (if present).=20 A DDP segment should be sized to fit within the lower layer=20 protocol MULPDU. =20 Change: Capitalization [hvs] Change not accepted. =20 17. Editorial, low 4.3 under Direct Data Placement =20 Is: A mechanism whereby ULP data contained=20 within DDP Segments may be Placed directly into its final=20 destination in memory without processing of the ULP. This may=20 occur even when the DDP Segments arrive out of order. Out of=20 order Placement support may require the Data Sink to implement=20 the LLP and DDP as one functional block. =20 Suggest: The placement of the ULP payload in a DDP segment into its final memory location without processing by the ULP. This may occur even when the DDP Segments arrive out of order. Out of order placement support may require the data sink to implement the LLP and DDP as one functional block. =20 Change: Reword and capitalization [hvs] Change not accepted. Rewording is not making it better.=20 =20 18. Editorial, medium 4.3 under Direct Data Placement Protocol =20 Is: Also, a wire protocol that=20 supports Direct Data Placement by associating explicit memory=20 buffer placement information with the LLP payload units. =20 Suggest: A wire protocol that enables direct data placement by associating placement information with the ULP payload units.=20 =20 Change: Wording, replaced LLP with ULP. [hvs] Change not accepted. LLP is correct because placement information is in LLP payload. =20 19. Editorial, low 4.3 under Message Offset =20 Is: For the DDP Untagged Buffer Model, specifies=20 the offset, in octets, from the start of a DDP Message. =20 Suggest: The offset, in octets, from the start of a DDP message. Used with the untagged buffer model. =20 Change: Wording, capitalization [hvs] Rewording not accepted. Not seeing advantage of rewording. =20 20. Editorial, low 4.3 under Message Sequence Number (MSN) =20 Is: For the DDP Untagged Buffer Model, specifies a sequence number that is increasing with each DDP Message. =20 Suggest: A sequence number in the header of a DDP segment. Used with untagged buffers. See clause 6.3. =20 Change: Replaced definition with reference to clause 6.3. The two did not appear to be consistent; goal is to have a single definition in spec. [hvs] Change not accepted. Keeping the definition unchanged. =20 21. Editorial, low 4.3 under Protection Domain =20 Is: A Mechanism used to associate a DDP Stream=20 and an STag. Under this mechanism, the use of an STag is valid=20 on a DDP Stream if the STag has the same Protection Domain=20 Identifier (PD ID) as the DDP Stream. =20 Suggest: A Mechanism used to associate a DDP stream=20 and an STag. Under this mechanism, the use of an STag is valid=20 on a DDP stream if the STag has the same protection domain=20 identifier (PD ID) as the DDP stream. =20 Change: Capitalization [hvs] Change not accepted. =20 22. Editorial, low 4.3 under QN =20 Is: For the DDP Untagged Buffer Model, identifies a destination Data Sink queue for a DDP Segment. =20 Suggest: The destination data sink queue for a DDP segment. Used with the untagged buffer model. =20 Change: wording, capitalization [hvs] Change not accepted.=20 =20 23. Editorial, low 4.3 under Steering Tag =20 Is: An identifier of a Tagged Buffer on a Node, valid as=20 defined within a protocol specification. =20 Suggest: An identifier of a tagged buffer on a node, valid as=20 defined within a protocol specification.=20 =20 Change: capitalization [hvs] Change not accepted. Sticking with the convention. =20 24. Editorial, low 4.3 under Tagged Buffer =20 Is: A buffer that is explicitly Advertised to the Remote=20 Peer through exchange of an STag, Target Offset, and length. =20 =20 Suggest: A buffer that is explicitly advertised to the remote=20 peer through exchange of an STag, target offset, and length. =20 Change: Capitalization [hvs] Change not accepted. Sticking with the convention. Changed Target Offset to Tagged Offset just to be consistent in the doc. Thanks for pointing this out.=20 =20 25. Editorial, medium, under Tagged Buffer Model =20 Is: A DDP data transfer model used to transfer Tagged Buffers from the Local Peer to the Remote Peer.=20 =20 Suggest: A DDP data transfer model that allows the local peer to advertise a named buffer. (See clause 3.1) =20 Change: Reword and added reference to more complete definition [hvs] Change not accepted. I will stick with the current definition. =20 26. Editorial, low 4.3 under Tagged DDP Message =20 Is: A DDP Message that targets a Tagged Buffer.=20 =20 Suggest: A DDP message containing a Stag. Messages which contain Stags use the tagged buffer model. =20 Change: Reworded to remove the word "targets" [hvs] Change not accepted. I will stick with the current definition. =20 27. Editorial, low, 4.3 under Tagged Offset =20 Is: The offset within a Tagged Buffer on a Node. =20 Suggest: The offset, in octets, from the start of a tagged buffer. Used with the tagged buffer model. =20 Change: wording to make consistent with MO. Capitalization [hvs] Change not accepted. =20 28. Editorial, low, 4.3 under ULP Buffer =20 Is: A buffer owned above the DDP Layer and advertised to=20 the DDP Layer either as a Tagged Buffer or an Untagged ULP=20 Buffer. =20 Suggest: A buffer owned above the DDP layer and advertised to=20 the DDP layer either as a tagged buffer or an untagged ULP=20 buffer. =20 Change: Capitalization [hvs] Change not accepted. =20 29. Editorial, low, 4.3 under ULP Message Length =20 Is: is the total length of the ULP Payload contained=20 in a DDP Message. =20 Suggest: The total length, in octets, of the ULP payload contained in a DDP message. =20 Change: removed leading is, added octets, changed capitalization. [hvs] Change accepted. =20 30. Editorial, low, 4.3 under Untagged Buffer =20 Is: A buffer that is not explicitly Advertised to the=20 Remote Peer. =20 =20 Suggest: A buffer that is not explicitly advertised to the remote peer. =20 Change: capitalization [hvs] Change not accepted. Defined term are used with capitalization. =20 31. Editorial, low, 4.3 under Untagged Buffer Model =20 Is: A DDP data transfer model used to transfer Untagged Buffers from the Local Peer to the Remote Peer.=20 =20 Suggest: A DDP data transfer model that preserves ULP message boundaries from the remote peer while keeping the local peers buffers anonymous. (See clause 3.1) [hvs] Change not accepted. =20 32. Editorial, low, 4.3 under Untagged DDP Message =20 Is: A DDP Message that targets an Untagged=20 Buffer. =20 Suggest: A DDP message containing a queue number. Messages which contain queue numbers use the untagged buffer model. =20 Change: reworded to remove the word "targets" [hvs] Change not accepted. The suggested text does not make the definition better. =20 =20 Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 =20 =20 =20 ------_=_NextPart_001_01C3F038.BB624DC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Barry,

Below is my response to = editorial comments on CLAUSE 4 that you posted to the reflector in late = Nov.

Hemal= 

CLAUSE 4
 
Below are =
comments on clause 4. There are 32 editorial comments, =
most
are nits, =
but there are some rewordings that are =
significantly
different. Most of the rewording was made in =
an effort to improve the
clarity =
of the concept being defined. None of the rewording is =
believed
to be a =
technical change.
 
 
1, =
Editorial, Low, 4.1 under Advertisement
 
Is: the =
act
 
Suggest: =
The act
 
Change =
is: Capitalize "the"
[hvs] =
Change accepted.
 
2, =
Editorial, low, 4.1 under Data Delivery
 
Is: =
Delivery is defined as the process of informing the ULP or =
consumer
that a =
particular Message is available for use.
 
Suggest: =
Delivery is defined as the process of informing the ULP =
or
consumer =
that a particular message is available for =
use.
 
Change: =
capitalization of "message" =
removed
[hvs] =
Change accepted.
3, =
Editorial, low, 4.1 under Data Delivery
 
Is: This =
is specifically different from "Placement", which may =
generally
occur in =
any order, while the order of "Delivery" is strictly =
defined.
 
Suggest: =
Delivery is distinct from "placement". Placement of data =
into
ULP =
buffers may occur in any order, whereas the order of =
message
"delivery" to the ULP is strictly =
defined.
 
Change: =
Reword
[hvs] =
Change not accepted. I would rather keep the text as it =
is.
 
4, =
Editorial, low, 4.1 under Data Sink
 
Is: Note =
that the Data Sink can be required to both send and =
receive
RDMA/DDP =
Messages to transfer a data payload.
 
Suggest: =
Note that the Data Sink can be required to both send =
and
receive =
RDMA/DDP messages to transfer a data =
payload.
 
Change: =
capitalization of "message" =
removed
[hvs] =
Change not accepted. Stick with the =
convention.
 
5, =
Editorial, low, 4.1 under Data Sink
 
Is: Note =
that the Data Source can be required to both send and =
receive
RDMA/DDP =
Messages to transfer a data payload.
 
Suggest: =
Note that the Data Source can be required to both send =
and
receive =
RDMA/DDP messages to transfer a data =
payload.
 
Change: =
capitalization of "message" =
removed
[hvs] =
Change not accepted. Stick with the =
convention.
 
6, =
Editorial, low, 4.1 under Node
 
Is: A =
computing device attached to one or more links of =
network.
 
Suggest: =
A computing device attached to a network by one or more =
links.
 
Change: =
Reword
[hvs] =
Change not accepted. Added a before the =
network
 
 
7. =
Editorial, low, 4.1 under ULP
 
Is: The =
ULP for RDMA/DDP is expected to be an OS, =
Application,
adaptation layer, or proprietary =
device.
 
Suggest: =
The ULP for RDMA/DDP is expected to be an OS, =
application,
adaptation layer, or proprietary =
device.
 
Change: =
capitalization of application removed
[hvs] =
Change accepted.
 
8. =
Editorial, low 4.1 under ULP Message
 
Is: the =
ULP data that is handed to a specific protocol layer =
for
transmission.
 
Suggest: =
The ULP data that is handed to a specific protocol layer =
for
transmission.
 
Change: =
Capitalize the first word in the sentence
[hvs] =
Change accepted.
 
9. =
Editorial, low 4.1, 4.2
 
Consistency of sections - The current draft =
has three sub sections,
General, =
LLP, and DDP. Given that framework it appears that there =
should
be a sub =
section for ULP containing (ULP, ULP message, ULP payload, =
ULP
buffer, =
and ULP message length). However, the way a glossary is used =
is
to =
quickly identify the meaning of a term. Given the size of =
the
glossary =
a single level alphabetical organization is probably =
better.
 
Suggest: =
Removing sub sections in the glossary.
[hvs] =
Change not accepted.
 
10. =
Editorial, medium, 4.2 & 4.3 under LLP Connection and LLP =
Stream,
also =
relates to 4.3 DDP Stream.
 
The =
definitions of stream and connection could be more =
precise.
Currently =
defined are DDP stream, LLP stream, and LLP connection. =

 
Within =
the draft document connection is used five times without a =
LLP
qualification (clause 3.2 page 6, clause 4.1 =
under local peer, remote
peer, and =
LLP stream, clause 10.4), stream is used four times (8.2, =
9.1
item 1, =
9.1 item 1 under non-zero case, and 10.4 item 3) =
without
qualification.
 
Suggest: =
Defining DDP stream, and DDP connection in terms of =
concepts
significant to DDP. Define LLP connection and =
LLP stream by reference to
LLP =
protocol specifications. Possible wording =
below:
 
DDP =
stream - A logical channel between a local peer and a remote peer =
in
which the =
ordering of a sequence of DDP messages is maintained. There =
is
no =
guarantee of message ordering when a sequence of DDP messages is =
sent
over more =
then one stream.
 
DDP =
connection - An association between two DDP peers that provides =
a
context =
for DDP streams. DDP streams can not exist outside the =
context
of a DDP =
connection. If supported by the LLP, more then one DDP =
stream
may exist =
within a single DDP connection as in SCTP. =

 
LLP =
connection - A connection as defined by the lower layer =
protocol.
See =
[SCTP], [TCP].
 
LLP =
stream - The logical channel provided by the LLP that allows =
the
ordered =
delivery of DDP messages between DDP peers. For SCTP the =
LLP
stream is =
the SCTP stream (see [SCTP]). For TCP the ordered =
delivery
service =
is provided by the TCP connection (see [TCP]). Note that =
TCP
supports =
no more than one DDP stream per TCP =
connection.
 
[hvs] =
Change not accepted. The current definitions of LLP connection, LLP =
Stream, and DDP Stream are
fine. I =
do see a need to have a DDP connection =
definition.
 
11. =
Editorial, medium, 4.2 under ULPDU
 
Is: Upper =
Layer Protocol Data Unit.  The data record defined by =

       the =
layer above MPA.
 
Suggest: =
Upper Layer Protocol Data Unit.  The data record defined by =

       the =
layer above DDP.
 
Change: =
Replaced MPA with DDP.
[hvs] =
Replaced MPA with LLP.
 
12. =
Editorial, low, 4.3 under Data Placement
 
Is: =
Placement (Placement, Placed, Places) - For DDP, this term is =

       spec=
ifically used to indicate the process of writing to a data =

       buff=
er by a DDP implementation.  DDP Segments carry Placement =

       info=
rmation, which may be used by the receiving DDP =

       impl=
ementation to perform Data Placement of the DDP Segment ULP =

       Payl=
oad. See "Data Delivery".
 
Suggest: =
Placement (Placement, Placed, Places) - The process of =
writing
the ULP =
payload of a DDP segment to the data buffer specified in =
the
header of =
the DDP segment. Placement and delivery have specific =
and
distinct =
meaning in DDP. See "Data Delivery" and "Direct =
Data
Placement".
 
Change: =
Reword and simplify, reference Direct Data Placement =
for
additional =
details.
[hvs] =
Added “Direct Data Placement” at the end. Other text is =
still the same.
 
13. =
Editorial, low, 4.3 under DDP Control =
Field
 
Is: a =
fixed 8-bit field in the DDP Header.
 
Suggested: A fixed 8-bit field in the DDP =
header.
 
Change: =
Capitalize "a", remove capitalization of =
header
[hvs] =
Change accepted.
 
14. =
Editorial, low, 4.3 under DDP Header
 
Is: The =
header present in all DDP Segments. The DDP Header =

       cont=
ains control and Placement fields that are used to define =

       the =
final Placement location for the ULP Payload carried in a =

       DDP =
Segment.
 
Suggest: =
The header present in all DDP segments. The DDP header =
contains
control =
and placement information. (See clause 6)
 
Change: =
Reword and added reference.
[hvs] =
Change not accepted. I am fine with the current =
text.
 
15. =
Editorial, low, 4.3 under DDP Message
 
 Is: A =
ULP defined unit of data interchange, which is =

       subd=
ivided into one or more DDP Segments. This segmentation may =

       occu=
r for a variety of reasons, including segmentation to =

       resp=
ect the maximum segment size of the underlying transport =

       prot=
ocol.
 
Suggest: =
A ULP defined unit of data interchange, which is =

       subd=
ivided into one or more DDP segments. This segmentation may =

       occu=
r for a variety of reasons, including segmentation to =

       resp=
ect the maximum segment size of the underlying transport =

       prot=
ocol.
 
Change: =
Changed capitalization of DDP Segments... (nice definition =
BTW)
[hvs] =
Change not accepted. Sticking with the =
convention.
 
16. =
Editorial, low 4.3 under DDP Segment
 
Is: The =
smallest unit of data transfer for the DDP =

       prot=
ocol. It includes a DDP Header and ULP Payload (if present). =

       A =
DDP Segment should be sized to fit within the Lower Layer =

       Prot=
ocol MULPDU.
 
Suggest: =
The smallest unit of data transfer for the DDP =

       prot=
ocol. It includes a DDP header and ULP payload (if present). =

       A =
DDP segment should be sized to fit within the lower layer =

       prot=
ocol MULPDU.
 
Change: =
Capitalization
[hvs] =
Change not accepted.
 
17. =
Editorial, low 4.3 under Direct Data =
Placement
 
Is: A =
mechanism whereby ULP data contained 
       with=
in DDP Segments may be Placed directly into its final =

       dest=
ination in memory without processing of the ULP. This may =

       occu=
r even when the DDP Segments arrive out of order. Out of =

       orde=
r Placement support may require the Data Sink to implement =

       the =
LLP and DDP as one functional block.
 
Suggest: =
The placement of the ULP payload in a DDP segment into =
its
final =
memory location without processing by the ULP. This may occur =
even
when the =
DDP Segments arrive out of order. Out of order =
placement
support =
may require the data sink to implement the LLP and DDP as =
one
functional =
block.
 
Change: =
Reword and capitalization
[hvs] =
Change not accepted. Rewording is not making it better. =

 
18. =
Editorial, medium 4.3 under Direct Data Placement =
Protocol
 
Is: Also, =
a wire protocol that 
       supp=
orts Direct Data Placement by associating explicit memory =

       buff=
er placement information with the LLP payload =
units.
 
Suggest: =
A wire protocol that enables direct data placement =
by
associating placement information with the =
ULP payload units. 
 
Change: =
Wording, replaced LLP with ULP.
[hvs] =
Change not accepted. LLP is correct because placement information is in =
LLP payload.
 
19. =
Editorial, low 4.3 under Message Offset
 
Is: For =
the DDP Untagged Buffer Model, specifies 
       the =
offset, in octets, from the start of a DDP =
Message.
 
Suggest: =
The offset, in octets, from the start of a DDP message. =
Used
with the =
untagged buffer model.
 
Change: =
Wording, capitalization
[hvs] =
Rewording not accepted. Not seeing advantage of =
rewording.
 
20. =
Editorial, low 4.3 under Message Sequence Number =
(MSN)
 
Is: For =
the DDP Untagged Buffer Model, specifies a sequence number =
that
is =
increasing with each DDP Message.
 
Suggest:   A sequence number in the =
header of a DDP segment. Used with
untagged =
buffers. See clause 6.3.
 
Change: =
Replaced definition with reference to clause 6.3. The two =
did
not =
appear to be consistent; goal is to have a single definition =
in
spec.
[hvs] =
Change not accepted. Keeping the definition =
unchanged.
 
21. =
Editorial, low 4.3 under Protection Domain
 
Is: A =
Mechanism used to associate a DDP Stream 
       and =
an STag. Under this mechanism, the use of an STag is valid =

       on =
a DDP Stream if the STag has the same Protection Domain =

       Iden=
tifier (PD ID) as the DDP Stream.
 
Suggest: =
A Mechanism used to associate a DDP stream =

       and =
an STag. Under this mechanism, the use of an STag is valid =

       on =
a DDP stream if the STag has the same protection domain =

       iden=
tifier (PD ID) as the DDP stream.
 
Change: =
Capitalization
[hvs] =
Change not accepted.
 
22. =
Editorial, low 4.3 under QN
 
Is: For =
the DDP Untagged Buffer Model, identifies a destination =
Data
Sink =
queue for a DDP Segment.
 
Suggest: =
The destination data sink queue for a DDP segment. Used =
with
the =
untagged buffer model.
 
Change: =
wording, capitalization
[hvs] =
Change not accepted. 
 
23. =
Editorial, low 4.3 under Steering Tag
 
Is: An =
identifier of a Tagged Buffer on a Node, valid as =

       defi=
ned within a protocol specification.
 
Suggest: =
An identifier of a tagged buffer on a node, valid as =

       defi=
ned within a protocol specification. 
 
Change: =
capitalization
[hvs] =
Change not accepted. Sticking with the =
convention.
 
24. =
Editorial, low 4.3 under Tagged Buffer
 
Is: A =
buffer that is explicitly Advertised to the Remote =

       Peer=
 through exchange of an STag, Target Offset, and length.  =

 
Suggest: =
A buffer that is explicitly advertised to the remote =

       peer=
 through exchange of an STag, target offset, and =
length.
 
Change: =
Capitalization
[hvs] =
Change not accepted. Sticking with the convention. Changed Target Offset =
to Tagged Offset just to be consistent in the doc. Thanks for pointing =
this out. 
 
25. =
Editorial, medium, under Tagged Buffer =
Model
 
Is: A DDP =
data transfer model used to transfer Tagged Buffers from =
the
Local =
Peer to the Remote Peer. 
 
Suggest: =
A DDP data transfer model that allows the local peer =
to
advertise =
a named buffer. (See clause 3.1)
 
Change: =
Reword and added reference to more complete =
definition
[hvs] =
Change not accepted. I will stick with the current =
definition.
 
26. =
Editorial, low 4.3 under Tagged DDP =
Message
 
Is:  =
A DDP Message that targets a Tagged Buffer. =

 
Suggest: =
A DDP message containing a Stag. Messages which contain =
Stags
use the =
tagged buffer model.
 
Change: =
Reworded to remove the word =
"targets"
[hvs] =
Change not accepted. I will stick with the current =
definition.
 
27. =
Editorial, low, 4.3 under Tagged Offset
 
Is:  =
The offset within a Tagged Buffer on a =
Node.
 
Suggest: =
The offset, in octets, from the start of a tagged buffer. =
Used
with the =
tagged buffer model.
 =

Change: =
wording to make consistent with MO. =
Capitalization
[hvs] =
Change not accepted.
 
28. =
Editorial, low, 4.3 under ULP Buffer
 =

Is: A =
buffer owned above the DDP Layer and advertised to =

       the =
DDP Layer either as a Tagged Buffer or an Untagged ULP =

       Buff=
er.
 
Suggest: =
A buffer owned above the DDP layer and advertised to =

       the =
DDP layer either as a tagged buffer or an untagged ULP =

       buff=
er.
 
Change: =
Capitalization
[hvs] =
Change not accepted.
 
29. =
Editorial, low, 4.3 under ULP Message =
Length
 
Is: is =
the total length of the ULP Payload contained =

       in =
a DDP Message.
 
Suggest: =
The total length, in octets, of the ULP payload contained in =
a
DDP =
message.
 
Change: =
removed leading is, added octets, changed =
capitalization.
[hvs] =
Change accepted.
 
30. =
Editorial, low, 4.3 under Untagged Buffer
 
Is: A =
buffer that is not explicitly Advertised to the =

       Remo=
te Peer.  
 
Suggest: =
A buffer that is not explicitly advertised to the remote =
peer.
 
Change: =
capitalization
[hvs] =
Change not accepted. Defined term are used with =
capitalization.
 
31. =
Editorial, low, 4.3 under Untagged Buffer =
Model
 
Is: A DDP =
data transfer model used to transfer Untagged Buffers from =
the
Local =
Peer to the Remote Peer. 
 
Suggest: =
A DDP data transfer model that preserves ULP message =
boundaries
from the =
remote peer while keeping the local peers buffers =
anonymous.
(See =
clause 3.1)
[hvs] =
Change not accepted.
 
32. =
Editorial, low, 4.3 under Untagged DDP =
Message
 
Is: A DDP =
Message that targets an Untagged 
       Buff=
er.
 
Suggest: =
A DDP message containing a queue number. Messages which =
contain
queue =
numbers use the untagged buffer model.
 
Change: =
reworded to remove the word =
"targets"
[hvs] =
Change not accepted. The suggested text does not make the definition =
better.
 
 
Barry =
Reinhold
Lamprey =
Networks
bbr@lampreynetworks.com
(603) = 868-8411
 =

 
 

 

=00 ------_=_NextPart_001_01C3F038.BB624DC4-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Feb 11 15:20:22 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 PAA19767 for ; Wed, 11 Feb 2004 15:20:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0pt-00019v-Kt for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 15:19:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKJr9X004451 for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 15:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0pt-00019i-Fw for rddp-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19714 for ; Wed, 11 Feb 2004 15:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0ps-0007lz-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 15:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0ox-0007fh-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 15:18:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0o4-0007ZO-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 15:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0o4-0000IZ-9a; Wed, 11 Feb 2004 15:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0nv-0000Fx-U7 for rddp@optimus.ietf.org; Wed, 11 Feb 2004 15:17:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19466 for ; Wed, 11 Feb 2004 15:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0nu-0007Y1-00 for rddp@ietf.org; Wed, 11 Feb 2004 15:17:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0n1-0007ST-00 for rddp@ietf.org; Wed, 11 Feb 2004 15:16:57 -0500 Received: from [192.55.52.30] (helo=fmsfmr003.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar0mD-0007HI-00 for rddp@ietf.org; Wed, 11 Feb 2004 15:16:05 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr003.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1BKD2JU019351; Wed, 11 Feb 2004 20:13:02 GMT Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1BKHF78010894; Wed, 11 Feb 2004 20:17:23 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxv041-1.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004021112152808351 ; Wed, 11 Feb 2004 12:15:28 -0800 Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 12:15:29 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F0DB.CAADD0DE" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 11 Feb 2004 12:15:28 -0800 Message-ID: <6315617889C99D4BA7C14687DEC8DB4E052188D2@fmsmsx402.fm.intel.com> Thread-Topic: [Re:] comment clause 5 Thread-Index: AcPw28Myy4RoI0dcRT6duEpdCwwiag== From: "Shah, Hemal" To: Cc: X-OriginalArrivalTime: 11 Feb 2004 20:15:29.0011 (UTC) FILETIME=[CAF5B430:01C3F0DB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [rddp] [Re:] comment clause 5 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.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F0DB.CAADD0DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barry, Below is my reply to your comments clause 5. Please let me know if you have any questions. Hemal =20 * To: "RDDP" =20 * Subject: [rddp] comment clause 5 of draft-ietf-rddp-ddp-01=20 * From: "Barry Reinhold" =20 * Date: Mon, 17 Nov 2003 13:38:56 -0500=20 * Importance: Normal=20 * List-help: =20 * List-id: IETF Remote Direct Data Placement (rddp) WG =20 * List-post: =20 * List-subscribe: ,=20 * List-unsubscribe: ,=20 * Sender: rddp-admin@ietf.org=20 _____ =20 There are three comments on clause 5, (2 and 3) have technical content. =20 CLAUSE 5 =20 NOTE: Given the effort associated with documenting the capitalization issues and the frequency of capitalization issues these corrections are no longer going to be documented. There may be some rule being applied here that I am unaware of and if so this is a waste of time.=20 =20 It is suggested that the following terms have their capitalization changed: Message, Remote Peer, Local Peer, Untagged Buffer Model, Tagged Buffer Model, Payload, Segment, Stream, Connection, Data Placement, Placement, Delivery, Application. =20 [hvs] Change is not accepted. This is the convention being used in the document. =20 1. Editorial, medium, 5 under item 4 =20 Is: 4. The LLP MUST preserve DDP Segment and Message boundaries at the =20 Data Sink.=20 Suggest: 4. The LLP MUST preserve DDP Segment at the Data Sink. =20 Change: Removed reference to Message boundaries. Note that this is a technical change if there is an actual requirement for the LLP to understand DDP message boundaries. This change request is made as an editorial request, believing that there is no requirement for the LLP to understand message boundaries. [hvs] Change is not accepted. This is an actual requirement. =20 2. Technical, medium, 5 under item 8 and 10 =20 Issue: The concept of an erroneous LLP stream is not defined or referenced in this specification. It occurs in item 8 and 10 of this clause. The semantics associated with marking a stream as an erroneous stream needs further definition. =20 Is:=20 If an LLP does not support teardown of a LLP stream independent=20 of other LLP streams and a DDP error occurs on a specific DDP=20 Stream, then the LLP MUST label the associated LLP stream as an=20 erroneous LLP stream and MUST NOT allow any further data=20 transfer on that LLP stream after DDP requests the associated=20 DDP Stream to be torn down.=20 =20 Suggest: =20 Add a definition for erroneous LLP stream in clause 4.2 =20 "LLP Erroneous Stream - The LLP layer may mark a stream as being erroneous to indicate to the DDP layer that the stream may no longer be used for transmission of DDP segments." =20 [hvs] Change is not accepted. The text clearly says what LLP must do when the stream is marked errorneous.=20 =20 Change item 8 to the following: =20 If an LLP does not support teardown of a LLP stream independent=20 of other LLP streams and DDP request that the LLP stream be shutdown, then LLP shall mark the stream as being an erroneous LLP stream. LLP MUST NOT allow any further data transmission on a LLP stream marked as erroneous. [hvs] Change is not accepted. =20 No change is necessary to item 10 =20 Suggestion 2: =20 Remove both references to erroneous streams. It is unclear to me that DDP needs to understand the concept of an erroneous stream. When DDP requests to tear down the stream due to a DDP error and the LLP must defer from de-allocating the resources associated with the stream the LLP should hide the "erroneous stream" state. In this case item 8 becomes: =20 If an LLP does not support teardown of a LLP stream independent of other LLP streams it must present the LLP stream to DDP as being terminated. The LLP entity MUST NOT allow any further data transfer on the LLP stream. The LLP entity is not obligated to free up resources associated with the LLP stream at the time of the teardown request. =20 Item 10 becomes: =20 10. For a specific LLP connection, when all LLP streams are gracefully torn down the LLP connection MUST be torn down.=20 [hvs] Change is not accepted. Errorneous LLP streams do have a meaning for DDP. =20 3 Editorial, Low, 5 under clause 9 =20 Is: =20 9. For a specific LLP Stream, the LLP MUST provide a mechanism to=20 indicate that the LLP Stream has been gracefully torn down. For=20 a specific LLP Connection, the LLP MUST provide a mechanism to=20 indicate that the LLP Connection has been gracefully torn down.=20 Note that if the LLP does not allow an LLP Stream to be torn=20 down independently of the LLP Connection, the above requirements=20 allow the LLP to notify DDP of both events at the same time.=20 Suggest: 9. For a specific LLP stream, the LLP MUST provide a mechanism to=20 indicate that the LLP stream has been gracefully torn down. Note that if the LLP does not allow an LLP stream to be torn=20 down independently of the LLP connection, the above requirements=20 allow the LLP to notify DDP of both events at the same time. =20 Changes: Removed duplicated sentence and changed capitalization. [hvs] Change is accepted. 3 Editorial/technical, Low 5 under clause 11 =20 Is: The LLP MUST NOT pass a duplicate DDP Segment to the DDP Layer=20 after it has passed all the previous DDP Segments to the DDP=20 Layer and the associated ordering information for the previous=20 DDP Segments and the current DDP Segment.=20 Suggest: The LLP MUST NOT pass a duplicate DDP segment to the DDP layer. =20 Change: Removed qualifications. Do not understand the need for the qualification.=20 [hvs] Change is not accepted. The qualification says that LLP must not pass a duplicate DDP segment if it falls into an ordered and already delivered stream. =20 Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 =20 =20 =20 ------_=_NextPart_001_01C3F0DB.CAADD0DE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Barry,

Below is my reply to your = comments clause 5. Please let me know if you have any = questions.

Hemal=

 

There are three comments on clause 5, (2 and 3) have technical =
content.
 
CLAUSE =
5
 
NOTE: =
Given the effort associated with documenting the =
capitalization
issues =
and the frequency of capitalization issues these corrections =
are
no longer =
going to be documented. There may be some rule being =
applied
here that =
I am unaware of and if so this is a waste of time. =

 
It is =
suggested that the following terms have their =
capitalization
changed:
Message, =
Remote Peer, Local Peer, Untagged Buffer Model, Tagged =
Buffer
Model, =
Payload, Segment, Stream, Connection, Data Placement, =
Placement,
Delivery, =
Application.
 
[hvs] =
Change is not accepted. This is the convention being used in the =
document.
 
1. =
Editorial, medium, 5 under item 4
 
Is:  =
4.  The LLP MUST preserve DDP Segment and Message boundaries at =
the
 
       Data =
Sink. 
Suggest:   4.  The LLP MUST =
preserve DDP Segment at the Data Sink.
 
Change: =
Removed reference to Message boundaries. Note that this is =
a
technical =
change if there is an actual requirement for the LLP =
to
understand DDP message boundaries. This =
change request is made as an
editorial =
request, believing that there is no requirement for the LLP =
to
understand message =
boundaries.
[hvs] =
Change is not accepted. This is an actual =
requirement.
 
2. =
Technical, medium, 5 under item 8 and 10
 
Issue: =
The concept of an erroneous LLP stream is not defined =
or
referenced in this specification. It occurs =
in item 8 and 10 of this
clause. =
The semantics associated with marking a stream as an =
erroneous
stream =
needs further definition.
 
Is: =

If an LLP =
does not support teardown of a LLP stream independent =

       of =
other LLP streams and a DDP error occurs on a specific DDP =

       Stre=
am, then the LLP MUST label the associated LLP stream as an =

       erro=
neous LLP stream and MUST NOT allow any further data =

       tran=
sfer on that LLP stream after DDP requests the associated =

       DDP =
Stream to be torn down. 
 
Suggest:
 
Add a =
definition for erroneous LLP stream in clause =
4.2
 
"LLP =
Erroneous Stream - The LLP layer may mark a stream as =
being
erroneous =
to indicate to the DDP layer that the stream may no longer =
be
used for =
transmission of DDP segments."
 
[hvs] =
Change is not accepted. The text clearly says what LLP must do when the =
stream is marked errorneous. 
 
Change =
item 8 to the following:
 
If an LLP =
does not support teardown of a LLP stream independent =

of other =
LLP streams and DDP request that the LLP stream be =
shutdown,
then LLP =
shall mark the stream as being an erroneous LLP stream. =
LLP
MUST NOT =
allow any further data transmission on a LLP stream marked =
as
erroneous.
[hvs] =
Change is not accepted.
 
No change =
is necessary to item 10
 
Suggestion 2:
 
Remove =
both references to erroneous streams. It is unclear to me =
that
DDP needs =
to understand the concept of an erroneous stream. When =
DDP
requests =
to tear down the stream due to a DDP error and the LLP =
must
defer =
from de-allocating the resources associated with the stream =
the
LLP =
should hide the "erroneous stream" state. In this case item =
8
becomes:
 
If an LLP =
does not support teardown of a LLP stream independent of =
other
LLP =
streams it must present the LLP stream to DDP as being =
terminated.
The LLP =
entity MUST NOT allow any further data transfer on the =
LLP
stream. =
The LLP entity is not obligated to free up resources =
associated
with the =
LLP stream at the time of the teardown =
request.
 
Item 10 =
becomes:
 
   10. For a specific LLP =
connection, when all LLP streams are
gracefully      =
     torn down the LLP connection MUST be torn down. =

[hvs] =
Change is not accepted. Errorneous LLP streams do have a meaning for =
DDP.
 
3 =
Editorial, Low, 5 under clause 9
 
Is:
 
   9.  For a specific LLP =
Stream, the LLP MUST provide a mechanism to =

       indi=
cate that the LLP Stream has been gracefully torn down. For =

       a =
specific LLP Connection, the LLP MUST provide a mechanism to =

       indi=
cate that the LLP Connection has been gracefully torn down. =

       Note=
 that if the LLP does not allow an LLP Stream to be torn =

       down=
 independently of the LLP Connection, the above requirements =

       allo=
w the LLP to notify DDP of both events at the same time. =

Suggest:
   9.  For a specific LLP =
stream, the LLP MUST provide a mechanism to =

       indi=
cate that the LLP stream has been gracefully torn =
down.
       Note =
that if the LLP does not allow an LLP stream to be torn =

       down=
 independently of the LLP connection, the above requirements =

       allo=
w the LLP to notify DDP of both events at the same =
time.
 
Changes: =
Removed duplicated sentence and changed =
capitalization.
[hvs] =
Change is accepted.
3 =
Editorial/technical, Low 5 under clause 11
 
Is:
The LLP =
MUST NOT pass a duplicate DDP Segment to the DDP Layer =

       afte=
r it has passed all the previous DDP Segments to the DDP =

       Laye=
r and the associated ordering information for the previous =

       DDP =
Segments and the current DDP Segment. 
Suggest:
The LLP =
MUST NOT pass a duplicate DDP segment to the DDP =
layer.
 
Change: =
Removed qualifications. Do not understand the need for =
the
qualification. 
[hvs] =
Change is not accepted. The qualification says that LLP must not pass a =
duplicate DDP segment if it falls into an ordered and already delivered =
stream.
 
Barry =
Reinhold
Lamprey =
Networks
bbr@lampreynetworks.com
(603) = 868-8411
 =

 

 

=00 ------_=_NextPart_001_01C3F0DB.CAADD0DE-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Feb 11 15:36: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 PAA20711 for ; Wed, 11 Feb 2004 15:36:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar15k-0002bU-82 for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 15:36:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKaGVa010002 for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 15:36:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar15k-0002bF-2Z for rddp-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:36:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20664 for ; Wed, 11 Feb 2004 15:36:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar15i-0001mk-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 15:36:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar14k-0001dh-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 15:35:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar13k-0001UH-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 15:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar13Z-0002RL-JM; Wed, 11 Feb 2004 15:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar12g-0002Nb-Mu for rddp@optimus.ietf.org; Wed, 11 Feb 2004 15:33:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20457 for ; Wed, 11 Feb 2004 15:33:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar12e-0001LD-00 for rddp@ietf.org; Wed, 11 Feb 2004 15:33:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar11i-0001D1-00 for rddp@ietf.org; Wed, 11 Feb 2004 15:32:07 -0500 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar10d-00010H-00 for rddp@ietf.org; Wed, 11 Feb 2004 15:30:59 -0500 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i1BKS6DL031252; Wed, 11 Feb 2004 20:28:06 GMT Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i1BKWF74021715; Wed, 11 Feb 2004 20:32:15 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.135]) by fmsmsxv041-1.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004021112302110084 ; Wed, 11 Feb 2004 12:30:21 -0800 Received: from fmsmsx402.amr.corp.intel.com ([132.233.42.200]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 12:30:20 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F0DD.DE38D5F2" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [rddp] [Re:] comment clause 5 Date: Wed, 11 Feb 2004 12:30:20 -0800 Message-ID: <6315617889C99D4BA7C14687DEC8DB4E052188D3@fmsmsx402.fm.intel.com> Thread-Topic: [rddp] [Re:] comment clause 5 Thread-Index: AcPw28Myy4RoI0dcRT6duEpdCwwiagAAIvZQ From: "Shah, Hemal" To: "Shah, Hemal" , Cc: X-OriginalArrivalTime: 11 Feb 2004 20:30:20.0867 (UTC) FILETIME=[DE8C2130:01C3F0DD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) 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.2 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F0DD.DE38D5F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barry, =20 I have a correction to one of my comments. See below. =20 Hemal 3 Editorial, Low, 5 under clause 9 =20 Is: =20 9. For a specific LLP Stream, the LLP MUST provide a mechanism to=20 indicate that the LLP Stream has been gracefully torn down. For=20 a specific LLP Connection, the LLP MUST provide a mechanism to=20 indicate that the LLP Connection has been gracefully torn down.=20 Note that if the LLP does not allow an LLP Stream to be torn=20 down independently of the LLP Connection, the above requirements=20 allow the LLP to notify DDP of both events at the same time.=20 Suggest: 9. For a specific LLP stream, the LLP MUST provide a mechanism to=20 indicate that the LLP stream has been gracefully torn down. Note that if the LLP does not allow an LLP stream to be torn=20 down independently of the LLP connection, the above requirements=20 allow the LLP to notify DDP of both events at the same time. =20 Changes: Removed duplicated sentence and changed capitalization. [hvs] Change is accepted. [Shah, Hemal] Looking at it carefully, I think they are not duplicated sentences as the first one covers LLP Stream and the second one covers LLP connection. So, I will not make this change.=20 ------_=_NextPart_001_01C3F0DD.DE38D5F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Barry,

 

I have a correction to one of my = comments. See below.

 

Hemal

3 Editorial, Low, 5 under clause =
9
 
Is:
 
   9.  For a specific LLP =
Stream, the LLP MUST provide a mechanism to 
       indi=
cate that the LLP Stream has been gracefully torn down. For =

       a =
specific LLP Connection, the LLP MUST provide a mechanism to =

       indi=
cate that the LLP Connection has been gracefully torn down. =

       Note=
 that if the LLP does not allow an LLP Stream to be torn =

       down=
 independently of the LLP Connection, the above requirements =

       allo=
w the LLP to notify DDP of both events at the same time. =

Suggest:
   9.  For a specific LLP =
stream, the LLP MUST provide a mechanism to 
       indi=
cate that the LLP stream has been gracefully torn =
down.
       Note =
that if the LLP does not allow an LLP stream to be torn =

       down=
 independently of the LLP connection, the above requirements =

       allo=
w the LLP to notify DDP of both events at the same =
time.
 
Changes: Removed duplicated sentence and =
changed capitalization.
[hvs] Change is =
accepted.
[Shah, Hemal] Looking at it =
carefully, I think they are not duplicated sentences as the first one =
covers LLP Stream and the second one covers LLP connection. So, I will =
not make this change.
=00 ------_=_NextPart_001_01C3F0DD.DE38D5F2-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Feb 11 16:40:20 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 QAA28725 for ; Wed, 11 Feb 2004 16:40:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar25H-0001VC-PD for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 16:39:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLdpPw005770 for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 16:39:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar25H-0001Uz-KO for rddp-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:39:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28704 for ; Wed, 11 Feb 2004 16:39:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar25F-0003wc-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 16:39:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar24S-0003pA-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 16:39:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar23Z-0003go-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 16:38:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar23Y-0006gF-WE for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 16:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar23V-0001BA-J3; Wed, 11 Feb 2004 16:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar23Q-00019n-GF for rddp@optimus.ietf.org; Wed, 11 Feb 2004 16:37:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28500 for ; Wed, 11 Feb 2004 16:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar23O-0003f1-00 for rddp@ietf.org; Wed, 11 Feb 2004 16:37:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar22e-0003WQ-00 for rddp@ietf.org; Wed, 11 Feb 2004 16:37:08 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar21u-0003IC-00 for rddp@ietf.org; Wed, 11 Feb 2004 16:36:22 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 5882B24614C; Wed, 11 Feb 2004 16:16:25 -0500 (EST) In-Reply-To: <6315617889C99D4BA7C14687DEC8DB4E052188D2@fmsmsx402.fm.intel.com> References: <6315617889C99D4BA7C14687DEC8DB4E052188D2@fmsmsx402.fm.intel.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <618B9F44-5CD7-11D8-90DA-003065D48EE0@asomi.com> Content-Transfer-Encoding: quoted-printable Cc: Barry Reinhold From: Caitlin Bestler Subject: Re: [rddp] [Re:] comment clause 5 Date: Wed, 11 Feb 2004 15:15:13 -0600 To: Hemal Shah , RDDP X-Mailer: Apple Mail (2.612) 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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Feb 11, 2004, at 2:15 PM, Shah, Hemal wrote: > > Is: > If an LLP does not support teardown of a LLP stream independent > =A0=A0=A0=A0=A0=A0=A0of other LLP streams and a DDP error occurs on a = specific DDP > =A0=A0=A0=A0=A0=A0=A0Stream, then the LLP MUST label the associated = LLP stream as an > =A0=A0=A0=A0=A0=A0=A0erroneous LLP stream and MUST NOT allow any = further data > =A0=A0=A0=A0=A0=A0=A0transfer on that LLP stream after DDP requests = the associated > =A0=A0=A0=A0=A0=A0=A0DDP Stream to be torn down. > =A0 > Suggest: > =A0 > Add a definition for erroneous LLP stream in clause 4.2 > =A0 > "LLP Erroneous Stream - The LLP layer may mark a stream as being > erroneous to indicate to the DDP layer that the stream may no longer = be > used for transmission of DDP segments." > =A0 > [hvs] Change is not accepted. The text clearly says what LLP must do > when the stream is marked errorneous. I definitely concur with not making the change. It is a very reasonable for an SCTP implementation to be layered, and for the SCTP layer to have no concept as to which SCTP streams are in what state. The SCTP adaptation layer knows that, but would only check that state on inbound packets, trusting the DDP layer not to send DDP Segments on a dead stream. This is more of an issue with the SCTP adaptation because the stream going dead does not necessarily close the SCTP association, or block the SCTP Stream from being re-used for a different DDP Stream (anymore than closing a TCP connection permanently forbids the same source/destination from ever being re-used). _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Wed Feb 11 20:22:19 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 UAA16998 for ; Wed, 11 Feb 2004 20:22:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5Y6-0003sh-70 for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 20:21:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1C1Loi0014913 for rddp-archive@odin.ietf.org; Wed, 11 Feb 2004 20:21:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5Y6-0003sS-39 for rddp-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 20:21:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16984 for ; Wed, 11 Feb 2004 20:21:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Y3-0003Hr-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 20:21:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5XB-0003Ce-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 20:20:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5WM-00036r-00 for rddp-web-archive@ietf.org; Wed, 11 Feb 2004 20:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5WN-0003fm-3b; Wed, 11 Feb 2004 20:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar5W9-0003et-Mf for rddp@optimus.ietf.org; Wed, 11 Feb 2004 20:19:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16944 for ; Wed, 11 Feb 2004 20:19:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5W7-00035K-00 for rddp@ietf.org; Wed, 11 Feb 2004 20:19:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar5VE-000305-00 for rddp@ietf.org; Wed, 11 Feb 2004 20:18:53 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1Ar5Uw-0002ty-00 for rddp@ietf.org; Wed, 11 Feb 2004 20:18:34 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 Feb 2004 17:17:42 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 11 Feb 2004 17:18:01 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Feb 2004 17:17:59 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Feb 2004 17:18:01 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 11 Feb 2004 17:18:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Wed, 11 Feb 2004 17:17:55 -0800 Message-ID: Thread-Topic: feedback on the security draft? Thread-Index: AcPxBgrqYb4ySI6qRT+GyWWeUpNprQ== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 12 Feb 2004 01:18:01.0397 (UTC) FILETIME=[0E9FFE50:01C3F106] Subject: [rddp] feedback on the security draft? 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.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F106.0E68CB39" ------_=_NextPart_001_01C3F106.0E68CB39 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I put out the security draft two weeks before the deadline. I did this in case anyone has comments that can be resolved before the deadline (Feb 16th) so I'd have enough time to get in the update. =20 So far I haven't seen any comments, but if you're expecting to submit them, doing so by this Friday, Feb 13th would allow them to be resolved expeditously. =20 =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C3F106.0E68CB39 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I put out the security draft two weeks before the = deadline. I did this in case anyone has comments that can be resolved before the = deadline (Feb 16th) so I’d have enough time to get in the = update.

 

So far I haven’t seen any comments, but if = you’re expecting to submit them, doing so by this Friday, Feb 13th = would allow them to be resolved expeditously.

 

 

 

Jim

 

 

 

------_=_NextPart_001_01C3F106.0E68CB39-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Feb 12 19:19:01 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 TAA27891 for ; Thu, 12 Feb 2004 19:19:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArR2P-0005Xe-OO for rddp-archive@odin.ietf.org; Thu, 12 Feb 2004 19:18:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D0IXnZ021298 for rddp-archive@odin.ietf.org; Thu, 12 Feb 2004 19:18:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArR2P-0005XR-IQ for rddp-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 19:18:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27876 for ; Thu, 12 Feb 2004 19:18:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArR2M-0001eH-00 for rddp-web-archive@ietf.org; Thu, 12 Feb 2004 19:18:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArR1Y-0001Zw-00 for rddp-web-archive@ietf.org; Thu, 12 Feb 2004 19:17:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArR0s-0001UH-00 for rddp-web-archive@ietf.org; Thu, 12 Feb 2004 19:16:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArR0v-0005Re-2P; Thu, 12 Feb 2004 19:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArR0b-0005Q6-AO for rddp@optimus.ietf.org; Thu, 12 Feb 2004 19:16:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27779 for ; Thu, 12 Feb 2004 19:16:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArR0X-0001S2-00 for rddp@ietf.org; Thu, 12 Feb 2004 19:16:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQzg-0001IL-00 for rddp@ietf.org; Thu, 12 Feb 2004 19:15:45 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1ArQyl-000106-00 for rddp@ietf.org; Thu, 12 Feb 2004 19:14:47 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 16:14:18 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 12 Feb 2004 16:14:18 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Feb 2004 16:14:22 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 16:14:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 12 Feb 2004 16:14:21 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 12 Feb 2004 16:14:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [rddp] feedback on the security draft? Date: Thu, 12 Feb 2004 16:14:14 -0800 Message-ID: Thread-Topic: [rddp] feedback on the security draft? Thread-Index: AcPxBgrqYb4ySI6qRT+GyWWeUpNprQAv/8Ow From: "Jim Pinkerton" To: X-OriginalArrivalTime: 13 Feb 2004 00:14:17.0869 (UTC) FILETIME=[5209ABD0:01C3F1C6] 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.2 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F1C6.5CAB867C" ------_=_NextPart_001_01C3F1C6.5CAB867C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The pdf version with the change-bars has still not been posted by the IETF Secretariat. =20 For those that would like the pdf version (it has change bars for what changed from the -00 version), please send me email. =20 =20 Jim =20 =20 =20 =20 ________________________________ From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim Pinkerton Sent: Wednesday, February 11, 2004 5:18 PM To: rddp@ietf.org Subject: [rddp] feedback on the security draft? =20 =20 I put out the security draft two weeks before the deadline. I did this in case anyone has comments that can be resolved before the deadline (Feb 16th) so I'd have enough time to get in the update. =20 So far I haven't seen any comments, but if you're expecting to submit them, doing so by this Friday, Feb 13th would allow them to be resolved expeditously. =20 =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C3F1C6.5CAB867C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The pdf version with the = change-bars has still not been posted by the IETF Secretariat.

 

For those that would like the pdf = version (it has change bars for what changed from the -00 version), please send = me email.

 

 

Jim

 

 

 

 

From: rddp-admin@ietf.org [mailto:rddp-admin@ietf.org] On Behalf Of Jim Pinkerton
Sent: Wednesday, February = 11, 2004 5:18 PM
To: rddp@ietf.org
Subject: [rddp] feedback = on the security draft?

 

 

I put out the security draft two weeks before the = deadline. I did this in case anyone has comments that can be resolved before the = deadline (Feb 16th) so I’d have enough time to get in the = update.

 

So far I haven’t seen any comments, but if you’re expecting to submit them, doing so by this Friday, Feb = 13th would allow them to be resolved expeditously.

 

 

 

Jim

 

 

 

------_=_NextPart_001_01C3F1C6.5CAB867C-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Thu Feb 19 15:39:56 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 PAA06620 for ; Thu, 19 Feb 2004 15:39:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtuxD-0008Fe-VJ for rddp-archive@odin.ietf.org; Thu, 19 Feb 2004 15:39:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JKdRj4031708 for rddp-archive@odin.ietf.org; Thu, 19 Feb 2004 15:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtuxD-0008FK-49 for rddp-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 15:39:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06107 for ; Thu, 19 Feb 2004 15:39:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtuxB-0006N3-00 for rddp-web-archive@ietf.org; Thu, 19 Feb 2004 15:39:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtuwG-0006KL-00 for rddp-web-archive@ietf.org; Thu, 19 Feb 2004 15:38:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atuvp-0006Ha-00 for rddp-web-archive@ietf.org; Thu, 19 Feb 2004 15:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atuvp-00082i-Pw; Thu, 19 Feb 2004 15:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtuvE-0007qc-3D for rddp@optimus.ietf.org; Thu, 19 Feb 2004 15:37:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04444 for ; Thu, 19 Feb 2004 15:37:21 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtuvC-0006GP-00 for rddp@ietf.org; Thu, 19 Feb 2004 15:37:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtuuF-0006Dh-00 for rddp@ietf.org; Thu, 19 Feb 2004 15:36:24 -0500 Received: from srexchimc2.lss.emc.com ([168.159.100.11] helo=srexchimc2.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AtutY-00069L-00 for rddp@ietf.org; Thu, 19 Feb 2004 15:35:40 -0500 Received: from maho3msx2.corp.emc.com ([128.221.11.32]) by srexchimc2.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZQJ3A1N; Thu, 19 Feb 2004 15:35:05 -0500 Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <1YVFF04T>; Thu, 19 Feb 2004 15:35:05 -0500 Message-ID: X-Sybari-Trust: 63ed38cb 1d8c424f cc4dbb5e 0000013d To: rddp@ietf.org Date: Thu, 19 Feb 2004 15:35:04 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] Meeting in Seoul 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.6 required=5.0 tests=AWL,NO_REAL_NAME, X_PRIORITY_HIGH autolearn=no version=2.60 The RDDP WG will meet in Seoul: WEDNESDAY, March 3, 2004 1530-1730 Afternoon Sessions II Sapphire 4 INT hipbof Host Identity Protocol BOF Sapphire 2/3 OPS capwap Control and Provisioning of Wireless Access Points BOF Emerald OPS ipfix IP Flow Information Export WG Crystal 1/2 RTG rtgarea Routing Area Meeting * Gardenia A-2 SEC syslog Security Issues in Network Event Logging WG Crystal 3 TSV avt Audio/Video Transport WG * Sapphire 1 TSV rddp Remote Direct Data Placement WG It's time to put the agenda together. Draft authors, please send me indications of whether time is needed on technical issues (vs. just a status update), and who will be presenting/ running the discussion. I would like these by end of the day tomorrow (Friday). I understand that some people will be unable to travel to Seoul - if you can't find anyone to present for your draft, send me a slide deck and I'll present & run the discussion for you. I need these decks in advance - that means next week, so that if there's something I don't understand there's time for me to check with you before the meeting. Thanks, --David (rddp WG chair) ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@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 Thu Feb 19 15:55:54 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 PAA21334 for ; Thu, 19 Feb 2004 15:55:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvCg-0000bo-BA for rddp-archive@odin.ietf.org; Thu, 19 Feb 2004 15:55:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JKtQ6W002333 for rddp-archive@odin.ietf.org; Thu, 19 Feb 2004 15:55:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvCf-0000bY-Nt for rddp-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 15:55:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20850 for ; Thu, 19 Feb 2004 15:55:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtvCe-00077W-00 for rddp-web-archive@ietf.org; Thu, 19 Feb 2004 15:55:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtvBn-00074x-00 for rddp-web-archive@ietf.org; Thu, 19 Feb 2004 15:54:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtvBJ-00071Y-00 for rddp-web-archive@ietf.org; Thu, 19 Feb 2004 15:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvBK-0000Nc-16; Thu, 19 Feb 2004 15:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtvAk-0000LU-Cs for rddp@optimus.ietf.org; Thu, 19 Feb 2004 15:53:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19326 for ; Thu, 19 Feb 2004 15:53:24 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtvAi-000703-00 for rddp@ietf.org; Thu, 19 Feb 2004 15:53:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atv9m-0006y0-00 for rddp@ietf.org; Thu, 19 Feb 2004 15:52:27 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1Atv9P-0006vO-00 for rddp@ietf.org; Thu, 19 Feb 2004 15:52:03 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by mercury.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 1ZQHR5ZM; Thu, 19 Feb 2004 15:51:32 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <1YVB3Q57>; Thu, 19 Feb 2004 15:51:32 -0500 Message-ID: X-Sybari-Trust: 972a0af0 1d8c424f 74f1dc3b 0000013d To: rddp@ietf.org Date: Thu, 19 Feb 2004 15:51:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] PS & Arch drafts: status and security issues 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 I have news to report ... The IESG has been reviewing the RDDP Problem Statement and Architecture drafts. The current draft status can be found in the IETF Draft Tracker at https://datatracker.ietf.org/public/pidtracker.cgi Enter rddp in the WG Acronym: field and hit the SEARCH button. New versions of both drafts are going to be needed, mostly to deal with editorial issues, but some security issues have arisen in the Architecture draft that I'm forwarding so that they can be discussed in the context of the security draft on the list and in Seoul: I see several threat issues. The first is the tension between direct copy and packet authentication. In many cases, it is not possible to authenticate a packet until the entire thing has been read. But here, the data is being copied to a receiving buffer directly from the wire, before authentication takes place. This is especially a challenge to a multi-threaded interface --- ATM where the cells for some packet are not consecutive, perhaps -- where you might get interleaving. The risk here is that if one does placement of fragments and then runs the (cryptographic) integrity check and the check fails, the application has a corrupted buffer. In particular, applications that are coded to a sockets paradigm can get corrupted memory that was never part of any successful receive with RDDP - that can't happen with plain sockets. More generally, authorization for access to storage has to be dependent on the connection as well as the steering tag. Otherwise, you introduce new vulnerabilities. This is especially problematic given that receive buffers may (according to the document) be used for data from a different socket. Probably just needs some clarifying text, as I believe this was always intended. Aside: I think that many of these issues, as well as the multiple receiver problem (and I do not accept the argument that requiring many different clients to use the same address is in any way comparable to any existing problem in that space), would go away if the steering tag sent over the wire to the receiver were not just opaque, but by intent a random 64- or 128-bit tag to a local buffer descriptor. That permits easy local revocation of capabilities, as well as a defense against remote contamination attempts if the value were communicated previously over an encrypted channel. Also, if the STag values generated by an implementation are hard to predict, traffic injection by an adversary becomes more difficult. The use of TLS (as discussed briefly in the security considerations) or any other protocol that provides authentication will not fit well into the proposed architecture. The integrity check cannot be performed until the entire packet (or record in the case of TLS) is available in memory. So, the data must be copied from the I/O interface to memory, which may involve some reassembly, before the integrity check can be performed. This issue should be discussed in the security considerations. This is the same issue as the first one, and suitable discussion should suffice. The bigger mismatch between TLS and RDDP is that TLS wants to run in-order whereas RDDP wants to enable out-of-order placement. The combination could require a significant amount of data to be placed before TLS can be run over it to determine that it's all junk. NOTE: While it's ok to start working on revisions to the architecture and problem statement drafts, this set of IESG comments is NOT COMPLETE. When I have a complete set of comments available, I'll communicate the comments and guidance on what to do about them to the draft authors. Anything with technical impact will be cc:'d to the list. 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 Fri Feb 20 15:04:39 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 PAA10026 for ; Fri, 20 Feb 2004 15:04:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGse-0007FW-Gj for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 15:04:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KK4CqB027860 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 15:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGse-0007FD-C2 for rddp-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 15:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09938 for ; Fri, 20 Feb 2004 15:04:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuGsb-0004uw-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 15:04:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuGrh-0004rw-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 15:03:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuGrT-0004og-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 15:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGrV-0005yT-9B; Fri, 20 Feb 2004 15:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuGqj-00052D-8p for rddp@optimus.ietf.org; Fri, 20 Feb 2004 15:02:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09813 for ; Fri, 20 Feb 2004 15:02:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuGqg-0004nV-00 for rddp@ietf.org; Fri, 20 Feb 2004 15:02:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuGpn-0004kJ-00 for rddp@ietf.org; Fri, 20 Feb 2004 15:01:16 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AuGow-0004cl-00 for rddp@ietf.org; Fri, 20 Feb 2004 15:00:22 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 9F4362469FC; Fri, 20 Feb 2004 15:00:55 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <525AA264-63DF-11D8-8790-003065D48EE0@asomi.com> Content-Transfer-Encoding: 7bit Cc: David Black From: Caitlin Bestler Subject: Re: [rddp] PS & Arch drafts: status and security issues Date: Fri, 20 Feb 2004 13:59:41 -0600 To: RDDP X-Mailer: Apple Mail (2.612) 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 Feb 19, 2004, at 2:51 PM, Black_David@emc.com wrote: > I have news to report ... > > The IESG has been reviewing the RDDP Problem Statement and Architecture > drafts. The current draft status can be found in the IETF Draft > Tracker at > https://datatracker.ietf.org/public/pidtracker.cgi > Enter rddp in the WG Acronym: field and hit the SEARCH button. > > New versions of both drafts are going to be needed, mostly to deal with > editorial issues, but some security issues have arisen in the > Architecture > draft that I'm forwarding so that they can be discussed in the context > of the security draft on the list and in Seoul: > > I see several threat issues. The first is the tension between > direct copy and packet authentication. In many cases, it is not > possible to authenticate a packet until the entire thing has been > read. But here, the data is being copied to a receiving buffer > directly from the wire, before authentication takes place. This > is especially a challenge to a multi-threaded interface --- ATM > where the cells for some packet are not consecutive, perhaps -- > where you might get interleaving. This assumes that placement of non-authenticated data into a target buffer represents a threat, but that is not the case. The contents of the buffer are logically void until completion of the trailing untagged message, by which time all of the packets have been authenticated at the transport layer. Authentication *above* the transport layer is unchanged. It is done *after* the ULP accepts delivery of the message. Now admittedly an application that ignores the rules and examines the data while its contents are still undefined is leaving itself open for an attack -- but that is true in general. The best encryption in the world is worthless if you publish your private key on your web site, or just leave it lying around in an unprotected file. > > The risk here is that if one does placement of fragments and then runs > the (cryptographic) integrity check and the check fails, the > application > has a corrupted buffer. In particular, applications that are coded to > a > sockets paradigm can get corrupted memory that was never part of any > successful receive with RDDP - that can't happen with plain sockets. > > More generally, authorization for access to storage has to be > dependent on the connection as well as the steering tag. Otherwise, > you introduce new vulnerabilities. This is especially problematic > given that receive buffers may (according to the document) be used > for data from a different socket. The spec makes it clear that the ULP is in control of enabling steering tags for specific connections. Short of drafting a "local interface requirements" document I don't see what else can be done. In general 90% of the "security issues" related to RDMA can be summarized as "the consumer may use the local interface in a manner which exposes more memory access rights than is strictly required by the ULP." But I believe that all of the local interfaces that have been discussed or proposed do a fine job of closely matching the security needs of most applications. (I still have problems with draft-hilland's lack of support for multi-connection sessions, but the overwhelming majority of applications use on a single active connection per session). > > Aside: I think that many of these issues, as well as the multiple > receiver problem (and I do not accept the argument that requiring > many different clients to use the same address is in any way > comparable to any existing problem in that space), would go away > if the steering tag sent over the wire to the receiver were not > just opaque, but by intent a random 64- or 128-bit tag to a local > buffer descriptor. That permits easy local revocation of > capabilities, as well as a defense against remote contamination > attempts if the value were communicated previously over an > encrypted channel. > > Also, if the STag values generated by an implementation are hard to > predict, traffic injection by an adversary becomes more difficult. If the STag has cryptographic value it will be too large for efficiency. A statement could be added that STags SHOULD be chosen so as to minimize the risk of bit-errors changing one valid STag into another valid STag. But there is no way to make that a "MUST" -- how would you know how an STag you have been given compares with other STags given to other clients? _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Feb 20 18:41: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 SAA22971 for ; Fri, 20 Feb 2004 18:41:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKGo-0006s2-Mk for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 18:41:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KNfM7c026404 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 18:41:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKGo-0006rn-I3 for rddp-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 18:41:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22966 for ; Fri, 20 Feb 2004 18:41:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKGl-0006YG-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 18:41:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKFn-0006Uu-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 18:40:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuKFY-0006Ri-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 18:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKFY-0006iW-PZ; Fri, 20 Feb 2004 18:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuKEp-0006ao-G2 for rddp@optimus.ietf.org; Fri, 20 Feb 2004 18:39:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22910 for ; Fri, 20 Feb 2004 18:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuKEm-0006QR-00 for rddp@ietf.org; Fri, 20 Feb 2004 18:39:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuKDs-0006NY-00 for rddp@ietf.org; Fri, 20 Feb 2004 18:38:20 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1AuKDO-0006K8-00 for rddp@ietf.org; Fri, 20 Feb 2004 18:37:50 -0500 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel13.hp.com (Postfix) with ESMTP id A580A1C03873 for ; Fri, 20 Feb 2004 15:37:50 -0800 (PST) Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id i1KNbmTl003026 for ; Fri, 20 Feb 2004 15:37:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.10/8.12.9) with SMTP id i1KNbmgv023685 for rddp@ietf.org; Fri, 20 Feb 2004 15:37:48 -0800 (PST) From: Jeffrey Mogul Message-Id: <200402202337.i1KNbmgv023685@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: RDDP Subject: Re: [rddp] PS & Arch drafts: status and security issues In-reply-to: Your message of "Fri, 20 Feb 2004 13:59:41 CST." <525AA264-63DF-11D8-8790-003065D48EE0@asomi.com> X-Organization: Hewlett-Packard Labs, Large Scale Systems group Date: Fri, 20 Feb 2004 15:37:48 -0800 X-Mts: smtp 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 In response to this comment, > I see several threat issues. The first is the tension between > direct copy and packet authentication. In many cases, it is not > possible to authenticate a packet until the entire thing has been > read. But here, the data is being copied to a receiving buffer > directly from the wire, before authentication takes place. This > is especially a challenge to a multi-threaded interface --- ATM > where the cells for some packet are not consecutive, perhaps -- > where you might get interleaving. Caitlin Bestler writes: This assumes that placement of non-authenticated data into a target buffer represents a threat, but that is not the case. The contents of the buffer are logically void until completion of the trailing untagged message, by which time all of the packets have been authenticated at the transport layer. Authentication *above* the transport layer is unchanged. It is done *after* the ULP accepts delivery of the message. Now admittedly an application that ignores the rules and examines the data while its contents are still undefined is leaving itself open for an attack -- but that is true in general. The best encryption in the world is worthless if you publish your private key on your web site, or just leave it lying around in an unprotected file. I'm not sure I would be quite so dismissive. Here is a *hypothetical* attack that is (1) not dependent on an application programmer violating the "logically void" restriction, and (2) possibly made easier by the failure of packet authentication: Step 1: attacker inserts packet fragments into a TCP connection between host H_benign and host H_victim, where the connection is using packet authentication. authentication in this case will fail, but perhaps not before some fragments have been placed. Step 2: attacker somehow causes (e.g., via a buffer-overflow attack that smashes a stack frame) the application to execute code out of the "corrupted" buffer. Of course, there are a lot of assumptions behind this hypothetical attack, and it's not clear if it's significantly worse than any other stack-smashing attack. But it suggests that there might be counter-measures that the receiver could take ... for example, if authentication fails then the buffer should be overwritten with a "safe" pattern (say, all-zeros or something else that is unlikely to represent executable code) rather than simply being treated as "undefined." I'm reasonably sure that someone will explain how this attack is either not possible or very unlikely to create a new security hole. But it only took me about 30 seconds to think it up, and I don't think of myself as very devious -- I'm often surprised by the creativity of malicious hackers, and I think we need to be thinking about this problem from their point of view, not from the point of view of what the spec expects the application to do. In general 90% of the "security issues" related to RDMA can be summarized as "the consumer may use the local interface in a manner which exposes more memory access rights than is strictly required by the ULP." Right, but what if the "consumer" in this case is an application that has already been partially broken into by an intruder, who can then use RDMA to open a wider hole? -Jeff _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Feb 20 19:54:51 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 TAA25325 for ; Fri, 20 Feb 2004 19:54:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLPS-0003lt-LW for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 19:54:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L0sMbR014491 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 19:54:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLPS-0003le-Gv for rddp-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 19:54:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25322 for ; Fri, 20 Feb 2004 19:54:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuLPQ-0003eD-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 19:54:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuLOV-0003av-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 19:53:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuLO8-0003Xf-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 19:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLO9-0003gi-Kh; Fri, 20 Feb 2004 19:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuLNT-0003ey-I5 for rddp@optimus.ietf.org; Fri, 20 Feb 2004 19:52:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25296 for ; Fri, 20 Feb 2004 19:52:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuLNR-0003Wu-00 for rddp@ietf.org; Fri, 20 Feb 2004 19:52:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuLMU-0003Tx-00 for rddp@ietf.org; Fri, 20 Feb 2004 19:51:19 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AuLM9-0003Qz-00 for rddp@ietf.org; Fri, 20 Feb 2004 19:50:57 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id 96654246C26; Fri, 20 Feb 2004 19:51:22 -0500 (EST) In-Reply-To: <200402202337.i1KNbmgv023685@wera.hpl.hp.com> References: <200402202337.i1KNbmgv023685@wera.hpl.hp.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: RDDP From: Caitlin Bestler Subject: Re: [rddp] PS & Arch drafts: status and security issues Date: Fri, 20 Feb 2004 18:50:09 -0600 To: Jeffrey Mogul X-Mailer: Apple Mail (2.612) 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 Feb 20, 2004, at 5:37 PM, Jeffrey Mogul wrote: > In response to this comment, > >> I see several threat issues. The first is the tension between >> direct copy and packet authentication. In many cases, it is not >> possible to authenticate a packet until the entire thing has been >> read. But here, the data is being copied to a receiving buffer >> directly from the wire, before authentication takes place. This >> is especially a challenge to a multi-threaded interface --- ATM >> where the cells for some packet are not consecutive, perhaps -- >> where you might get interleaving. > > Caitlin Bestler writes: > > This assumes that placement of non-authenticated data into a target > buffer represents a threat, but that is not the case. > > The contents of the buffer are logically void until completion of > the trailing untagged message, by which time all of the packets > have been authenticated at the transport layer. > > Authentication *above* the transport layer is unchanged. It is done > *after* the ULP accepts delivery of the message. > > Now admittedly an application that ignores the rules and examines > the data while its contents are still undefined is leaving itself > open for an attack -- but that is true in general. The best > encryption in the world is worthless if you publish your private > key on your web site, or just leave it lying around in an > unprotected file. > > I'm not sure I would be quite so dismissive. > > Here is a *hypothetical* attack that is (1) not dependent on > an application programmer violating the "logically void" > restriction, and (2) possibly made easier by the failure of > packet authentication: > > Step 1: attacker inserts packet fragments into a TCP > connection between host H_benign and host H_victim, > where the connection is using packet authentication. > > authentication in this case will fail, but > perhaps not before some fragments have been > placed. > > Step 2: attacker somehow causes (e.g., via a buffer-overflow > attack that smashes a stack frame) the application > to execute code out of the "corrupted" buffer. > Buffer overflow? That's a symptom of anonymous buffers defined only as streams -- which does not apply to RDMA. Each placement is to a ULP authorized buffer, period. It was authorized by enabling an STag or by posting a receive operation. Each receive operation specifies a maximum size. If the message is larger it does not "overflow" anywhere, it is discarded as an invalid packet and the connection/stream is torn down. Your peer can obviously use authorized buffers in a way that you did not anticipate -- but that is also true even before using RDMA. However an executable image is received it should be ULP authenticated *before* execution. Authentication of executables and confining the scope of damage of partially trusted executables are OS issues. They have nothing to do with transport. RDMA actually improves security here by eliminating the need for system buffering. When system buffers are involved there is a greater risk of "uninitialized" data migrating from one use to another. Unlike a conventional TCP application, with out-of-order placement RDMA can ensure that all placements are to unprivileged *user* memory -- greatly increasing system integrity. > Of course, there are a lot of assumptions behind this hypothetical > attack, and it's not clear if it's significantly worse than any > other stack-smashing attack. But it suggests that there might > be counter-measures that the receiver could take ... for example, > if authentication fails then the buffer should be overwritten > with a "safe" pattern (say, all-zeros or something else that is > unlikely to represent executable code) rather than simply being > treated as "undefined." After delivery, the application can invalidate remote access and then validate the received message. But because this is a *user* buffer there is no harm in leaving the contents there as long as the user process does not ascribe meaning to the buffer. > > I'm reasonably sure that someone will explain how this attack > is either not possible or very unlikely to create a new security > hole. But it only took me about 30 seconds to think it up, and > I don't think of myself as very devious -- I'm often surprised > by the creativity of malicious hackers, and I think we need to > be thinking about this problem from their point of view, not > from the point of view of what the spec expects the application > to do. > > In general 90% of the "security issues" related to RDMA can be > summarized as "the consumer may use the local interface in a manner > which exposes more memory access rights than is strictly required > by the ULP." > > Right, but what if the "consumer" in this case is an application > that has already been partially broken into by an intruder, who > can then use RDMA to open a wider hole? Each and every memory byte accessible by RDMA was accessible by the application anyway. The ULP is merely delegating access rights that it already had to the RNIC. The only "security vulnerability" created is the potential that the ULP will not properly understand what it delegated. That is why the security document details procedures such as invalidating STags before examining buffers when the remote peer is untrusted. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Feb 20 21:12:47 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 VAA28066 for ; Fri, 20 Feb 2004 21:12:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMcu-00018Q-DD for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 21:12:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L2CKuC004359 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 21:12:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMcu-00018E-9E for rddp-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 21:12:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28063 for ; Fri, 20 Feb 2004 21:12:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMcr-00018o-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 21:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMbt-00016e-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 21:11:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuMbe-00014X-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 21:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMbe-00010k-K9; Fri, 20 Feb 2004 21:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMay-0000zW-Cu for rddp@optimus.ietf.org; Fri, 20 Feb 2004 21:10:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28023 for ; Fri, 20 Feb 2004 21:10:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMav-00013b-00 for rddp@ietf.org; Fri, 20 Feb 2004 21:10:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMZx-0000zz-00 for rddp@ietf.org; Fri, 20 Feb 2004 21:09:18 -0500 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1AuMZ6-0000wk-00 for rddp@ietf.org; Fri, 20 Feb 2004 21:08:24 -0500 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel11.hp.com (Postfix) with ESMTP id 1309F1C01181 for ; Fri, 20 Feb 2004 18:08:24 -0800 (PST) Received: from wera.hpl.hp.com (wera.hpl.hp.com [15.9.120.80]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id i1L28MTl012686 for ; Fri, 20 Feb 2004 18:08:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by wera.hpl.hp.com (8.12.10/8.12.9) with SMTP id i1L28McN024303 for rddp@ietf.org; Fri, 20 Feb 2004 18:08:22 -0800 (PST) From: Jeffrey Mogul Message-Id: <200402210208.i1L28McN024303@wera.hpl.hp.com> X-Authentication-Warning: wera.hpl.hp.com: localhost [127.0.0.1] didn't use HELO protocol To: RDDP Subject: Re: [rddp] PS & Arch drafts: status and security issues In-reply-to: Your message of "Fri, 20 Feb 2004 18:50:09 CST." X-Organization: Hewlett-Packard Labs, Large Scale Systems group Date: Fri, 20 Feb 2004 18:08:22 -0800 X-Mts: smtp 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 I wrote: > Here is a *hypothetical* attack that is (1) not dependent on > an application programmer violating the "logically void" > restriction, and (2) possibly made easier by the failure of > packet authentication: > > Step 1: attacker inserts packet fragments into a TCP > connection between host H_benign and host H_victim, > where the connection is using packet authentication. > > authentication in this case will fail, but > perhaps not before some fragments have been > placed. > > Step 2: attacker somehow causes (e.g., via a buffer-overflow > attack that smashes a stack frame) the application > to execute code out of the "corrupted" buffer. > Caitlin Bestler writes: Buffer overflow? That's a symptom of anonymous buffers defined only as streams -- which does not apply to RDMA. You're thinking inside the box. I didn't say "cause an overflow of an RDMA buffer"; applications have many buffers, only some of which are involved in RDMA. Typical buffer overflow attacks often target intermediate buffers within the application. So whether or not RDMA prevents overflow of network-related buffers has nothing to do with whether an application is vulnerable to other kinds of buffer-overflow attacks. However an executable image is received it should be ULP authenticated *before* execution. Authentication of executables and confining the scope of damage of partially trusted executables are OS issues. They have nothing to do with transport. Nor did I say they did. But in the typical stack-smashing attack on an application, one could hardly argue that the application has done everything it "should" have done; the fact remains that they succeed all too often. > In general 90% of the "security issues" related to RDMA can be > summarized as "the consumer may use the local interface in a manner > which exposes more memory access rights than is strictly required > by the ULP." > > Right, but what if the "consumer" in this case is an application > that has already been partially broken into by an intruder, who > can then use RDMA to open a wider hole? Each and every memory byte accessible by RDMA was accessible by the application anyway. The ULP is merely delegating access rights that it already had to the RNIC. I'm not sure this is true -- the question quoted in David's original message was (in effect) whether an attacker could sneak bytes past a packet authentication stage in a way that would not be possible if RDMA were not used. Whether or not the application *should* look at such bytes is not the issue; the problem arises when the application can be tricked into looking at them. I remain willing to believe that the attack I hypothesized cannot actually be made, but I don't think you have proved that because I think you are confusing what applications should do with what they might be caused to do. -Jeff _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Feb 20 21:26:50 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 VAA28665 for ; Fri, 20 Feb 2004 21:26:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMqV-00027S-KH for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 21:26:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L2QNrK008139 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 21:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMqV-00027C-Fs for rddp-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 21:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28638 for ; Fri, 20 Feb 2004 21:26:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMqS-000246-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 21:26:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMpj-00020r-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 21:25:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuMpA-0001vJ-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 21:25:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMpB-0001u3-9G; Fri, 20 Feb 2004 21:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuMp4-0001tb-Da for rddp@optimus.ietf.org; Fri, 20 Feb 2004 21:24:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28430 for ; Fri, 20 Feb 2004 21:24:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuMp1-0001ty-00 for rddp@ietf.org; Fri, 20 Feb 2004 21:24:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuMo1-0001kG-00 for rddp@ietf.org; Fri, 20 Feb 2004 21:23:49 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AuMmy-0001W5-00 for rddp@ietf.org; Fri, 20 Feb 2004 21:22:44 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id ED32F245F95; Fri, 20 Feb 2004 21:23:26 -0500 (EST) In-Reply-To: <200402210208.i1L28McN024303@wera.hpl.hp.com> References: <200402210208.i1L28McN024303@wera.hpl.hp.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: RDDP From: Caitlin Bestler Subject: Re: [rddp] PS & Arch drafts: status and security issues Date: Fri, 20 Feb 2004 20:22:13 -0600 To: Jeffrey Mogul X-Mailer: Apple Mail (2.612) 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 Feb 20, 2004, at 8:08 PM, Jeffrey Mogul wrote: > I'm not sure this is true -- the question quoted in David's > original message was (in effect) whether an attacker could sneak > bytes past a packet authentication stage in a way that would not > be possible if RDMA were not used. Whether or not the application > *should* look at such bytes is not the issue; the problem arises > when the application can be tricked into looking at them. A given byte in user memory space is either exposed for read and/or write or it is not. The ULP validity of the packet that takes advantage of that enabled access is irrelevant. Developing packet steering logic for each ULP creates *more* of a vulnerability because there are more algorithms that can be fooled. RDMA standardizes the unpacking process, making it easier to validate. But there is nothing in the RDMAP or DDP headers that "authorizes" access to memory, it merely *requests* access to memory. The authorization came from the local ULP, and cannot exceed the authority that the local ULP was already in possession of. And yes, the local interface could be compromised, leading to an RNIC making unauthorized access to local memory. But that is true of *any* DMA-enabled device on virtually any local system bus. By standardizing payload placement, RDMA can reduce the temptation to create multiple application specific solutions that must be promoted to the kernel for efficiency. Providing a mechanism for efficient handling of incoming data even for user mode applications, RDMA should decrease the temptation of "opening up" the kernel for new applications. -- Caitlin Bestler - cait@asomi.com - http://asomi.com/ http://asomi.com/CaitlinBestlerPublicPgpKey.html _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Fri Feb 20 22:46:49 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 WAA01358 for ; Fri, 20 Feb 2004 22:46:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuO5v-0006XF-9z for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 22:46:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L3kNJP025118 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 22:46:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuO5v-0006X3-0y for rddp-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 22:46:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01347 for ; Fri, 20 Feb 2004 22:46:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuO5r-0007KL-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 22:46:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuO4x-0007Ht-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 22:45:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuO4b-0007FP-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 22:45:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuO4b-0006Tm-NQ; Fri, 20 Feb 2004 22:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuO47-0006Sd-K5 for rddp@optimus.ietf.org; Fri, 20 Feb 2004 22:44:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01308 for ; Fri, 20 Feb 2004 22:44:27 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuO44-0007EI-00 for rddp@ietf.org; Fri, 20 Feb 2004 22:44:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuO3I-0007A4-00 for rddp@ietf.org; Fri, 20 Feb 2004 22:43:40 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AuO2T-000729-00 for rddp@ietf.org; Fri, 20 Feb 2004 22:42:49 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by mercury.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FKYM91TV; Fri, 20 Feb 2004 22:42:15 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Feb 2004 22:42:15 -0500 Message-ID: X-Sybari-Trust: bf56b871 1d8c424f 74f1dc3b 0000013d To: cait@asomi.com Cc: rddp@ietf.org Subject: RE: [rddp] PS & Arch drafts: status and security issues Date: Fri, 20 Feb 2004 22:42:14 -0500 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 > > I'm not sure this is true -- the question quoted in David's > > original message was (in effect) whether an attacker could sneak > > bytes past a packet authentication stage in a way that would not > > be possible if RDMA were not used. Whether or not the application > > *should* look at such bytes is not the issue; the problem arises > > when the application can be tricked into looking at them. > > A given byte in user memory space is either exposed for read > and/or write or it is not. The ULP validity of the packet > that takes advantage of that enabled access is irrelevant. > > Developing packet steering logic for each ULP creates *more* > of a vulnerability because there are more algorithms that can > be fooled. Unfortunately, that's not the comparison that the AD who wrote the original comment is concerned with. The comparison of interest is whether RDDP introduces additional security issues by comparison to a protocol stack that does no direct placement. Jeff's outlined a scenario in which a corrupted buffer that the ULP would not ordinarily look at could be used as part of an attack on the ULP. The first-order response to this threat should be a recommendation to use IPsec and run the packet authentication/ integrity check *before* placement when this threat is a concern. The "*before*" is a good idea anyhow, as the IPsec check also covers the placement data. Beyond this, Jeff's suggestion to overwrite placed data that has failed this sort of check seems reasonable, and the possible need to do that overwrite can be added to the discussion we already need on why TLS and in-order security mechanisms like may not be good fits to 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 Fri Feb 20 22:55:50 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 WAA01569 for ; Fri, 20 Feb 2004 22:55:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuOEe-00071z-R6 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 22:55:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1L3tOZd027021 for rddp-archive@odin.ietf.org; Fri, 20 Feb 2004 22:55:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuOEe-00071k-Nu for rddp-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 22:55:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01561 for ; Fri, 20 Feb 2004 22:55:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuOEb-00005e-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 22:55:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuODk-00002r-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 22:54:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuODG-0007nE-00 for rddp-web-archive@ietf.org; Fri, 20 Feb 2004 22:53:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuODJ-0006yh-3p; Fri, 20 Feb 2004 22:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuOCl-0006xr-U8 for rddp@optimus.ietf.org; Fri, 20 Feb 2004 22:53:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01506 for ; Fri, 20 Feb 2004 22:53:23 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuOCi-0007lf-00 for rddp@ietf.org; Fri, 20 Feb 2004 22:53:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuOBl-0007hx-00 for rddp@ietf.org; Fri, 20 Feb 2004 22:52:26 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AuOAs-0007av-00 for rddp@ietf.org; Fri, 20 Feb 2004 22:51:30 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by mercury.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FKYM91XF; Fri, 20 Feb 2004 22:51:01 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Feb 2004 22:51:01 -0500 Message-ID: X-Sybari-Trust: 1a2de910 1d8c424f 74f1dc3b 0000013d To: cait@asomi.com, rddp@ietf.org Cc: Black_David@emc.com Date: Fri, 20 Feb 2004 22:51:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] STag value choices 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 > > Aside: I think that many of these issues, as well as the multiple > > receiver problem (and I do not accept the argument that requiring > > many different clients to use the same address is in any way > > comparable to any existing problem in that space), would go away > > if the steering tag sent over the wire to the receiver were not > > just opaque, but by intent a random 64- or 128-bit tag to a local > > buffer descriptor. That permits easy local revocation of > > capabilities, as well as a defense against remote contamination > > attempts if the value were communicated previously over an > > encrypted channel. > > > > Also, if the STag values generated by an implementation are hard to > > predict, traffic injection by an adversary becomes more difficult. > > If the STag has cryptographic value it will be too large for > efficiency. There can be value in unpredictability before getting to 64 or 128 bit sizes. SCTP uses a 32-bit Verification Tag for a roughly analogous purpose, and 32 bits is not cryptographic strength. > A statement could be added that STags SHOULD be chosen so as to minimize > the risk of bit-errors changing one valid STag into another valid STag. > But there is no way to make that a "MUST" -- how would you know how an > STag you have been given compares with other STags given to other > clients? The concern is not about an STag being bit-errored into another STag, but rather that if an adversary knows the algorithm being used to generate STag values (e.g., can predict the next one that an implementation will generate), certain aspects of forging and injecting traffic become easier (e.g., more of the forged traffic can be precomputed). 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 Feb 21 10:35:15 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 KAA04647 for ; Sat, 21 Feb 2004 10:35:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZ9V-0006VO-Aw for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 10:34:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LFYnuV025006 for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 10:34:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZ9V-0006VF-3f for rddp-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 10:34:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04626 for ; Sat, 21 Feb 2004 10:34:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuZ9S-0002VB-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:34:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuZ8c-0002Sb-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:33:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuZ7k-0002PE-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZ7l-0006Rz-48; Sat, 21 Feb 2004 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZ7i-0006Rf-CU for rddp@optimus.ietf.org; Sat, 21 Feb 2004 10:32:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04560 for ; Sat, 21 Feb 2004 10:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuZ7g-0002Og-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:32:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuZ6c-0002L4-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:31:51 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AuZ6K-0002Hl-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:31:32 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id B3E7024576E; Sat, 21 Feb 2004 10:32:14 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: rddp@ietf.org From: Caitlin Bestler Subject: Re: [rddp] PS & Arch drafts: status and security issues Date: Sat, 21 Feb 2004 09:30:59 -0600 To: Black_David@emc.com X-Mailer: Apple Mail (2.612) 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 Feb 20, 2004, at 9:42 PM, Black_David@emc.com wrote: >>> I'm not sure this is true -- the question quoted in David's >>> original message was (in effect) whether an attacker could sneak >>> bytes past a packet authentication stage in a way that would not >>> be possible if RDMA were not used. Whether or not the application >>> *should* look at such bytes is not the issue; the problem arises >>> when the application can be tricked into looking at them. >> >> A given byte in user memory space is either exposed for read >> and/or write or it is not. The ULP validity of the packet >> that takes advantage of that enabled access is irrelevant. >> >> Developing packet steering logic for each ULP creates *more* >> of a vulnerability because there are more algorithms that can >> be fooled. > > Unfortunately, that's not the comparison that the AD who wrote the > original comment is concerned with. The comparison of interest > is whether RDDP introduces additional security issues by comparison > to a protocol stack that does no direct placement. Jeff's outlined > a scenario in which a corrupted buffer that the ULP would not > ordinarily look at could be used as part of an attack on the ULP. > > The first-order response to this threat should be a > recommendation to use IPsec and run the packet authentication/ > integrity check *before* placement when this threat is a concern. > The "*before*" is a good idea anyhow, as the IPsec check also covers > the placement data. Beyond this, Jeff's suggestion to overwrite > placed data that has failed this sort of check seems reasonable, > and the possible need to do that overwrite can be added to the > discussion we already need on why TLS and in-order security > mechanisms like may not be good fits to RDDP. > DDP works on packets presented to it by the LLP. They can be presented out-of-order, but they have to have passed LLP validation. So LLP or lower security/authentication is transparent to DDP. Admittedly serial methods aren't likely to present packets to DDP out-of-order. If they are using host memory for their own packet processing then the benefits of RDMA will be minimized. But many "before" packet authentication/integrity checks can essentially be performed as though they were in the network rather than on the host itself. Voiding invalid data post RDMAP/DDP is exactly that, a post RDMAP/DDP step. But ultimately it is the same issue for any application that applies application layer security/authentication above the transport layer. But the bottom line is that incorrect STags, MOs or TOs do NOT pose a security problem -- whether they result from packet injection, undetected packet corruption, a peer software bug or a peer with less than honorable intent. All local memory access is enabled by the ULP using the local interface. The STag/TO, MSN/MO can only select bytes within the enabled local memory. Ease of packet injection is determined by the LLP, and is not affected by RDMA. The ability of a peer to supply payload that is not what was expected also exists with or without RDMA. The ULP must adjust to the fact that is not bothered with the details. It does not know which bytes of the advertised buffer were written in what order, but this is not a security problem if the buffer is being used properly. The ULP can decide to trust its peer, and simplify its use of the local interface resulting is some excess exposure of its buffers. But they are user buffers, the negative impact of their abuse can easily be evaluated on an application specific basis. So an application that is perfectly capable of treating a void buffer as a void buffer should not have to pay the overhead of having their iWarp provider zeroing out voided buffers. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Feb 21 10:49:20 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 KAA05060 for ; Sat, 21 Feb 2004 10:49:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZN7-00078L-U0 for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 10:48:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LFmqZE027413 for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 10:48:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZN6-000784-Se for rddp-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 10:48:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05006 for ; Sat, 21 Feb 2004 10:48:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuZN4-0003BK-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:48:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuZMA-00037e-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:47:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuZLH-00033w-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZLJ-00074b-2a; Sat, 21 Feb 2004 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZLB-00074D-VS for rddp@optimus.ietf.org; Sat, 21 Feb 2004 10:46:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04865 for ; Sat, 21 Feb 2004 10:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuZL9-00033R-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuZKA-00030G-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:45:51 -0500 Received: from lists.your-site.com ([140.186.45.30] helo=thebe.your-site.com) by ietf-mx with esmtp (Exim 4.12) id 1AuZJd-0002x2-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:45:17 -0500 Received: from [192.168.0.2] (64-144-5-25.client.dsl.net [64.144.5.25]) by thebe.your-site.com (Postfix) with ESMTP id C3E1324521B; Sat, 21 Feb 2004 10:46:00 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: rddp@ietf.org From: Caitlin Bestler Date: Sat, 21 Feb 2004 09:44:45 -0600 To: Black_David@emc.com X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [rddp] Re: STag value choices 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 Feb 20, 2004, at 9:51 PM, Black_David@emc.com wrote: >>> Aside: I think that many of these issues, as well as the multiple >>> receiver problem (and I do not accept the argument that requiring >>> many different clients to use the same address is in any way >>> comparable to any existing problem in that space), would go away >>> if the steering tag sent over the wire to the receiver were not >>> just opaque, but by intent a random 64- or 128-bit tag to a local >>> buffer descriptor. That permits easy local revocation of >>> capabilities, as well as a defense against remote contamination >>> attempts if the value were communicated previously over an >>> encrypted channel. >>> >>> Also, if the STag values generated by an implementation are hard to >>> predict, traffic injection by an adversary becomes more difficult. >> >> If the STag has cryptographic value it will be too large for >> efficiency. > > There can be value in unpredictability before getting to 64 or > 128 bit sizes. SCTP uses a 32-bit Verification Tag for a roughly > analogous purpose, and 32 bits is not cryptographic strength. > >> A statement could be added that STags SHOULD be chosen so as to >> minimize >> the risk of bit-errors changing one valid STag into another valid >> STag. >> But there is no way to make that a "MUST" -- how would you know how an >> STag you have been given compares with other STags given to other >> clients? > > The concern is not about an STag being bit-errored into another STag, > but rather that if an adversary knows the algorithm being used to > generate > STag values (e.g., can predict the next one that an implementation > will generate), certain aspects of forging and injecting traffic > become easier (e.g., more of the forged traffic can be precomputed). > > There is no real need to predict STags. Even if STags are only open for a single transfer, most RDMA Writes will be encoded as multiple DDP Segments. Also buffers are advertised in ULP messages. Someone in a position to overhear and inject SCTP or TCP packets will still be able to do so. An incoming STag is evaluated in hardware, and should be done with only absolutely required access to context data for validation. In a typical implementation the STag will be parsed into a fixed portion referencing a Memory Window or Region and a variable portion that updates with each dynamic bind. Anything that would truly make it too hard for an eavesdropper to detect the pattern would add to the amount of context data that must be checked to validate each arriving STag. A simple hash (perhaps as simple as an XOR) would be cheap and minimize bit errors producing false matches, but would be more effective at confusing debuggers than in confusing hackers. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Feb 21 11:01:16 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 LAA05442 for ; Sat, 21 Feb 2004 11:01:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZYg-0007Z0-9x for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 11:00:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LG0ocu029068 for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 11:00:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZYg-0007Yk-2C for rddp-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 11:00:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05433 for ; Sat, 21 Feb 2004 11:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuZYd-0003mD-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 11:00:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuZXd-0003jK-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:59:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuZWs-0003gm-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 10:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZWu-0007Vk-8h; Sat, 21 Feb 2004 10:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuZWk-0007VZ-45 for rddp@optimus.ietf.org; Sat, 21 Feb 2004 10:58:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05393 for ; Sat, 21 Feb 2004 10:58:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuZWh-0003ga-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:58:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuZVk-0003ed-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:57:49 -0500 Received: from mx01.netapp.com ([198.95.226.53]) by ietf-mx with esmtp (Exim 4.12) id 1AuZVN-0003cB-00 for rddp@ietf.org; Sat, 21 Feb 2004 10:57:25 -0500 Received: from frejya.corp.netapp.com (frejya [10.57.157.119]) by mx01.netapp.com (8.12.10/8.12.10/NTAP-1.4) with ESMTP id i1LFurJC029063; Sat, 21 Feb 2004 07:56:53 -0800 (PST) Received: from svlexc01.hq.netapp.com (svlexc01.corp.netapp.com [10.10.22.171]) by frejya.corp.netapp.com (8.12.9/8.12.9/NTAP-1.5) with ESMTP id i1LFurB4002514; Sat, 21 Feb 2004 07:56:53 -0800 (PST) Received: from tmt.netapp.com ([10.97.6.35]) by silver.hq.netapp.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 21 Feb 2004 10:56:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F893.4CDDEF80" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: Re: [rddp] STag value choices Date: Sat, 21 Feb 2004 07:56:25 -0800 Message-ID: <5.2.1.1.2.20040221104559.01b14fa0@silver.nane.netapp.com> Thread-Topic: [rddp] STag value choices Thread-Index: AcP4k02RN1pn0FeFRNm0kAxOgU1qSg== From: "Talpey, Thomas" To: Cc: 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.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F893.4CDDEF80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 10:51 PM 2/20/2004, Black_David@emc.com wrote: >The concern is not about an STag being bit-errored into another STag, >but rather that if an adversary knows the algorithm being used to = generate >STag values (e.g., can predict the next one that an implementation >will generate), certain aspects of forging and injecting traffic=20 >become easier (e.g., more of the forged traffic can be precomputed). Remember too that the scope of the STag is important to consider. Generally speaking, STags are constrained to be valid only in the context of a single connection. In this case the adversarial peer has not gained access to any additional memory than that which was already granted. The Architecture document specifically states that ddp_register() permits access to the registered buffer via the resulting STag on the specific "socket" (endpoint, queuepair) where the registration was performed. This is not intended to exclude the possibility of wider scope, but warns (in the security section) that widening the scope has security implications. Tom. ------_=_NextPart_001_01C3F893.4CDDEF80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [rddp] STag value choices

At 10:51 PM 2/20/2004, Black_David@emc.com = wrote:
>The concern is not about an STag being = bit-errored into another STag,
>but rather that if an adversary knows the = algorithm being used to generate
>STag values (e.g., can predict the next one that = an implementation
>will generate), certain aspects of forging and = injecting traffic
>become easier (e.g., more of the forged traffic = can be precomputed).

Remember too that the scope of the STag is important = to
consider. Generally speaking, STags are constrained = to be
valid only in the context of a single connection. In = this case
the adversarial peer has not gained access to any = additional
memory than that which was already granted.

The Architecture document specifically states that = ddp_register()
permits access to the registered buffer via the = resulting STag
on the specific "socket" (endpoint, = queuepair) where the
registration was performed. This is not intended to = exclude the
possibility of wider scope, but warns (in the = security section)
that widening the scope has security = implications.

Tom.

------_=_NextPart_001_01C3F893.4CDDEF80-- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Feb 21 14:26:23 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 OAA10872 for ; Sat, 21 Feb 2004 14:26:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuclA-0000s1-KH for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 14:25:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LJPurU003339 for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 14:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuclA-0000rm-GJ for rddp-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 14:25:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10859 for ; Sat, 21 Feb 2004 14:25:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aucl7-000178-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 14:25:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuckD-00014S-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 14:24:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AucjI-00011K-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 14:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AucjI-0000l8-Rt; Sat, 21 Feb 2004 14:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AucjA-0000kc-R9 for rddp@optimus.ietf.org; Sat, 21 Feb 2004 14:23:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10800 for ; Sat, 21 Feb 2004 14:23:49 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aucj8-0000zs-00 for rddp@ietf.org; Sat, 21 Feb 2004 14:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuciB-0000xd-00 for rddp@ietf.org; Sat, 21 Feb 2004 14:22:52 -0500 Received: from srexchimc2.lss.emc.com ([168.159.100.11] helo=srexchimc2.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1AuchU-0000t7-00 for rddp@ietf.org; Sat, 21 Feb 2004 14:22:08 -0500 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by srexchimc2.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1ZQJRBMD; Sat, 21 Feb 2004 14:21:04 -0500 Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 21 Feb 2004 14:21:04 -0500 Message-ID: X-Sybari-Trust: 82c692aa 1d8c424f b145f4d4 0000013d To: Black_David@emc.com Cc: rddp@ietf.org Subject: RE: [rddp] PS & Arch drafts: status and security issues Date: Sat, 21 Feb 2004 14:21:03 -0500 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 > >>> I'm not sure this is true -- the question quoted in David's > >>> original message was (in effect) whether an attacker could sneak > >>> bytes past a packet authentication stage in a way that would not > >>> be possible if RDMA were not used. Whether or not the application > >>> *should* look at such bytes is not the issue; the problem arises > >>> when the application can be tricked into looking at them. > >> > >> A given byte in user memory space is either exposed for read > >> and/or write or it is not. The ULP validity of the packet > >> that takes advantage of that enabled access is irrelevant. > >> > >> Developing packet steering logic for each ULP creates *more* > >> of a vulnerability because there are more algorithms that can > >> be fooled. > > > > Unfortunately, that's not the comparison that the AD who wrote the > > original comment is concerned with. The comparison of interest > > is whether RDDP introduces additional security issues by comparison > > to a protocol stack that does no direct placement. Jeff's outlined > > a scenario in which a corrupted buffer that the ULP would not > > ordinarily look at could be used as part of an attack on the ULP. > > > > The first-order response to this threat should be a > > recommendation to use IPsec and run the packet authentication/ > > integrity check *before* placement when this threat is a concern. > > The "*before*" is a good idea anyhow, as the IPsec check also covers > > the placement data. Beyond this, Jeff's suggestion to overwrite > > placed data that has failed this sort of check seems reasonable, > > and the possible need to do that overwrite can be added to the > > discussion we already need on why TLS and in-order security > > mechanisms like may not be good fits to RDDP. > > > > DDP works on packets presented to it by the LLP. They can be > presented out-of-order, but they have to have passed LLP > validation. > > So LLP or lower security/authentication is transparent to DDP. > Admittedly serial methods aren't likely to present packets to > DDP out-of-order. If they are using host memory for their own > packet processing then the benefits of RDMA will be minimized. > But many "before" packet authentication/integrity checks can > essentially be performed as though they were in the network > rather than on the host itself. That looks like violent agreement - the best thing to do if injection of invalid traffic is a concern is to arrange the security functionality so that invalid data is rejected prior to placement. > Voiding invalid data post RDMAP/DDP is exactly that, a post > RDMAP/DDP step. But ultimately it is the same issue for any > application that applies application layer security/authentication > above the transport layer. There's one very important difference. In error cases, RDMAP/DDP will place data in buffers that are never successfully received for ULP processing, including application security/authentication; a vanilla (e.g., sockets) interface does not do that - in the error case, the unreceived data is in unpredictable system buffers that the system cleans up as a routine matter. RDMAP/DDP has more junk that may have to be cleaned up in error cases, and this will need to be noted as a potential security concern. > But the bottom line is that incorrect STags, MOs or TOs do NOT > pose a security problem -- whether they result from packet > injection, undetected packet corruption, a peer software > bug or a peer with less than honorable intent. > > All local memory access is enabled by the ULP using the local > interface. The STag/TO, MSN/MO can only select bytes within > the enabled local memory. > > Ease of packet injection is determined by the LLP, and is not > affected by RDMA. The ability of a peer to supply payload that > is not what was expected also exists with or without RDMA. > > The ULP must adjust to the fact that is not bothered with > the details. It does not know which bytes of the advertised > buffer were written in what order, but this is not a security > problem if the buffer is being used properly. > > The ULP can decide to trust its peer, and simplify its use > of the local interface resulting is some excess exposure of > its buffers. But they are user buffers, the negative impact > of their abuse can easily be evaluated on an application > specific basis. > > So an application that is perfectly capable of treating > a void buffer as a void buffer should not have to pay the > overhead of having their iWarp provider zeroing out voided > buffers. In other words, it's a ULP by ULP decision, and the possible security consequences of deciding whether or not to void out the buffers in the error cases needs to be discussed in the security considerations section. I never said that this voiding out would need to be mandatory - it should suffice to have a solid discussion of the security exposure here (and there is a security exposure based on the fact that placement can occur without the ULP being told about it in error cases), and ways to deal with it, with voiding out of placed but unreceived data as a possible means of doing so. OTOH, announcing that this does "NOT pose a security problem" is an invitation to a lengthy discussion with the Security ADs, who happen to be correct that there is a potential security issue here that needs attention in the security considerations section of the architecture draft (and also in the security draft). 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 Feb 21 21:28:32 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 VAA25694 for ; Sat, 21 Feb 2004 21:28:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujLg-0003a1-AC for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 21:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2S4jJ013757 for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 21:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujLg-0003Zo-4n for rddp-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 21:28:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25680 for ; Sat, 21 Feb 2004 21:28:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AujLd-00034Y-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 21:28:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujKe-00031d-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 21:27:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AujJh-0002yI-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 21:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujJi-0003Rk-0k; Sat, 21 Feb 2004 21:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujIs-0003Qe-T4 for rddp@optimus.ietf.org; Sat, 21 Feb 2004 21:25:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25623 for ; Sat, 21 Feb 2004 21:25:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AujIq-0002vm-00 for rddp@ietf.org; Sat, 21 Feb 2004 21:25:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujHx-0002so-00 for rddp@ietf.org; Sat, 21 Feb 2004 21:24:14 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AujHa-0002pR-00 for rddp@ietf.org; Sat, 21 Feb 2004 21:23:50 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel12.hp.com (Postfix) with ESMTP id 729891C01D4A for ; Sat, 21 Feb 2004 18:23:41 -0800 (PST) Received: from mk731915.cup.hp.com ([15.244.168.197]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id i1M2E9015579 for ; Sat, 21 Feb 2004 18:14:09 -0800 (PST) Message-Id: <5.1.0.14.2.20040221174905.02539950@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 21 Feb 2004 17:55:39 -0800 To: rddp@ietf.org From: Michael Krause Subject: Re: [rddp] Re: STag value choices In-Reply-To: References: 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 09:44 AM 2/21/2004 -0600, Caitlin Bestler wrote: >On Feb 20, 2004, at 9:51 PM, Black_David@emc.com wrote: > >>>> Aside: I think that many of these issues, as well as the multiple >>>> receiver problem (and I do not accept the argument that requiring >>>> many different clients to use the same address is in any way >>>> comparable to any existing problem in that space), would go away >>>> if the steering tag sent over the wire to the receiver were not >>>> just opaque, but by intent a random 64- or 128-bit tag to a local >>>> buffer descriptor. That permits easy local revocation of >>>> capabilities, as well as a defense against remote contamination >>>> attempts if the value were communicated previously over an >>>> encrypted channel. >>>> >>>>Also, if the STag values generated by an implementation are hard to >>>>predict, traffic injection by an adversary becomes more difficult. >>> >>>If the STag has cryptographic value it will be too large for >>>efficiency. >> >>There can be value in unpredictability before getting to 64 or >>128 bit sizes. SCTP uses a 32-bit Verification Tag for a roughly >>analogous purpose, and 32 bits is not cryptographic strength. >> >>>A statement could be added that STags SHOULD be chosen so as to minimize >>>the risk of bit-errors changing one valid STag into another valid STag. >>>But there is no way to make that a "MUST" -- how would you know how an >>>STag you have been given compares with other STags given to other >>>clients? >> >>The concern is not about an STag being bit-errored into another STag, >>but rather that if an adversary knows the algorithm being used to generate >>STag values (e.g., can predict the next one that an implementation >>will generate), certain aspects of forging and injecting traffic >>become easier (e.g., more of the forged traffic can be precomputed). >> > > >There is no real need to predict STags. Even if STags are only open >for a single transfer, most RDMA Writes will be encoded as multiple >DDP Segments. The size of the RDMA Writes may vary between 1 and 4GB but I don't see that as having any real bearing on the discussion. The STag has a ULP-defined / application instance scope and is intended to act as a key to enable fast memory translation possible. It isn't there to provide any sense of protection. >Also buffers are advertised in ULP messages. > >Someone in a position to overhear and inject SCTP or TCP packets will >still be able to do so. Correct. If the fabric is open to a sniffer then they can see the information assuming they knew how to parse the packets to determine where the headers are in a given byte stream / message chunk. If there is concern that this can exist, then use something like IP Security to protect the stream and avoid the exposure. >An incoming STag is evaluated in hardware, and should be done with only >absolutely required access to context data for validation. In a typical >implementation the STag will be parsed into a fixed portion referencing a >Memory Window or Region and a variable portion that updates with each >dynamic bind. Anything that would truly make it too hard for an >eavesdropper to detect the pattern would add to the amount of context data >that must be checked to validate each arriving STag. Correct. Since a STag is not used for security, its size was kept reasonably small to allow implementations to encode the STag to optimize their solutions to meet their particular design - simplicity, performance, scalability, etc. >A simple hash (perhaps as simple as an XOR) would be cheap and minimize >bit errors producing false matches, but would be more effective at >confusing debuggers than in confusing hackers. These can be done without requiring anything new within the specification as STags are an opaque handle used to optimize the implementation by passing the handle between the communicating endnodes. Mike _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Sat Feb 21 22:15:32 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 VAA25695 for ; Sat, 21 Feb 2004 21:28:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujLg-0003aL-Vl for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 21:28:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M2S4hV013775 for rddp-archive@odin.ietf.org; Sat, 21 Feb 2004 21:28:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujLg-0003a4-SQ for rddp-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 21:28:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25683 for ; Sat, 21 Feb 2004 21:28:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AujLe-00034d-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 21:28:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujKf-00031l-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 21:27:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AujJh-0002yJ-00 for rddp-web-archive@ietf.org; Sat, 21 Feb 2004 21:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujJh-0003Rc-NY; Sat, 21 Feb 2004 21:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AujIs-0003QZ-6o for rddp@optimus.ietf.org; Sat, 21 Feb 2004 21:25:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25620 for ; Sat, 21 Feb 2004 21:25:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AujIp-0002vg-00 for rddp@ietf.org; Sat, 21 Feb 2004 21:25:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AujHw-0002sf-00 for rddp@ietf.org; Sat, 21 Feb 2004 21:24:13 -0500 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1AujHa-0002pQ-00 for rddp@ietf.org; Sat, 21 Feb 2004 21:23:50 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel13.hp.com (Postfix) with ESMTP id 3891A1C01959 for ; Sat, 21 Feb 2004 18:23:40 -0800 (PST) Received: from mk731915.cup.hp.com ([15.244.168.197]) by esmail.cup.hp.com (8.11.1/8.8.6) with ESMTP id i1M2E7015575 for ; Sat, 21 Feb 2004 18:14:08 -0800 (PST) Message-Id: <5.1.0.14.2.20040221173600.0251d840@15.13.130.73> X-Sender: krause@15.13.130.73 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 21 Feb 2004 17:47:16 -0800 To: rddp@ietf.org From: Michael Krause Subject: RE: [rddp] PS & Arch drafts: status and security issues In-Reply-To: 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 02:21 PM 2/21/2004 -0500, Black_David@emc.com wrote: > > >>> I'm not sure this is true -- the question quoted in David's > > >>> original message was (in effect) whether an attacker could sneak > > >>> bytes past a packet authentication stage in a way that would not > > >>> be possible if RDMA were not used. Whether or not the application > > >>> *should* look at such bytes is not the issue; the problem arises > > >>> when the application can be tricked into looking at them. > > >> > > >> A given byte in user memory space is either exposed for read > > >> and/or write or it is not. The ULP validity of the packet > > >> that takes advantage of that enabled access is irrelevant. > > >> > > >> Developing packet steering logic for each ULP creates *more* > > >> of a vulnerability because there are more algorithms that can > > >> be fooled. > > > > > > Unfortunately, that's not the comparison that the AD who wrote the > > > original comment is concerned with. The comparison of interest > > > is whether RDDP introduces additional security issues by comparison > > > to a protocol stack that does no direct placement. Jeff's outlined > > > a scenario in which a corrupted buffer that the ULP would not > > > ordinarily look at could be used as part of an attack on the ULP. > > > > > > The first-order response to this threat should be a > > > recommendation to use IPsec and run the packet authentication/ > > > integrity check *before* placement when this threat is a concern. > > > The "*before*" is a good idea anyhow, as the IPsec check also covers > > > the placement data. Beyond this, Jeff's suggestion to overwrite > > > placed data that has failed this sort of check seems reasonable, > > > and the possible need to do that overwrite can be added to the > > > discussion we already need on why TLS and in-order security > > > mechanisms like may not be good fits to RDDP. > > > > > > > DDP works on packets presented to it by the LLP. They can be > > presented out-of-order, but they have to have passed LLP > > validation. > > > > So LLP or lower security/authentication is transparent to DDP. > > Admittedly serial methods aren't likely to present packets to > > DDP out-of-order. If they are using host memory for their own > > packet processing then the benefits of RDMA will be minimized. > > But many "before" packet authentication/integrity checks can > > essentially be performed as though they were in the network > > rather than on the host itself. > >That looks like violent agreement - the best thing to do if injection >of invalid traffic is a concern is to arrange the security functionality >so that invalid data is rejected prior to placement. > > > Voiding invalid data post RDMAP/DDP is exactly that, a post > > RDMAP/DDP step. But ultimately it is the same issue for any > > application that applies application layer security/authentication > > above the transport layer. > >There's one very important difference. In error cases, RDMAP/DDP >will place data in buffers that are never successfully received >for ULP processing, including application security/authentication; RDMA/DDP may place data into buffers which are completed in error upon a problem being detected. The associated ULP / middleware knows that on error the buffers are in an indeterminate state and thus should not be trusted in terms of their contents. Implementations may scrub (e.g. zero out) the buffers, release the buffers, etc. and see no ill effects. >a vanilla (e.g., sockets) interface does not do that - in the error case, >the unreceived data is in unpredictable system buffers that the system >cleans up as a routine matter. It is somewhat a function of where processing occurs as this can vary by implementation. For example, in a user-space or embedded environment network stack implementation, the buffers may be ULP buffers and thus placement may have occurred. The clean-up process / exposure would be the same as for RDMA/DDP. I recall several network stack implementations (e.g. Solaris fastbufs from a few years back) that allowed application buffers to be posted to a NIC and thus making them subject to this same concern as for RDMA/DDP. For a traditional OS kernel network stack implementation, the ULP may or may not see the data depending upon where it sits relative to the network stack such as directly on top of the LLP or on top of a sockets interface. I agree that in many OS, the kernel buffers which are used for intermediate receive buffers provides a method to isolate any erroneous buffers from the application if a copy operation is performed as detection of an error / security violation may result in these buffers being scrubbed / freed prior to the copy operation which is a fairly standard operating procedure. >RDMAP/DDP has more junk that may have to be cleaned up in error cases, and >this will need to be noted as a potential security concern. I do not disagree that a warning should be provided but it isn't unique to RDMA/DDP as this problem exists with existing network stacks / usage models. > > But the bottom line is that incorrect STags, MOs or TOs do NOT > > pose a security problem -- whether they result from packet > > injection, undetected packet corruption, a peer software > > bug or a peer with less than honorable intent. > > > > All local memory access is enabled by the ULP using the local > > interface. The STag/TO, MSN/MO can only select bytes within > > the enabled local memory. > > > > Ease of packet injection is determined by the LLP, and is not > > affected by RDMA. The ability of a peer to supply payload that > > is not what was expected also exists with or without RDMA. > > > > The ULP must adjust to the fact that is not bothered with > > the details. It does not know which bytes of the advertised > > buffer were written in what order, but this is not a security > > problem if the buffer is being used properly. > > > > The ULP can decide to trust its peer, and simplify its use > > of the local interface resulting is some excess exposure of > > its buffers. But they are user buffers, the negative impact > > of their abuse can easily be evaluated on an application > > specific basis. > > > > So an application that is perfectly capable of treating > > a void buffer as a void buffer should not have to pay the > > overhead of having their iWarp provider zeroing out voided > > buffers. > >In other words, it's a ULP by ULP decision, and the possible >security consequences of deciding whether or not to void out the >buffers in the error cases needs to be discussed in the security >considerations section. I never said that this voiding out >would need to be mandatory I would be opposed to making this a mandatory requirement. > - it should suffice to have a solid discussion of the security exposure > here (and there is a security >exposure based on the fact that placement can occur without the ULP being >told about it in error cases), and ways to deal with it, with voiding out >of placed but unreceived data as a possible means of doing so. > >OTOH, announcing that this does "NOT pose a security problem" is an >invitation to a lengthy discussion with the Security ADs, who happen to be >correct that there is a potential security issue here that needs attention >in the security considerations section of the architecture draft (and also >in the security draft). Mike _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Mon Feb 23 16:50:09 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 QAA22821 for ; Mon, 23 Feb 2004 16:50:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNxO-0004so-RI for rddp-archive@odin.ietf.org; Mon, 23 Feb 2004 16:49:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1NLngoA018769 for rddp-archive@odin.ietf.org; Mon, 23 Feb 2004 16:49:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNxO-0004se-ND for rddp-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 16:49:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22471 for ; Mon, 23 Feb 2004 16:49:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvNxM-00004w-00 for rddp-web-archive@ietf.org; Mon, 23 Feb 2004 16:49:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvNwX-0007nL-00 for rddp-web-archive@ietf.org; Mon, 23 Feb 2004 16:48:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvNvk-0007h3-00 for rddp-web-archive@ietf.org; Mon, 23 Feb 2004 16:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNvl-0004og-4p; Mon, 23 Feb 2004 16:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvNvS-0004no-Me for rddp@optimus.ietf.org; Mon, 23 Feb 2004 16:47:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22060 for ; Mon, 23 Feb 2004 16:47:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvNvQ-0007fL-00 for rddp@ietf.org; Mon, 23 Feb 2004 16:47:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvNue-0007ZE-00 for rddp@ietf.org; Mon, 23 Feb 2004 16:46:52 -0500 Received: from mail3.ttlc.net ([66.94.32.26] helo=mail.communicom.net) by ietf-mx with esmtp (Exim 4.12) id 1AvNtp-0007SL-00 for rddp@ietf.org; Mon, 23 Feb 2004 16:46:01 -0500 Received: from lampreynetworks.com [66.94.32.4] by mail.communicom.net with ESMTP (SMTPD32-7.07) id A637213300EC; Mon, 23 Feb 2004 16:52:55 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A6363EC400DE; Mon, 23 Feb 2004 16:52:54 -0500 From: "Barry Reinhold" To: "RDDP" Date: Mon, 23 Feb 2004 16:45:51 -0500 Message-ID: <002001c3fa56$6b80a3f0$467fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [rddp] (no subject) 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 To: Any interested party From: Barry Reinhold Re: Development of RDDP testing infrastructure It has been my experience that most developers desire to have access to conformance-like test suites as well as the ability to engage in "plug-fests" during the development cycle of products related to a new technology. It has also been my experience that this type of work is best done in the context of an open technical community that is well connected to the standards process. Given the shared need of the RDDP developer community there is reasons to believe that a light weight organization can be established that would create an iWARP conformance test suite and run plug-fests. Please contact me, or post to the reflector if you, or your organization, would like to support such an effort. Given sufficient interest I will generate some sort of document and an agenda for a conference call where a first level of discussion can take place. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From exim@www1.ietf.org Tue Feb 24 11:08:57 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 LAA27742 for ; Tue, 24 Feb 2004 11:08:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avf6k-000247-TG for rddp-archive@odin.ietf.org; Tue, 24 Feb 2004 11:08:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OG8UW2007933 for rddp-archive@odin.ietf.org; Tue, 24 Feb 2004 11:08:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avf6k-00023s-PG for rddp-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 11:08:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27733 for ; Tue, 24 Feb 2004 11:08:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avf6i-0004la-00 for rddp-web-archive@ietf.org; Tue, 24 Feb 2004 11:08:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avf4M-0004cL-00 for rddp-web-archive@ietf.org; Tue, 24 Feb 2004 11:06:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avf3M-0004WW-00 for rddp-web-archive@ietf.org; Tue, 24 Feb 2004 11:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avf3M-0001Z5-UW; Tue, 24 Feb 2004 11:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avf2T-0001Ug-MB for rddp@optimus.ietf.org; Tue, 24 Feb 2004 11:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27591 for ; Tue, 24 Feb 2004 11:04:01 -0500 (EST) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avf2R-0004RY-00 for rddp@ietf.org; Tue, 24 Feb 2004 11:04:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avf1V-0004MY-00 for rddp@ietf.org; Tue, 24 Feb 2004 11:03:06 -0500 Received: from mercury.lss.emc.com ([168.159.100.12] helo=mercury.eng.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1Avf0Z-0004EH-00; Tue, 24 Feb 2004 11:02:07 -0500 Received: from mxic2.corp.emc.com ([128.221.12.9]) by mercury.eng.emc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id FKYND6HB; Tue, 24 Feb 2004 11:01:36 -0500 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 11:01:36 -0500 Message-ID: X-Sybari-Trust: f0f9f832 1d8c424f 1616d124 0000013d To: agenda@ietf.org, rddp@ietf.org Date: Tue, 24 Feb 2004 11:01:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [rddp] RDDP WG Seoul agenda 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 Seoul IETF Meeting February 29 - March 4, 2004 --------------------------- Remote Direct Data Placement WG (rddp) CHAIR: David L. Black The RDDP WG works on Remote Direct Data Placement and Remote Direct Memory Access functionality. For more information, please refer to the rddp charter at: http://www.ietf.org/html.charters/rddp-charter.html AGENDA: Subject to change WEDNESDAY, March 3, 2004, 0900-1130 ------------------------------------- - Agenda Bashing and Administrivia (5 min) - Blue Sheets - NOTE WELL - Status of drafts (5 min) - Applicability Statement (5 min) (draft-ietf-rddp-applicability-01.txt) Mostly a status update. - DDP and RDMAP drafts (10 min) (draft-ietf-rddp-ddp-02.txt, draft-ietf-rddp-rdmap-01.txt) Mostly a status update. - SCTP Mapping (5 min) (draft-ietf-rddp-sctp-00.txt) Despite the -00 version number, this is the fourth version of this draft, and it is relatively mature. - TCP mapping (30 min) (draft-ietf-rddp-mpa-00.txt, draft-culley-mpa-issueresponses-00.txt) The mpa-issueresponses draft is a separate draft from the MPA authors describing issues raised in MPA and proposed approaches. - Security (60 min) (draft-ietf-rddp-security-01.txt) Time allocated reflects the importance of progress on this draft. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp