Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07
Chuck Lever <chuck.lever@oracle.com> Mon, 28 October 2019 18:39 UTC
Return-Path: <chuck.lever@oracle.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 ED1641208E0 for <nfsv4@ietfa.amsl.com>; Mon, 28 Oct 2019 11:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 d_jIAsZNwkwc for <nfsv4@ietfa.amsl.com>; Mon, 28 Oct 2019 11:39:31 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6D31208DE for <nfsv4@ietf.org>; Mon, 28 Oct 2019 11:39:31 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9SINcT9164897; Mon, 28 Oct 2019 18:39:30 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=m/FxfqMXdkeLYk4fxi7OPo3nUH8ZFHyUuN19XDvTf4g=; b=M6DdLSQRZ/V2mZhmN8w2pgnurW5RY5fKfZOOL4P20kLlSTna2mi3z6x0/EyRWIkQl/rj sUNjL2k46O8iQRFhsMQkXa1QMvpKagkAt4wNFkthGUX/xjsRfkPZsJjKoFNX3+dEyyiL fY48979MlHtNfcpFCc5hAPhrc3RbhT/glewlSJg/g/Kav1erhp1HcgHu8N2oUDYByMqa VWCaiI9TFYJleK9U/Z81qz0i+qJgdrExsv6PNB7G80/NzSXjoznd3kFsnXWv1NWi5igF Y7nLEElSH5sshCoFwhkUd/5Yfp5UW6/0Xx6NxI3Gk/Sm3OmggCLe++ld9SPaNg+b7Pz+ YA==
Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 2vvdju42cu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Oct 2019 18:39:30 +0000
Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9SIOE1W100939; Mon, 28 Oct 2019 18:39:29 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2vw09g8h0c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Oct 2019 18:39:29 +0000
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x9SIdSKs014195; Mon, 28 Oct 2019 18:39:28 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Oct 2019 11:39:28 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CAFt6Ba=q=vSt+wtcHsi59gWnwFpuUaDqQue7f=GFSUvd25uV+g@mail.gmail.com>
Date: Mon, 28 Oct 2019 14:39:27 -0400
Cc: NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BFDF314F-B913-4C4A-BAB4-C09FA840F4F6@oracle.com>
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>
To: spencer shepler <spencer.shepler@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9424 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910280177
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9424 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910280177
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/02riScYyi79wAWwlHC8zrAkxO60>
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 18:39:41 -0000
> On Oct 28, 2019, at 12:36 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. I don't understand the "if" clause. The NFS implementations do not interpret this metadata _ever_. The metadata can be interpreted on a server host by a private security module. But that is separate from the NFS server implementation itself. The NFS implementation on the server does not interpret this metadata. I'm defining a transport for the metadata, and nothing more. > 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. How about "Transport and Storage of Linux Integrity Metadata for Network File System 4" ? > 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. An NFS server is merely a vessel for integrity metadata. If the server happens to have an integrity appraisal module, then that module will process the metadata. The NFS server implementation itself does not parse this metadata. > > 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. There is no open definition of this metadata other than the implementation in Linux and the wiki that describes how to use it. In other words, IMA is an application that uses NFS (or any other file system) to store its data. > 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. It is opaque, period. There is not enough information in this document to implement appraisal, and that's on purpose. The document is meant to define a transport mechanism only. > > 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. That's exactly what this mechanism is supposed to achieve. The metadata is a signed hash of the file's content. It is not interpreted and should remain unaltered from the point the content is created to the point where it is used. There, an independent mechanism appraises the content and the metadata to see if any alteration has occurred since the hash was signed. Appraisal is done at the point when file content is about to be used. With NFS, most frequently that would be on an NFS client system. That does not mean the NFS client implementation itself does the appraisal. The focus here is on read-mostly data (software distribution) because of the high overhead of re-signing the file content hash in a secure fashion. The key material is stored in TCMs. Suppose an OS implementer wants to implement something that interoperates with Linux's IMA. It is up to that implementer to approach the Linux IMA community and get them to provide this information. Does anyone have suggestions as to where the Linux IMA community should go to publish a standard describing the integrity metadata format? Maybe the Trusted Computing Group ? Somewhere else? Would it make sense to make up our own integrity metadata format just for NFS? Or, perhaps we leave this explicitly to storage vendors to enable them to innovate. As the generation and appraisal of this metadata occurs outside of the filesystem, it is possible to provide plug-ins that handle this. > 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. The discussion in the room during IETF 105 suggested there was interest enough to move this document forward to publication. I thought this whole issue had been resolved at that time, as the conversation finished with an understanding that this was opaque metadata and that the next step was WGLC. Of the two options, IMO option 1 is the only sensible one because there is no citable specification of what goes in the metadata. However you've stated you will object if I take option 1. I don't have any strong sense of how to move this forward. Is there an appropriate opportunity for a design phone call to work all this out? -- Chuck Lever
- [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