Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-11
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 08 August 2017 19:29 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF761323C6; Tue, 8 Aug 2017 12:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6NtEz2ihCJX2; Tue, 8 Aug 2017 12:29:50 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660DC13295A; Tue, 8 Aug 2017 12:28:58 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id l82so27510918ywc.2; Tue, 08 Aug 2017 12:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CE4QZtkJbBOfppaFtrmbgpPbD2H/OCDsZDNGPTEXdzM=; b=MkG3Qxq4iICliW6GVLat+Yp+rhHqVnRB+ATgoLjCn4wZZb/ak2O5zA4kqoZbxI1AZ1 VRmn2OTGS+c3DdJLnnU4yXkhPKqgg0I/eQNDSFTCR/Hr/9S3D5oJWPVKuVrtcU/hmmSG OHOZzPimhuh4hp/WKAwWk6LkD8e/Czn+BsIx6uzrSgPAgVcwc9R6E7adcX2zJ96v9Lu/ GsM4nIq7KXCNC+LTp9nQLT/oAkugNxMIORiE6eDRHZ86tRGChMsYiXqodNVAYJ9z6GDq 6p2yDlARcVZwJvY5EaIzythSh/+MIOXU0E8YdYW0PxceY6FlitR/io3S/AHKMq8BbA7a AKEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CE4QZtkJbBOfppaFtrmbgpPbD2H/OCDsZDNGPTEXdzM=; b=HIu9dccZ+FFdM66zJPQBnDyoCr0wTrtUAFk2EayLEY+/gOBtAdhPL7Ed+p0xMK1ios jVKLTsIZEjk1McjkPgFZqrz7HX3NgbYdkJECBPvbo4VHJVYIg9SHJm6Ke4mDd6TESZGI Hlw+5X6bJi0cT08CI5m/IOlVcySH97Tn+d2FDnkNlkaeWOTfv89BS7FNE4Zh+IfZ8o/p MvC/YrP0AeQJ6+0iQnI5P5n8l5vzp0Nz1tZKtV5+MHQpTarc+7tBYWfN+V9peVRA1eHK s96TTmLEd+uHgQeUEhhKPc/LGQWYxfVuEc0Lx4/peBQ7C1apyGs36jscFCARDACbA/rr mfPQ==
X-Gm-Message-State: AHYfb5gVUIBNsc6m067uQgsoBIfqoYcs4WWnx8Ygp8uS9Xwbnb1e8Wk0 nXV+mLPN5+i/7ddj3TCR1ovOUCgjQkpQ
X-Received: by 10.13.210.67 with SMTP id u64mr4604949ywd.218.1502220537514; Tue, 08 Aug 2017 12:28:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.52.79 with HTTP; Tue, 8 Aug 2017 12:28:57 -0700 (PDT)
In-Reply-To: <CAKKJt-fbpBjz9=z8RqSGseKZxCY3e=rb6TsBZCEmNtPxKe0sdw@mail.gmail.com>
References: <CAKKJt-fFFyxV=VhJxhe=3P283xZQG_yvdP6AHJkzU6iB=74JCw@mail.gmail.com> <C6965A7A-3A9F-466B-AEB7-73A8C96F3A9D@oracle.com> <CAKKJt-fbpBjz9=z8RqSGseKZxCY3e=rb6TsBZCEmNtPxKe0sdw@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 08 Aug 2017 14:28:57 -0500
Message-ID: <CAKKJt-foDqkhh_Q-pZT2Jqzfm8dCeBbtiRcarHJXtvMPykQFiw@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: draft-ietf-nfsv4-rfc5667bis@ietf.org, nfsv4-chairs@ietf.org, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a114e7e3083564a055642f9dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/oazZCBXTy86RN0VKEfNC0RU_0jc>
Subject: Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-11
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 19:29:53 -0000
Hi, Chuck, On Mon, Aug 7, 2017 at 6:05 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Chuck, > > Thanks for the quick response. Getting back with an AD who hasn't slept > since he sent his evaluation is ALWAYS appreciated. > > Responses inline, but Tl;Dr is "this all looks excellent". > I see that you've submitted a -12, and I think it's ready for Last Call. You had mentioned wanting to think about the Security Considerations a bit more, so I thought a bit more, too. Here's what I'm wondering. The current text says this: 8 <https://tools.ietf.org/html/draft-ietf-nfsv4-rfc5667bis-12#section-8>. Security Considerations RPC-over-RDMA version 1 supports all RPC security models, including RPCSEC_GSS security and transport-level security [RFC7861 <https://tools.ietf.org/html/rfc7861>]. The choice of what Direct Data Placement mechanism to convey RPC argument and results does not affect this, since it changes only the method of data transfer. Specifically, the requirements of [RFC8166 <https://tools.ietf.org/html/rfc8166>] ensure that this choice does not introduce new vulnerabilities. Because this document defines only the binding of the NFS protocols atop [RFC8166 <https://tools.ietf.org/html/rfc8166>], all relevant security considerations are therefore to be described at that layer. What I think you're saying, is that the RPC security considerations have already been analyzed in RFC 7861, and the RDMA security considerations have already been analyzed in RFC 8166, so using RPC over RDMA shouldn't introduce new security considerations. Am I getting that right? Assuming so ... the sentence I was questioning, was Specifically, the requirements of [RFC8166 <https://tools.ietf.org/html/rfc8166>] ensure that this choice does not introduce new vulnerabilities. Although I'm not a secdir reviewer (I don't even play one on the Internet), I'm reading that sentence as an invitation to go look at the requirements of [RFC8166] and see if that makes sense. Other reviewers might or might not accept that invitation, but I find myself wondering whether you need this sentence at all, since you've basically said, "we've analyzed the pizza crust, and we've analyzed the pizza ingredients, so we don't have new problems when we put the ingredients on the crust and make a pizza". Do you think the working group needs to think about this some more? I'm happy to hold off on Last Call, if the answer is "yes", of course. Thanks, Spencer (D)
- [nfsv4] AD review of draft-ietf-nfsv4-rfc5667bis-… Spencer Dawkins at IETF
- Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667… Chuck Lever
- Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667… Spencer Dawkins at IETF
- Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667… Spencer Dawkins at IETF
- Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667… Chuck Lever
- Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667… David Noveck
- Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667… Spencer Dawkins at IETF
- Re: [nfsv4] AD review of draft-ietf-nfsv4-rfc5667… Chuck Lever