RE: [rddp] DDP/RDMAP Applicability
"Caitlin Bestler" <caitlinb@broadcom.com> Thu, 20 April 2006 16:19 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbsp-0007Wb-Tc; Thu, 20 Apr 2006 12:19:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbso-0007WW-7p for rddp@ietf.org; Thu, 20 Apr 2006 12:19:54 -0400
Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbsn-0000St-TJ for rddp@ietf.org; Thu, 20 Apr 2006 12:19:54 -0400
Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 20 Apr 2006 09:19:40 -0700
X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 37A022B2; Thu, 20 Apr 2006 09:19:39 -0700 (PDT)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 4A4AA2B1; Thu, 20 Apr 2006 09:19:38 -0700 (PDT)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5-GA) with ESMTP id DIS89613; Thu, 20 Apr 2006 09:19:37 -0700 (PDT)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6782120501; Thu, 20 Apr 2006 09:19:37 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [rddp] DDP/RDMAP Applicability
Date: Thu, 20 Apr 2006 09:19:36 -0700
Message-ID: <54AD0F12E08D1541B826BE97C98F99F143A7DD@NT-SJCA-0751.brcm.ad.broadcom.com>
Thread-Topic: [rddp] DDP/RDMAP Applicability
Thread-Index: AcZkh6wbJG9sNQ20SMO8nunT8tq78wADaMpQ
From: Caitlin Bestler <caitlinb@broadcom.com>
To: Derek Atkins <derek@ihtfp.com>, secdir-secretary@MIT.EDU
X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006042004; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34343437423332442E303035452D412D; ENG=IBF; TS=20060420161942; CAT=NONE; CON=NONE;
X-MMS-Spam-Filter-ID: A2006042004_4.00.0004_2.0.6,4.0-7
X-WSS-ID: 68596B160HW8894901-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: Sam Hartman <hartmans-ietf@MIT.EDU>, Pat Cain <pcain@acmehacking.com>, Russ Housley <housley@vigilsec.com>, rddp@ietf.org
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
Derek Atkins wrote: > I was asked to review the DDP/RDMAP specifications. Here are > my comments on draft-ietf-rddp-applicability-05.txt > Typos noted and fixed. Thanks. > > ---- > ---- > > Section 6.6 : Data Integrity Implications > > CRC32 helps protect against accidental data corruption, but > not intensional data corruption. An attacker could easily > intentionally corrupt the data and a CRC32 cannot detect > that. I recommend some stronger wording that an active > attacker could easily subvert the CRC32, or at least > additional text that explains that CRC32 only protects > against accidental data corruption and not intensional data > corruption. > Clarification on the types of corruption will be added. > ---- > > Section 9 : Security considerations > > The discussion of the steering tag doesn't discuss what > information is exposed, or how guessable these tags could be. > What's the implication of a "peer" guessing at random STags? > Could I get data that I shouldn't have access to? Are these > STags tied to a particular peer session, and if so how? > A paragraph will be added to emphasize that STags must be validated for use on a connection. Therefore there is a set of advertised buffers that a peer can access, and those are the *only* buffers that the peer can use. There is no "guessing" involved. However there is no way for the RDMA layer to know that the peer has not *confused* which of the buffers it is authorized to use and has specified the wrong one. > -- > > There's no discussion of peer authentication. How do I know > who I'm talking to and how do I authenticate and authorize > their RDMA access? > > ---- > > Section 9.2 : Tagged Buffer Exposure > > This section does not go into enough detail of what can > happen if an attacker can insert random (or worse, non > random!) data into arbitrary buffers. We've got so many > buffer overrun attacks. Imagine what could happen if an > attacker didn't need to overrun a buffer but could co-opt the > RDMA and insert arbitrary data into buffers directly. > Language will be added emphasizing that random data placed into advertised buffers must be handled by the ULP, just as sending arbitrary data over a non-RDMA connection must be detected and handled up the ULP. _______________________________________________ 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