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

[spencer shepler <[e-mail]>]

On Mon, Oct 28, 2019 at 1:05 PM Chuck Lever <[e-mail]> wrote:

>
>
> > On Oct 28, 2019, at 3:28 PM, David Noveck <[e-mail]> 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.

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.

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.

Spencer