Re: [secdir] SECDIR review of draft-ietf-nfsv4-rpcrdma-bidirection

Chuck Lever <chuck.lever@oracle.com> Mon, 30 January 2017 16:19 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51FC12953B; Mon, 30 Jan 2017 08:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.419
X-Spam-Level:
X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF_clJJjwtkE; Mon, 30 Jan 2017 08:19:34 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E6212955D; Mon, 30 Jan 2017 08:19:03 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0UGJ0bW031517 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Jan 2017 16:19:01 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0UGJ0w9032147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Jan 2017 16:19:00 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v0UGIvu5019904; Mon, 30 Jan 2017 16:18:58 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 30 Jan 2017 08:18:57 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CAFOuuo72ASH2f_n4dpanWDDtoyAH7gP-ckkW-sP6KTJdtjs=mA@mail.gmail.com>
Date: Mon, 30 Jan 2017 11:18:56 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <09B9253D-6C00-4584-B420-AD17202CC48B@oracle.com>
References: <CAFOuuo72ASH2f_n4dpanWDDtoyAH7gP-ckkW-sP6KTJdtjs=mA@mail.gmail.com>
To: Radia Perlman <radiaperlman@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/7lU35s_aQ5nmMlqnteEwIKB4JRc>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpcrdma-bidirection.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-nfsv4-rpcrdma-bidirection
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 16:19:37 -0000

> On Jan 29, 2017, at 10:11 PM, Radia Perlman <radiaperlman@gmail.com> wrote:
> 
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. 
> 
> This draft concerns running NFS over RDMA (memory to memory access), and in particular running RPC requests “in both directions” (client to server – called forward direction – and callbacks from server to client called reverse direction). The RFC claims to describe current practice rather than to prescribe future practice, but it is intended to be Standards track, which is a little odd, but I guess documenting what is current practice and standardizing on it for the future is fine.
> 
>  
> 
> In any case, RDMA is a high performance protected channel considered to be secure by its nature. If an RDMA protocol were run over a network tunnel, it would be the responsibility of the tunnel to implement authentication and encryption. And access rights of particular nodes and/or users is defined in higher layers of NFS, and so is unaffected by the fact that this is running over RDMA.
> 
>  
> 
> Bottom line is there are no security considerations. The security considerations section refers readers to RFC5666bis (which is about NFS over RDMA generally rather than the specific issue of callbacks). This seems appropriate.
> 
> 
> 
> If I were to make one comment it's that I don't like the terminology "backwards".  I might have used "reverse".  "Backwards" has a somewhat negative connotation, and it's slightly confusing when discussing "Backward Credits".  I'd think a "backwards credit" would be taking away credits from someone.  "Reverse credits" would be just as bad, but perhaps "reverse-direction credits" might be clear.

At first blush, this suggestion seems like an improvement to me. I'll need to
revisit the document to ensure that "reverse" and "reverse-direction" do not
introduce any specific issues. I'll consider this change for the next revision
if I don't hear objections.


--
Chuck Lever