QUIC H. Shi Internet-Draft Huawei Technologies Intended status: Standards Track 4 March 2024 Expires: 5 September 2024 Structured Connection ID Carrying Metadata draft-shi-quic-structured-connection-id-02 Abstract This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://VMatrix1900.github.io/draft-quic-structured-connection-id/ draft-shi-quic-structured-connection-id.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- shi-quic-structured-connection-id/. Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-quic-structured-connection-id. 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. Shi Expires 5 September 2024 [Page 1] Internet-Draft Structured Connection ID March 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Structured Connection ID . . . . . . . . . . . . . . . . . . 4 5. Coexistence with QUIC Load Balancer . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Nowadays, media applications are usually able to dynamically adjust the size and quality of the stream to adapt to fluctuating network conditions. However, for the high throughput and low latency media traffic, adaptation only by the endpoint is not good enough, especially when the network condition is challenging, such as the wireless networks discussed in [I-D.kaippallimalil-tsvwg-media-hdr-wireless] and [I-D.defoy-moq-relay-network-handling]. To this end, it is desirable to have the intermediary performing optimization for the endpoint. For example, low-priority packets can be dropped to save the resource when the network is congested. One example of such an intermediary is the relay in the Media over QUIC working group. To quote the charter from the MoQ working group. "Media over QUIC (moq) will develop a simple low-latency media delivery solution for ingest and distribution of media. This solution addresses use cases including live streaming, gaming, and media conferencing and will scale efficiently." "Even when media content is end-to-end encrypted, the relays can access metadata needed for caching (such as timestamp), making media forwarding decisions (such as drop or delay under congestion), and so on." Shi Expires 5 September 2024 [Page 2] Internet-Draft Structured Connection ID March 2024 Due to the end-to-end encryption of the QUIC, the intermediary does not have the necessary metadata to perform optimization. A similar problem exists when the media is encrypted and transferred using SRTP [RFC3711]. To solve the problem, [I-D.ietf-avtext-framemarking] defines an extension of the RTP header containing the video frame information. This document defines an extension of the QUIC header, using the connection ID to carry the necessary metadata. To mitigate the linkability between the multiple connection IDs of the same connection and protect privacy, the metadata MAY be encrypted and only decrypted by an authenticated intermediary. Similar to [I-D.ietf-quic-load-balancers], a configuration agent is used to distribute the encryption parameters and the template of the metadata. 2. Terminology This document uses terms in the [I-D.ietf-quic-load-balancers]: * "client" and "server" refer to the QUIC endpoint. * Intermediary refers to a network element that forwards QUIC packets and does not possess the QUIC connection keys. Such an intermediary can be QUIC proxy defined in the MASQUE working group, wireless node described in the [I-D.kaippallimalil-tsvwg-media-hdr-wireless], and relay defined in the Media over QUIC working group. * CID: Connection ID in the QUIC header. * Configuration agent: An entity that distributes the encryption parameter and the template of the metadata field. All wire formats will be depicted using the notation defined in Section 1.3 of [RFC9000]. 2.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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Architecture Shi Expires 5 September 2024 [Page 3] Internet-Draft Structured Connection ID March 2024 + --------------+ | Configuration | +-------------------+ agent +-------------------+ / +------+--------+ \ /Config Parameters and template of the Metadata field in CID\ / | \ / _______ | _______ \ +---V----+ ( ) +------v-------+ ( ) +-----v----+ | Client +----( Network )----+ Intermediary +----( Network )----+ Server | +--------+ (_______) +--------------+ (_______) +----------+ Figure 1: Architecture of the intermediary Figure 1 shows the architecture of the optimization intermediary. The sender, which can be either the client or server based on the direction of communication, incorporates metadata into the connection ID field as outlined in the referenced section (See Section 4). This metadata allows the intermediary to execute optimizations tailored to the information provided. Given that various applications may require the disclosure of distinct metadata to the intermediary, a standardized template is adopted to specify the metadata's content and structure. There are two primary methods for obtaining this template: 1. For each category of application, a specific template is crafted and cataloged within a new IANA registry. This approach leverages the global accessibility of the template definition, eliminating the need for its distribution by the configuration agent. The responsibility for developing these templates falls to the respective working groups or documents, which is beyond the scope of this document. 2. The configuration agent, operating within its domain, defines and disseminates the template. This strategy ensures the template's relevance and effectiveness is confined to the domain under the agent's control, tailored according to the capabilities of the network devices present. If the network between the intermediary and endpoints is not trusted, the metadata MUST be encrypted. In such scenarios, the encryption parameters must be exclusively shared with authenticated intermediaries, potentially via the configuration agent. A viable encryption strategy might involve adopting the algorithm proposed in [I-D.ietf-quic-load-balancers], ensuring the security of the metadata. 4. Structured Connection ID Shi Expires 5 September 2024 [Page 4] Internet-Draft Structured Connection ID March 2024 Structured Connection ID { Config Parameters (8), Metadata (40...152), } Figure 2: Format of structured CID The format of the structured connection ID is shown in Figure 2. The content and the format of the metadata field are defined by a template, carrying the information such as media characteristics in Section 3.1 of [I-D.ietf-avtext-framemarking], the service requirement such as delay and importance in Section 3 of [I-D.kaippallimalil-tsvwg-media-hdr-wireless-04]. 5. Coexistence with QUIC Load Balancer As both the Metadata and Server ID share the same field within the Connection ID (CID), it's crucial to devise mechanisms that prevent conflicts and ensure their seamless coexistence. If an intermediary serves dual roles as both the load balancer and the optimization node, and if both entities are underpinned by a unified trust relationship, then it is feasible to consolidate the Metadata and the Server ID specified in [I-D.ietf-quic-load-balancers]. This consolidation allows for the utilization of a singular Config Parameter and a shared encryption/ decryption methodology. Conversely, if the load balancer and the optimization node are separated, the Server ID and the Metadata needs to be segregated too. One option is to split the CID into two segments: one for the Server ID and the other for the metadata. Each segment would be governed by its own set of Config Parameters and subjected to individual encryption protocols, ensuring the integrity and segregation of the transmitted information. 6. Security Considerations TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Shi Expires 5 September 2024 [Page 5] Internet-Draft Structured Connection ID March 2024 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 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, . 7.2. Informative References [I-D.defoy-moq-relay-network-handling] de Foy, X. and R. Krishna, "MOQ Relays for Support of High-Throughput Low-Latency Traffic", Work in Progress, Internet-Draft, draft-defoy-moq-relay-network-handling-01, 23 January 2023, . [I-D.ietf-avtext-framemarking] Zanaty, M., Berger, E., and S. Nandakumar, "Video Frame Marking RTP Header Extension", Work in Progress, Internet- Draft, draft-ietf-avtext-framemarking-15, 26 July 2023, . [I-D.ietf-quic-load-balancers] Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating Routable QUIC Connection IDs", Work in Progress, Internet- Draft, draft-ietf-quic-load-balancers-19, 5 February 2024, . [I-D.kaippallimalil-tsvwg-media-hdr-wireless] Kaippallimalil, J., Gundavelli, S., and S. Dawkins, "Media Handling Considerations for Wireless Networks", Work in Progress, Internet-Draft, draft-kaippallimalil-tsvwg- media-hdr-wireless-04, 14 February 2024, . [I-D.kaippallimalil-tsvwg-media-hdr-wireless-04] Kaippallimalil, J., Gundavelli, S., and S. Dawkins, "Media Handling Considerations for Wireless Networks", Work in Shi Expires 5 September 2024 [Page 6] Internet-Draft Structured Connection ID March 2024 Progress, Internet-Draft, draft-kaippallimalil-tsvwg- media-hdr-wireless-04, 14 February 2024, . Author's Address Hang Shi Huawei Technologies China Email: shihang9@huawei.com Shi Expires 5 September 2024 [Page 7]