QUIC Q. Misell Internet-Draft AS207960 Intended status: Standards Track 4 March 2024 Expires: 5 September 2024 Extensible Address Validation Tokens for QUIC draft-misell-quic-ex-token-latest Abstract This document describes a method to extend QUIC address validation tokens to include structured data that a client can parse and make use of. The initial application envisioned in this document is signalling congestion control parameters for use with Careful Resume. 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 5 September 2024. Copyright Notice Copyright (c) 2024 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 1.1. Requirements Language 2. Extensible Tokens 2.1. Extensible token signalling 2.2. Invalid Extensible tokens 2.3. Extension design 3. BDP Tokens 3.1. Client interaction 3.2. Invalid BDP tokens 4. IANA Considerations 4.1. QUIC Transport Parameters 4.2. QUIC Transport Error Codes 4.3. QUIC Extensible Token Extension IDs 5. Security Considerations 6. References 6.1. Normative References 6.2. Informative References Appendix A. Example method for protecting the BDP Token's Private Data Field Author's Address 1. Introduction This document defines a method to extend QUIC address validation tokens to have structure, so that a client can parse them, and optionally make use of additional information within the token, depending on the nature of the extensions in use. The initial application for this is envisioned to be allowing a QUIC server to send calculated Congestion Control parameters to a client for storage and later use on a future connection with Careful Resume [I-D.ietf-tsvwg-careful-resume]. 1.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 [BCP14] when, and only when, they appear in all capitals, as shown here. 2. Extensible Tokens QUIC [RFC9000] defines an address validation token as an opaque blob that the client should not inspect. This document extends this by providing structure to the token, allowing arbitrary fields to be defined on the token by this and future documents. A QUIC client unaware of this document will still be able to make use of extensible tokens without modification, although it will do nothing but pass the entire token back to the server unmodified. The format of an extensible token is defined as follows: BDP Token { Address Validation Length (i), Address Validation (..), Extension ID (i), Extension Data Length (i), Extension Data (..), ... } Figure 1: Extensible Token The fields are as follows: Address Validation Length A variable-length integer specifying the length of the Address Validation field, in bytes. A value of 0 indicates that the server is not using address validation and is using the token purely for extensible information. Address Validation Opaque information specific to the server that it will use for address validation. The construction of this field MUST comply with the requirements of [RFC9000] section 8.1. Extension ID A variable-length integer specifying the ID of the extension. The registry for these IDs is defined in the IANA Considerations section of this document. Extension Data Length A variable-length integer specifying the length of the Extension Data field, in bytes. Extension Data A byte field containing the data for the extension. Extension ID, Extension Data Length, and Extension Data can be repeated as many times as needed to include desired extensions. Extension IDs MUST NOT appear multiple times in a token. 2.1. Extensible token signalling The server can send extended tokens to all clients without further negotiation. However a client needs some way to know that there is meaningful structure to a token its received from the server. To this end a new transport parameter is defined. ex_token (04143414213370002) The ex_token transport parameter is a boolean value that indicates that the server is using extensible tokens. It can have the following values: - 0, default value: Extensible Tokens are not in use. - 1: Extensible Tokens are in use. 2.2. Invalid Extensible tokens If the server is unable to decode the token received from the client, or vise versa, this MUST be treated as the connection error EX_TOKEN_ERROR (0x4143414213370002). 2.3. Extension design As an extensible token is designed to be presented to clients that may not be aware of what an extensible token is, all extensions defined for extensible tokens MUST be designed such that it can handle its data being echoed back to the server unmodified on a future connection. 3. BDP Tokens This document defines the BDP_TOKEN extension, designed to Congestion Control information for use in Careful Resume [I-D.ietf-tsvwg-careful-resume]. The format of a token extension containing BDP information is defined as follows: BDP Token { Private Data Length (i), Private Data (..), Capacity (i), RTT (i), Requested Capacity (i), } Figure 2: BDP Token The fields are as follows: Private Data Length A variable-length integer specifying the length of the Private Data field, in bytes. A value of 0 indicates that the server does not intend to store Congestion Control data on the client, and that the Capacity and RTT fields are merely informative. Private Data Opaque information specific to the server that it will use to prime its congestion controller state. This field SHOULD contain expiration/lifetime information, and any additional information that the server may need to validate that the same path is being used, such as an endpoint token as defined in Careful Resume [I-D.ietf-tsvwg-careful-resume]. The data MUST be signed, or otherwise protected against modification by the client. If the data contains information that could potentially be used to fingerprint the client, it MUST be encrypted, or otherwise protected against inspection by wire observers. An example method for protecting the Private Data field is provided in Appendix A. Capacity The estimated capacity of the path in bytes (congestion window), encoded as a variable-length integer. RTT The RTT of the path in microseconds, encoded as a variable- length integer. Requested capacity In a token sent by the server, this field is set to the same value as the Capacity field. If the client becomes aware of a change in the available bandwidth of the path, it can adjust this field to request a lower capacity be used by the server when priming its congestion controller state. 3.1. Client interaction If the client becomes aware of a change in the available bandwidth of the path, it can use the Requested Capacity field to signal to the server a change it its available bandwidth. The server MUST not accept a value higher than that of the Capacity field, as this could cause an overload of the network path. If the client sets the Requested Bandwidth field to 0 then it is signalling that the server should not attempt to prime its congestion controller from previous state and should instead treat this connection as an entirely new congestion control context. 3.2. Invalid BDP tokens If a server or client is unable to decode the token received as a valid BDP token then this MUST be treated as a connection error BDP_TOKEN_ERROR (0x4143414213370003). A token which is merely expired MUST NOT trigger a connection error, instead it should be silently discarded. 4. IANA Considerations 4.1. QUIC Transport Parameters Per this document, one new entry has been added to the "QUIC Transport Parameters" registry defined in [RFC9000] section 22.3. This entry is defined below: +============+=============+===============+================+ | Value | Status | Specification | Parameter name | +============+=============+===============+================+ | 0x41434142 | Provisional | This document | ex_token | | 13370002 | | | | +------------+-------------+---------------+----------------+ Table 1: New Transport Parameter entries 4.2. QUIC Transport Error Codes Per this document, two new entries have been added to the "QUIC Transport Error Codes" registry defined in [RFC9000] section 22.5. This entry is defined below: +==========+===========+=================+===========+=============+ |Value |Status | Code |Description|Specification| +==========+===========+=================+===========+=============+ |0x41434142|Provisional| EX_TOKEN_ERROR |The |This document| |13370002 | | |extensible | | | | | |token | | | | | |received is| | | | | |invalid. | | +----------+-----------+-----------------+-----------+-------------+ |0x41434142|Provisional| BDP_TOKEN_ERROR |The BDP |This document| |13370003 | | |token | | | | | |received is| | | | | |invalid. | | +----------+-----------+-----------------+-----------+-------------+ Table 2: New Transport Error Code entries 4.3. QUIC Extensible Token Extension IDs Per this document, a new registry for "QUIC Extensible Token Extension IDs" is created under the "QUIC" heading defined in [RFC9000] section 22. In addition to the fields listed in [RFC9000] section 22.1.1, permanent registrations in this registry MUST include the following field: Extension name A short mnemonic for the extension type. +=======+================+===============+ | Value | Extension name | Specification | +=======+================+===============+ | 0x01 | BDP_TOKEN | Section 3 | +-------+----------------+---------------+ Table 3: Initial QUIC Extensible Token Extension IDs Entries Each value of the form 31 * N + 26 for integer values of N (that is, 26, 57, 88, ...) are reserved for private use; these values are to be treated as opaque blobs meaningful only to the server operator. Each value of the form 31 * N + 27 for integer values of N (that is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. 5. Security Considerations The Congestion Control data MUST be protected against manipulation by malicious or mis-behaving clients. A client that can modify Congestion Control data could cause an overload of the network path. 6. References 6.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . 6.2. Informative References [I-D.ietf-tsvwg-careful-resume] Kuhn, N., Emile, S., Fairhurst, G., Secchi, R., and C. Huitema, "Convergence of Congestion Control from Retained State", Work in Progress, Internet-Draft, draft-ietf- tsvwg-careful-resume-07, 16 February 2024, . [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . Appendix A. Example method for protecting the BDP Token's Private Data Field This section is non-normative. Consider the following private data structure: Private Data { IP Address (16 bytes), Expiry Timestamp (8 bytes) } Figure 3: BDP Private Data This structure contains information that could be used to track a client (its previous IP address), and therefore MUST be protected from inspection by wire observers. Additionally the Capacity and RTT fields MUST be protected from modification by a client. To this end this example uses the ChaCha20-Poly1305 [RFC8439] cipher with additional data. The ChaCha20-Poly1305 cipher encrypts data, and protects the encrypted data as well as additional unencrypted data against modification. The additional data has the following structure: Additional Data { Saved Capacity (8 bytes), Saved RTT (16 bytes) } Figure 4: BDP Additional Data After encryption the 12 byte nonce is appended to the Private Data structure to allow the encryption to be reversed when the token is later used. Author's Address Q Misell AS207960 Cyfyngedig 13 Pen-y-lan Terrace Caerdydd CF23 9EU United Kingdom Email: q@as207970.net, q@magicalcodewit.ch URI: https://magicalcodewit.ch