Spencer Shepler's review of draft-ietf-nfsv4-integrity-measurement-07

[chucklever]

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.

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.

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.

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

[chucklever]

Some fall-out from resulting conversation:

• Better title would be "Transport and Storage of Linux Integrity Metadata"
• Should state explicitly that the IM architecture does not trust data storage, therefore measurement and appraisal is handled separately from filesystems.
• Document should note that the proposed protocol extension does not enable the construction of an appraisal module; only the transport and storage of the metadata as an opaque blob.
• Despite the narrow focus of this document, there is still some desire to see a specific definition of the metadata format. I proposed adding an Appendix that provides an Informative description of the main formats used today, in lieu of a more complete and standard definition provided in some other venue.

[chucklever]

Spencer's follow-up:

I agree that RFC 8178 provides the ability to add features, particularly attributes, to the protocol and I agree with the utility of 8178 and that is appropriate.

I also agree with the utility of RFC 8276 but I disagree with the interpreted precedent of the RFC per Chuck's comment.

To quote from RFC 8276:

"Xattr keys and values MUST NOT be interpreted
by the NFS clients and servers, as such behavior would lead to
non-interoperable implementations. If there were a need to specify
one or more attributes that servers need to act upon, the appropriate
semantics would be specified by adding a new attribute for the
purpose as provided for by [RFC5661] and [RFC8178]."

I read the proposed integrity measurement capability as providing a "system-level" interpretation.

The decision to allow for the execution of application binaries is a "system" level activity or in other words, a feature that explicitly requires the client to interpret the semantics of the protocol extension. Because of the client's need to interpret the capability, the definition should be defined in a way that it can be implemented in an open fashion and hopefully, but not required, defined in a way that it is "upgradeable".

To the point of "open", I don't believe the availability of open source sufficient in this instance. Yes, a clean-room approach to implementation can be executed but even with that action, a patent claim can still be made. Therefore, without the protocol definition being captured in a way that clearly allows the reader to have a sense that IETF's policies for disclosure have followed, I don't believe it should be allowed as an extension of the NFS protocol.

So, I am left with my objection to this work moving forward.

If this proposal would to be accepted, it sets a precedent that a individual could define a similar extension for their favorite XYZ product in such a way that interoperable implementations could be not implemented. In least this could lead to a proliferation of OS, vendor specific feature creep and at worse, non IP infringing implementations would be impossible to implement.

[chucklever]

Dave's response:

Why isn't the SELinux label work a problem in this regard?

I don't understand Spencer's position well enough to know if he has
a problem with this, but given that this model has already been adopted
by the working group for arguably system-level attributes, it is hard for
me to believe such objections, if they were to exist, would be widely
shared.

Since adopting a parallel approach for the IMA metadata
format is compatible with your plans for -08, perhaps you should
adopt a similar approach (an IANA registry with a specification-required
policy) for IMA. I know that such things have been suggested in the past
and seemed at the time like overkill, but, given that there are a number
of existing formats, and likely there will be a more general format which
has not been arrived at right now, it might be best to take this step,
hoping that it will deal with the objections about the lack of a metadata
format specification even though the Linux community is kind of slow
about producing one. I think you ould have to add a new fs-scope
attribute with the id, rather than stick with the local-policy approach,
but there would b no requirement tat the client check this.

BTW, specification-required and even RFC-required do not require a
normative specification. With specification-required, the IETF does
not have to be involved in writing the spec although a designated-expert
would have to check that it clear enough to enable implementation.

[chucklever]

My conclusion?

It appears that draft-ietf-nfsv4-integrity-measurement can't move forward without some description of the IMA metadata format.

My preference would be that the Linux community is responsible for the process and document(s) that describe their own format. Failing that, a description can be added to integrity-measurement, as I recently proposed.

To make an IANA registry a sensible thing to do, at least one more independent integrity metadata format will have to be identified.

I will see what can be done.