> On Oct 5, 2017, at 4:08 PM, Stefan Hajnoczi <stefanha@xxxxxxxxxx> wrote: > > I have previously submitted patches that implement NFS client and nfsd > support for the AF_VSOCK address family. In order for this to be > acceptable for merge the AF_VSOCK transport needs to be defined in an > IETF RFC. Below is a draft RFC that defines ONC RPC over AF_VSOCK. > > My patches use netid "vsock" but "tcpv" has also been suggested. This draft > RFC still uses "vsock" but I'll update it to "tcpv" if there is consensus. > > The uaddr format proposed in this RFC is not implemented yet. RPCBIND and the > NFSv4 callback were not supported in my previous patch submissions but it's > clear that a uaddr format is required for full ONC RPC support so I've > included it. > > Discussion and pointers for getting this in shape for submission with > the IETF would be appreciated! I will apply final RFC formatting before > submission and am mostly concerned about content at this stage. > > Thanks, > Stefan > --- > > Remote Procedure Call (RPC) Network Identifier and Universal Address Format > Definitions for the AF_VSOCK Transport > > S. Hajnoczi > Red Hat, Inc. > October 2017 > > 1. Introduction and Motivation > > The AF_VSOCK address family facilitates socket communication between a > hypervisor and virtual machines running on the hypervisor. It was implemented > in Linux 3.9 with initial transport support for VMware. Further transports > were added for KVM and Hyper-V hypervisors later. AF_VSOCK services can > run on any supported hypervisor because the network address and semantics > remain the same across AF_VSOCK transports. > > ONC RPC services are bound to transport addresses (RFC 1833 [1]). Transport > addresses are described by netid and universal address strings. This standard > representation of transport addresses allows address information to be > communicated between client programs and RPC services, including the RPCBIND > program. > > It is necessary to define a network identifier and universal address > representation so that ONC RPC may be used over AF_VSOCK. This document > describes string representations for the AF_VSOCK netid and universal > addresses. > > 2. Requirements Language > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be > interpreted as described in RFC 2119 [2]. > > 3. Security Considerations > > AF_VSOCK addresses are local to the hypervisor instance that the virtual > machine is running on. Source address spoofing is not possible because the > hypervisor enforces the assigned address of the virtual machine. RPC services > running on the hypervisor MAY use the source address for authorization if they > do not implement additional security features. > > 4. Intended Use > > The intended use of this new ONC RPC transport is Network File System (NFS) > v4.1 (RFC5661 [3]) to export file systems from the hypervisor into virtual > machines. Other RPC services could also be used with the hypervisor offering > the service to the virtual machine or vice versa. > > The need for an AF_VSOCK transport arises because management tools require the > ability to deploy RPC services for virtual machines in an automated fashion. > Existing TCP/IP network interface configuration, including firewall > configuration, is difficult to automate without risk of interfering with the > virtual machine owner's networking configuration. AF_VSOCK provides a > zero-configuration communications channel with the dedicated purpose of > communicating between a hypervisor and virtual machines without these > configuration difficulties. > > 5. Network addresses > > AF_VSOCK addresses contain an unsigned 32-bit integer called the Context > Identifier (CID) that is the network address. An unsigned 32-bit integer port > number acts as the transport selector so that multiple services can be offered > on a single network address. > > CID values in the range [0, 2] are reserved. Virtual machines are assigned > values outside this range. The hypervisor exposes services on the well-known > CID value 2. > > Ports in the range [0, 1023] are privileged and can only be bound by programs > that have sufficient privilege. > > 6. Netid for AF_VSOCK > > The netid for AF_VSOCK is given in Table 1. > > +---------+----------+-------------------------------+------+------+ > | Netid | Constant | RFC(s) and Description (if | PoC | CR | > | | Name | needed) | | | > +---------+----------+-------------------------------+------+------+ > | "vsock" | NC_VSOCK | Netid for AF_VSOCK. | IESG | TBD1 | > | | | Section 6 of RFC TBD1. | | | > +---------+----------+----------------------------- -+------+------+ > > PoC: Point of Contact. > > CR: Cross Reference to the Uaddr Format Registry. > > Table 1: Netid for AF_VSOCK > > 7. Uaddr Format for AF_VSOCK > > The format of the uaddr for AF_VSOCK is the US-ASCII string: > > cid.port > > The "cid" prefix is the ASCII-decimal representation of the CID network > address. The "port" suffix is the ASCII-decimal representation of the > port number transport selector. > > +-------+------------------------------------+------+-------+ > | Basis | Description and/or Reference | PoC | CR | > +-------+------------------------------------+------+-------+ > | STDS | Uaddr format for AF_VSOCK. | IESG | TBD1 | > | | Section 7 of RFC TBD1. | | | > +-------+------------------------------------+------+-------+ > > Table 2: Uaddr format for AF_VSOCK > > 8. Record Marking > > AF_VSOCK sockets of type SOCK_STREAM are used for connection-oriented, > in-order, guaranteed delivery semantics. These bytestream semantics require > that RPC messages are delimited so message boundaries can be detected. > > The Record Marking Standard, defined in RFC 1831 Section 10 [4], is used for > this purpose. > > 9. References > > [1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", > RFC 1833, August 1995. > > [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [3] Eisler, M., "IANA Considerations for Remote Procedure Call (RPC) > Network Identifiers and Universal Address Formats", RFC 5665, > January 2010. > > [4] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification > Version 2", RFC 1831, August 1995. Hi Stefan- There's no need for a bulky Cc: list. Everyone (except perhaps Daniel) is already on linux-nfs@xxxxxxxxxxxxxxx. Please use xml2rfc to ensure the document is properly formatted, and can be efficiently converted to HTML, PDF, and other forms. https://xml2rfc.tools.ietf.org There are XML versions of personal drafts that you can copy to get started, at the bottom of this page: https://datatracker.ietf.org/wg/nfsv4/documents/ You need to state somewhere that the VSOCK/SOCK_STREAM transport guarantees reliable and ordered delivery of bytes. NFSv4 requires this (see RFC 5661, Section 2.9.1). AF_VSOCK is not a transport, it's an address family. A shorter and more precise title might be "Remote Procedure Call (RPC) on VSOCK Sockets". Ensure that the text (and any discussion of this I-D) uses the term AF_VSOCK appropriately. I prefer the term "VSOCK sockets" for this purpose. The Security Considerations section needs a description of your threat model, IMO, and it belongs at the end of the document, not at the front of it. What kind of attacks is VSOCK designed to prevent? You need to mention what AUTH flavors are supported on this transport, and which are not. Are there any changes expected to the credentials for these supported formats? If no GSS flavors are supported, please explain in the Security Considerations section how deployments can avoid attacks. An unchanging public reference to a specification of VSOCK is important to cite. If you can't find one, you'll have to explain why in the document. If the VSOCK specification is not an IETF document, it will have to be an Informative reference, and this I-D will also have to be Informative. Sections 5, 6, and 7 should be made subsections of a single section entitled "IANA Considerations", which should follow the Security Considerations section. Especially the current section 5 needs to cite something that specifies the behavior and structure of AF_VSOCK addresses, IMO. You might want to make an explicit statement about whether RPC functions with the SOCK_DATAGRAM flavor of VSOCK, or if this mode of operation is explicitly not to be used. Or, you might want to ensure it can be supported in the future by reserving a netid for it in this document. You must have your company's permission to contribute this I-D to the IETF, and you must be clear about any existing Intellectual Property related to VSOCK that you or your company owns. http://trustee.ietf.org/trust-legal-provisions.html If you're not clear about what this means, consult your company's legal counsel. -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
