Framework for CID Flow Indicator (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/.¶

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 17 August 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

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). This is also called an 'intentional management policy'.¶

Due to network constraints a network element will need to drop or even prioritize a packet ahead of other packets within the same UDP 4-tuple. The decision of which packet to drop or prioritize is improved if the network element knows the importance of the packet. By mapping packet metadata to a network-visible field in each packet, the network element is better informed and better able to improve the user experience.¶

There are also exceptional cases (crisis) where "normal" network resources cannot be used at maximum and, thus, a network would seek to reduce or offload some of the traffic during these events -- often called 'reactive traffic policy'. Network-to-host signals are useful to put in place adequate traffic distribution policies (e.g., prefer the use of alternate paths, offload a network).¶

Figure 1 depicts examples of approaches to establish channels to convey and share metadata between hosts, networks, and servers. This document adheres to the client-centric metadata sharing approach because it preserves privacy and also takes advantage of clients having a full view on their available network attachments. Metadata exchanges can occur in one single direction or both directions of a flows.¶

The document is a generic framework that would function in any network deployment. This framework can be leveraged by any transport protocol (see Appendix A). To illustrate the framework's applicability this document focuses on QUIC transport.¶

The design supports multiple CIDFI and QUIC implementations on one host (i.e., by several applications), cellular devices providing IP connectivity to other devices (see Section 3 of [RFC7649]), multiple CIDFI-aware network elements (e.g., Wi-Fi and an ISP network), DOCSIS and 5G networks, and hosts behind one or more IPv4 NATs or other IP translation technologies. A comprehensive list of such translation technologies is provided in Section 2.2 of [RFC8512].¶

2. Overview

This document defines CIDFI (pronounced "sid fye") which is a system of several protocols that allow communicating about a [QUIC] connection 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. The following main steps are involved in CIDFI; some of them are optional:¶

• CIDFI-awareness discovery between a host and a network.¶

• Establishment of a secure association with all or a subset of CIDFI-aware networks.¶

• Negotiation of CIDFI support with remote servers.¶

• CIDFI-aware networks sharing of changes of network conditions.¶

• CIDFI-aware clients sharing of metadata with CIDFI-aware networks as hints to help processing flows.¶

• CIDFI-aware clients sharing of metadata with CIDFI-aware server to adapt to local network conditions.¶

CIDFI does not require that all these steps are enabled. Incremental deployments may be envisaged (e.g., network and client support, network, client, and server support). Differentiated service can be provided to a flow, packets within a flow, or a combination thereof as a function of the CIDFI support by various involved entities. For example, a CIDFI-aware network might share signals with clients that would then trigger locally connection migration or relay the information to the server (if it is CIDFI-aware) to adjust its sending behavior by avoiding aggressive use of local resources or using alternate paths. Section 12 further elaborates on the differentiated service that can be provided by enabling CIDFI.¶

Figure 2 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. Readers may refer to Appendix C of [I-D.ietf-teas-5g-ns-ip-mpls] for an overview of key 5G building blocks.¶

For the sake of illustration, Figure 2 simplifies the representation of the various involved network segments. It also assumes that multiple server instances are enabled in the server network but the document does not make any assumption about the internal structure of the service nor how a flow is processed by or steered to a service instance. However, CIDFI includes provisions to ensure that the service instance that is selected to service a client request is the same instance that will receive CIDFI metadata for that client.¶

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 (n2h) and it sends mapping of QUIC Destination CIDs to packet importance (h2n).¶

The design creates new state in the CIDFI-aware network elements for mapping from Destination CID to the packet metadata and maintaining triggers to update the client if the network characteristics change, and to maintain a TLS channel with the client.¶

Section 7.3.2 describes network-to-host signaling similar to the use case described in Section 2 of [I-D.joras-sadcdn], with metadata relaying through the client.¶

Section 7.3.1 describes host-to-network metadata signaling similar to the use cases described in Section 3 of [I-D.joras-sadcdn]. The host-to-network metadata signaling can also benefit [I-D.ietf-avtcore-rtp-over-quic].¶

CIDFI brings benefits to QUIC as that protocol is of primary interest. QUIC is quickly replacing HTTPS-over-TCP on many websites and content delivery networks because of its advantages to both end users and servers. CIDFI can bring value to a system comprised solely of a CIDFI-aware client and the CIDFI-aware network elements. By adding a CIDFI-aware server that supports QUIC unreliable datagrams [RFC9221] and API integration (see Section 16), each packet can receive differentiated service from the network. This is especially useful during user transitions from a high quality wireless reception to lower quality reception (e.g., entering a building). Additionally, CIDFI can be extended to other protocols as discussed in Appendix A.¶

3. 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.¶

The document makes use of the following terms:¶

CID:

Connection Identifier used by [QUIC].¶

CNE:

CIDFI-aware Network Element, a network element that supports this CIDFI specification. This is typically a router.¶

Differentiated service:

Refers to a differentiated processing that can be provided to a flow (or specific packets within a flow) by a network, client, or server.¶

