Subject: [nfsv4] Proposal: Registered port numbers for NFS-related daemons

From: Nils Steinger <[email-masked]>
Date: Fri, 15 Sep 2017 00:02:48 +0200

Dear all,

I recently had to grant access to an NFSv3 server behind a firewall,
which requires reconfiguring statd, mountd, lockd, and possibly rquotad
to use static port numbers, rather than ones assigned dynamically in
conjunction with portmap.
This raised the question which ports to use to minimise the risk of
collisions with other existing or future services.

I was unable to find any best practice documentation or IANA port
registrations for statd, lockd, and rquotad.
For mountd, there is a IANA registration for port 20048, granted to one
Nicolas Williams (@oracle.com) in 2010. [1]

*Proposal:*
Obtain IANA port registrations for the remaining three services.
(And perhaps contact Mr Williams about transferring the administration
of his port registration to the IETF.)

This would establish a guideline that would hopefully prevent any
(production-quality) software from using that set of ports, so they
could be used safely whenever the need for static NFS port configuration
arises.

Is this an idea that would be (1) feasible and (2) make sense to
implement?
From my inquiry to the IANA, they see any NFS-related requests and
decisions as a responsibility of the IETF (i.e., they refused to discuss
the matter with me and directed me to this WG instead).

(Incidentally, I'm also inclined to ask why NFS doesn't use static ports
in the first place. As a mere user of implementations of the protocol, I
frankly have no clue about the design decisions behind this and am
curious to learn about them.)

Kind regards,
Nils Steinger

[1]:
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=mountd

---

From: Tom Talpey <[email-masked]>
Date: Sat, 16 Sep 2017 09:35:25 -0700

Properly implemented RPC clients will use the RPC Portmapper (RFC1833)
on port 111 to resolve the port of each RPC service, for instance NFS,
statd, lockd, mountd, etc. For this reason, there's been no need to
standardize the port numbers for each of the services you mention; each
one is free to choose any local port, as long as the server advertises
via portmap. You should look into whether these server services are
configurable on your preferred systems.

This situation changes in NFSv4.x. In these versions, there are no
"side protocols" and the NFS port is used for all client-to-server 
communications. Additionally, the registered port 2049 (or 20049 for
NFS/RDMA) is used without required lookups to the portmapper. In 
NFSv4.0, however, the callback channel is dynamically allocated and
requires explicit firewall configuration to allow the server to connect
to the client (note the opposite polarity). This was corrected in
NFSv4.1 and all recent NFS minor versions use the single port.

You should think very carefully before exposing NFSv3 services to
the internet. I assume you are considering this only in private
network settings.

On 9/14/2017 3:02 PM, Nils Steinger wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Nils Steinger <[email-masked]>
Date: Sun, 17 Sep 2017 14:45:46 +0200

On 2017-09-16 18:35, Tom Talpey wrote:
> via portmap.

The need for fixed port numbers arises when using a firewall between the
NFS server and client.
I have yet to find a firewall that can talk to the portmapper to
dynamically configure ACCEPT rules for the ports currently in use, so
the only option is to configure away the dynamic behaviour.
The client will of course still ask the portmapper for the port numbers,
but the response will always be the same.

I'm very uncomfortable with just choosing any arbitrary port number
that happens to be unregistered *now*, since it might be registered at
some point in the future, perhaps to a service that I wish to use.

Hence the request to get some officially sanctioned port numbers to
avoid any future double use scenarios.

> NFSv4.1 and all recent NFS minor versions use the single port.

I have to admit I have very little experience with NFSv4 at this time.
From what I've gathered, it no longer should (or can) use raw numeric
user/group IDs on the wire. My small environment doesn't have a central
user database (yet), so it was my impression that using v4 instead of v3
would break things.

> the internet. I assume you are considering this only in private

The firewall sits between the fileserver on the main network and a VPN
for "road warriors". Technically, I could just grant unrestricted access
from the VPN to the main network, but (again planning for potential
future services), I'd rather specify what services the VPN users have
access to.