BDP_Frame Extension

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 24 April 2024.¶

Copyright Notice

Copyright (c) 2023 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 extends the Careful Resume method [I-D.ietf-tsvwg-careful-resume] to allow sender-generated CC parameters to be stored at the receiver. Transfering the CC parameters to a receiver, can release the sender from needing to retain CC parameter state for each receiver. This also allows a receiver to implement a policy that informs a sender whether the receiver desires the sender to reuse previously saved CC parameters.¶

It defines the method to exchange the CC parameters between a QUIC receiver and the sender in an interoperable manner. The process is outlined here:¶

1. For an established connection, the current RTT, measured capacity and receiver Endpoint Token are computed and are respectively stored as the saved_rtt, saved_capacity and saved_endpoint_token. These are placed within a BDP_FRAME. The sender also computes a secured hash over these CC parameters and sends this within the BDP_FRAME.¶

2. The receiver can read the non-encrypted portion of the BDP_FRAME parameters. It cannot verify the hash and is not permitted to modify any CC parameters.¶

3. At a later time, the receiver sends the BDP-FRAME to the sender to re-use previously computed CC parameters.¶

4. Upon reception, the sender MUST verify the hash, and only use the CC parameters when valid. This is to prevent a receiver from modifying the parameters. The sender is able to utilise the CC parameters in a received BDP_FRAME when it is connected to the same endpoint.¶

2. Notation and Terms

• BDP: Bandwdith Delay Product of the path (maximum path capacity);¶

• saved_capacity: The capacity preserved from a previous connection;¶

• saved_rtt: The preserved minimum RTT, corresponding to the minimum of a set RTT of measurements taken at the time when the saved_capacity was estimated;¶

• endpoint_token: An Endpoint Token for a receiver;¶

• secured hash: hash generated by the sender using a list of CC parameters that it selected. The sender uses a private key to protect the hash.¶

3. BDP_Frame

This section describes the use of a new QUIC Frame, the BDP_FRAME. This can be utilized by the congestion controller in the Careful Resume method.¶

Sending a BDP_FRAME is not be limited by flow control limits. The sender and the receiver MAY send multiple BDP_FRAMEs in both 1-RTT and 0-RTT connections. The rate of update SHOULD be limited (e.g., much less frequent than once for several RTTs).¶

The format of a BDP_FRAME is shown in Figure 1.¶

BDP_FRAME {
  Type (i) = 0xXXX,
  Hash (...),
  Lifetime (i),
  Saved Capacity (i),
  Saved RTT (i),
  Saved Endpoint Token (...)
}

This contains the following fields:¶

• Hash (secured_hash): The secured_hash is generated by the sender using CC parameters from the BDP_FRAME. The sender encrypts the hash to prevent the receiver from reading it, and allow the sender bto verify that the contents were not changed.¶

• Lifetime (extension_lifetime): The extension_lifetime is a value in milliseconds, encoded as a variable-length integer. This follows the design of a NewSessionTicket of TLS [RFC8446]. This represents the validity in time of this extension.¶

• Saved capacity estimate (saved_capacity): The saved_capacity is a value in bytes, encoded as a variable-length integer. The available capacity can be estimated for the previous connection by the sender. Using the previous values of bytes_in_flight defined in [RFC9002] can result in overshoot of the bottleneck capacity, and ought to be used carefully. It is advised to not only use the amount of bytes in flight, but also the goodput.¶

• Saved RTT (saved_rtt): The saved_rtt is a value in milliseconds, encoded as a variable-length integer. The saved_rtt is set to the min_rtt. NOTE: The min_rtt defined in [RFC9002], does not track a decreasing RTT: therefore the min_rtt reported might be larger than the actual minimum RTT measured during the 1-RTT connection.¶

• Saved Endpoint Token (saved_endpoint_token) : Note: The Endpoint Token is defined in [I-D.ietf-tsvwg-careful-resume], and is discussed in the context of this protocol exchange in a later section.¶

4. Discussion

A receiver using the BDP_FRAME extension has the choice of allowing the reuse of the previous CC parameters, or requesting the sender to not reuse these parameters.¶

This extension MUST NOT provide an opportunity for the current connection to be a vector for an amplification attack. The QUIC address validation process, used to prevent amplification attacks, SHOULD be performed [RFC9000].¶

The CC parameters are measured by the sender by observing a previous connection to the same receiver. During transmission, the BDP_Frame is protected by the mechanism that protects the exchange of the 0-RTT transport parameters. For version 1 of QUIC, the this is protected using the mechanism that already protects the "initial_max_data" parameter. This is defined in sections 4.5 to 4.7 of [RFC9001]. It provides a way for the sender to verify that the CC parameters proposed by the receiver are the same as those that the sender sent to the receiver during a previous connection.¶

Although a BDP_Frame is encrypted on transmission, a receiver could modify the value of the received CC parameters. The sender detects this by adding a secured hash over the CC parameters. If the receiver modifies any CC parameter, the result of the hash would be different. If a sender fails to veridy the secured hash, it MUST not use the CC parameters.¶

An example of an implementation where the sender computes an Endpoint Token that seeks to uniquely identify the receiver is provided in Section 4.3. The implementation details are independent from the specification of BDP_Frame.¶

5. Acknowledgments

The authors thank Gabriel Montenegro, Patrick McManus, Ian Swett, Igor Lubashev, Robin Marx, Roland Bless and Franklin Simo for their fruitful comments on earlier versions of this document.¶

The authors particularly thank Tom Jones for co-authoring previous versions of this document.¶

6. IANA Considerations

{XXX-Editor note: Text is required to register the BDP_Frame and the enable_bdp transport parameter. Parameters are registered using the procedure defined in [RFC9000].}¶

TBD: Text is required to register the BDP_FRAME and the enable_bdp transport parameter. Parameters are registered using the procedure defined in [RFC9000].¶

7. Security Considerations

Security considerations for the CC method are discussed in the Security Considerations section of Careful Resume.¶

Appendix A. Change Log

This section to be rmeoved prior to publication.¶

• -00 Introduced session tickets and BDP_Frames¶

• -01 Reviewed receiver actions when a receiver holds CC parameters¶

• -02 Interim version to align with terminology in Careful Resume¶

• -03 Rewritten to align with Careful Resume and use the BDP_Frame method. Removed annexe 1, and discussion of session tickets, prefering BDP Frames.¶

Authors' Addresses