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