[nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07
spencer shepler <spencer.shepler@gmail.com> Mon, 28 October 2019 06:50 UTC
Return-Path: <spencer.shepler@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 20AF212016E for <nfsv4@ietfa.amsl.com>; Sun, 27 Oct 2019 23:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_PASS=-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 yZPTxdr85rNx for <nfsv4@ietfa.amsl.com>; Sun, 27 Oct 2019 23:50:27 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 D137A12004F for <nfsv4@ietf.org>; Sun, 27 Oct 2019 23:50:26 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id u22so10014076lji.7 for <nfsv4@ietf.org>; Sun, 27 Oct 2019 23:50:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XyrZRYpeBnZzre1rcOtMSoHTMMKS75AXwGeRpbNk7JY=; b=pGKRE/2bAa/0O7SiKlI5LoNXmvEb1/XN/4Pq+u42pDLh1ViuAVNz0c0IONfSkXssLL b92NUtexAMmtBNM3TTTsjB9MuAiSWgZnYthrusXL4yCdF9DU8Xb0Xm5lALAlbUjJEqnZ OjpDnzU/ft8iw4sTXuMFaQyVMf4F7e1qh7mYVPBaGXPvl+aNIkMhlguwCO7pZFFqC0Au DVijMUt+9UPjTrAEr2JD+rMew1fcVTlO9z2bvvR1q4K7pouEYAYe1h+gmvQX3lhPiuK3 mtZe0q7RdBRehTkWYGDHcDtFoEUSXZaWvCm+oICNshK8eEnWXrbcdNk9wI9wj3TKSjW4 hMVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XyrZRYpeBnZzre1rcOtMSoHTMMKS75AXwGeRpbNk7JY=; b=gG0bBbG/GnLg5or+vCumaVU+SXRWM6GzXPd3g/miy0G8mzmDKDhmNIvzAtOFteRD55 5EqP4dYkVUUFLkJYcbUl4RTjayR5SDl35tg/2pBtci35B5oZNLOgYz4Y7OuulRXE5X/N mbBLKF5vu1QRVdNSbpRBUBTawVn2RSPZow14NmgFV7boTjzU6MAdwj2/mkNOXiW1uVia HJd4LuOMR1qx8+L3nYzkD/ePns/Gddx/LdXbTZq4urBq4QLPH4Ez6xqQ2CyagdkLIX1m KIOdFYuL4QXjjy5rK8TBgXRFz9ULBd5p+ZuxVKoQaGNsmaj4Z8uAYZFURjipsM/GUEvU U91A==
X-Gm-Message-State: APjAAAV06cSs324Q4QfRARHF17XCpriTGlXZp9GYSfJSje5Qp+LsVGhl Xq9Up7j9VgZ0DyeqTB84qySjolqwErvZ8hrOq+J9yrX5
X-Google-Smtp-Source: APXvYqzskufCMn9IYwbgTLls4yQNw7BmaUroTA+0UG4FoO4Ud3c7q2sUi6g4ucM/cnTbLBm+wDepyzKzW/KOMkK1cu0=
X-Received: by 2002:a05:651c:1024:: with SMTP id w4mr8541207ljm.206.1572245424556; Sun, 27 Oct 2019 23:50:24 -0700 (PDT)
MIME-Version: 1.0
From: spencer shepler <spencer.shepler@gmail.com>
Date: Sun, 27 Oct 2019 23:50:17 -0700
Message-ID: <CAFt6BakApq=FJWs+r-jwxvTdXYs9yOg9KS47no93kdnp2gZ_+Q@mail.gmail.com>
To: NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000007cfb90595f2ea67"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/E0ikUqQD7C1y7MsjfOlkOlAu0Ok>
Subject: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 28 Oct 2019 06:50:29 -0000
Feedback and comments on the draft “Integrity Measurement for Network File System version 4” - draft-ietf-nfsv4-integrity-measurement-07. Note that these comments are personal contribution and do not reflect my position as working group co-chair. In short, I am opposed to moving this draft to last call in its current state. Generally, the draft describes the Linux implementation of a feature that is to be extended via NFS. However, the description provided is insufficient for interoperable implementations to be achieved. There are two options, in my opinion, to moving this document forward: 1) Limit the description to the addition of the new, opaque attribute and corresponding errors that can be returned as a result of the interpretation of that attribute. 2) Fully define the contents of the new attribute such that independent implementations can be achieved. This would include, but is not limited to, the open definition of the content of the new attribute and the procedures associated with defining new content and interpretation thereof. If option 1) were chosen, I would still be of the opinion that the draft should not move forward since it would present another barrier to open, interoperable implementations. Note that I am also doubtful of the use case being presented. Using NFS to directly store and supply application executables seems to be in rapid decline or has already fallen out of use. Given the rise of virtualization and the hosting of virtual disks on NFS along with the rise of containers and distribution thereof, application distribution seems to be a thing of the past with respect to their store/retrieval from NFS mounts. If the effort was more focused on more traditional data integrity from source to consumption, that would be a more interesting use case. With the rise of large scale data center usage of NFS (e.g. cloud computing) where customers expect data integrity or the identification of failure, the scale of cloud computing presents many opportunities for the loss of data integrity and NFS (and the client and server implementations thereof) do nothing to ensure data integrity. The draft does mention spot fixes of data-at-rest methods, and in-transit methods, but there are many points that present areas of potential failure, and these are ignored in today’s implementations (at least to this commenter's knowledge). Spencer
- [nfsv4] Comments on draft-ietf-nfsv4-integrity-me… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Craig Everhart
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Benjamin Kaduk
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… spencer shepler
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Benjamin Kaduk
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… David Noveck
- Re: [nfsv4] Comments on draft-ietf-nfsv4-integrit… Chuck Lever