Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07
David Noveck <davenoveck@gmail.com> Mon, 28 October 2019 17:14 UTC
Return-Path: <davenoveck@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 EEB541208EF for <nfsv4@ietfa.amsl.com>; Mon, 28 Oct 2019 10:14:55 -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 124J-Yg8oKwF for <nfsv4@ietfa.amsl.com>; Mon, 28 Oct 2019 10:14:52 -0700 (PDT)
Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 4E76812087B for <nfsv4@ietf.org>; Mon, 28 Oct 2019 10:14:52 -0700 (PDT)
Received: by mail-oi1-x231.google.com with SMTP id g81so6524597oib.8 for <nfsv4@ietf.org>; Mon, 28 Oct 2019 10:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ce1gn/+rSL7O8/nW1FvXMQmuTkFERxhqAQOlIH8fUoI=; b=BLnhUO9u+ULVzLtRzvVRTv91YfnnmAlkx3Bc1KyzZIDiETYDCtNXBq1FLCOSkgOHOy zXX5hfXw7c6p5GjwPLUKKN/j3gvAd/Y+jPDZbQHcvG5QnMISZ1vqt9hTFXaBbv7PpQOb 9GXmMDf/u7PpFVxaYsGl9yFmMjPIObPjlizd6aCl2iGZo+lA8TsjgN6jxj6/7n4Ekvmq RwkPr77NnZCPCrIZP30rFijpGR+NLGqYV2/rWreXNwZVt9rbHgep1e78VM75TaS1GWa0 ShQqnz4xp96BU0BIUGV6JV9Mms4iSen+3rvrMODx1g/bvleZL/tY8rMSLstIdkBZe9Ng mmOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ce1gn/+rSL7O8/nW1FvXMQmuTkFERxhqAQOlIH8fUoI=; b=O5GNNCq1TIeDynO+0q0pWojykodQQkru+IsorbrJeWYw+QSQol3pK3J8WTBCGsu1uf dBMrktqo528goa7rRv8vghgHoc9a4kd8TYX5d5LLoVt35giSz5U7cMot5jBSdTWYyJY+ saKSRC2f9RLilPllsw208EeteBwL8KTiFd2uhMzf58dOD9uVyQjQp7in0YIRsFYWhA6V X+kJ3GiZEJDAwhelW2OBrCbvo1XP3IipKL0v0rg5fPZuSy6rIdAU3fEP1L2Vtv1RnwiN sEFC2RY4nmn8sJPAgMAews4Dsw4yqQm9/1ERD4dh4oQS9FG4p60UGI704irsaK/RXIVw C5gw==
X-Gm-Message-State: APjAAAXbCmlRYsm2kuTE1GGuqTzpY3vr3n4h3Yi7S5VyafRDFIKo8gPr VDeIkjElhW0BJcq1UIzB1wFYxQPcgz6dP0dsn0Y=
X-Google-Smtp-Source: APXvYqxQWPT3L29dhA4EtnqoJ2JKX//r0c+IWmFVpBvLyABpXyGgyeLulT+U35KWitjCz3LB/gjS08Cjs6npgCnpbUk=
X-Received: by 2002:aca:281a:: with SMTP id 26mr294801oix.82.1572282891298; Mon, 28 Oct 2019 10:14:51 -0700 (PDT)
MIME-Version: 1.0
References: <CAFt6BakApq=FJWs+r-jwxvTdXYs9yOg9KS47no93kdnp2gZ_+Q@mail.gmail.com> <9BEBDE7A-522A-4A6B-8132-D9C3A8A4922C@oracle.com> <CAFt6Ba=q=vSt+wtcHsi59gWnwFpuUaDqQue7f=GFSUvd25uV+g@mail.gmail.com>
In-Reply-To: <CAFt6Ba=q=vSt+wtcHsi59gWnwFpuUaDqQue7f=GFSUvd25uV+g@mail.gmail.com>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 28 Oct 2019 13:14:40 -0400
Message-ID: <CADaq8jdA=4-r1-TQm=0YDp4JSYGc1T1JRdEbZh-HPUKFjpKxpA@mail.gmail.com>
To: spencer shepler <spencer.shepler@gmail.com>
Cc: Chuck Lever <chuck.lever@oracle.com>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000038ee470595fba398"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/pkkPLcQ69hUbkh0R37bFLbevO3c>
Subject: Re: [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 17:15:06 -0000
>To the statement of the server implementation, the document refers to the server's ability to check the file content. > This to me meant that there was a client / server interoperability issue at hand. I note that the server is not > required to implement the capability but if it is possible, then it should be well defined. Agree. > This is the question of client interoperability. If two separate client implementations to follow the "IMA standard for > Linux", then there should be an open definition of what that standard is in my opinion. And I do mean the ability > to implement with clarity about how and what implications there are for any intellectual property that exists. Right. This is why "just look at the (open) source" is not a solution. I'm not sure of the exact legalities but feel that some people might justifiably feel that doing so exposes them to the possibility of viral infection. I think this is the issue that Craig's suggestion would address. On Mon, Oct 28, 2019 at 12:37 PM spencer shepler <spencer.shepler@gmail.com> wrote: > > Chuck, > > inline for comments. > > On Mon, Oct 28, 2019 at 8:00 AM Chuck Lever <chuck.lever@oracle.com> > wrote: > >> Hi Spencer, thanks for taking time to review this document. Responses >> to individual comments are below. >> >> >> > On Oct 28, 2019, at 2:50 AM, spencer shepler <spencer.shepler@gmail.com> >> wrote: >> > >> > >> > 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. >> >> Issues about interoperation have already been raised and addressed >> multiple times both on the mailing list and in presentations at IETF >> meetings. The metadata stored in this attribute is opaque to the NFS >> protocol and implementations, just like file data is opaque. >> >> The metadata is not created by the NFS implementation; it is created >> by a user space tool. It is not interpreted by the NFS implementation; >> it is interpreted by a separate privileged security module. >> >> NetApp, for instance, could create a fully interoperating implementation >> today, based solely on this document, simply by enabling clients to store >> and retrieve this attribute. There is no more to it than that. >> >> NFS, in this case, is used as a transport. It is an intermediary. There's >> no reason it needs to interpret the metadata. It's only job is to ensure >> that data and metadata is not maliciously or accidentally altered. >> > > If the attribute is truly opaque to one implementation, then state it > clearly. > If this is an attribute that is in support of the Linux method of > operation and only ever intended to be such, then retitle the document to > make that clear and remove the extraneous content of the document. This > will make it clear to the reviewer what the intent is. > > To the statement of the server implementation, the document refers to the > server's ability to check the file content. This to me meant that there > was a client / server interoperability issue at hand. I note that the > server is not required to implement the capability but if it is possible, > then it should be well defined. > > >> >> >> > 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. >> >> "To move this document forward, pick option 1 or 2. But if you pick option >> 1, I will still object." >> >> That means there is really only one option in your opinion. I have >> repeatedly >> stated why option 2 is not practical or necessary. The nfsv4 working group >> and the IETF does not want to be the bearer of the IMA standard for Linux. >> >> Further, there is no need for it do so, because the metadata stored in >> this >> attribute is opaque to the NFS protocol and to NFS implementations. >> >> "Barrier to open implementations." The Linux implementation is open >> source. >> It would certainly be possible to port the Linux implementation, or with a >> little more work, provide a clean-room implementation. In an era in which >> open source dominates, "open" no longer means just that there is an open >> standard. Maybe "open" is not what you actually meant here. >> > > This is the question of client interoperability. If two separate client > implementations to follow the "IMA standard for Linux", then there should > be an open definition of what that standard is in my opinion. And I do > mean the ability to implement with clarity about how and what implications > there are for any intellectual property that exists. > > >> >> Seems to me that rejecting a protocol mechanism that enables the use of a >> data format with an open source implementation but no published standard >> is >> also a barrier to open implementations. >> > > I am asking for clarity. Either the attribute is opaque and that is clear > to everyone or there is enough information to create interoperable > implementations as mentioned above. > > >> >> >> > 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. >> >> Do you have evidence that this change is taking place? Sharing the same >> application executable on NFS seems pretty common in Oracle deployments. >> >> Do you believe IMA is not also useful for the read-only virtual disk use >> case? >> >> One reason that virtual disks are used is /because/ NFS does not support >> things like xattrs, capabilities, and integrity metadata. Otherwise, >> maintaining guest root filesystems on NFS would be a popular solution. >> >> How about protection of other types of read-mostly data like configuration >> files? > > >> >> > 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). >> >> There is no claim made in the document that this mechanism closes all >> integrity exposures. Can you identify particular areas that need to be >> addressed by this mechanism but are not? Do you have specific alternative >> proposals? >> > > My comment was not meant to offer an alternative solution to the > document's proposal but rather to suggest that there are other areas of > "integrity" that could be addressed that would result in utility. If the > working group finds the area interesting, this may be a potential path. > > Spencer > > >> >> >> -- >> Chuck Lever >> >> >> >> _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 >
- [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