Re: [nfsv4] Comments on draft-ietf-nfsv4-integrity-measurement-07

Chuck Lever <chuck.lever@oracle.com> Tue, 29 October 2019 15:33 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 1210A12085A for <nfsv4@ietfa.amsl.com>; Tue, 29 Oct 2019 08:33:27 -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 2s1YyybXu68J for <nfsv4@ietfa.amsl.com>; Tue, 29 Oct 2019 08:33:24 -0700 (PDT)
Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 D3D7B120862 for <nfsv4@ietf.org>; Tue, 29 Oct 2019 08:33:24 -0700 (PDT)
Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9TFOxOq196305; Tue, 29 Oct 2019 15:33:23 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=lXcsYFgJXbqiCzEbbKM2hysaSVlAiq6a+AzrTGT+yL8=; b=AAxZxD69Nr8iJKpHqZZ02EeL9RlVpWBEmq8UrxHHNWqN3OXslZYXEPeE8tJkoqvjZceR 2a4aS0vJ39VvTkr76mIuFZtGbK3HYY3A+ZdnhYJjPD8Prwt34/C8tE4y5l6qIwJEEzk5 gBc4ULdwVphG2gQJmkNMUEAws5y8n3N7q8l8nuN/WmaJO03RgzAZaic1EvBJgYPK6JXm y639B8RtQwsswa5VAehMVTbt1JtyQLXxMG/o/zHRANKxu2j6dgW3tejMzW4tIGJQ0aqC 51KuoFuOHtaynzEZBrCbiCb3Lac5rnrjsiI96OQ1m3j/8U/PMzFkxXzelgLYv/sbN/ZH LQ==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2vvumfewr1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Oct 2019 15:33:22 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9TFO9gq084768; Tue, 29 Oct 2019 15:33:22 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2vxpfd71hg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Oct 2019 15:33:21 +0000
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x9TFXKg5009356; Tue, 29 Oct 2019 15:33:20 GMT
Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2019 08:33:20 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CAFt6BanwC4uu=9SpZQdiGjFswzkC3cSWPzGia34qBT5W+uuMNw@mail.gmail.com>
Date: Tue, 29 Oct 2019 11:33:18 -0400
Cc: David Noveck <davenoveck@gmail.com>, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B51BB44-F39D-4EF6-9E1E-3EF958F90260@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> <BFDF314F-B913-4C4A-BAB4-C09FA840F4F6@oracle.com> <CADaq8jc_gM0SWe9weRJYp7s7xjtN9kihbVnUiBN61hF2LUJjzQ@mail.gmail.com> <FD12C92F-BBF4-4174-B896-48738C02B78E@oracle.com> <CAFt6BanwC4uu=9SpZQdiGjFswzkC3cSWPzGia34qBT5W+uuMNw@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-1910290143
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-1910290143
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/cf56uWAEvDRlddTSlCVD7Uc-43M>
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: Tue, 29 Oct 2019 15:33:29 -0000


> On Oct 29, 2019, at 2:15 AM, spencer shepler <spencer.shepler@gmail.com> wrote:
>> 
>> 
>> 
>> On Mon, Oct 28, 2019 at 1:05 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>> 
>> 
>> > On Oct 28, 2019, at 3:28 PM, David Noveck <davenoveck@gmail.com> wrote:
>> > 
>> > > 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.
>> > 
>> > Perhaps not but the fact is that if you want to have a client implementation
>> > you need to know the formal so that appraisal can be done correctly.   The
>> > fact that this is not within the Linucx Client as you would describe it is to me
>> > a distinction without a difference.
>> > 
>> > > 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.
>> > 
>> > That is the problem that people are concerned about.   I think some people
>> > want one now  and I can see their point although I don't have any need for this
>> > data.
>> 
>> That's my problem with the request: no-one here has a real need
>> for this metadata format except for Linux, where it is already
>> implemented.
>> 
>> The only fresh real-world need is to be able to store and transport
>> this metadata on behalf of OS implementations that can generate and
>> interpret it.
>> 
>> Thus the additional request for a specific format definition seems
>> specious to me.
>> 
>> 
>> > > 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?
>> > 
>> > I have no suggestions in this regard but am sure that if the Linux IMA community
>> > were willing to do this it could find some place suitable.
>> > 
>> > > Would it make sense to make up our own integrity metadata format just
>> > > for NFS? 
>> > 
>> > No.
>> > 
>> > > Or, perhaps we leave this explicitly to storage vendors to enable
>> > > them to innovate. 
>> > 
>> > I don't see much much interest in that.
>> > 
>> > > As the generation and appraisal of this metadata occurs
>> > > outside of the filesystem, it is possible to provide plug-ins that handle
>> > > this.
>> > 
>> > But to interoperate successfully everybody's plug-in would have to implement the
>> > same format.   That's why a specification of that format is needed to provide 
>> > interoperability.
>> > 
>> > > The discussion in the room during IETF 105 suggested there was interest
>> > > enough to move this document forward to publication. 
>> > 
>> > There was and there still is.
>> > 
>> > > I thought this
>> > > whole issue had been resolved at that time, as the conversation finished
>> > > with an understanding that this was opaque metadata 
>> > 
>> > It did but apparently there were people not present who now feel that it cannot
>> > be treated as totally opaque and needs to be documented. 
>> > 
>> > > the next step was WGLC.
>> > 
>> > I still think it should be.   However, during WGLC, objections  will 
>> > inevitably be offered to the lack of a specfication of the integrity 
>> > metadata fomat.
>> 
>> If the document is clear that this is a transport protocol, and treats
>> the metadata as opaque, they should have the same reaction as others
>> did during our conversation at IETF 105: that this is perfectly
>> reasonable for a transport protocol.
>> 
>> 
>> > While I don't need this and would prefer that 
>> > this go forward even without it, I don't feel that these objections 
>> > can simply be dismissed.
>> > 
>> > > Of the two options, IMO option 1 is the only sensible one because there
>> > > is no citable specification of what goes in the metadata.
>> > 
>> > The alternative is to create one.   I don't understand why it is so difficult
>> > given that there is an implementation that can be examined to determine
>> > the format.
>> 
>> The difficulty isn't that I can't look at the format and spell it out
>> somewhere, but rather: If the IETF documents this format, then the IETF
>> becomes responsible for publishing it as a standard. I don't think either
>> the Linux community or the IETF wants to take this step with something so
>> far outside of the purview of either the IETF or the nfsv4 WG. It ties
>> everyone down -- and as mentioned above, there doesn't yet seem to be
>> any need for that.
>> 
>> In my earlier reply, I proposed breaking this process into two steps:
>> 
>> 1. Specify how NFS is to transport IMA metadata in an IETF publication
>> 2. Specify the Linux IMA metadata format itself in some other venue
>> 
>> So then:
>> 
>> 1. would be a Normative extension to the NFS protocol
>> 
>> 2. might be published by the nfsv4 as an Informative description of the
>> metadata format, in lieu of getting this published somewhere else. Think
>> of it as an illustrative example rather than a hard specification.
>> 
>> It still doesn't feel like it's the job of an inter-networking standards
>> body to maintain this metadata data format specification, however.
>> 
>> Does it make sense to publish either a separate Informative document or
>> have an Appendix to this document that provides an Informative example
>> that gives a specific format for Linux IMA metadata?
>> 
> Chuck, 
> 
> Given this last set of responses, you seem to be saying that the only implementation of this capability will be with Linux and that you would be surprised to find any other implementations that would need to implement the support for this feature.