Examples of differentiated service are: prioritization, adaptive transmission, or traffic steering.¶

4. 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 flow.¶

Same Server Instance:

When the server also participates in CIDFI, the same QUIC connection is used for CIDFI communication with that server, which ensures it arrives at the same server instance even in the presence of network translators (NAT) or server-side ECMP load balancers or server-side CID-aware load balancers [I-D.ietf-quic-load-balancers].¶

Privacy:

The host-to-network signaling of the mapping from packet metadata to CID is only sent to CIDFI-aware network elements (CNEs) and is protected by TLS. The network-to-host signaling of network metadata is protected by TLS. For CIDFI to operate, a CNE never needs the server's identity, and a CNE is never provided decryption keys for the QUIC communication between the client and server.¶

Integrity:

Metadata sharing, including the mapping of packet importance to Destination CIDs, are integrity protected by QUIC itself and cannot be modified by on-path network elements. The communication between client, server, and network elements is protected by TLS.¶

Packet metadata is communicated over a TLS-encrypted channel from the CIDFI client to its CIDFI-aware network elements, and mapped to integrity-protected QUIC CIDs.¶

Internet Survival:

The QUIC communications between clients and servers are not changed so CIDFI is expected to work wherever QUIC works. The elements involved are only the QUIC client and server and with the participating CIDFI-aware network elements.¶

CIDFI can operate over IPv4, IPv6, IPv4/IPv4 translation (NAT), and IPv6/IPv4 translation (NAT64).¶

Fast Path Forwarding Support:

For some differentiated services (e.g., capacity awareness), CIDFI does not require specific processing by on-path network devices. For others, once a state is programmed (CIDs, for example) no other forwarding constraint is required at CNEs.¶

Single Encryption and No Nested Congestion Control:

CIDFI does not require any tunneling mechanism or any overhead of multi-layer encryption schemes that would impact CNEs processing. CIDFI uses the base connection to convey specific signals. Unlike tunneling mechanisms, CIDFI does not suffer from nested congestion control.¶

5. Network Configuration to Support CIDFI

The network is configured to advertise its support for CIDFI using a variety of means.¶

Four mechanisms are described in [I-D.wing-cidfi-discovery]: DNS SVCB records [RFC9460], IPv6 Provisioning Domains (PvD) [RFC8801], DHCP [RFC2131][RFC8415], and 3GPP PCO.¶

6. Client Operation on Network Attach or Topology Change

On initial network attach topology change (see Section 10), the client learns if the network supports CIDFI (Section 6.1) and authorizes discovered network elements (Section 6.2).¶

{
   "cidfi-path-authentication":[
      {
         "nonce":"ddqwohxGZysgy0BySNh7sNHV5IH9RbE7rqXmg9wb9Npo",
         "hmac-secret":"jLNsCvuU59mt3F4/ePD9jbZ932TfsLSOP2Nx3XnUqc8v"
      }
   ]
}

7. Client Operation on Each Connection to a Server

When a QUIC client connects to a QUIC server, the client:¶

1. Learns if the server supports CIDFI and obtains its mapping of transmitted Destination CIDs to metadata, described in Section 7.1.¶

2. Proves ownership of its UDP 4-tuple to the on-path CNEs, described in Section 7.2.¶

3. Performs initial metadata exchange with the CIDFI network element and server, and server and network element, described in Section 7.3.¶

4. For the duration of the connection, receives network-to-host and performs host-to-network updates as network conditions or network requirements change, described in Section 8. Some policies are provided to CNEs to control which network changes can trigger updating clients.¶

• 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.¶

  HMAC-output = HMAC-SHA256( hmac-secret, nonce | "cidfi" )

8. Ongoing Signaling

Throughout the life of the connection host-to-network and network-to-host signaling is updated whenever characteristics change. Still, some policies are provided to control when these updates are triggers. Such policies are meant to preserve the connection stability.¶

Typically, due to environmental changes on wireless networks or other user's traffic patterns, a particular flow may be able to operate faster or might need to operate slower. The relevant CNE SHOULD signal such conditions to the client (Section 7.3.2), which can then relay that information to the server using either CIDFI or via its application.¶

For example, a streaming video client might be retrieving low quality video because one of their invoked CNEs indicated constrained bandwidth. Later, after moving closer to an antenna, more bandwidth is available which is signaled by the CNE to the client. The client uses that signal to now request higher-quality video from the server.¶

Similarly, the CIDFI client may begin receiving traffic with different characteristics which might be be signaled to the CNEs.¶

For example, a client might be participating in an audio-only call which is modified to audio and video, requiring additional bandwidth and likely new CIDs to differentiate the video packets from the audio packets.¶

9. Interaction with Load Balancers

QUIC servers are likely to be behind CID-aware load balancers [I-D.ietf-quic-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 are incompatible with CIDFI because TCP lacks QUIC's stream identification.¶

10. 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. The server will consider this as a connection migration (Section 9 of [QUIC]) 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]).¶

