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

[David Noveck <[e-mail]>]

>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 <[e-mail]>
wrote:

>
> Chuck,
>
> inline for comments.
>
> On Mon, Oct 28, 2019 at 8: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.
>>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>