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

[David Noveck <[e-mail]>]

> 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.

There is a third option which should be mentioned:

3) Provide enough information to enable interoperable server implementation
to be developed, while delaying work necessary to accomplish the ability to
develop other client implementations, i.e. to do 2)

While 2) would be preferrable to doing 3), that appears not to be possible,
in any realistic time frame, so the choice we have is between 3) and 1)
(or nothing).  If that is the choice, and I think it is, my choice would be
3).    I realize there may be objections to 3) as a general approach but I
feel that it makes sense to address those during the document's WGLC.
Given the naturre of the situation, it does not make sense to delay WGLC
until this issue addressed, since it is not the kind of issue where a delay
of any reasonable length could change the situation.

> > 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.

Even if it were happening there would still be a need to transfer the
executables
acros machine boundaries, even if the uyltimate use were not using NFS to
access
directly.   I would prefer that if there are important  file system
interfaaces supported
by local file systems, we  provide that support remotely as well, unless
doing so
poses insuperable obstacles.   In this case it doesn't and so we should be
able to
proceed to WGLC as soon as Chuck feels the document is ready and have the
necessary discussion about 1), 2), and 3)  above.


On Mon, Oct 28, 2019 at 11:00 AM Chuck Lever <[e-mail]> 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 <[e-mail]>
> 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.
>
>
> > 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.
>
> 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.
>
>
> > 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?
>
>
> --
> Chuck Lever
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>