idnits 2.17.1 draft-cel-nfsv4-rpc-over-quicv1-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 (7 January 2022) is 839 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network File System Version 4 B. Coddington 3 Internet-Draft S. Mayhew 4 Intended status: Standards Track Red Hat 5 Expires: 11 July 2022 C. Lever, Ed. 6 Oracle 7 7 January 2022 9 Remote Procedure Call over QUIC Version 1 10 draft-cel-nfsv4-rpc-over-quicv1-00 12 Abstract 14 This document specifies a protocol for conveying Remote Procedure 15 (RPC) messages on QUIC version 1 connections. It requires no 16 revision to application RPC protocols or the RPC protocol itself. 18 Note 20 This note is to be removed before publishing as an RFC. 22 Discussion of this draft occurs on the NFSv4 working group mailing 23 list (nfsv4@ietf.org), archived at 24 https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group 25 information is available at https://datatracker.ietf.org/wg/nfsv4/ 26 about/. 28 Submit suggestions and changes as pull requests at 29 https://github.com/chucklever/i-d-rpc-over-quicv1. Instructions are 30 on that page. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 11 July 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 67 3. RPC-over-QUIC Framework . . . . . . . . . . . . . . . . . . . 3 68 3.1. Transport Layer Security . . . . . . . . . . . . . . . . 3 69 3.2. RPC Message Framing . . . . . . . . . . . . . . . . . . . 4 70 3.3. Connections and Streams . . . . . . . . . . . . . . . . . 4 71 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 6.1. Netids for RPC-over-QUIC . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 7.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 QUIC is a reliable, connection-oriented network transport protocol 84 that is designed to be general-purpose and secure [RFC9000]. Its 85 features include integrated transport layer security, multiple 86 streams over each connection, fast reconnect, and robust recovery 87 from packet loss and network congestion. 89 Open Network Computing Remote Procedure Call (often shortened to 90 "RPC") is a Remote Procedure Call protocol that runs over a variety 91 of network transports [RFC5531]. RPC implementations so far use UDP 92 [RFC0768] or TCP [RFC0793]. This document specifies how to transport 93 RPC messages over QUIC version 1. 95 | Explain motivations: 96 | 97 | * TLS 98 | 99 | * Multiple streams--though applications are speculative at 100 | this point. (Maybe they will allow more sophisticated 101 | prioritization of traffic without the overhead of 102 | multiple TCP connections?) 103 | 104 | * Lower-latency connection setup--though NFS connections 105 | are typically long-lived. 106 | 107 | * Likely SMB adoption of QUIC should make QUIC 108 | implementations widely available. 109 | 110 | In addition, this section needs to document and demonstrate 111 | specific use cases that cannot be addressed using existing RPC 112 | transports and security mechanisms such as RPC-over-TCP, RPC- 113 | with-TLS, or RPC-over-RDMA. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. RPC-over-QUIC Framework 125 RPC is first and foremost a message-passing protocol. This section 126 covers the implementaion details of exchanging RPC messages over 127 QUICv1. Readers should already be familiar with ONC RPC [RFC5531]. 129 3.1. Transport Layer Security 131 RPC-over-QUIC provides peer authentication and encryption services 132 using a framework based on Transport Layer Security (TLS). Ergo, 133 RPC-over-QUIC inherently fulfills many of the requirements of 134 [I-D.ietf-nfsv4-rpc-tls]. The details of QUIC's use of TLS are 135 specified in [RFC9001]. In particular: 137 * With QUICv1, security at the transport layer is always enabled. 138 Thus, there is no need or use for the STARTTLS mechanism described 139 in Section 4 of [I-D.ietf-nfsv4-rpc-tls]. 141 * The discussion in [I-D.ietf-nfsv4-rpc-tls] about the opportunistic 142 use of TLS does not apply to RPC-over-QUIC. 144 * The peer authentication requirements in Section 5.2 of 145 [I-D.ietf-nfsv4-rpc-tls] do apply to RPC-over-QUIC. 147 * The PKIX Extended Key Usage values defined in 148 [I-D.ietf-nfsv4-rpc-tls] are also valid for use with RPC-over- 149 QUIC. 151 * The ALPN defined in Section 8.2 of [I-D.ietf-nfsv4-rpc-tls] is 152 also used for RPC-over-QUIC. 154 3.2. RPC Message Framing 156 Record marking on QUIC is exactly as in TCP. See Section 11 of 157 [RFC5531]. 159 | Discussion: This is the simplest thing to do. 160 | 161 | bfields: Open question whether we should do something more 162 | complicated that adds RDMA-like features or at least provides 163 | some minimal help with data alignment. Possibilities might 164 | include a single additional integer giving the offset of a 165 | payload, serving only as a hint; or reference additional 166 | streams in the same connection for payloads; or even looking 167 | into full RDMA--long-term there may be interest in supporting 168 | RDMA over QUIC, and we may be able to piggyback on that effort. 169 | 170 | cel: Direct data placement over TCP can already be accomplished 171 | today using MPA/DDP protocols (formerly known as iWARP). Using 172 | a software iWARP implementation means no special hardware is 173 | necessary. Likewise, if MPA/DDP can be made to support QUIC, 174 | much of the need for a separate RPC-over-QUIC is moot. In 175 | addition, it would bring automatically transport layer security 176 | to other RDMA-enabled protocols (such as RPC-over-RDMA). 177 | 178 | lars: If changes to the RPC-over-QUIC binding might be desired 179 | in the future, how would they be negotiated/expressed? Should 180 | a versioned ALPN be used instead of the one from 181 | [I-D.ietf-nfsv4-rpc-tls]? 183 3.3. Connections and Streams 185 QUIC provides a "stream" abstraction, described in Section 2 of 186 [RFC9000]. Each QUIC stream can be unidirectional or bidirectional. 187 QUIC supports a nearly unlimited number of concurrent streams per 188 connection. 190 Unless explicitly specified, when RPC protocol specifications refer 191 to a "connection", this applies to a QUIC connection, not to a 192 stream. As an example, in the case of NFSv4.1 [RFC8881], a 193 BIND_CONN_TO_SESSION operation binds a QUIC connection and does not 194 need to be repeated for each stream on the connection. 196 An RPC Reply MUST be sent over the same connection and stream as the 197 Call message with a matching XID. Forward-direction RPC messages 198 MUST be sent over a client-initiated bidirectional stream (stream 199 type 0x00). Reverse-direction RPC messages MUST be sent over a 200 server-initiated bidirectional stream (stream type 0x01). Otherwise, 201 unless otherwise explicitly specified, RPC callers are free to use 202 streams as they wish, and responders have to accommodate callers that 203 do so. 205 | NFS requirement on resends: QUIC allows reconnecting using the 206 | same connection ID, so isn't breaking/reconnection somewhat 207 | ambiguous? When can a server drop or a client resend? Any 208 | advice needed for server-side DRC implementations? 209 | 210 | lars: I'm not sure I understand what is meant by "reconnecting" 211 | above. Is this referring to connection migration? Or a 0-RTT 212 | repeated connection instance? Something else? 213 | 214 | lars: Also, I'm not sure if the use of streams is fully 215 | specified by the above. Is the intent here to leave it to 216 | callers to decide if they want to use a fresh stream for each 217 | RPC, or reuse an existing stream for a series of RPCs? 219 4. Implementation Status 221 This section is to be removed before publishing as an RFC. 223 This section records the status of known implementations of the 224 protocol defined by this specification at the time of posting of this 225 Internet-Draft, and is based on a proposal described in [RFC7942]. 226 The description of implementations in this section is intended to 227 assist the IETF in its decision processes in progressing drafts to 228 RFCs. 230 Please note that the listing of any individual implementation here 231 does not imply endorsement by the IETF. Furthermore, no effort has 232 been spent to verify the information presented here that was supplied 233 by IETF contributors. This is not intended as, and must not be 234 construed to be, a catalog of available implementations or their 235 features. Readers are advised to note that other implementations may 236 exist. 238 There are no known implementations of RPC-over-QUICv1 as described in 239 this document. 241 5. Security Considerations 243 Readers should refer to the discussion of QUIC's transport layer 244 security in Section 21 of [RFC9000]. 246 6. IANA Considerations 248 RFC Editor: In the following subsections, please replace RFC-TBD with 249 the RFC number assigned to this document. Furthermore, please remove 250 this Editor's Note before this document is published. 252 6.1. Netids for RPC-over-QUIC 254 Each new RPC transport is assigned one or more RPC "netid" strings. 255 These strings are an rpcbind [RFC1833] string naming the underlying 256 transport protocol, appropriate message framing, and the format of 257 service addresses and ports, among other things. 259 This document requests that IANA allocate the following "Netid" 260 registry strings in the "ONC RPC Netid" registry, as defined in 261 [RFC5665]: 263 NC_QUIC "quic" 264 NC_QUIC6 "quic6" 266 These netids MUST be used for any transport satisfying the 267 requirements described in this document. The "quic" netid is to be 268 used when IPv4 addressing is employed by the underlying transport, 269 and "quic6" for IPv6 addressing. IANA should use this document (RFC- 270 TBD) as the reference for the new entries. 272 | lars: Why one per IP address family? This seems common 273 | practice with netids, but also seems to be a layering 274 | violation? 276 7. References 278 7.1. Normative References 280 [I-D.ietf-nfsv4-rpc-tls] 281 Myklebust, T. and C. Lever, "Towards Remote Procedure Call 282 Encryption By Default", Work in Progress, Internet-Draft, 283 draft-ietf-nfsv4-rpc-tls-11, 23 November 2020, 284 . 287 [RFC1833] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", 288 RFC 1833, DOI 10.17487/RFC1833, August 1995, 289 . 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 297 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 298 May 2009, . 300 [RFC5665] Eisler, M., "IANA Considerations for Remote Procedure Call 301 (RPC) Network Identifiers and Universal Address Formats", 302 RFC 5665, DOI 10.17487/RFC5665, January 2010, 303 . 305 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 306 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 307 May 2017, . 309 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 310 Multiplexed and Secure Transport", RFC 9000, 311 DOI 10.17487/RFC9000, May 2021, 312 . 314 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 315 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 316 . 318 7.2. Informative References 320 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 321 DOI 10.17487/RFC0768, August 1980, 322 . 324 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 325 RFC 793, DOI 10.17487/RFC0793, September 1981, 326 . 328 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 329 Code: The Implementation Status Section", BCP 205, 330 RFC 7942, DOI 10.17487/RFC7942, July 2016, 331 . 333 [RFC8881] Noveck, D., Ed. and C. Lever, "Network File System (NFS) 334 Version 4 Minor Version 1 Protocol", RFC 8881, 335 DOI 10.17487/RFC8881, August 2020, 336 . 338 Acknowledgments 340 The authors express their deepest appreciation for the contributions 341 of J. Bruce Fields who was an original author of this document. In 342 addition, we are indebted to Lars Eggert and the QUIC working group 343 for the creation of the QUIC transport protocol. 345 The editor is grateful to Bill Baker, Greg Marsden, and Martin 346 Thomson for their input and support. 348 Special thanks to Transport Area Directors Martin Duke and 349 Zaheduzzaman Sarker, NFSV4 Working Group Chairs David Noveck and 350 Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for 351 their guidance and oversight. 353 Authors' Addresses 355 Benjamin Coddington 356 Red Hat 357 United States of America 359 Email: bcodding@redhat.com 361 Scott Mayhew 362 Red Hat 363 United States of America 365 Email: smayhew@redhat.com 367 Charles Lever (editor) 368 Oracle Corporation 369 United States of America 371 Email: chuck.lever@oracle.com