A Transport Services Mapping for QUIC

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 20 September 2022.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document defines a Transport Services mapping, as defined in [I-D.ietf-taps-impl] for the QUIC protocol [RFC9000]. This mapping, presented in Section 3, allows QUIC to be used with the calls defined in the Transport Services API [I-D.ietf-taps-interface].¶

This mapping treats a single QUIC stream as a Transport Services Connection object, since this is an equivalent abstraction to the byte-stream abstractions offered by TCP or TLS over TCP. QUIC streams are multiplexed within QUIC connections; a QUIC connection is represented in the Transport Services API as a Connection Group.¶

2. Conventions and Definitions

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. QUIC Stream Mapping

Connectedness: Multiplexing Connected¶

Data Unit: Byte-stream¶

Connection Object:

A Connection object in the Transport Services API maps to a single QUIC stream between two hosts. This stream can be bidirectional or unidirectional.¶

Initiate:

Calling Initiate on a QUIC stream Connection causes the implementation to prepare a new QUIC stream to the Remote Endpoint. If there is already a QUIC connection to the Remote Endpoint, Initiate simply prepares a new stream by allocating a stream ID. If there is not already a QUIC connection established, the implementation will establish a connection first.¶

InitiateWithSend:

Early data sent in InitiateWithSend will be used for 0-RTT QUIC connection establishment, if the QUIC connection to the Remote Endpoint is not already established and the local device has previously negotiated support for 0-RTT establishment with the Remote Endpoint.¶

Ready:

A QUIC stream Connection is ready once the underlying QUIC connection is established, and once a stream ID can be allocated. This may be delayed if stream creation is blocked due to reaching the maximum streams limit.¶

InitiateError:

QUIC can throw various errors during connection setup (handshake failure, timeouts, etc). Errors for Initiate will represent QUIC connection-level errors. Once a QUIC connection is established, allocation of a QUIC stream ID may be delayed, but will not generate an error.¶

ConnectionError:

Once created, a QUIC stream Connection throws an error whenever the stream is disconnected, such as when a RESET_STREAM frame is receieved.¶

Listen:

Calling Listen for QUIC binds to a local UDP port and prepare to receive inbound QUIC connections and streams.¶

ConnectionReceived:

QUIC listeners will deliver each inbound QUIC stream as a Connection object. The relationship of inbound streams to other streams in a single QUIC connection can be detected by checking Connection.GroupedConnections().¶

Clone:

Cloning a QUIC stream Connection creates a new stream on an existing QUIC connection. This new stream will inherently share all parameters with the original stream.¶

Send:

Sending data will generate a STREAM frame using the stream ID assigned to the Connection object.¶

Receive:

Calling Receive will indicate that the caller is ready to receive data from this stream, which is sent by the peer in STREAM frames using the stream ID assigned to the Connection object. Data is delivered in either the Recieved or RecievedPartial event.¶

Close:

Calling Close on a QUIC stream Connection indicates that the stream should gracefully closed by setting the FIN bit on the stream.¶

Abort:

Calling Close on a QUIC stream Connection indicates that the stream should closed immediately, by sending a RESET_STREAM frame.¶

CloseGroup:

Calling CloseGroup on any QUIC stream in a Connection Group indicates that the shared QUIC connection should be closed using a CONNECTION_CLOSE frame once all open streams have completed.¶

AbortGroup:

Calling AbortGroup on any QUIC stream in a Connection Group indicates that the shared QUIC connection should be closed immediately using a CONNECTION_CLOSE frame.¶

4. Security Considerations

The security properties of a QUIC connection are expressed in the QUIC handshake, and thus are shared amongst all streams on a single QUIC connection. When used with the Transport Services API, security parameters are expressed in the Preconnection object. Connection objects used for QUIC streams MUST only be grouped with other QUIC streams when the security parameters defined in the Preconnection objects are identical or equivalent.¶

5. IANA Considerations

This document has no IANA actions.¶

Author's Address