Remote Procedure Call over QUIC Version 1

Remote Procedure Call over QUIC Version 1 Red Hat

United States of America bcodding@redhat.com

Red Hat

United States of America smayhew@redhat.com

Oracle Corporation

United States of America chuck.lever@oracle.com

Transport Network File System Version 4 This document specifies a protocol for conveying Remote Procedure (RPC) messages on QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. Note This note is to be removed before publishing as an RFC. Discussion of this draft occurs on the NFSv4 working group mailing list, archived at . Working Group information is available at . Submit suggestions and changes as pull requests at . Instructions are on that page.

Introduction QUIC is a reliable, connection-oriented network transport protocol that is designed to be general-purpose and secure . Its features include integrated transport layer security, multiple streams over each connection, fast reconnect, and robust recovery from packet loss and network congestion. Open Network Computing Remote Procedure Call (often shortened to "RPC") is a Remote Procedure Call protocol that runs over a variety of network transports . RPC implementations so far use UDP or TCP . This document specifies how to transport RPC messages over QUIC version 1.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

RPC-over-QUIC Framework RPC is first and foremost a message-passing protocol. This section covers the implementaion details of exchanging RPC messages over QUICv1. Readers should already be familiar with ONC RPC .

Transport Layer Security RPC-over-QUIC provides peer authentication and encryption services using a framework based on Transport Layer Security (TLS). Ergo, RPC-over-QUIC inherently fulfills many of the requirements of . The details of QUIC's use of TLS are specified in . In particular:

With QUICv1, security at the transport layer is always enabled. Thus, there is no need or use for the STARTTLS mechanism described in .
The discussion in about the opportunistic use of TLS does not apply to RPC-over-QUIC.
The peer authentication requirements in do apply to RPC-over-QUIC.
The PKIX Extended Key Usage values defined in are also valid for use with RPC-over-QUIC.
The ALPN defined in is also used for RPC-over-QUIC.

RPC Message Framing Record marking on QUIC is exactly as in TCP. See .

Discussion: This is the simplest thing to do. bfields: Open question whether we should do something more complicated that adds RDMA-like features or at least provides some minimal help with data alignment. Possibilities might include a single additional integer giving the offset of a payload, serving only as a hint; or reference additional streams in the same connection for payloads; or even looking into full RDMA--long-term there may be interest in supporting RDMA over QUIC, and we may be able to piggyback on that effort. cel: Direct data placement over TCP can already be accomplished today using MPA/DDP protocols (formerly known as iWARP). Using a software iWARP implementation means no special hardware is necessary. Likewise, if MPA/DDP can be made to support QUIC, much of the need for a separate RPC-over-QUIC is moot. In addition, it would bring automatically transport layer security to other RDMA-enabled protocols (such as RPC-over-RDMA). lars: If changes to the RPC-over-QUIC binding might be desired in the future, how would they be negotiated/expressed? Should a versioned ALPN be used instead of the one from ?

Connections and Streams QUIC provides a "stream" abstraction, described in . Each QUIC stream can be unidirectional or bidirectional. QUIC supports a nearly unlimited number of concurrent streams per connection. Unless explicitly specified, when RPC protocol specifications refer to a "connection", this applies to a QUIC connection, not to a stream. As an example, in the case of NFSv4.1 , a BIND_CONN_TO_SESSION operation binds a QUIC connection and does not need to be repeated for each stream on the connection. An RPC Reply MUST be sent over the same connection and stream as the Call message with a matching XID. Forward-direction RPC messages MUST be sent over a client-initiated bidirectional stream (stream type 0x00). Reverse-direction RPC messages MUST be sent over a server-initiated bidirectional stream (stream type 0x01). Otherwise, unless otherwise explicitly specified, RPC callers are free to use streams as they wish, and responders have to accommodate callers that do so.

Implementation Status This section is to be removed before publishing as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. There are no known implementations of RPC-over-QUICv1 as described in this document.

Security Considerations Readers should refer to the discussion of QUIC's transport layer security in .

IANA Considerations RFC Editor: In the following subsections, please replace RFC-TBD with the RFC number assigned to this document. Furthermore, please remove this Editor's Note before this document is published.

Netids for RPC-over-QUIC Each new RPC transport is assigned one or more RPC "netid" strings. These strings are an rpcbind string naming the underlying transport protocol, appropriate message framing, and the format of service addresses and ports, among other things. This document requests that IANA allocate the following "Netid" registry strings in the "ONC RPC Netid" registry, as defined in : These netids MUST be used for any transport satisfying the requirements described in this document. The "quic" netid is to be used when IPv4 addressing is employed by the underlying transport, and "quic6" for IPv6 addressing. IANA should use this document (RFC-TBD) as the reference for the new entries.

References Normative References Towards Remote Procedure Call Encryption By Default Hammerspace Inc Oracle Corporation This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption of Remote Procedure Call (RPC) transactions while they are in-transit. The proposed mechanism interoperates with ONC RPC implementations that do not support it. This document updates RFC 5531. Binding Protocols for ONC RPC Version 2 This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK] RPC: Remote Procedure Call Protocol Specification Version 2 This document describes the Open Network Computing (ONC) Remote Procedure Call (RPC) version 2 protocol as it is currently deployed and accepted. This document obsoletes RFC 1831. [STANDARDS-TRACK] IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833. [STANDARDS-TRACK] QUIC: A UDP-Based Multiplexed and Secure Transport This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Using TLS to Secure QUIC This document describes how Transport Layer Security (TLS) is used to secure QUIC. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References User Datagram Protocol Transmission Control Protocol Improving Awareness of Running Code: The Implementation Status Section This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Network File System (NFS) Version 4 Minor Version 1 Protocol This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661.

Acknowledgments The authors express their deepest appreciation for the contributions of J. Bruce Fields who was an original author of this document. In addition, we are indebted to Lars Eggert and the QUIC working group for the creation of the QUIC transport protocol. The editor is grateful to Bill Baker, Greg Marsden, and Martin Thomson for their input and support. Special thanks to Transport Area Directors Martin Duke and Zaheduzzaman Sarker, NFSV4 Working Group Chairs David Noveck and Brian Pawlowski, and NFSV4 Working Group Secretary Thomas Haynes for their guidance and oversight.