Internet-Draft RPC over QUIC July 2022
Coddington, et al. Expires 6 January 2023 [Page]
Workgroup:
Network File System Version 4
Internet-Draft:
draft-cel-nfsv4-rpc-over-quicv1-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. Coddington
Red Hat
S. Mayhew
Red Hat
C. Lever, Ed.
Oracle

Remote Procedure Call over QUIC Version 1

Abstract

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 https://mailarchive.ietf.org/arch/browse/nfsv4/. Working Group information is available at https://datatracker.ietf.org/wg/nfsv4/about/.

Submit suggestions and changes as pull requests at https://github.com/chucklever/i-d-rpc-over-quicv1. Instructions are on that page.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 6 January 2023.

Table of Contents

1. Introduction

QUIC is a reliable, connection-oriented network transport protocol that is designed to be general-purpose and secure [RFC9000]. 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 [RFC5531]. RPC implementations so far use UDP [RFC0768] or TCP [RFC0793]. This document specifies how to transport RPC messages over QUIC version 1.

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. 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 [RFC5531].

3.1. 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 [I-D.ietf-nfsv4-rpc-tls]. The details of QUIC's use of TLS are specified in [RFC9001]. In particular:

3.2. RPC Message Framing

Record marking on QUIC is exactly as in TCP. See Section 11 of [RFC5531].

3.3. Connections and Streams

QUIC provides a "stream" abstraction, described in Section 2 of [RFC9000]. 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 [RFC8881], 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.

4. 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 [RFC7942]. 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.

5. Security Considerations

Readers should refer to the discussion of QUIC's transport layer security in Section 21 of [RFC9000].

6. 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.

6.1. Netids for RPC-over-QUIC

Each new RPC transport is assigned one or more RPC "netid" strings. These strings are an rpcbind [RFC1833] 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 [RFC5665]:

      NC_QUIC    "quic"
      NC_QUIC6   "quic6"

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.

7. References

7.1. Normative References

[I-D.ietf-nfsv4-rpc-tls]
Myklebust, T. and C. Lever, "Towards Remote Procedure Call Encryption By Default", Work in Progress, Internet-Draft, draft-ietf-nfsv4-rpc-tls-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-rpc-tls-11>.
[RFC1833]
Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, DOI 10.17487/RFC1833, , <https://www.rfc-editor.org/rfc/rfc1833>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5531]
Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, , <https://www.rfc-editor.org/rfc/rfc5531>.
[RFC5665]
Eisler, M., "IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats", RFC 5665, DOI 10.17487/RFC5665, , <https://www.rfc-editor.org/rfc/rfc5665>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9001]
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, , <https://www.rfc-editor.org/rfc/rfc9001>.

7.2. Informative References

[RFC0768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://www.rfc-editor.org/rfc/rfc768>.
[RFC0793]
Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, , <https://www.rfc-editor.org/rfc/rfc793>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8881]
Noveck, D., Ed. and C. Lever, "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 8881, DOI 10.17487/RFC8881, , <https://www.rfc-editor.org/rfc/rfc8881>.

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.

Authors' Addresses

Benjamin Coddington
Red Hat
United States of America
Scott Mayhew
Red Hat
United States of America
Charles Lever (editor)
Oracle Corporation
United States of America