Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)

Spencer Dawkins at IETF <> Wed, 11 April 2018 14:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 21CF31201FA; Wed, 11 Apr 2018 07:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hLWFHoMMMJuc; Wed, 11 Apr 2018 07:14:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BF010120726; Wed, 11 Apr 2018 07:14:57 -0700 (PDT)
Received: by with SMTP id t8-v6so650270ybo.9; Wed, 11 Apr 2018 07:14:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XjY6Uh+PL3BwRBaaecGrqEAtF4Qiy/iK7B3It6ZtXME=; b=JQJmh8Xn+bl5zkwuOK76L31i0IJCpZDACuDsWAMpqMlvhKbR7Ckdkj0qbEdUd1Ek0d M54s8ES2Cd50kh4yvGwi7lEKKejg0XfTrBKp4udAgyQxH01+0QeMQaFDqnJlxlUftBlO 9rbl+5Tschnv617VW6or3braKzUmG4zxnX8RKogVYsL5ewt76OorY12W3GMpedt0sRqR 3c9m9s3FH9denXAhlP5I/TE8qac423mYgrTGS3XdcciPAunurulQgkuNOGK9iJe0dHPe nUVXu+FkiYQUQo4E4MOLtwHjhw64r8YOfBTDpycrQAbyONv44/fpZ5mE4B75ak7Bfwz0 KZJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XjY6Uh+PL3BwRBaaecGrqEAtF4Qiy/iK7B3It6ZtXME=; b=ewIGKG2sUjaAwurciNpGf4OPzimLgxp/140+YgNR3ORnx/RxVtA9U3Wk9W1/TFlAhS aRn4DmG56Da3kgTF2C2C1LTw/alBhPfgXO9s23qDEU8m1Efg7+IXb0M25N2qsHQfNufP Pk24FXAYqMz48ySWqW14TSdm6kRXBT+5x1Te6GXFW4ETO3cunblsT2INhB95jHwFTWQK UXi+xcP1ljJDG6ITep2iwj4faxiVI3nHWLYrNrVlDDE4XmV2WwdzqIdRZ+l8YxKTZCP/ n34FeUqSD6AdYsK5CJuv0aWEChIq+bsfi5m1+na9K1zXiyF6bf+ENgabJxlFl4Vxw1ak Q7Hw==
X-Gm-Message-State: ALQs6tAkDDx57uKzjTiNEL+r+UFwTQHDvHw8yCM7VUJ+JL6x+sqDiQvX IBfbNiral00ylHcXbeTxvbuZ8NkywnnA21ZrGVI=
X-Google-Smtp-Source: AIpwx48j9dsOLPnAPqcTFZJS+q83YS1jADy5edTZUWtagT3/AG7cZAfhZEq4ga7Q3WdoF2m+4QcrBiIy4cs36eARxss=
X-Received: by 2002:a25:6a46:: with SMTP id f67-v6mr2278083ybc.235.1523456096402; Wed, 11 Apr 2018 07:14:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:7cc1:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 07:14:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Spencer Dawkins at IETF <>
Date: Wed, 11 Apr 2018 09:14:55 -0500
Message-ID: <>
Cc: Eric Rescorla <>, The IESG <>, NFSv4 <>,, Thomas Haynes <>
Content-Type: multipart/alternative; boundary="0000000000007502e305699343af"
Archived-At: <>
Subject: Re: [nfsv4] Eric Rescorla's Discuss on draft-ietf-nfsv4-flex-files-15: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Apr 2018 14:15:02 -0000

Hi, Dear Authors,

On Tue, Apr 10, 2018 at 11:20 PM, Thomas Haynes <> wrote:

> Hi Eric,
> You are asking good questions, they illustrate how the community is too
> close to
> the problem.

That can happen with NFSv4, through no fault of that community!

