Subject: RE: [nfsv4] pNFS security

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 17 Nov 2004 12:17:42 -0500

> > 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" ;-).

The "differently secured"? -)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 17, 2004 11:42 AM
To: [email-masked]
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 ([email-masked]), 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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
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: "Noveck, Dave" <[email-masked]>
Date: Wed, 17 Nov 2004 18:26:44 -0500

> ignores a lot of requirements and "running code" out there.

As far pNFS being restricted to an NFSv4-only world, I think that 
that is a constraint that pretty much comes with the territory.

A pNFS client must be an NFSv4 client.

A pNFS (meta-data) server must be an NFSv4 server.

It is possible that v2 and v3 data servers might be used within a
pNFS deployment, thereby diluting the NFSv4-only-ness of pNFS, but
if your argument is that this is a good thing because it allows
servers that haven't implemented Kerberos to be used, it makes me
wonder what the IESG is going to say (and I admit I don't know).
NFSv4 made Kerberos support mandatory-to-implement (although not
to use) and at that time it was judged that "I don't want to.  I
have this existing RPC code that I don't want to rewrite." was not
judged a sufficient argument.  Given that context, I can't see why
the same would not apply to a v2/v3 server participating in pNFS
(which is an NFSv4-based protocol).  If we define v2/v3 as a storage
protocol for use with pNFS, I have trouble understanding why the 
same argument, i.e "I don't want to change the code I have and want
to use the servers that exist.", would not get the same response.
I would expect that if you want to use v2/v3 as a storage protocol
for pNFS then Kerberos would be mandatory to implement in that 
context just as it is for NFSv4.

The IESG was OK with auth_sys which is a "different" trust model
(you trust the clients to set the uid/gid values) and you are
free to use that if you judge that it matches the circumstances
of your deployment, but you still have to implement Kerberos.
Why would it be different now?

> so Dave Noveck's proposal to make NFSv4

It wasn't a proposal.  I was merely exploring possibilities.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 17, 2004 11:42 AM
To: [email-masked]
Subject: [nfsv4] pNFS security

environments
it

Thanks,
--David