NFSv4 Questions

[Rick Macklem]

Andrey Simonenko wrote:
> On Mon, May 07, 2012 at 07:40:18PM -0400, Rick Macklem wrote:
> > Andrey Simonenko wrote:
> > > On Sun, Apr 29, 2012 at 04:36:03PM -0400, Rick Macklem wrote:
> > > >
> > > > Also, be sure to check "man nfsv4" and maybe reference it (it is
> > > > currently
> > > > in the See Also list, but that might not be strong enough).
> > >
> > > There is another question not explained in documentation (I could
> > > not
> > > find the answer at least). Currently NFSv3 client uses reserved
> > > port
> > > for NFS mounts and uses non reserved port if "noresvport" is
> > > specified.
> > > NFSv4 client always uses non reserved port, ignoring the
> > > "resvport"
> > > option in the mount_nfs command.
> > >
> > > Such behaviour of NFS client was introduced in 1.18 version of
> > > fs/nfsclient/nfs_clvfsops.c [1], where the "resvport" flag is
> > > cleared
> > > for NFSv4 mounts.
> > >
> > > Why does "reserved port logic" differ in NFSv3 and NFSv4 clients?
> > >
> > It is my understanding that NFSv4 servers are not supposed to
> > require
> > a "reserved" port#. However, at a quick glance, I can't find that
> > stated
> > in RFC 3530. (It may be implied by the fact that NFSv4 uses a "user"
> > based
> > security model and not a "host" based one.)
> >
> > As such, the client should never need to "waste" a reserved port# on
> > a NFSv4
> > connection.
> 
> Since AUTH_SYS can be used in NFSv4 as well and according to RFC 3530
> AUTH_SYS in NFSv4 has the same logic as in NFSv2/3, then
> 
> 1. Does "user" based security model mean RPCSEC_GSS?
> 
> 2. Does "host" based security model mean AUTH_SYS?
> 
My guess is that AUTH_SYS is not considered a security model at all,
but the "authenticators" refer to users.

I believe the "host" based security model referred to in the RFCs refers
to the restrictions implemented by /etc/exports, based on client host IP
addresses.

I do remember that the IETF working group discussed "reserved port #s" and
agreed that requiring one did not enhance security and that NFSv4 servers
should not require that a client's port# be within a certain range.
(If you were to search the archive for nfsv4 at ietf.org, it should be somewhere
 in there.)

However, I agree that this does not seem to be stated in the RFCs, because
I couldn't find it when the question came up. (It may be that IETF does not
have a definition of a "reserved port#".)

Personally, I agree with the working group and have always thought requiring
a client to use a "reserved port#" was meaningless. However, I already noted
that I don't mind enabling it, with a comment that it should not be required
for NFSv4.

> I did not find any mention about port numbers in RFC 1813 and 3530,
> looks like that ports numbers range used by NFS clients and checked by
> NFS server is the implementation decision.

During interoperability testing (I'll be at another NFSv4 Bakeathon in June)
I have never had a server that would not allow a connection to happen from
a non-reserved port# for NFSv4, so I believe that the implementation practice is to
not require it for NFSv4. (Consistent with the discussion on nfsv4 at ietf.org.)

rick