In the fourth paragraph of Section 15, there is the recommended case:
>    The combination of file handle, synthetic uid, and gid in the layout
>    are the way that the metadata server enforces access control to the
>    data server.  The directory namespace on the storage device SHOULD
>    only be accessible to the metadata server and not the clients.
> ….
> In that context, the client has no access to the storage device’s
> namespace,
> and as such, cannot easily do a READDIR or LOOKUP for traversing.
> It can snoop the file handles going to the storage device, but unlike a
> normal server, the credentials can change underneath the client. I.e.,
> they are not controlled by an app, but by the metadata server.
> If we allow access to the directory namespace, as suggested by paragraph 5:
>    If the configuration of the storage device is such that clients can
>    access the directory namespace, then the access control degrades to
>    that of a typical NFS server with exports with a security flavor of
>    AUTH_SYS.  Any client which is allowed access can forge credentials
>    to access any data file.  The caveat is that the rogue client might
>    have no knowledge of the data file's type or position in the metadata
>    directory namespace.
> then we “degrade” the security back to that faced by a normal server.
> The point isn’t that flex file is more secure, but that by taking care of
> how exports are managed on the storage devices, admins can do a bit
> better than awful.
> Hope this explains it.

When I see authors explaining something about existing text (in any
document), I usually think that it would be helpful to propose text that
would provide the same insights to future readers. At a minimum, that's
what Eric would be looking at, in considering his ballot position, rather
than email threads that other readers wouldn't have access to.

Do you folks know what such proposed text would look like?

And thanks to all involved, in moving this conversation forward.

Spencer (D)

> Thanks,
> Tom
> On Apr 10, 2018, at 5:53 PM, Eric Rescorla <> wrote:
> On Tue, Apr 10, 2018 at 5:02 PM, Tom Haynes <> wrote:
>> No, it does not have better security than typical NFS, it has the same
>> security.
> OK, then I'm confused about "degrades to"  Can you help me with that?
>> The synthetic IDs control access to the files and the metadata server can
>> modify them to fence off a rogue client*, but in the end, the security of
>> any
>> AUTH_SYS approach is limited.
>> * By rogue client I do not mean malicious, I mean one which had
>> established
>> a connection with the metadata server, was handed a layout, and then when
>> the layout was recalled, took over 91s to return that layout. It is
>> probable that
>> there is a network partition between the client and the metadata server
>> and
>> it is unknown if there is one between the client and the storage device.
>> The
>> fencing act causes the client to become aware that it needs to once again
>> reach out to the metadata server.
>> The security aspect of this version of the flex file layout type is to be
>> as secure
>> as any other NFS in a data center environment.
>> The goal of the next version of the flex file layout type is to be as
>> secure
>> as any other NFS in the WAN. I.e., kerberized connections.
>> On Apr 10, 2018, at 4:25 PM, Eric Rescorla <> wrote:
>> Not entirely. I'm inferring from the following text that this draft is
>> supposed to have somewhat better security than typical NFS, but it's
>> not really clear.
>>    If the configuration of the storage device is such that clients can
>>    access the directory namespace, then the access control degrades to
>>    that of a typical NFS server with exports with a security flavor of
>>    AUTH_SYS.
>> On Tue, Apr 10, 2018 at 11:43 AM, Spencer Dawkins at IETF <
>>> wrote:
>>> Hi, Eric,
>>> On Mon, Apr 2, 2018 at 2:56 PM, Tom Haynes <> wrote:
>>>> Hi Eric,
>>>> Kathleen has removed her “discuss” from this document (the new version
>>>> was pushed,
>>>> which satisfied her need for the SecDir review.
>>>> Could you please revisit your position on this draft?
>>> I'm just following up on this one - could you take a look at whether -17
>>> addresses your Discuss position?
>>> Thanks,
>>> Spencer
>>> (diff from telechat version is
>>> iff?url1=draft-ietf-nfsv4-flex-files-15.txt&url2=draft-ietf-
>>> nfsv4-flex-files-17.txt)