[nfsv4] pNFS security

Black_David@emc.com

From: Black_David@emc.com
Message-ID: <B459CE1AFFC52D4688B2A5B842CA35EA07E5CAE4@corpmx14.corp.emc.com>
Date: Wed, 17 Nov 2004 11:42:25 -0500
Subject: [nfsv4] pNFS security

In 20/20 hindsight, the pNFS ops draft is clearly missing a
structure/architecture overview discussion on security (mea culpa,
as I'm one of the authors).  That will need to be addressed in
the -01 version, as there are some fundamental structural aspects
of pNFS security that apparently aren't clear from the current
draft based on the amount of discussion they're causing.

pNFS is motivated by the large amount of work on SAN filesystems
- one of pNFS's goals is to use NFSv4 as the client-server protocol
in a SAN filesystem to enable a common client (with large amounts
of code reuse from existing clients) across these SAN filesystems.
In a SAN filesystem using a block protocol like iSCSI or Fibre
Channel, it's necessary to place more trust in the client by
making it responsible for only accessing what it's supposed to
within a volume as SAN access control is at volume granularity,
not sub-volume.  This is a change to the trust model for NFS
systems, as very little trust is currently placed in clients.
The draft needs to be up-front about describing this change.

It's important to distinguish the trust and responsibility placed
in the NFS client from the security properties delivered to the
application accessing NFS files.  To a first approximation, some
of the security enforcement responsibility has been moved to the
client, but the overall security properties of file access have
not changed.  There's a great deal of "running code" that suggests
this change in client trust/responsibility is acceptable *under
suitable deployment restrictions* - not every NFS client can be
trusted to properly control access to a SAN volume that stores
NFS files, and such untrustable clients should not run pNFS, at
least not with SAN block storage.  One of the purposes of a Security
Considerations section in an RFC is to describe this sort of
security-motivated deployment consideration, as Nico suggested:

> 5) Be sure to explain why lesser security is good for some environments
> (e.g., HPC?) if the trade off is for higher performance and there are
> mitigations.  You will get major pushback on this, so be sure to sell it
> well.

although I wouldn't have used the word "lesser" ;-).

This changed trust model may also be useful in using NFSv2 or v3
servers as the data storage for an NFSv4 pNFS system, particularly
ones that don't implement full NFSv4-class security.  Restricting
pNFS to an NFSv4-only world is going to be a severe constraint that
ignores a lot of requirements and "running code" out there.

Beyond this, I'd like to respond to a couple of things:

Mike Eisler wrote:

> Second, IETF owns the iSCSI storage protocol, and it is certainly
> within IETF's power to re-define (in a backwards compatible manner)
> iSCSI so that we get more than nothing.

Actually that's not true.  The re-definition to provide finer granularity
security would involve SCSI command sets that the IETF does *not* own.
I strongly recommend that IETF not venture into SCSI command set
specification, as IETF does not have the requisite expertise, and trying
to do so will cause massive problems in the relationship with T10 (SCSI
standards committee), where that expertise resides.  Besides, one
attempt to define a new SCSI command set that provides finer granularity
security has already been done - it's called OSD.  OTOH, commercial
uptake of that has been limited, in part because it's not backwards-
compatible with most existing SCSI commands.

Beyond this, discussion of possible "improvements" to iSCSI belongs
on the IP Storage WG mailing list (ips@ietf.org), please.

Nico wrote:

> 3) I highly recommend that you include a REQUIRED to implement
> mode/configuration which truly is comparable, in terms of security
> properties, to NFSv4.

I agree, but probably not in a fashion that Nico expected ...

Among the draft authors the plan for this has been to require
fallback to NFSv4 without pNFS.  Alternatives seem to run into either
reality check or interoperability issues, as requiring clients to
implement support for all the important storage protocols (block,
object, file) would be nice, but is probably unrealistic (I'd love
to be wrong about this, as it's the "best" outcome from a strictly
technical viewpoint), and requiring clients to always support NFSv4
as the storage protocol requires that the data be always accessible
via an NFSv4 layout.  The latter is headed towards require that
SAN storage arrays support NFSv4 for use with pNFS, which is
definitely unrealistic.

I should note that this "fallback to NFSv4 without pNFS" for
interoperability is not a uniformly held view, among other reasons
because there's an IBM SAN filesystem that can't do that, although
they might be able to fall back to an NFSv4 server on one of
the SAN filesystem clients, so Dave Noveck's proposal to make NFSv4
a REQUIRED layout type might be useful to give the metadata NFSv4
server the choice between falling back to no pNFS and serving the
data itself vs. pointing at another NFSv4 server that will serve
the data.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

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