That's not at all what I'm saying.

There is currently no published standard definition of the IMA metadata format.
I've made it clear from the very beginning that one does not yet exist, and
have asked repeatedly whether this will be a problem. For the past 18 months,
I've gotten the answer "no, it shouldn't be, because NFS implementations won't
be required to interpret the metadata format."

Thus I'm asking for a protocol extension so that NFS can transport, and NFS
servers can store, a particular piece of opaque metadata. This is a narrow
scope. All I want to do is store and retrieve this metadata via NFS.

I've been asked to provide the format of the metadata. But at this time, no-one,
except for Linux, has stated a plan to actually use it. Thus, this sounds like
a piece of this puzzle that can be deferred until it is actually needed (or
until someone decides the Linux IMA format is awesome and publishes it).

I'm also not claiming the metadata format should /never/ be published; merely
that we don't need this format definition to create a mechanism for storing it.

 - Interpretation of the metadata can be left to the future because there is
   a clean dividing line between moving the data and parsing it. This allows
   the protocol piece of this work to move forward quickly while we wrestle
   with the standards issues around the metadata format.

 - I don't believe the IETF is the right place to publish the metadata format.
   The IETF does networking, not data storage and not Trusted Computing. If
   we have to publish anything, it should be Informative only. Or maybe we
   can approach another standards setting organization where it would be more
   appropriate. I'm open to hear arguments either way about this.


It seems to me that the only thing that is missing from the current document
is a clear statement that this document, by itself, will not enable the
implementation of an IMA appraiser on the NFS server or client. The document
does not prevent or forbid future publication that would enable such an
implementation.


> So, this is then clearly opening the door for the NFS protocol to be used for implementation specific features and to the point that all that is needed is an opaque attribute and possibly some error codes to go along with it to achieve a side band protocol for that specific implementation.  And if anyone is interested in the feature, a pointer to some "open source" is sufficient.
> 
> Well, I don't believe that is an appropriate use of the NFS protocol as defined within the IETF.  I apologize if I have the characterization incorrect and would be happy to hear otherwise.

I believe your characterization is incorrect.


> There have been other implementations of this type of ride-a-long or side-band protocol in the past.  The Solaris ACL protoocl for example - and there are others.  To be honest, that seems to be what is needed for Linux.  Just create a small RPC protocol that can ride on top of the NFS port and shares the same file handles and it should be good to go.

As I state above, I'm seeking a standards-based NFS protocol extension
because I would like to see non-Linux NFS servers store this metadata. The
question of whether non-Linux NFS servers want to interpret and use it is
left open for another time.

The same arguments were made for user xattrs, which are opaque to the NFS
protocol. I don't see how this situation is different from those or from NFS
Security Labels, which are also largely Linux-only, and could have been
implemented using a side-band RPC protocol.

I am trying to meet your requirements, but because there is currently no
published standard for the metadata format, it is difficult. I am only the
messenger here.

Can you help me understand why those extensions were appropriate but the one
I'm requesting now is not? And, why is it not appropriate to split the
standard for IMA on NFS into a transport document and later, something that
might define the metadata format?


--
Chuck Lever