[nfsv4] Review of stefanha-nfav4-rpc-over-vsock-00 (part three of three)

[David Noveck <[e-mail]>]

*Comments by Section (Section 4 through end)*

*4.  Intended Use*

Suggest replacing the section title by "Intended Uses".

Suggest replacing the first sentence of the first paragraph by the
following;

The primary intended use of RPC over AF_VSOCK is to allow a hypervisor
to provide access to Network File System (NFS) v4.1 [RFC5661] file
systems for access by virtual machines.

In the second sentence of the first paragraph suggest deleting the word
"also".

Suggest the addition of the following new paragraph after the existing
first paragraph:

When used with NFS version 4 [RFC7530] [RFC5661] the hypervisor has the
ability to make multiple file systems available as directories within a
pseudo-fs. Some of these file systems might be proxied by the hypervisor.to
allow remote file systems to be made available in a similar fashion.


Suggest replacing the second sentence of the second paragraph by the
following:

Such software is often referred to as a "guest agent".

I was confused by your third pargraph for a number of reasons:

   - I'm not sure what "mangement tools" are being referred to in the first
   sentence.
   - The reference to "firewall configuration" was hard to understand. If a
   hypervisor is to supply an IP address by which a client might access an NFS
   service provided by the hypervisor, I can't understand where the firewall
   that might need to be configured would be.
   - For all other uses of NFSv4, firewall configuration, when firewalls
   are present, has not been an issue that the working group has needed to
   deal with in the past. Given that fact, it is hard to understand why the
   working need to address it in the context of hypervisor/guest
   communication, where the need might be reasonably expected to be less
   pressing.
   - Many of the references to "automation" seem to be beside the point.
   The problem is that provision of an IP address when IP is not in fact being
   used inevitably raises the possibility of conflicting with the guest
   virtual machine's IP configuration and this applies whether that
   configuration is maintained by a human being, some piece of automation
   software, or some other entity.
   - The reference to manual steps in the last sentece is confusing. While
   I can understand how a virtual machine administrator might perform manual
   steps (i.e grudgingly :-), I can't understand how a hypervisor might
   perform them.

It seems to me that this material really belongs in its own section dealing
with the motivation for this work. The existing paragraph, beyond the
deficiencies noted above, is not really sufficient to explain to the
members of the working group, why this particuar use case is important
enough to justify a significant effort to accommoate a non-IP-based server
conection. It was written to explain the use case for this feature and
further clarification is needed to reach the deeper question of whether
there is suffcient motivation for the working group to take on this work.

*Potential New Section Dealing with Motivation*

A treatment of the motivation question needs to provided. I'm focusing here
on the question of use in the context of NFSv4 because the corresponding
question for many other protocols (e.g. NFSv3) is relatively easy to deal
with. As a result, if a decision is made as discussed in *Uncertainty
Regarding Role of this Document*, to handle NFSv4-related issues in a
separate document, the material I discuss below would appear in that
document, with the corresponding treatment in a document dealing with the
RPC-level quite limited.

Although definition of new network ids and universal address formats is
straightforward, particularly if FCFS registration is possible in this
case, there may be additional consequences that the working group will need
to consider before proceeding down this path.  NFSv4 assumes that host
names are available to define the service provided by the server for use by
RPCSEC_GSS as well as assuming that IP addresses can be provided within
location entries.  Changes that conflict with these choices may be
difficult and therefore be avoided.  As an example, RPC-over-RDMA might
well have defined a GUID-based universal address format to directly support
Infiniband.  Instead, Infinibandd access used IPv4 an IPv6 universal adress
format to avoid specification complexity.

If you decide to provide a motivation section, I suggest that you include
in the discussion a clear example of how the use of VSOCK might affect
something done without it. One likely example is a mount, which normally
specifies:

   - The location within the guest local file system at which the mounted
   fs is to appear.
   - The path, within the hypervisor name space, of the file system to be
   mounted.
   - The IP address (or hostname) of the server.

If we now look at the configuration issues associated with each of these
and how they would be affected by the presence/absence of VSOCK, we find
that:

   - The location within the guest local file system needs to be configured
   based on the structure of the guest local file system.  There must be an
   empty directory with a given name and it is always possible that that name
   may desginate an  inconstent  file system object.  This problem could be
   ameliorated by adopting a convention whereby a name unlikely to be
   otherwise used (e.g. the UTF-8 correspondin to Unicoe characters for
   "hypervisor" in Klingon :-) is adopted.

