idnits 2.17.1 draft-stefanha-nfsv4-rpc-over-vsock-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2017) is 2339 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 156 -- Looks like a reference, but probably isn't: '2' on line 152 -- Looks like a reference, but probably isn't: '1023' on line 156 -- Obsolete informational reference (is this intentional?): RFC 5661 (Obsoleted by RFC 8881) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 S. Hajnoczi, Ed. 3 Internet-Draft Red Hat, Inc. 4 Intended status: Informational November 23, 2017 5 Expires: May 27, 2018 7 Remote Procedure Call (RPC) over AF_VSOCK 8 draft-stefanha-nfsv4-rpc-over-vsock-00 10 Abstract 12 This document describes how to transfer Remote Procedure Call (RPC) 13 messages over AF_VSOCK sockets. This allows RPC services such as 14 Network File System (NFS) to operate over AF_VSOCK. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 27, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Status of AF_VSOCK . . . . . . . . . . . . . . . . . . . . . 2 52 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 4. Intended Use . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Network Addresses . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Use of netids for AF_VSOCK . . . . . . . . . . . . . . . . . 4 56 7. Uaddr Format for AF_VSOCK . . . . . . . . . . . . . . . . . . 4 57 8. Record Marking on Connection-oriented Sockets . . . . . . . . 4 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 10.1. Netids for AF_VSOCK . . . . . . . . . . . . . . . . . . 5 61 10.2. Uaddr Format for AF_VSOCK . . . . . . . . . . . . . . . 6 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 11.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The AF_VSOCK address family facilitates socket communication between 70 a hypervisor and virtual machines running on the hypervisor. It was 71 implemented in Linux 3.9 with initial support for VMware. Further 72 hypervisor support was added for KVM and Hyper-V later. AF_VSOCK 73 services can run on any supported hypervisor because semantics remain 74 the same across hypervisors. 76 ONC RPC services are bound to transport addresses [RFC1833]. 77 Transport addresses are described by network identifiers (netids) and 78 universal address strings. This standard representation of transport 79 addresses allows address information to be communicated between 80 client programs and RPC services, including the RPCBIND program. 82 It is necessary to define a network identifier and universal address 83 representation so that ONC RPC may be used over AF_VSOCK. This 84 document describes string representations for the AF_VSOCK netids and 85 universal addresses. 87 2. Status of AF_VSOCK 89 This section provides background information that may help reviewers 90 suggest how to proceed with this document. It is not intended to be 91 included unchanged in the final document. 93 The Linux AF_VSOCK address family does not have a specification 94 document. AF_VSOCK is purely an implementation that first became 95 available in Linux in 2013. 97 The Linux community generally uses VMware's AF_VSOCK driver as a 98 reference for how sockets should behave. This tends to mirror TCP 99 for SOCK_STREAM and UDP for SOCK_DGRAM so that porting applications 100 from AF_INET to AF_VSOCK is easy. 102 There is currently momentum towards creating a man page for AF_VSOCK 103 and a shared test suite. This will provide a stronger basis for both 104 users and implementors to work from in the future. 106 VMware has published reference documentation to their own API, which 107 is called vSockets and encompasses additional header files and APIs 108 not shipped as part of Linux. For the purposes of this document the 109 VMware material is out of scope but might be interesting to those 110 wishing to see a manual on using the vSockets technology that is 111 based on AF_VSOCK: https://code.vmware.com/doc/preview?id=5521. 113 This raises the question of how this document should reference 114 AF_VSOCK since no external document exists. 116 3. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119] [RFC8174] 121 when, and only when, they appear in all capitals, as shown here. 123 4. Intended Use 125 The intended use of RPC over AF_VSOCK is Network File System (NFS) 126 v4.1 [RFC5661] to export file systems from the hypervisor into 127 virtual machines. It is possible that other RPC services will also 128 be offered by hypervisors to virtual machines. 130 RPC services can also be provided by virtual machines to the host. 131 Such software is often called a guest agent. 133 The need for RPC over AF_VSOCK arises because management tools 134 require the ability to deploy RPC services for virtual machines in an 135 automated fashion. Existing TCP/IP network interface configuration, 136 including firewall configuration, is difficult to automate without 137 risk of interfering with the virtual machine owner's networking 138 configuration. AF_VSOCK provides a zero-configuration communications 139 channel with the dedicated purpose of communicating between a 140 hypervisor and virtual machines without these configuration 141 difficulties. This makes it possible to deploy RPC services without 142 requiring manual steps by hypervisor and virtual machine 143 administrators. 145 5. Network Addresses 147 AF_VSOCK addresses contain an unsigned 32-bit integer called the 148 Context Identifier (CID) that is the network address. An unsigned 149 32-bit integer port number acts as the transport selector so that 150 multiple services can be offered on a single network address. 152 CID values in the range [0, 2] are reserved. Virtual machines are 153 assigned values outside this range. The hypervisor has the well- 154 known CID value 2. 156 Ports in the range [0, 1023] are privileged and can only be bound by 157 programs that have sufficient privilege. 159 6. Use of netids for AF_VSOCK 161 Initial use of RPC over AF_VSOCK is expected to be over connection- 162 oriented sockets since NFS v4.1 [RFC5661] requires reliable, in-order 163 delivery offered by AF_VSOCK connection-oriented sockets. The 164 possibility of using datagram sockets in the future is acknowledged 165 by also reserving a netid for this purpose. 167 7. Uaddr Format for AF_VSOCK 169 The format of the uaddr for AF_VSOCK is the US-ASCII string: 171 cid.port 173 The "cid" prefix is the ASCII-decimal representation of the CID 174 network address. The "port" suffix is the ASCII-decimal 175 representation of the port number transport selector. 177 8. Record Marking on Connection-oriented Sockets 179 Connection-oriented AF_VSOCK sockets have in-order, guaranteed 180 delivery semantics. RPC messages must be delimited so that message 181 boundaries can be detected. The Record Marking Standard, defined in 182 [RFC5531], is used for this purpose since connection-oriented 183 AF_VSOCK sockets are byte streams. 185 9. Security Considerations 187 AF_VSOCK addresses are local to the hypervisor that the virtual 188 machine is running on. Traffic is point-to-point with no routing or 189 forwarding through components external to the hypervisor. This makes 190 AF_VSOCK traffic immune to eavesdropping, replay, message insertion, 191 deletion, modification, and man-in-the-middle attacks as long as the 192 virtual machine and hypervisor are not compromised. 194 Source address (CID) spoofing by the virtual machine is not possible 195 because the hypervisor enforces the virtual machine's assigned 196 address. RPC services running on the hypervisor MAY use the source 197 CID for authentication since it cannot be faked. 199 The privileged port range prevents unprivileged processes from 200 binding to low-numbered ports. The privileged port range is a scarce 201 resource but MAY be used to authenticate privileged processes. This 202 allows messages from unprivileged processes to be refused or treated 203 as unathenticated. In particular, RPC AUTH_UNIX authentication MUST 204 only be trusted when the RPC message was sent from a privileged port. 206 Only AUTH_NULL and AUTH_UNIX flavors are supported although [RFC5531] 207 states that "Standards Track RPC services MUST mandate support for 208 RPCSEC_GSS". Due to the point-to-point nature of AF_VSOCK described 209 above, there are different security considerations than for RPC 210 services deployed on the Internet or even on local networks. RPC 211 services provided by the hypervisor establish the identity of the 212 client by inspecting the source CID and port number. An NFS service 213 facilitates access to an exported file system for which the virtual 214 machine has authorization. The AUTH_UNIX uid and gid are used for 215 NFS file operations but do not give the client access to other 216 virtual machine's file systems. Therefore isolation can be achieved 217 with just AUTH_UNIX. 219 10. IANA Considerations 221 10.1. Netids for AF_VSOCK 223 IANA is asked to assign the following netids from the ONC RPC Netids 224 Registry [RFC5665] on a Standards Action basis: 226 +----------+-----------+------------------------------+------+------+ 227 | Netid | Constant | RFC(s) and Description | PoC | CR | 228 | | Name | | | | 229 +----------+-----------+------------------------------+------+------+ 230 | "vsockc" | NC_VSOCKC | Netid for AF_VSOCK | IESG | TBD1 | 231 | | | connection-oriented sockets. | | | 232 | | | Section 6 of this document. | | | 233 | "vsockd" | NC_VSOCKD | Netid for AF_VSOCK datagram | IESG | TBD1 | 234 | | | sockets. Section 6 of this | | | 235 | | | document. | | | 236 +----------+-----------+------------------------------+------+------+ 238 PoC: Point of Contact. CR: Cross Reference to the Uaddr Format 239 Registry. 241 Table 1: Netids for AF_VSOCK 243 10.2. Uaddr Format for AF_VSOCK 245 IANA is asked to assign the following uaddr format from the ONC RPC 246 Uaddr Format Registry [RFC5665] on a Standards Action basis: 248 +-------+---------------------------------------------+------+------+ 249 | Basis | Description and/or Reference | PoC | CR | 250 +-------+---------------------------------------------+------+------+ 251 | STDS | Uaddr format for AF_VSOCK. Section 7 of | IESG | TBD1 | 252 | | this document. | | | 253 +-------+---------------------------------------------+------+------+ 255 PoC: Point of Contact. CR: Cross Reference to the Uaddr Format 256 Registry. 258 Table 2: Uaddr format for AF_VSOCK 260 11. References 262 11.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 270 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 271 May 2017, . 273 11.2. Informative References 275 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 276 RFC 1833, DOI 10.17487/RFC1833, August 1995, 277 . 279 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 280 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 281 May 2009, . 283 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 284 "Network File System (NFS) Version 4 Minor Version 1 285 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 286 . 288 [RFC5665] Eisler, M., "IANA Considerations for Remote Procedure Call 289 (RPC) Network Identifiers and Universal Address Formats", 290 RFC 5665, DOI 10.17487/RFC5665, January 2010, 291 . 293 Author's Address 295 Stefan Hajnoczi (editor) 296 Red Hat, Inc. 297 100 East Davie Street 298 Raleigh, NC 27601 299 USA 301 Email: stefanha@redhat.com