Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-minorversion2-15.txt

From: [email-masked]
Date: Wed, 03 Oct 2012 18:01:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title           : NFS Version 4 Minor Version 2
	Author(s)       : Thomas Haynes
	Filename        : draft-ietf-nfsv4-minorversion2-15.txt
	Pages           : 86
	Date            : 2012-10-03

Abstract:
   This Internet-Draft describes NFS version 4 minor version two,
   focusing mainly on the protocol extensions made from NFS version 4
   minor version 0 and NFS version 4 minor version 1.  Major extensions
   introduced in NFS version 4 minor version two include: Server-side
   Copy, Application I/O Advise, Space Reservations, Sparse Files,
   Application Data Blocks, and Labeled NFS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-minorversion2-15

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 4 Oct 2012 01:11:08 +0000

The changes in this draft are the removal of the Labeled NFS call back and
the addition of a new attribute: FATTR4_CHANGE_SEC_LABEL.

As Trond outlined, this can be combined with VERIFY/NVERIFY to
quickly determine if the security label has changed.

On Oct 3, 2012, at 6:01 PM, [email-masked] wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 4 Oct 2012 13:59:48 -0400

> quickly determine if the security label has changed.

A couple things I'm unclear about:

	- Is it mandatory for the server to support
	  FATTR4_CHANGE_SEC_LABEL on any filesystem that supports
	  security labeling?
	- If so, is it mandatory for all objects or just for regular
	  files?

--b.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 4 Oct 2012 18:08:23 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of J. Bruce Fields
> Sent: Thursday, October 04, 2012 11:00 AM
> To: Haynes, Tom
> Cc: nfsv4 list
> Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-minorversion2-15.txt
> 
> > The changes in this draft are the removal of the Labeled NFS call back
> > and the addition of a new attribute: FATTR4_CHANGE_SEC_LABEL.
> >
> > As Trond outlined, this can be combined with VERIFY/NVERIFY to quickly
> > determine if the security label has changed.
> 

Implementing FATTR4_CHANGE_SEC_LABEL should be fairly light weight: if the server supports labels, then it has a trivial implementation of the FATTR_CHANGE_SEC_LABEL in the form of a simple hash of the label string. Perhaps it might be worth mentioning this in the draft?

Cheers
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 4 Oct 2012 14:17:09 -0400

> Implementing FATTR4_CHANGE_SEC_LABEL should be fairly light weight: if the server supports labels, then it has a trivial implementation of the FATTR_CHANGE_SEC_LABEL in the form of a simple hash of…

We'd need to change this too:

	"Each time the sec_label is changed, the server MUST increment
	the value of change_sec_label by one."

--b.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 4 Oct 2012 18:23:15 +0000

> Sent: Thursday, October 04, 2012 11:17 AM
> To: Myklebust, Trond
> Cc: Haynes, Tom; nfsv4 list
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of J. Bruce Fields
> > > > The changes in this draft are the removal of the Labeled NFS call
> > > > back and the addition of a new attribute: FATTR4_CHANGE_SEC_LABEL.
> > > >
> > Implementing FATTR4_CHANGE_SEC_LABEL should be fairly light weight: if
> the server supports labels, then it has a trivial implementation of the
> FATTR_CHANGE_SEC_LABEL in the form of a simple hash of the label string.
> Perhaps it might be worth mentioning this in the draft?
> 

Yes. That isn't needed for VERIFY/NVERIFY support.

Cheers
  Trond

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 5 Oct 2012 07:42:22 -0400

> Yes. That isn't needed for VERIFY/NVERIFY support.

True.  We need a statement of the requirement as opposed to a description
of one way to satisfy it.

I think the requirement should be something like,

      If the value of sec_label for a file is different at two different 
      Times then the values of change_sec_label at those times MUST be 
      different as well.

I don't see how you can meet that requirement with a simple hash of the
label string.  Maybe my definition of 'simple hash' is just too 
simple-minded.

> > > 	- If so, is it mandatory for all objects or just for regular

How about making it RECOMMENDED (for all objects)?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Myklebust, Trond
Sent: Thursday, October 04, 2012 2:23 PM
To: J. Bruce Fields
Cc: Haynes, Tom; nfsv4 list
Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-minorversion2-15.txt

Cheers
  Trond

---

From: "Myklebust, Trond" <[email-masked]>
Date: Sat, 6 Oct 2012 21:43:29 +0000

> label string.  Maybe my definition of 'simple hash' is just too 

As far as I'm concerned, false positives (i.e. client believes that the label has changed) are of relatively little consequence: it will force the current operation to be aborted, the label to be re-read, and the operation retried. Given the basic assumption that label changes are _rare_, I don't think this is unreasonable.

If you are worried that the hash may lead to collisions despite the rarity of label changes, then one way to solve that might be to use a time stamp instead: something that isn't stored on permanent storage will probably suffice, since false positives are (relatively) cheap.

> How about making it RECOMMENDED (for all objects)?  

We should at least ensure that it is available for all objects that are subject to labelled NFS. Theory has it that we should be able to use the security label itself as part of VERIFY/NVERIFY, but that means transmitting the entire label, which means a lot more processing for the server just in order to catch a rare corner case...

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sat, 6 Oct 2012 19:12:31 -0400

> As far as I'm concerned, false positives (i.e. client believes that the label has changed) are of relatively little consequence: it will force the current operation to be aborted, the label to be r…

By the way, I was idly thinking: "oh, I could just use the change
attribute on the file, as long as it was bumped on label changes too."
But obviously that would be a disater.

So, *might* be worth saying something along the lines of:

	If the value of sec_label for a file is different at two
	different times then the values of change_sec_label at those
	times MUST be different as well.  The value of change_sec_label
	MAY change at other times as well, but this should be rare, as
	that will require the client to abort any operation in progress,
	re-read the label, and retry the operation.

> If you are worried that the hash may lead to collisions despite the
> rarity of label changes, then one way to solve that might be to use a
> time stamp instead: something that isn't stored on permanent storage
> will probably suffice, since false positives are (relatively) cheap.

False negatives might also be possible if time granularity's too course?

But I suppose given the rarity of label changes you should be able
to just block a repeated label change for a second if necessary, and
then all you need to do is use something like unix time and ensure it
never goes backwards.  OK.

If we really want to allow a hash then we'd want something bigger than a
u32.

--b.

---

From: "Noveck, David" <[email-masked]>
Date: Mon, 8 Oct 2012 10:51:35 -0400

I hope we are all in agreement that a moderate frequency of false positives
is not of concern.

My proposed requirement does not say anything regarding false positives.
It basically says "THERE MUST NEVER BE FALSE NEGATIVES".   Should the 
requirement say something about false positives and if so, what?

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 15 Oct 2012 23:07:32 +0000

> 	- If so, is it mandatory for all objects or just for regular

I'd like to make it mandatory for all objects. The concern then becomes does
the server have to make it persistent? As a server vendor, as long as I can
do that outside of the inode, I'm happy enough to say the cost of storing
a nfstime4 is negligible to an opaque array is not a huge delta.

Given my latest proposal, time since open, and the fact that most objects
do not get "opened", I'd say a server could either store it or return a 0
whenever queried.

I think it is more likely the server will deny MAC access before the client
cares about updating the label.