Subject: RE: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 12 Nov 2004 10:20:51 -0500

> I think that adding data access features is better than 
> replicating ACLs
 
Not sure what you are saying here.
 
> but I doubt that excluding V2 & V3 from data access makes too much 
> sense giving the long time required for a new protocol to become 
> prevalent and the widespread use of V2/V3 
 
I don't understand your logic here.  The set of pNFS clients is already
limited to systems that can speak v4.x (for whatever x turns out to be).
So the widespread use of V2/V3 by clients that cannot speak v4.x does
not really come into it.  They will not be able to speak pNFS, whether 
we do the work to support V2 and V3 as a storage protocol or not.  On
the other hand, since all clients which support pNFS must have a V4.x
client (or else they wouldn't be pNFS clients), supporting v4.x as a
storage protocol should provide 100% coverage of that subset (unless 
the implementer has some ideological objection to the files variant). 
 
It is true that pNFS will take time to become prevalent but that comes
with the territory.  If you want new features that aren't provided by
an existing protocol, you have to wait for that protocol to happen.
 
No matter what we do about storage protocols, V2 and V3 clients would be
supported by pNFS servers in proxy mode, the same way they would support
V4.0 clients or V4.x clients that don't have pNFS support.

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, November 11, 2004 8:02 PM
To: Noveck, Dave
Cc: Mike Eisler; [email-masked]; [email-masked]
Subject: RE: [nfsv4] comments on draft-welch-pnfs-ops-00.txt

[email-masked] wrote on 10/11/2004 10:58:53:

> > Assuming the capability route is going to be taken (a huge assumption,
> > IMHO), why not introduce a new NFSv4 pseudo op, (say "PUT_CAP") which
> injects
> > a capability into the COMPOUND procedure's operations stream?
> 
> Apart from the merits of the capability approach, Mike's suggestion
> is a specific instance of a general point, which we should take
> note of.  If nfsv4 is going to be used as a storage protocol within 
> pNFS we have the option of adding features specifically designed
> to support that use.  If pNFS is going appear in a specific v4.x,
> I would argue that it is quite reasonable only to support v4.x 
> (and not earlier v4 versions) as the pNFS storage access protocol.
> 

I think that adding data access features is better than replicating ACLs but I doubt that excluding V2 & V3 from data access makes too much sense giving the long time required for a new protocol to become prevalent and the widespread use of V2/V3 

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]] 
> Sent: Tuesday, November 09, 2004 9:29 PM
> To: [email-masked]
> Subject: [nfsv4] comments on draft-welch-pnfs-ops-00.txt
> 
> 
> My comments are around the security area.
> 
> It isn't clear why new authentication systems are being invented
> here, when we alread have one: ONC RPC authentication flavors, and
> specifically, RPCSEC_GSS. The i-d needs to justify its direction.
> 
> > 4.1 Object Storage Security
> > 
> > 
> >   The object storage protocol relies on a cryptographically secure
> >   capability to control accesses at the object storage devices.
> >   Capabilities are generated by the metadata server, returned to the
> >   client, and passed to the object storage device, which verifies
> >   that the capability allows the requested operation.
> > 
> > 
> >   Each capability is specific to a particular object, an operation
> >   on that object, a byte range w/in the object, and has an explicit
> >   expiration time.  The capabilities are signed with a secret key
> >   that is shared by the object storage devices (OSD) and the metadata
> >   managers.  Typically each OSD has a set of master keys and working
> >   keys, and the working keys are rotated periodically under the
> >   control of the metadata manager.  Clients do not have device keys
> >   so they are unable to forge capabilities.  Capabilities need to
> >   be protected from snooping, which can be done by using facilities
> >   such as Ipsec to create a secure VPN that contains the clients,
> >   the file server, and the storage devices.
> 
> Requiring IPsec to protect the capabilities strikes me as
> overkill.
> 
> Why doesn't the protocol assign each user a session key
> known to metadata server and OSD, and then use the session
> key to compute an HMAC on some or all of the messages?
> GSS-API would be the ideal way to wrap an HMAC.
> 
> 
> > 4.2 File Security
> > 
> > 
> >   The file storage protocol has the same security mechanism between
> >   the client and metadata server as between the client and data
> server.
> >   This implies that the files that store the data need the same ACL as
> >   the metadata file that represents the "control point" for the file.
> >   This ensures that access control decisions are consistent between
> >   the metadata server and the data server.
> > 
> > 
> >   One alternative that was briefly discussed was the introduction
> >   of special file handles that essentially have the properties of
> >   capabilities so they can be generated by the metadata servers and
> >   checked by the data servers.  (Peter Corbett described "one shot"
> >   file handles.)  To be effective, these need all the properties of a
> >   capability so the data server can efficiently and securely enforce
> >   the access control decisions made by the metadata manager.
> 
> The problem with opaque special file handles is that presumably each
> user of a given file gets his own file handle. This means NFS clients
> are going cache multiple copies of the same data.
> 
> Assuming the capability route is going to be taken (a huge assumption,
> IMHO), why not introduce a new NFSv4 pseudo op, (say "PUT_CAP") which
> injects
> a capability into the COMPOUND procedure's operations stream?
> 
> > 
> >   [We need to elaborate on this section. We should be able to
> >   leverage the NFSv4 GSS context between the client and the NFSv4
> >   "Storage Devices".]
> 
> If this is the direection, then at minimum the paragraph previous
> to this should be struck. But to beat the not quite dead horse,
> it is unclear why RPCSEC_GSS can't be used as is.
> 
> > 4.3 Block Security
> > 
> > 
> >   The block model relies on SAN-based security, and trusts that
> >   clients will only access the blocks they have been directed to use.
> >   In these systems, there may not need to be any additional security
> >   information returned with the map.  There are LUN masking/unmapping
> >   and zone-based security schemes that can be manipulated to fence
> >   clients from each other's data.  These are fairly heavy weight
> >   operations that are not expected to be part of the normal execution
> >   path for pNFS. But, a metadata server can always fall back to these
> >   mechanisms if it needs to prevent a client from accessing storage
> >   (i.e., "fence the client".)
> 
> Here I can accept that RPCSEC_GSS-like system authenticating a blocks
> protocol
> isn't going to happen, mostly because blocks protocols have no
> provision for real authentication. That said, at the recent NAS
> conference,
> when the issue was raised, I thought I'd understood Brent Welch
> to say that capabilities could be added to the blocks protocol.
> If so, couldn't a capability, mutually signed by the metadata server and
> the NFS
> server, could be used?
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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

---

From: Julian Satran <[email-masked]>
Date: Mon, 15 Nov 2004 15:41:18 +0200

> V4.0 clients or V4.x clients that don't have pNFS support.

I was thinking more about supporting V2/V3 servers as data repositories
and accessing them from a pNFS client should be straightforward 

> I think that adding data access features is better than replicating 
> ACLs but I doubt that excluding V2 & V3 from data access makes too 
> much sense giving the long time required for a new protocol to 
> become prevalent and the widespread use of V2/V3 
>