When the CIDFI-aware client determines that it is connected to a new network or has received a QUIC PATH_CHALLENGE, the CIDFI-aware client MUST re-discover its CNEs (Section 6.1) and continue with normal CIDFI processing with any discovered CNEs. This usually means repeating the initial metadata exchange (Section 7.3) to prove path ownership.¶

11. Flushing Mapping State

When the server supports CIDFI the metadata mapping creates additional state in the client, CIDFI Network Elements, and the server.¶

Between the QUIC client and server when a mapping is no longer needed it can be cleaned up with RETIRE_CONNECTION_ID. If that connection ID was mapped in one or more CNEs, the client SHOULD also remove that mapping state from the CNEs. This allows the mapping state to be used for other CIDFI implementations on the same host or by other hosts (belonging to the same subscriber) or by other subscribers.¶

As a client can disappear from a network without informing its CNE and are unlikely to voluntarily clean up CNE state even if they remain connected to the network, the CNE should retire its CIDFI state after 3 minutes of bi-directional inactivity on that UDP 4-tuple or a more convenient time such as when it normally flushes its UDP NAT binding for bi-directional inactivity.¶

12. 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 a CNE.¶

{
   "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
               ]
            }
         ]
      }
   ]
}

{
   "dscp":[
      {
         "quicversion":1,
         "dcidlength":3,
         "map":[
            {
               "dscp":10,
               "dcids":[
                  123,
                  456
               ]
            },
            {
               "dscp":46,
               "dcids":[
                  998,
                  183
               ]
            }
         ]
      }
   ]
}

{
   "dcid":123,
   "bandwidth":"1Mbps"
}

13. Privacy Considerations

14. Discussion Points

This section discusses known issues that would benefit from wider discussion.¶

15. State Maintenance

A CNE can safely remove state after UDP inactivity timeout Section 4.3 of [RFC4787]. The CIDFI client MUST re-signal its CNE(s) when it receives a QUIC path validation message, as that indicates a NAT rebinding occurred. A CNE's state can also be cleared by signaling from the CIDFI client, such as when closing the application; however, this signal cannot be relied upon due to network disconnect, battery depletion, and suchlike.¶

• TODO: Probably want keepalives on client->CNE communication. To be assessed.¶

16. API Integration for QUIC Stream and Packet-Level Prioritization

For each QUIC stream requiring differentiated service, the QUIC stack can map that stream to a different Destination CID. The application-level code would require an API to instruct the QUIC stack that a particular stream needs differentiated service. Similarly, if the application-level code seeks differentiated service for packets within a stream (e.g., prioritizing P-frames over I-Frames in a video stream), it would need an API to inform the QUIC stack that different packets within the QUIC stream require differentiated services and to map these packets to different Destination CIDs.¶

Where packet-level differentiation is not desired, such API enhancements are not needed. In that situation, the CIDFI-aware client and CIDFI-aware network elements can utilize bandwidth information to optimize their video streaming usage and their interactive audio/video streams, without the benefit of packet-level differentiation.¶

17. 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.¶

Other than what can be inferred from a destination IP address, the server's identity is not disclosed to the CIDFI Network Elements, thus maintaining the end user's privacy. Communications are relayed through the client because only the client knows the identity of the server and can validate its certificate.¶

Spoofing Attacks:

For an attacker to succeed with the nonce challenge against a victim's UDP 4-tuple, an attacker has to send a STUN CIDFI-NONCE packet using the victim's source IP address and a valid HMAC. A valid HMAC can be obtained by the attacker making its own connection to the CIDFI-aware server and spoofing the source IP address and UDP port number of the victim.¶

If the client does not support CIDFI, the attacker can influence the packet treatment of the victim's UDP 4-tuple.¶

If the client implements CIDFI, a CIDFI network element can identify an IP address spoofing attack. Concretely, the CNE will receive two HTTPS connections describing the same DCID; one connection from the attacker and another one from the victim. The CNE will then issue unique Nonces and HMACs to both the attacker and victim, and both the attacker and victim should send the STUN Indication on that same UDP 4-tuple. Such an event should trigger an alarm on the CNE. In this scenario, it is recommended that both the attacker and the victim be denied CIDFI access.¶

The spoofing of a victim's IP address is prevented by the network using network ingress filtering ([RFC2827], [RFC7513], [RFC6105], and/or [RFC6620]).¶

On-Path Attacks:

An on-path attacker can observe the victim's Discovery Packet, block it, and then forward the packet within the attacker's 5-tuple. Subsequently, the on-path attacker can 'steal' the victim's CIDFI control from the victim's UDP 4-tuple, causing the victim's CIDFI signaling for that UDP 4-tuple to influence the attacker's UDP 4-tuple.¶

Although the on-path attacker can't directly observe the encrypted CIDFI signaling, this attack effectively disables the victim's CIDFI treatment, making it accessible to the attacker. The attacker can send NEW_CONNECTION_ID frames to the server with the victim's (observed) Destination CID, effectively claiming the victim's CIDFI signaling for themselves. An on-path attacker can do a lot more damage by blocking or rate-limiting the victim's traffic.¶

18. IANA Considerations

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.¶

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