Network Working Group D. Wing Internet-Draft Cloud Software Group Intended status: Standards Track T. Reddy Expires: 16 March 2024 Nokia M. Boucadair Orange 13 September 2023 CID Flow Indicator (CIDFI) draft-wing-cidfi-02 Abstract Conveying metadata about network conditions and metadata about individual packets can improve the user experience especially on wireless networks which suffer bandwidth and delay variability. This document describes how clients and servers can cooperate with network elements so their QUIC and DTLS streams can be augmented with information about network conditions and packet importance. 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://danwing.github.io/cidfi/draft-wing-cidfi.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wing-cidfi/. Discussion of this document takes place on the ART Area Working Group mailing list (mailto:art@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/art/. Subscribe at https://www.ietf.org/mailman/listinfo/art/. Source for this draft and an issue tracker can be found at https://github.com/danwing/cidfi. 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/. Wing, et al. Expires 16 March 2024 [Page 1] Internet-Draft CIDFI September 2023 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 16 March 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 2.1. Notations . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Network Preparation . . . . . . . . . . . . . . . . . . . . . 6 4.1. DNS SVCB Records . . . . . . . . . . . . . . . . . . . . 6 4.2. Provisioning Domains . . . . . . . . . . . . . . . . . . 7 4.3. DHCP or 3GPP PCO . . . . . . . . . . . . . . . . . . . . 7 5. Client Operation on Network Attach or Topology Change . . . . 7 5.1. Client Learns Local Network Supports CIDFI . . . . . . . 7 5.1.1. Client Learns Using DNS SVCB . . . . . . . . . . . . 8 5.1.2. Client Learns Using Provisioning Domain . . . . . . . 8 5.1.3. Client Learns Using DHCP or 3GPP PCO . . . . . . . . 8 5.2. Client Authorizes CIDFI Network Elements . . . . . . . . 8 6. Client Operation on Each Connection to a QUIC Server . . . . 9 6.1. Client Learns Server Supports CIDFI . . . . . . . . . . . 9 6.2. Client Proves Ownership of its UDP 4-Tuple . . . . . . . 10 6.2.1. STUN CIDFI-NONCE Attribute . . . . . . . . . . . . . 11 6.3. Initial Metadata Exchange . . . . . . . . . . . . . . . . 12 6.3.1. Server to Network Elements . . . . . . . . . . . . . 14 6.3.2. Network Element to Server . . . . . . . . . . . . . . 14 6.4. Ongoing Metadata Exchange . . . . . . . . . . . . . . . . 15 7. Interaction with Load Balancers . . . . . . . . . . . . . . . 15 8. Topology Change . . . . . . . . . . . . . . . . . . . . . . . 16 9. Details of Metadata Exchanged . . . . . . . . . . . . . . . . 16 Wing, et al. Expires 16 March 2024 [Page 2] Internet-Draft CIDFI September 2023 9.1. Server to CIDFI-aware Network Element . . . . . . . . . . 16 9.1.1. Mapping Metadata Parameters to DCIDs . . . . . . . . 16 9.1.2. Mapping DiffServ Code Point (DSCP) to DCIDs . . . . . 17 9.2. CIDFI-aware Network Element to Server . . . . . . . . . . 17 10. Discussion Points . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Client versus Server Signaling CID-to-importance Mapping . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. Overhead of QUIC DCID Packet Examination . . . . . . . . 18 10.3. Interaction with Wi-Fi Packet Aggregation . . . . . . . 18 10.4. Overhead of Mapping CIDs to Packet Metadata . . . . . . 18 10.5. Improve CIDFI Initialization Time . . . . . . . . . . . 18 10.6. Primary QUIC Channel CID Change {#primary-cid-change}: . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12.1. New QUIC Transport Parameter . . . . . . . . . . . . . . 20 12.2. New Well-known URI "cidfi-aware" . . . . . . . . . . . . 20 12.3. New Special-use Domain Name . . . . . . . . . . . . . . 20 12.4. New DNS Service Binding (SVCB) . . . . . . . . . . . . . 20 12.5. New STUN Attribute . . . . . . . . . . . . . . . . . . . 20 12.6. New Provisioning Domain Additional Information Key . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Extending CIDFI to Other Protocols . . . . . . . . . 25 A.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 A.2. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.3. RTP and SRTP . . . . . . . . . . . . . . . . . . . . . . 26 A.4. Bespoke UDP Application Protocols . . . . . . . . . . . . 26 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction Senders rely on ramping up their transmission rate until they encounter packet loss or see [ECN] indicating they should level off or slow down their transmission rate. This feedback takes time and contributes to poor user experience when the sender over- or under- shoots the actual available bandwidth, especially if the sender changes fidelity of the content (e.g., improves video quality which consumes more bandwidth which then gets dropped by the network). Due to network constraints a network element will need to drop or even prioritize a packet ahead of other packets. The decision of which packet to drop or prioritize is improved if the network element knows the importance of the packet. Metadata carried in each packet can influence that decision to improve the user experience. Wing, et al. Expires 16 March 2024 [Page 3] Internet-Draft CIDFI September 2023 This document defines CIDFI (pronounced "sid fye") which is a system of several protocols that allow communicating about a [QUIC] connection or a DTLS connection [DTLS-CID] from the network to the server and the server to the network. The information exchanged allows the server to know about network conditions and allows the server to signal packet importance. Figure 1 provides a sample network diagram of a CIDFI system showing two bandwidth-constrained networks (or links) depicted by "B" and CIDFI-aware devices immediately upstream of those links, and another bandwidth-constrained link between a smartphone handset and its Radio Access Network (RAN). This diagram shows the same protocol and same mechanism can operate with or without 5G, and can operate with different administrative domains such as Wi-Fi, an ISP edge router, and a 5G RAN. | | | +------+ +------+ | +------+ | | |CIDFI-| |CIDFI-| | |CIDFI-| | | |aware | |aware | | |aware | +------+ | | |client+-B-+Wi-Fi +-B-+edge +--+router+------+ | +------+ |access| | |router| +------+ | | | +--------+ |point | | +------+ | | | | CIDFI- | +------+ | | +-+----+ | | aware | | | |router+---+ QUIC or| +---------+ | +------+ | +-+----+ | | DTLS | | CIDFI- | | |CIDFI-| | | | | server | | aware | | |aware | +------+ | | | +--------+ | client +-----B-----+RAN +--+router+------+ | |(handset)| | |router| +------+ | | +---------+ | +------+ | | | | | | | transit | server user network | ISP network | network | network Figure 1: Network Diagram The CIDFI-aware client establishes a TLS connection with the CIDFI- aware network elements (Wi-Fi access point, edge router, and RAN router in the above diagram). Over this connection it receives network performance information and it sends mapping of (QUIC or DTLS) Destination CIDs to packet importance. The design creates new state in the CIDFI-aware network elements for mapping from the QUIC Destination CID or DTLS Destination CID to the packet importance, bandwidth information for that connection towards the client, and for the TLS-encrypted communication with the client. Wing, et al. Expires 16 March 2024 [Page 4] Internet-Draft CIDFI September 2023 Section 6.3.2 describes network-to-server signaling similar to the use case described in Section 2 of [I-D.joras-sadcdn], with metadata relaying through the client. Section 6.3.1 describes server-to-network metadata signaling similar to the use cases described in Section 3 of [I-D.joras-sadcdn]. The server-to-network metadata signaling can also benefit [I-D.ietf-avtcore-rtp-over-quic] and [DTLS-CID]. A discussion of extending CIDFI to other protocols is provided in Appendix A. 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. CID: Connection Identifier used by [QUIC] or by [DTLS-CID]. CNE: CIDFI-aware Network Element, a network element that supports this CIDFI specification. This is usually a router. 2.1. Notations For discussion purposes, JSON is used in the examples to give a flavor of the data that the client retrieves from a CNE. The authors anticipate using a more efficient encoding such as [CBOR]. 3. Design Goals This section highlights the design goals of this specification. Client Authorization: The client authorizes each CIDFI-aware network element (CNE) to participate in CIDFI for each QUIC or DTLS flow. Same Server: Communication about the network metadata arrives over the primary QUIC or DTLS connection which ensures it arrives at the same server instance even through local network translators (NAT) or server-side load balancers. Privacy: The packet importance is only known by CIDFI-aware network elements (CNE). The network performance data is protected by TLS. Integrity: The packet importance is mapped to Destination CIDs which Wing, et al. Expires 16 March 2024 [Page 5] Internet-Draft CIDFI September 2023 are integrity protected by QUIC (or DTLS) itself and cannot be modified by on-path network elements. The communication between client, server, and network element is protected by TLS. Internet Survival: The QUIC (or DTLS) communications between the client and server are not changed so CIDFI is expected to work wherever QUIC (or DTLS) works. The elements involved are only the QUIC (or DTLS) client and server and with the participating CIDFI network elements. 4. Network Preparation The network is configured to advertise its support for CIDFI. For this step, four mechanisms are described in this document: DNS SVCB records, IPv6 Provisioning Domains (PvD), DHCP, and 3GPP PCO. These are described below. Standardizing on all or some of these mechanisms is for further discussion. 4.1. DNS SVCB Records This document defines a new DNS Service Binding "cidfi-aware" in Section 12.4 and a new Special-Use Domain Name "cifi.arpa" in Section 12.3. The local network is configured to respond to DNS SVCB [I-D.ietf-dnsop-svcb-https] queries with ServiceMode (Section 2.4.3 of [I-D.ietf-dnsop-svcb-https]) for _cidfi-aware.cidfi.arpa with the DNS names of that network's and upstream network's CIDFI-aware network elements (CNEs). If upstream networks also support CIDFI (e.g., the ISP network) those SVCB records are aggregated into the local DNS server's response by the local network's recursive DNS resolvers. For example, a query for _cidfi-aware.cidfi.arpa might return two answers for the two CNEs on the local network, one belonging to the local ISP (example.net) and the other belonging to the local Wi-Fi network (example.com), _cidfi-aware.cidfi.arpa. 7200 IN SVCB 0 service-cidfi.example.net. ( alpn=h3 cidfipathauth=/path-auth-query {?cidfi} cidfimetadata=/cidfi-metadata ) _cidfi-aware.cidfi.arpa. 7200 IN SVCB 0 wifi.example.com. ( alpn=h3 cidfipathauth=/path-auth-query {?cidfi} cidfimetadata=/cidfi-metadata ) Wing, et al. Expires 16 March 2024 [Page 6] Internet-Draft CIDFI September 2023 When multihoming, the multihome-capable CPE aggregates all upstream networks' _cidfi-aware.cidfi.arpa responses into the response sent to its locally-connected clients. 4.2. Provisioning Domains The CIDFI networks are configured to set the H-flag so clients can request PvD Additional Information (Section 4.1 of [RFC8801]). The application/pvd+json returned looks like this when there are two CIDFI-aware network elements, service-cidfi and wi-fi, {"cidfi":[ {"cidfinode": "service-cidfi.example.net", "cidfipathauth": "/path-auth-query {?cidfi}", "cidfimetadata": "/cidfi-metadata"}, {"cidfinode": "wi-fi.example.net", "cidfipathauth": "/path-auth-query {?cidfi}", "cidfimetadata": "/cidfi-metadata"}]} Multiple CIDFI-aware network elements on a network path will require propagating the Provisioning Domain Additional Information. For example, a CIDFI-aware Wi-Fi access point connected to a CIDFI-aware 5G network will require the information for both CIDFI networks be available to the client, in a single Provisioning Domain Additional Information request. This means the Wi-Fi access point has to obtain that information so the Wi-Fi access point can provide both the 5G network's information and the Wi-Fi access point's information. 4.3. DHCP or 3GPP PCO The network is configured to respond to DHCPv6, DHCPv4 sub-option, or 3GPP PCO (Protocol Configuration Option) Information Element. 5. Client Operation on Network Attach or Topology Change On initial network attach topology change (see Section 8), the client learns if the network supports CIDFI (Section 5.1) and authorizes those network elements (Section 5.2). 5.1. Client Learns Local Network Supports CIDFI For this step, four mechanisms are identified: DNS SVCB records, IPv6 Provisioning Domains (PvD), DHCP, or 3GPP PCO. These are described below. Standardizing on all or some of these mechanisms is for further discussion. Wing, et al. Expires 16 March 2024 [Page 7] Internet-Draft CIDFI September 2023 In all cases below, * if the discovery succeeds (i.e., the client concludes that the local and/or ISP network support CIDFI) client processing proceeds to Section 5.2. * if the discovery failed (i.e., the client concludes that the local network and ISP do not support CIDFI) client processing stops. 5.1.1. Client Learns Using DNS SVCB The client determines if the local network provides CIDFI service by issuing a query to the local DNS server for "_cidfi- aware.cidfi.arpa." with the SVCB resource record type (64) [I-D.ietf-dnsop-svcb-https]. 5.1.2. Client Learns Using Provisioning Domain The client determines if the local network supports CIDFI by querying https:///.well-known/pvd as described in Section 4.1 of [RFC8801]. 5.1.3. Client Learns Using DHCP or 3GPP PCO The client determines that a local network is CIDFI-capable if the client receives an explicit signal from the network, e.g., via a dedicated DHCP option or a 3GPP PCO (Protocol Configuration Option) Information Element. An example of explicit signal would be a DHCPv6 option or DHCPv4 sub-option that that is returned as part of [RFC7839]. 5.2. Client Authorizes CIDFI Network Elements The response from the previous step in Section 5.1 will contain one or more CNEs. The client authorizes each of the CNEs using a local policy. This policy is implementation specific. An implementation example might have the users authorize their ISP's CIDFI server (e.g., allow "cidfi.example.net" if a user's ISP is configured with "example.net"). Similarly, if none of the CNEs are recognized by the client, the client might silently avoid using CIDFI on that network. After authorizing that subset of CNEs, the client makes a new HTTPS connection to each of those CNEs and performs PKIX validation of their certificates. The client MAY have to authenticate itself to the CIDFI network element. Wing, et al. Expires 16 March 2024 [Page 8] Internet-Draft CIDFI September 2023 The client then obtains the CIDFI nonce and CIDFI HMAC secret from each network element used later in Section 6.2 to prove the client owns its UDP 4-tuple. {"cidfi-path-authentication":[ {"nonce":"ddqwohxGZysgy0BySNh7sNHV5IH9RbE7rqXmg9wb9Npo", "hmac-secret":"jLNsCvuU59mt3F4/ePD9jbZ932TfsLSOP2Nx3XnUqc8v"}]} 6. Client Operation on Each Connection to a QUIC Server When a QUIC client (or {DTLS-CID}) client connects to a QUIC (or {DTLS-CID}) server, the client: 1. learns the server supports CIDFI and obtains its mapping of transmitted destinations CID to metadata. 2. proves ownership of its UDP 4-tuple to the on-path network elements. 3. performs initial metadata exchange with the CIDFI network element and server, and server and network element. 4. continually updates the server and the CIDFI network element whenever new information is received from the other party. These steps are described in more detail below. Note: the client is also a sender, and can also perform all these functions in its direction. This functionality will be expanded in later versions of this document. For example, a mobile device connected to Wi-Fi with 5G backhaul might be running an interactive audio/video application and want to indicate to its internal Wi-Fi driver and to the 5G modem its mapping from its transmitted QUIC Destination CID to per-packet metadata and the application can benefit from receiving network performance metrics. 6.1. Client Learns Server Supports CIDFI On initial connection to a QUIC server, the client includes a new QUIC transport parameter CIDFI (Section 12.1) which is remembered for 0-RTT. If the server does not indicate CIDFI support, CIDFI processing stops. Wing, et al. Expires 16 March 2024 [Page 9] Internet-Draft CIDFI September 2023 If the server indicates CIDFI support, then the server creates a new Server-Initiated, Bidirectional QUIC stream which is dedicated to CIDFI communication. This stream number is communicated in the CIDFI transport response during the QUIC handshake. TODO: specify how CIDFI stream number is communicated to client. The QUIC client and QUIC server exchange CIDFI information over this CIDFI-dedicated stream as described in Section 6.3. 6.2. Client Proves Ownership of its UDP 4-Tuple To ensure that the client messages to the CNE pertain only to the client's own UDP 4-tuple, the client sends the CIDFI nonce protected by the HMAC secret it obtained from Section 5.2 over the QUIC UDP 4-tuple it is using with the QUIC server. The ability to transmit that packet on the same UDP 4-tuple as the QUIC connection indicates ownership of that IP address and UDP port. The nonce and HMAC are sent in a [STUN] indication (STUN class of 0b01) containing one or more CIDFI-NONCE attributes (Section 12.5). If there are multiple CNE the single STUN indication contains a CIDFI-NONCE attribute from each of them. This message is discarded by the QUIC server. The figure below shows a summarized message flow obtaining the nonce and HMAC secret from the CNE then later sending the nonce and HMAC in the same UDP 4-tuple towards the QUIC server: Wing, et al. Expires 16 March 2024 [Page 10] Internet-Draft CIDFI September 2023 QUIC CIDFI-aware QUIC client edge router server | | | | HTTPS: Enroll CIDFI router to participate | +----------------------------------->| | | HTTPS: Ok. nonce=12345 | | |<-----------------------------------+ | | | | : : : | | | | QUIC Initial, transport parameter=CIDFI | +------------------------------------------------------>| | STUN Indication, nonce=12345, hmac=e8FEc | +------------------------------------------------------>| | | discarded | | | | "I saw my nonce, HMAC is valid" | | | | | HTTPS: "Map DCID=xyz as high importance" | +----------------------------------->| | | QUIC Initial, transport parameter=CIDFI | |<------------------------------------------------------+ | HTTPS: Ok | | |<-----------------------------------+ | Because multiple QUIC clients will use the same incoming Destination CID on their own UDP 4-tuple, the STUN Indication message also allows the CIDFI network element to distinguish which UDP 4-tuple belongs to each CIDFI client. To reduce CIDFI setup time the client STUN Indication MAY be sent at the same time as the QUIC Initial packet, which is encouraged if the client remembers the server supports CIDFI (0-RTT). To prevent replay attacks, the Nonce is usable only for authenticating one UDP 4-tuple. When the connection is migrated (Section 9 of [QUIC]) the CIDFI network element won't apply any CIDFI behavior to that newly-migrated connection. The client will have to restart CIDFI procedures at the beginning (Section 5). 6.2.1. STUN CIDFI-NONCE Attribute The format of the STUN CIDFI-NONCE attribute is: Wing, et al. Expires 16 March 2024 [Page 11] Internet-Draft CIDFI September 2023 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Nonce (128 bits) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | HMAC-output (256 bits) | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of CIDFI-NONCE Attribute The nonce is 128 bits obtained from the CIDFI network element. The HMAC-output field is computed per [RFC5869] using the CIDFI network element-provided HMAC secret, and the CIDFI network element-provided Nonce concatenated with the fixed string "cidfi" (without quotes), shown below with "|" denoting concatenation. HMAC-output = HMAC-SHA256( hmac-secret, nonce | "cidfi" ) 6.3. Initial Metadata Exchange Using its HTTPS channel with each of the CIDFI network elements it previously authorized for CIDFI participation, the client signals the mapping of the server's transmitted short Destination Connection ID and its length to the CNE. As server support of the QUIC CIDFI transport parameter is remembered for 0-RTT, the client can immediately send the nonce. The primary purpose of a second Connection ID is connection migration (Section 9 of [QUIC]). With CIDFI, additional Connection IDs are necessary to: * maintain CIDFI operation when topology remains the same. * use Destination Connection ID to indicate packet importance To maintain CIDFI operation when topology remains the same, the CIDFI client signals the CNEs of that 'next' Destination CID. When QUIC detects a topology change, however, that Destination CID MUST NOT be used by the peer, otherwise it links the communication on the old topology to the new topology (Section 9.5 of [QUIC]). Thus, an additional Connection ID is purposefully not communicated from the Wing, et al. Expires 16 March 2024 [Page 12] Internet-Draft CIDFI September 2023 CIDFI client to its CNEs, so that Connection ID can be immediately used by the peer during connection migration when the topology changes. Note the source IP address and source UDP port number are not signaled by design. This is because NATs ([NAPT], [NAT]), multiple NATs on the path, IPv6/IPv4 translation, similar technologies, and QUIC connection migration all complicate accurate signaling of the source IP address and source UDP port number. If the CNE receives the HTTPS map request but has not yet seen the STUN nonce message it rejects the mapping request with a 403 and provides a new nonce. The new nonce avoids the problem of an attacker seeing the previous nonce and using that nonce on its own UDP 4-tuple. The client then sends a new STUN message with that new nonce value and send a new HTTPS mapping request(s). This interaction is highlighted in the simplified message flow, below. CIDFI-aware QUIC client edge router server | | | | HTTPS: Enroll CIDFI router to partipate | +----------------------------------->| | | HTTPS: Ok. nonce=12345 | | |<-----------------------------------+ | | | | : : : | | | | QUIC Initial, transport parameter=CIDFI | +------------------------------------------------------>| | STUN Indication, nonce=12345, HMAC=8f93e | +--------------------> X (lost) | | | | | | HTTPS: "Map DCID=xyz as high importance" | +----------------------------------->| | | HTTPS: 403, new Nonce=5678 | | |<-----------------------------------| | | STUN Indicate, nonce=5678, HMAC=aaf3c | +------------------------------------------------------>| | | discarded | | | | "I saw my nonce, HMAC is valid" | | | | | HTTPS: "Map DCID=xyz as high importance" | +----------------------------------->| | | Ok | | |<-----------------------------------+ | Wing, et al. Expires 16 March 2024 [Page 13] Internet-Draft CIDFI September 2023 Figure 3: Client re-transmitting lost nonce There are two types of metadata exchanged, described in the following sub-sections. 6.3.1. Server to Network Elements The server communicates to network elements via the client which then communicates with the network element(s). While this adds communication delay, it allows the user at the client to authorize the metadata communication about its own incoming (and outgoing) traffic. The communication from the client to the server are using a CIDFI- dedicated QUIC stream over the same QUIC connection as their primary communication. CIDFI-aware CIDFI-aware client Wi-Fi Access Point edge router server | | | | | QUIC CIDFI stream: "Map DCID=xyz as high importance" | |<------------------------------------------------------+ | "Map DCID=xyz as | | | high importance"| | | +----------------->| | | | "Map DCID=xyz as high importance" | | +----------------------------------->| | | Ok | | | |<-----------------+ | | | Ok | | | |<-----------------------------------+ | | QUIC CIDFI stream: Ok | | +------------------------------------------------------>| To each of the network elements authorized by the client, the client sends the mappings of the server's transmitted Destination CIDs to packet metadata (see {#packet-metadata}). 6.3.2. Network Element to Server The network element sends network performance information to the server which is intended to influence the sender's traffic rate (such as improving or reducing fidelity of the audio or video). In the figure below the CNE informs the client of reduced bandwidth and the client informs the server using CIDFI. Wing, et al. Expires 16 March 2024 [Page 14] Internet-Draft CIDFI September 2023 CIDFI-aware CIDFI-aware client Wi-Fi Access Point edge router server | | | | | "bandwidth now 1Mbps" | | |<-----------------------------------+ | | QUIC CIDFI stream: "bandwidth now 1Mbps" | +------------------------------------------------>| | QUIC CIDFI stream: Ok | | |<------------------------------------------------+ | Ok | | | +----------------------------------->| | The communication from the client to the server is using a CIDFI- dedicated QUIC stream over the same QUIC connection as their primary communication. The CNE can update the client with whenever the metadata about the connection changes significantly, but MUST NOT update more frequently than once every second. The metadata exchanged over this channel is described in Section 9. 6.4. Ongoing Metadata Exchange For the duration of the primary QUIC connection between the client and server, the client relays network element metadata changes to the server, and server's transmitted QUIC Destination CID to the network elements. 7. Interaction with Load Balancers HTTPS servers, including QUIC servers, are frequently behind load balancers. With CIDFI, all the communications to the load-balanced QUIC server are over the same UDP 4-tuple as the primary QUIC connection but in a different QUIC stream. This means no changes are required to ECMP load balancers or to CID-aware load balancers when using a CIDFI- aware back-end QUIC server. Load balancers providing QUIC-to-TCP interworking is incompatible with CIDFI because TCP lacks QUIC's stream identification. Wing, et al. Expires 16 March 2024 [Page 15] Internet-Draft CIDFI September 2023 8. Topology Change When the topology changes the client will transmit from a new IP address -- such as switching to a backup WAN connection, or such as switching from Wi-Fi to 5G. If using QUIC, QUIC server will consider this a connection migration and will issue a PATH_CHALLENGE. If the client is aware of the topology change (such as attaching to a different network), the client would also change its QUIC Destination CID (Section 9 of [QUIC]). If the QUIC CIDFI-aware client is otherwise unaware of a topology change and receives a QUIC PATH_CHALLENGE then the CIDFI-aware client SHOULD re-discover its CIDFI network elements Section 5.1. If that set of network elements differs from the previous set, the client SHOULD continue with normal CIDFI processing. todo: include discussion of [DTLS-CID] client and discussion of its ICE interaction, if any? 9. Details of Metadata Exchanged This section describes the metadata that can be exchanged from a CNE to a server (generally network performance information) and from the server to the CNE. 9.1. Server to CIDFI-aware Network Element Because there is no direct communication from the server to the network element the communication is relayed through the client. The communications from servers to network elements do not occur directly, but rather through the client. Two types of mapping metadata are described below: metadata parameters and DSCP values. 9.1.1. Mapping Metadata Parameters to DCIDs Several of metadata parameters can be mapped to Destination CIDs: Importance: Low/Medium/High importance, relative to other CIDs within this same UDP 4-tuple. Delay budget: Time in milliseconds until this packet is worthless to the receiver. This is counted from when the packet arrives at the CNE to when it is transmitted; other delays may occur before or after that event occurs. The receiver knows its own jitter (playout) buffer length and the client and server can calculate Wing, et al. Expires 16 March 2024 [Page 16] Internet-Draft CIDFI September 2023 the one-way delay using timestamps. With that information, the client can adjust the server's signaled delay budget with the client's own knowledge. TODO: provide enough details to create interoperable implementations. Over the CIDFI-dedicated QUIC stream, the server sends mapping information to the client when then propagates that information to each of the CNEs. {"metadata-parameters":[{"quicversion":1, "dcidlength":3, "map":[ {"import":17,"burst":83,"delaybudget":71,"dcids":[551,381]}, {"import":3,"burst":888,"delaybudget":180,"dcids":[89,983]}, {"import":7,"burst":37,"delaybudget":55,"dcids":[33]}]}]} 9.1.2. Mapping DiffServ Code Point (DSCP) to DCIDs A mapping from Destination CID to DiffServ code point [RFC2474] leverages existing DiffServ handling that may already exist in the CIDFI network element. If there are downstream network elements configured with the same DSCP the CIDFI network element could mark the packet with that code point as well. Signaling the DSCP values for different QUIC Destination CIDs increases the edge network's confidence that the sender's DiffServ intent is preserved into the edge network, even if the DSCP bits were modified en route to the edge network (e.g., [pathologies]). Over the CIDFI-dedicated QUIC stream, the server sends the mapping information to the client when then propagates that information to each of the CNEs. {"dscp":[{"quicversion":1, "dcidlength":3, "map":[ {"dscp":10,"dcids":[123,456]}, {"dscp":46,"dcids":[998,183]}]}]} Figure 4: Example JSON for DSCP Mapping 9.2. CIDFI-aware Network Element to Server The CIDFI-aware client informs the network element of the client's received Destination CIDs. As bandwidth availability to that client changes, the CNE updates the client with new metadata. Wing, et al. Expires 16 March 2024 [Page 17] Internet-Draft CIDFI September 2023 {"dcid":123, "bandwidth":"1Mbps"} The client then sends that information to the server in the CIDFI- dedicated QUIC stream associated with that same Connection ID. 10. Discussion Points This section discusses known issues that would benefit from wider discussion. 10.1. Client versus Server Signaling CID-to-importance Mapping Need to evaluate number of round trips (and other overhead) of client signaling CID-to-importance mapping or server signaling CID-to- importance mapping. 10.2. Overhead of QUIC DCID Packet Examination If CID-to-importance metadata was signaled by the server as described in Section 6.3.1, the CNE have to examine the UDP payload of each packet for a matching Destination CID for the lifetime of the connection. This is somewhat assuaged by the STUN nonce transmitted which may well be an easier signal to identify. 10.3. Interaction with Wi-Fi Packet Aggregation Per-packet metadata influences transmission of that packet but may well conflict with some Wi-Fi optimizations (e.g., [wifi-aggregation]) and similar 5G optimizations. This impact needs further study. 10.4. Overhead of Mapping CIDs to Packet Metadata Network Elements have to maintain a mapping between each UDP 4-tuple and QUIC CID and its DSCP code point. This also needs updating whenever sender changes its CID. This is awkward. An alternative is a fixed mapping of QUIC CIDs to their meanings, as proposed in [I-D.zmlk-quic-te]. However, this will ossify the meaning of those QUIC CIDs. It also requires all networks to agree on the meaning of those QUIC CIDs. 10.5. Improve CIDFI Initialization Time Find approaches to further reduce network communications to start CIDFI. Wing, et al. Expires 16 March 2024 [Page 18] Internet-Draft CIDFI September 2023 10.6. Primary QUIC Channel CID Change {#primary-cid-change}: Because the CIDFI network element, QUIC server, and QUIC client all cooperate to share the primary QUIC connection's Destination CID, when a new CIDFI network element is involved (e.g., due to client attaching to a different network), a new Destination CID SHOULD be used for the reasons discussed in Section 9.5 of [QUIC]}. We need clear way to signal which DCIDs can be used for 'this' network attach and which DCIDs are for a migrated connection. Probably belongs in the QUIC transport parameter signaling? 11. Security Considerations Because the sender's QUIC Destination Connection ID is mapped to packet importance, and the DCID remains the same for many packets, an attacker could determine which DCIDs are important by causing interference on the bandwidth-constrained link (by creating other legitimate traffic or creating radio interference) and observing which DCIDs are transmitted versus which DCIDs are dropped. This is a side- effect of using fixed identifier (DCIDs) rather than encrypting the packet importance. This was a design trade-off to reduce the CPU effort on the CNEs. A mitigation is using several DCIDs for every packet importance. Communications are relayed through the client because only the client and server knows the identity of the server and can validate its certificate. The protocol in this specification does not disclose the server's identity to the CIDFI network element. For an attacker to succeed with the nonce challenge against a victim's UDP 4-tuple the attacker has to send a STUN CIDFI-NONCE packet using the victim's source IP address and a valid HMAC. A valid HMAC can only be obtained by the attacker making its own connection to the CIDFI server and spoofing the source IP address and UDP port of the victim. Such spoofing of a victim's IP address is prevented by the network using network ingress filtering ([RFC2827], [RFC7513], [RFC6105], and/or [RFC6620]). In the event network ingress filtering is not configured or configured improperly, the CIDFI network element can detect an attack if the client implements CIDFI. The CIDFI network element receive two HTTPS connections describing the same DCID (one connection from the attacker, another from the victim). The CIDFI network element will issue unique Nonces and HMACs to both the attacker and victim, and the attacker and victim will both send the STUN indication on that same UDP 4-tuple. This should never normally occur and should generate an alarm on the CIDFI network element. In this situation, it is recommended both attack and victim be denied CIDFI access. Wing, et al. Expires 16 March 2024 [Page 19] Internet-Draft CIDFI September 2023 12. IANA Considerations 12.1. New QUIC Transport Parameter This document requests IANA to register the following new permanent QUIC transport parameter in the "QUIC Transport Parameters" registry under the "QUIC" registry group available at [IANA-QUIC]: +=======+================+===============+ | Value | Parameter Name | Reference | +=======+================+===============+ | TBD1 | CIDFI | This-Document | +-------+----------------+---------------+ Table 1: New QUIC Transport Parameter 12.2. New Well-known URI "cidfi-aware" This document requests IANA to register the new well-known URI "cidfi" in the "Well-Known URIs" registry available at [IANA-WKU]. 12.3. New Special-use Domain Name Register new special-use domain name cidfi.arpa for DNS SVCB discovery. 12.4. New DNS Service Binding (SVCB) This document requests IANA to register the new DNS SVCB "_cidfi- aware" in the "DNS Service Bindings (SVCB)" registry available at [IANA-SVCB]. 12.5. New STUN Attribute This document requests IANA to register the new STUN attribute "CIDFI-NONCE" in the "STUN Attributes" registry available at [IANA-STUN]. 12.6. New Provisioning Domain Additional Information Key This document requests IANA to register two new JSON keys in the Provisioning Domains Additional Information registry at [IANA-PVD]: JSON key: cidfi Description: CID Flow Indicator Type: array of cidfi details Example: ["cidfinode": "service.example.net", "cidfipathauth": "/authpath", "cidfimetadata": "/meta"] Wing, et al. Expires 16 March 2024 [Page 20] Internet-Draft CIDFI September 2023 Additionally, in the following cidfi keys are to be registered: JSON key: cidfinode Description: FQDN of CIDFI node Type: string Example: service.example.net JSON key: cidfipathauth Description: authentication and authorization path for CIDFI type: string Example: "/authpath" JSON key: cidfimetadata Description: metadata path for CIDFI type: string example: "/metadata" 13. References 13.1. Normative References [CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [DTLS-CID] Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146, DOI 10.17487/RFC9146, March 2022, . [I-D.ietf-dnsop-svcb-https] Schwartz, B. M., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft- ietf-dnsop-svcb-https-12, 11 March 2023, . [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Wing, et al. Expires 16 March 2024 [Page 21] Internet-Draft CIDFI September 2023 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8801] Pfister, P., Vyncke, É., Pauly, T., Schinazi, D., and W. Shao, "Discovering Provisioning Domain Names and Data", RFC 8801, DOI 10.17487/RFC8801, July 2020, . [STUN] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, February 2020, . 13.2. Informative References [cryptex] Uberti, J., Jennings, C., and S. Murillo, "Completely Encrypting RTP Header Extensions and Contributing Sources", RFC 9335, DOI 10.17487/RFC9335, January 2023, . [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [I-D.ietf-avtcore-rtp-over-quic] Ott, J., Engelbart, M., and S. Dawkins, "RTP over QUIC (RoQ)", Work in Progress, Internet-Draft, draft-ietf- avtcore-rtp-over-quic-05, 26 July 2023, . [I-D.ietf-moq-requirements] Gruessing, J. and S. Dawkins, "Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design", Work in Progress, Internet-Draft, draft-ietf-moq- requirements-01, 10 July 2023, . Wing, et al. Expires 16 March 2024 [Page 22] Internet-Draft CIDFI September 2023 [I-D.joras-sadcdn] Joras, M., "Securing Ancillary Data for Communicating with Devices in the Network", Work in Progress, Internet-Draft, draft-joras-sadcdn-01, 10 July 2023, . [I-D.zmlk-quic-te] Zheng, Z., Ma, Y., Liu, Y., and M. Kühlewind, "QUIC- enabled Service Differentiation for Traffic Engineering", Work in Progress, Internet-Draft, draft-zmlk-quic-te-00, 5 May 2023, . [IANA-PVD] "Provisioning Domains (PvDs)", 13 August 2020, . [IANA-QUIC] "QUIC", 26 July 2023, . [IANA-STUN] "STUN Attributes", 20 March 2023, . [IANA-SVCB] "DNS Service Bindings (SVCB)", 13 June 2023, . [IANA-WKU] "Well-known URIs", 20 June 2023, . [NAPT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, . [NAT] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, . Wing, et al. Expires 16 March 2024 [Page 23] Internet-Draft CIDFI September 2023 [pathologies] Custura, A., Secchi, R., and G. Fairhurst, "Exploring DSCP modification pathologies in the Internet", May 2018, . [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, . [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, . [RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, . [RFC7839] Bhandari, S., Gundavelli, S., Grayson, M., Volz, B., and J. Korhonen, "Access-Network-Identifier Option in DHCP", RFC 7839, DOI 10.17487/RFC7839, June 2016, . [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [SRTP] 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, . Wing, et al. Expires 16 March 2024 [Page 24] Internet-Draft CIDFI September 2023 [wifi-aggregation] Høiland-Jørgensen, T., Kazior, M., Täht, D., Hurtig, P., and A. Brunstrom, "Ending the Anomaly: Achieving Low Latency and Airtime Fairness in WiFi", 22 May 2017, . Appendix A. Extending CIDFI to Other Protocols CIDFI can be extended to other protocols including TCP, SCTP, RTP and SRTP, and bespoke UDP protocols. An extension to each protocol is described below which retains the ability of the client to prove its ownership of the 5-tuple to a CNE. A.1. TCP To prove ownership of the TCP 4-tuple, TCP can utilize a new TCP option to carry the CNE's nonce and HMAC-output. This TCP option can be carried in both the TCP SYN and in some subsequent packets to avoid consuming the entire TCP option space (40 bytes). Sub-options can be defined to carry pieces of the Nonce and HMAC output, with the first piece of the Nonce in the TCP SYN so the CIDFI network element can be triggered to begin looking for the subsequent TCP frames containing the rest of the CIDFI nonce and CIDFI HMAC-output. For example, 1. send TCP SYN + CIDFI option (including Nonce bits 0-63) 2. if received TCP SYNACK does not indicate CIDFI support, stop sending CIDFI option 3. send next TCP packet + CIDFI option (including Nonce bytes 64-128) 4. send next TCP packet + CIDFI option (including HMAC-output bits 0-127) 5. send next TCP packet + CIDFI option (including HMAC-output bytes 128-256) To shorten this further we might truncate the HMAC output and/or truncate the Nonce after security evaluation. Wing, et al. Expires 16 March 2024 [Page 25] Internet-Draft CIDFI September 2023 A.2. SCTP If SCTP is sent directly over IP, proof of ownership of the SCTP 4-tuple can be achieved using an extension to its INIT packets, similar to what is described above for TCP SYN. If SCTP is run over UDP, the same proof of ownership of the UDP 4-tuple as described in Section 6.2 can be performed. A.3. RTP and SRTP The RTP Synchronization Source (SSRC) is in the clear for [RTP], [SRTP], and [cryptex]. If the SSRC is signaled similarly to CID, RTP could also benefit from CIDFI. CIDFI network elements could be told the mapping of SSRC values to importance and schedule those SSRCs accordingly. However, SSRC is used in playout (jitter) buffers and a new SSRC seen by a receiver will cause confusion. Thus, overloading SSRC to mean both 'packet importance' for CIDFI and 'synchronization source' will require engineering work on the RTP receiver to treat all the signaled SSRCs as one source for purposes of its playout buffer. RTP over QUIC [I-D.ietf-avtcore-rtp-over-quic] is another approach which exposes QUIC headers to the network (which have CIDs) and does not overload the RTP SSRC. The Media over QUIC (MOQ) working group includes RTP over QUIC as one of its use cases Section 3.1 of [I-D.ietf-moq-requirements]. A.4. Bespoke UDP Application Protocols To work with CIDFI, other UDP application protocols would have to prove ownership of their UDP 4-tuple (Section 6.2) and extend their protocol to include a connection identifier in the first several bits of each of their UDP packets. Alternatively, rather than modifying the application protocol it could be run over [QUIC] or [DTLS-CID]. Acknowledgments Thanks to Dave Täht, Magnus Westerlund, Christian Huitema, Gorry Fairhurst, and Tom Herbert for hallway discussions and feedback at TSVWG that encouraged the authors to consider the approach described in this document. Thanks to Ben Schwartz for suggesting PvD as an alternative discovery mechanism. Authors' Addresses Wing, et al. Expires 16 March 2024 [Page 26] Internet-Draft CIDFI September 2023 Dan Wing Cloud Software Group, Inc. United States of America Email: danwing@gmail.com Tirumaleswar Reddy Nokia Bangalore Karnataka India Email: kondtir@gmail.com Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com Wing, et al. Expires 16 March 2024 [Page 27]