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

welch@panasas.com

Message-Id: <200411120035.iAC0Z0X12889@medlicott.panasas.com>
Subject: Re: [nfsv4] comments on draft-welch-pnfs-ops-00.txt 
From: Brent Welch <welch@panasas.com>
Date: Thu, 11 Nov 2004 16:35:00 -0800

I have clouded the issue by introducing files, object, and blocks,
and by explaining the object security model incorrectly.
I will attempt a better explanation at the end of this email.

>>>Mike Eisler said:
 > 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.

First, the main point of confusion is the introduction of different
storage protocols in addition to the pNFS extensions that affect
the protocol between the client and the NFSv4 server.  The pNFS protocol
as currently described covers the client -> NFSv4 protocol.  The
client also has a client -> storage protocol that it will use to
read and write data.  With the goal of making things concrete, let's
assume that this protocol is also NFSv4.  HOWEVER, that is not the
only possibility.  For the purposes of the pNFS extension, this
possibility is acknowledged by the use of type fields in data layouts
that indicate what that storage protocol is.  Again, for a concrete
protocol spec, we plan to define layout types that are used with
NFSv4 as the storage protocol.  

But, we really do not want to preclude
other storage protocols.  The people discussing this protocol for
the past year come from companies that do NFS servers, scientists that
use non-kernel filesystems like PVFS, companies that do object storage,
and companies that do SAN filesystems.   By keeping these other
storage protocols in mind when we design the extension, and putting
in the appropriate type fields to all for them, we think we are adding
more value to the extension.  We are not requiring (i.e., REQUIRED) that
all possible storage protocols be implemented.  But, we would really
like to allow them.

About security.  I know you all have worked hard to get good security
into NFSv4, and I think that's great.  We have no intention of watering
down the security of NFSv4.  I think Dave Noveck said the right thing,
that the requirement is that the data servers honor the ACL stored
on the metadata server.  That can be done by pushing ACLs out to
the data servers (in a fault tolerant way) or by having the data servers
pull ACL information and cache it. Currently, the protocol used
between the metadata server and the storage servers is out of scope
of the pNFS extension.  (We're calling this the 
"Storage Management Protocol", although that is probably an overloaded term)

In contrast to what Nico said,
we've never stated that the client must interpret and enforce ACLs.
Instead, what we said is that some storage protocols (e.g., used with
SAN filesystems) rely on physical security, protection zones in the
storage network, and, yes, some trust of the client code.  However,
please keep in mind that if someone wants to use an insecure data
storage protocol in conjunction with pNFS, it is not REQUIRED that
anyone else use it, nor should their use of it in any way affect
the security of pNFS used, e.g., with NFSv4 as the storage protocol.

About the object security model.  First, yes, this is different.  It
comes from Howard Gobioff's thesis work.  It is designed to be something
that is cryptographically strong yet simple to enforce at the storage
device.  The pNFS extension is not mandating that a new security model
be used by NFSv4.  But, ideally, the pNFS extension would support the
use of this security model when OSD/iSCSI is used as the storage protocol.

The basic ideas are: the metadata server and the object storage devices
share a secret key. Key provisioning is part of the storage management
protocol and is out of scope of pNFS.  Next, when the metadata server
returns a capability to a client, it also returns a signing key to
the client.  When the client presents operations to the OSD (object
storage device) it signs those commands with the signing key.  Plus,
a timestamp nonce is included in the command to prevent replay attacks.
Where this affects pNFS is that the signing key needs to be returned
from the metadata server to the client through a secure channel. We
can use the GSS infrastructure for this, but I think it places a new
demand on the return path.

--
Brent Welch
Software Architect, Panasas Inc
Delivering the premier storage system for scalable Linux clusters

www.panasas.com
welch@panasas.com

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4