This issue is not affected by the potential use of VSOCK.


   - The path of the file system to be mountednees to be determined by the
   guest.  In the context of NFSv4, the set of poosible choices could be made
   available to the client, who can search the pseudo-fs for appropriate file
   sustems to mount.

This issue is not affected by the potential use of VSOCK.  However there is
an opprtunity to direct (and possibly standardize) the appropiriate
information to govern the selection of file systems through the use of
named attributes provining useful escriptiive information.


   - The need for the IP address is avoided by the use of NFS using a VSOCK
   connection.  However, it is nor clear how the role of the hostname (in
   defining the service being provided, for the use of RPCSEC_GSS) can be
   similarly accommodated.   One posibility would be to use the information
   available in loction-related ttributes to provided this information,
   although it would involve making an exception to the normal requirement
   that such information be fetched using RPCSEC_GSS with integrity specified.

An alternative would involve the use of VSOCK to establish VSOCK connection
to provde neeed configuration information such as a service name and an IP
address representing the server endpoint.  Once this is provided, NFSv4
could operate over existing RPC transports without change.  This need not
preclude the use of optimized mechanism (e.g. vsockets) to effect any
required message transfer.


Any treatment of firewall configuration difficulties, if they are relevant
to motivation should:

   - Give a concrete example of how such difficulties might arise.
   - Explain how addressing this specific case by means of using VSOCK
   might relate to this general issue for other sorts of NFSv4 use.

*5.  Network Addresses*

I think the phrase "network address" is confusing in this context.
Because your addresses, while analogous to network addresses but
significantly different,  I suggest:


   - In the first sentence, replacing "is the network address" by
'identifies a particular network participant".
   - in the second sentence, replacing "on a single network address"
by "by a single network participant".

I don't understand why 32-bit port numbers are used.  Is there any
reason 16-bit port numbers are insufficient?

*6.  Use of netids for AF_VSOCK*

Suggesr replacing "netids" by "Network Identifiers".  If you stick
with "netids", it needs to capitalized in the section title.

Suggest replacing the second sentence by the following:

It is possibile to use datagram sockets and a netid is reserved for
this purpose.

*8. Record Marking on Connection-oriented Sockets*

Suggest adding a summary paragraph as follows:

As a result, the data streeam transferred using VSOCK is the same as it
would be if TCP were used, although TCP protocol fields will not be present.

*9.  Security Considerations*

I think that the third paragraph needs major revision, whether you
decide to make this an informational or standards-track document.  If
it is not an RFC, you might as well just delete the section.

It is not clear what is meant by "Only AUTHNULL and AUTH_UNIX flavors"
are supported. Are you saying that use of RPCSEC_GSS over AF_VSOCK is
somehow forbidden?  To do that you would have to make this a
Standards-track document updating RFC 5661 (at least).  I don't
recommend that.   Or do you mean to say that there exist
server/hypervisor implementations that currently have no code to
support for the use of RPCSEC_GSS over AF_VSOCK.  That kind of
statement would normally make sense in an informational document.
However, if this statement relates to an NFSv4 implementation, as I
expect it does, tha't makes that implementation non-compliant with
RFCs 5661 and/or 7530.  In any case, you need to have a serious
discussion of how NFSv4 security requirements need to be addressed.
I'm not sure whether that would be in this document or in an
NFSv4-specific document but that issue does have to be addressed.

*10.1.  Netids for AF_VSOCK*

Suggest changing title to "Network Identifiers for AF_VSOCK" or "RPC
Network Identifiers for AF_VSOCK"

There a couple of issues that need to be considered both for this
section and for *10.2.  Uaddr Format for AF_VSOCK* as well.


   - I note that a standards action assigment is requested but it is't
clear why.  I'm not saying that this should be changed but the author
needs to be clear that such an assigmrent can only be requested in
standards-track RFC, which requires working group consensus and review
and approval by the IESG.
   - I think that an email address should be provided for Poc (the
author's most likely).  While RFC5665 is not very clear on this point
and Network Idenifiers such as "TCP" list "IESG" as a point of
contact, I think an email addrsss is needed in this case.

*10.2.  Uaddr Format for AF_VSOCK*

Suggest changing title to "Universal Address Format for AF_VSOCK".

The same issues noted in *10.1.  Netids for AF_VSOCK* apply here as well.