RE: [rddp] DDP/RDMAP Applicability
Black_David@emc.com Thu, 20 April 2006 22:03 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhF2-0002yW-2v; Thu, 20 Apr 2006 18:03:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWhF1-0002yR-B8 for rddp@ietf.org; Thu, 20 Apr 2006 18:03:11 -0400
Received: from mexforward.lss.emc.com ([168.159.213.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWhF1-0000lJ-2l for rddp@ietf.org; Thu, 20 Apr 2006 18:03:11 -0400
Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3KM39Lx021237; Thu, 20 Apr 2006 18:03:09 -0400 (EDT)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id k3KM36aL019216; Thu, 20 Apr 2006 18:03:07 -0400 (EDT)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <JF77S8P8>; Thu, 20 Apr 2006 18:03:05 -0400
Message-ID: <F222151D3323874393F83102D614E05502B66A33@CORPUSMX20A.corp.emc.com>
From: Black_David@emc.com
To: caitlinb@broadcom.com, rddp@ietf.org
Subject: RE: [rddp] DDP/RDMAP Applicability
Date: Thu, 20 Apr 2006 18:02:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.4.20.143109
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc:
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
Errors-To: rddp-bounces@ietf.org
Caitlin, The correct capitalization of IPsec is IPsec ("sec" is lower case). I also noticed that the ESP reference needs to be updated from RFC 2406 to RFC 4303 - it is one of a number of references that aren't cited in the body of the draft (citations should be added or the reference dropped). I also have a few comments below. Please make these changes plus the typo fix noted in previous email and submit the resulting draft on Monday, just in case anyone else wants to comment on the new text in the interim. 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 ---------------------------------------------------- > -----Original Message----- > From: Caitlin Bestler [mailto:caitlinb@broadcom.com] > Sent: Thursday, April 20, 2006 4:09 PM > To: rddp@ietf.org > Subject: RE: [rddp] DDP/RDMAP Applicability > > These are additional paragraphs that would address the > questions raised: > > > In 6.6 (data integrity implications) > > CRC32c only provides protection against random corruption. To > protect against unauthorized alteration or forging of data packets Add a comma at the end of this line. > security methods must be applied. Use of IPSEC is supported for > both SCTP and MPA/TCP. > > > In 9.1 (Security Consideratins - Connection/Association Setup) > > Authentication of peers and approval of connections is outside of the > scope of DDP. Connections are initiated and accepted by the ULP > using authentication information as provided by the LLP. IPSEC is > usable for both TCP and SCTP. "using authentication information as provided by the LLP" could be misread as implying use of LLP identities. Change it to "and connection authentication is the responsibility of the ULP". In addition to fixing the capitalization of IPsec, add the following to the end of the last sentence above : "and can provide authentication at a protocol layer beneath DDP" > In 9.2 (Security Considerations - Tagged Buffer Exposure) > > DDP validates that STags are only used by the remote peer to the > extent authorized by the ULP. The STag is selects amongst authorized > buffers; "is selects amongst authorized buffers" --> "selects among buffers previously authorized by the ULP" > an STag by itself does not authorize access. Spacing STags > is more a defense against 'off by one' errors than a cryptographic > protection. Replace the last sentence with: Use of randomization in generating STag values may be useful in preventing 'off by one' and other programmatic errors, but is of limited value in countering generation and misuse of STag values by an active attacker. IPsec provides countermeasures that can prevent such an unauthorized attacker from gaining access to buffers used by DDP and RDMAP. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp
- [rddp] DDP/RDMAP Applicability Derek Atkins
- RE: [rddp] DDP/RDMAP Applicability Caitlin Bestler
- RE: [rddp] DDP/RDMAP Applicability Caitlin Bestler
- RE: [rddp] DDP/RDMAP Applicability Black_David