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)