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

[Chuck Lever <[e-mail]>]

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