Framework for CID Flow Indicator (CIDFI)
draft-wing-cidfi-04
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Dan Wing , Tirumaleswar Reddy.K , Mohamed Boucadair | ||
| Last updated | 2023-12-14 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wing-cidfi-04
Network Working Group D. Wing
Internet-Draft Cloud Software Group
Intended status: Standards Track T. Reddy
Expires: 17 June 2024 Nokia
M. Boucadair
Orange
15 December 2023
Framework for CID Flow Indicator (CIDFI)
draft-wing-cidfi-04
Abstract
Host-to-network signaling and network-to-host signaling can improve
the user experience to adapt to network's constraints and share
expected application needs, and thus to provide differentiated
service to a flow and to packets within a flow. The differentiated
service may be provided at the network (e.g., packet prioritization),
the server (e.g., adaptive transmission), or both.
This document describes how clients can communicate with their nearby
network elements so they can learn network constraints. Optionally,
with QUIC server support their incoming QUIC packets can be mapped to
metadata about their contents so packet importance can influence both
intentional and reactive management policies. The framework handles
both directions of a flow.
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 TSV Area Working Group
mailing list (mailto:tsvwg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/tsvwg/. Subscribe at
https://www.ietf.org/mailman/listinfo/tsvwg/.
Source for this draft and an issue tracker can be found at
https://github.com/danwing/cidfi.
Wing, et al. Expires 17 June 2024 [Page 1]
Internet-Draft CIDFI December 2023
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 June 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Operation with Streaming Video . . . . . . . . . . . . . 8
2.2. Operation with Interactive Audio/Video/Screen sharing . . 9
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 9
3.1. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Network Configuration to Support CIDFI . . . . . . . . . . . 11
5.1. DNS SVCB Records . . . . . . . . . . . . . . . . . . . . 11
5.2. Provisioning Domains . . . . . . . . . . . . . . . . . . 12
5.3. DHCP or 3GPP PCO . . . . . . . . . . . . . . . . . . . . 12
6. Client Operation on Network Attach or Topology Change . . . . 13
6.1. Client Learns Local Network Supports CIDFI . . . . . . . 13
6.1.1. Client Learns Using DNS SVCB . . . . . . . . . . . . 13
6.1.2. Client Learns Using Provisioning Domain . . . . . . . 13
Wing, et al. Expires 17 June 2024 [Page 2]
Internet-Draft CIDFI December 2023
6.1.3. Client Learns Using DHCP or 3GPP PCO . . . . . . . . 13
6.2. Client Authorizes CIDFI-aware Network Elements . . . . . 13
7. Client Operation on Each Connection to a Server . . . . . . . 14
7.1. Client Learns Server Supports CIDFI . . . . . . . . . . . 15
7.2. Client Proves Ownership of its UDP 4-Tuple . . . . . . . 15
7.2.1. STUN CIDFI-NONCE Attribute . . . . . . . . . . . . . 18
7.3. Initial Metadata Exchange . . . . . . . . . . . . . . . . 19
7.3.1. Host to Network Signaling . . . . . . . . . . . . . . 20
7.3.2. Network to Host Signaling . . . . . . . . . . . . . . 21
8. Ongoing Signaling . . . . . . . . . . . . . . . . . . . . . . 22
9. Interaction with Load Balancers . . . . . . . . . . . . . . . 22
10. Topology Change . . . . . . . . . . . . . . . . . . . . . . . 23
11. Flushing Mapping State . . . . . . . . . . . . . . . . . . . 23
12. Details of Metadata Exchanged . . . . . . . . . . . . . . . . 24
12.1. Server to CIDFI-aware Network Element . . . . . . . . . 24
12.1.1. Mapping Metadata Parameters to DCIDs . . . . . . . . 24
12.1.2. Mapping DiffServ Code Point (DSCP) to DCIDs . . . . 26
12.2. CIDFI-aware Network Element to Server . . . . . . . . . 27
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27
13.1. Privacy-Aware Metadata Sharing in Network
Relationships . . . . . . . . . . . . . . . . . . . . . 27
14. Discussion Points . . . . . . . . . . . . . . . . . . . . . . 27
14.1. Client versus Server Signaling CID-to-importance
Mapping . . . . . . . . . . . . . . . . . . . . . . . . 27
14.2. Overhead of QUIC DCID Packet Examination . . . . . . . . 28
14.3. Interaction with Wi-Fi Packet Aggregation . . . . . . . 28
14.4. Overhead of Mapping CIDs to Packet Metadata . . . . . . 28
14.5. Improve CIDFI Initialization Time . . . . . . . . . . . 28
14.6. Primary QUIC Channel CID Change . . . . . . . . . . . . 28
15. State Maintenance . . . . . . . . . . . . . . . . . . . . . . 29
16. API Integration for QUIC Stream and Packet-Level
Prioritization . . . . . . . . . . . . . . . . . . . . . 29
17. Security Considerations . . . . . . . . . . . . . . . . . . . 29
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
18.1. New QUIC Transport Parameter . . . . . . . . . . . . . . 31
18.2. New QUIC Frame Type . . . . . . . . . . . . . . . . . . 31
18.3. New Well-known URI "cidfi-aware" . . . . . . . . . . . . 31
18.4. New Special-use Domain Name . . . . . . . . . . . . . . 31
18.5. New DNS Service Binding (SVCB) . . . . . . . . . . . . . 31
18.6. New STUN Attribute . . . . . . . . . . . . . . . . . . . 32
18.7. New Provisioning Domain Additional Information Key . . . 32
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
19.1. Normative References . . . . . . . . . . . . . . . . . . 33
19.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Extending CIDFI to Other Protocols . . . . . . . . . 38
A.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.3. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Wing, et al. Expires 17 June 2024 [Page 3]
Internet-Draft CIDFI December 2023
A.4. RTP and SRTP . . . . . . . . . . . . . . . . . . . . . . 40
A.5. Bespoke UDP Application Protocols . . . . . . . . . . . . 40
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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.
Wing, et al. Expires 17 June 2024 [Page 4]
Internet-Draft CIDFI December 2023
(1) Proxied Connection
.--------------. +------+
| | +-+----+ |
+------+ | Network(s) | +-+----+ +-+
|Client+--------------)----------------(--------------+Server+-+
+---+--+ | | +---+--+
| '-------+------' |
| | |
+<===User Data+Metadata===>+<===User Data+Metadata===>+
| Secure Connection 1 | Secure Connection 2 |
| | |
(2) Out-of-band Metadata Sharing
.--------------. +------+
| | +-+----+ |
+------+ | Network(s) | +-+----+ +-+
|Client+---------------)----------------(-------------+Server+-+
+---+--+ | | +---+--+
| '-------+------' |
| | |
+<-----End-to-End Secure Connection + User Data------>+<---.
| | | GLUE|
| | | CXs |
+<-- Metadata (Optional) -->+<----- Metadata -------->+<---'
| Secure Connection 1 | Secure Connection 2 |
| | |
(3) Client-centric Metadata Sharing
.--------------. +------+
| | +-+----+ |
+------+ | Network(s) | +-+----+ +-+
|Client+-----------------)----------------(-------------+Server+-+
+---+--+ | | +---+--+
| '-------+------' |
| | |
+<--------- Metadata -------->+ |
| Secure Connection | |
| | |
+<== End-to-End Secure Connection User Data+Metadata ==>+
| | |
Figure 1: Candidate Design Approaches
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.
Wing, et al. Expires 17 June 2024 [Page 5]
Internet-Draft CIDFI December 2023
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.
Wing, et al. Expires 17 June 2024 [Page 6]
Internet-Draft CIDFI December 2023
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.
| | |
+------+ +------+ | +------+ | |
|CIDFI-| |CIDFI-| | |CIDFI-| | |
|aware | |aware | | |aware | +------+ | | +--------+
|client+-B-+Wi-Fi +-B-+edge +--+router+------+ | +-+------+ |
+------+ |access| | |router| +------+ | | | +-+------+ | |
|point | | +------+ | | | | CIDFI- | | |
+------+ | | +-+----+ | | aware | +-+
| | |router+---+ QUIC +-+
+---------+ | +------+ | +-+----+ | | server |
| CIDFI- | | |CIDFI-| | | | +--------+
| aware | | |aware | +------+ | | |
| client +-----B-----+RAN +--+router+------+ |
|(handset)| | |router| +------+ | |
+----+----+ | +------+ | |
| | | |
+----+----+ | | |
| CIDFI- | | | |
| aware | | | |
| app | | | |
+---------+ | | |
| | Transit | Server
User Network | ISP Network | Network | Network
Figure 2: Network Diagram
Wing, et al. Expires 17 June 2024 [Page 7]
Internet-Draft CIDFI December 2023
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.
2.1. Operation with Streaming Video
Incremental deployment: Streaming video only needs to be transmitted
slightly faster than the video playout rate. Sending the video
significantly faster can waste bandwidth, most notably if the user
abandons the video early. Worse, as discussed in Section 3.10 of
[RFC8517], a fast download of a video that won't be viewed
completely by the subscriber may lead to quick exhaustion of the
user data quota. CIDFI helps this use-case with its network-to-
host signaling which informs the client of available bandwidth
allowing the client to choose a compatible video stream. This
functionality does not need a CIDFI- aware server.
Full system deployment: With reliable transport such as TCP, the
Wing, et al. Expires 17 June 2024 [Page 8]
Internet-Draft CIDFI December 2023
only purpose of video key frames is the user scrolling forward/
backward. When video streaming uses unreliable transport
([RFC9221]) it is beneficial to differentiate keyframes from
predictive frames on the network especially when the network
performs reactive policy management. When the server also
supports CIDFI, key frames can be differentiated which improves
user experience during linear playout.
2.2. Operation with Interactive Audio/Video/Screen sharing
Incremental deployment: With interactive sessions CIDFI can help
determine the bandwidth available for the flow so the video (and
screen sharing) quality and size can be constrained to the
available bandwidth. This benefit can be deployed locally with a
CIDFI-aware client and CIDFI-aware network.
Full system deployment: When the remote peer also supports CIDFI,
the remote peer can differentiate packets containing audio, video,
or screen sharing. In certain use-cases audio is the most
important whereas in other use-cases screen sharing is most
important. With CIDFI, the relative importance of each packet can
be differentiated as that relative importance changes during a
session.
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.
Wing, et al. Expires 17 June 2024 [Page 9]
Internet-Draft CIDFI December 2023
3.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].
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
Wing, et al. Expires 17 June 2024 [Page 10]
Internet-Draft CIDFI December 2023
(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.
For this step, four mechanisms are described in this document: DNS
SVCB records [RFC9460], IPv6 Provisioning Domains (PvD) [RFC8801],
DHCP [RFC2131][RFC8415], and 3GPP PCO. These are described in the
following sub-sections.
Standardizing all or some of these mechanisms is for further
discussion.
5.1. DNS SVCB Records
This document defines a new DNS Service Binding parameter "cidfi-
aware" in Section 18.5 and a new Special-Use Domain Name "cidfi.arpa"
in Section 18.4.
The local network is configured to respond to DNS SVCB [RFC9460]
queries with ServiceMode (Section 2.4.3 of [RFC9460]) 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 17 June 2024 [Page 11]
Internet-Draft CIDFI December 2023
Figure 3: Example of SVCB Records
When multihoming, the multihome-capable CPE aggregates all upstream
networks' "_cidfi-aware.cidfi.arpa" responses into the response sent
to its locally-connected clients.
5.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 what is depicted in
Figure 4 when there are two CIDFI-aware network elements, service-
cidfi and wi-fi.
{
"cidfi":[
{
"cidfinode":"service-cidfi.example.net",
"min-ttl":3,
"cidfipathauth":"/path-auth-query{?cidfi}",
"cidfimetadata":"/cidfi-metadata"
},
{
"cidfinode":"wi-fi.example.net",
"min-ttl":2,
"cidfipathauth":"/path-auth-query{?cidfi}",
"cidfimetadata":"/cidfi-metadata"
}
]
}
Figure 4: Example of PvD Information
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.
5.3. DHCP or 3GPP PCO
The network is configured to respond to DHCPv6, DHCPv4 sub-option, or
3GPP PCO (Protocol Configuration Option) Information Element.
Wing, et al. Expires 17 June 2024 [Page 12]
Internet-Draft CIDFI December 2023
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).
6.1. Client Learns Local Network Supports CIDFI
For this step, four mechanisms are identified: DNS SVCB records, IPv6
PvD, DHCP, or 3GPP PCO. These are described in the following sub-
sections.
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 6.2.
* if the discovery failed (i.e., the client concludes that the local
network and ISP do not support CIDFI) client processing stops.
6.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) [RFC9460].
6.1.2. Client Learns Using Provisioning Domain
The client determines if the local network supports CIDFI by querying
https://<PvD-ID>/.well-known/pvd as described in Section 4.1 of
[RFC8801].
6.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].
6.2. Client Authorizes CIDFI-aware Network Elements
The response from the previous step in Section 6.1 will contain one
or more CNEs.
Wing, et al. Expires 17 June 2024 [Page 13]
Internet-Draft CIDFI December 2023
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 CNE.
The client then obtains the CIDFI nonce and CIDFI HMAC secret from
each CNE used later in Section 7.2 to prove the client owns its UDP
4-tuple.
{
"cidfi-path-authentication":[
{
"nonce":"ddqwohxGZysgy0BySNh7sNHV5IH9RbE7rqXmg9wb9Npo",
"hmac-secret":"jLNsCvuU59mt3F4/ePD9jbZ932TfsLSOP2Nx3XnUqc8v"
}
]
}
Figure 5: Example of CIDFI HMAC and Nonce
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.
Wing, et al. Expires 17 June 2024 [Page 14]
Internet-Draft CIDFI December 2023
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.
7.1. Client Learns Server Supports CIDFI
On initial connection to a QUIC server, the client includes a new
QUIC transport parameter "enable_cidfi" (TBD1) (Section 18.1) which
is remembered for 0-RTT.
If the server does not indicate CIDFI support by means of
enable_cidfi transport parameter, the client can still perform CIDFI
-- but does not expect different CIDs to indicate differentiated
behavior. The client can still signal to its CNE(s) about the flow,
because the client knows some characteristics of the flow it is
receiving. For example, if the client requested streaming video of a
certain bandwidth from a server or participated in a WebRTC offer/
answer exchange, the client knows some connectivity expectation about
the incoming flow without the server supporting CIDFI. Processing
continues with the next step.
The QUIC client and server exchange CIDFI information using the new
CIDFI_NEW_CONNECTION_ID_MAPPING frame type as described in
Section 7.3.
Processing continues with the next step.
7.2. Client Proves Ownership of its UDP 4-Tuple
Optimizations to this mechanism are being considered while
maintaining support for multiple CIDFI and QUIC implementations on
one host (i.e., by several applications) and support for cellular
devices providing IP connectivity to other devices (see Section 3
of [RFC7849]).
To ensure that the client messages to a 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 6.2 over the QUIC UDP
4-tuple it is using with the QUIC server over the path that involves
that CNE. 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 number. The nonce and HMAC are sent in a [STUN]
Wing, et al. Expires 17 June 2024 [Page 15]
Internet-Draft CIDFI December 2023
indication (STUN class of 0b01) containing one or more CIDFI-NONCE
attributes (Section 18.6). If there are multiple CNEs the single
STUN indication contains a CIDFI-NONCE attribute from each of them.
This message is discarded, if received, by the QUIC server.
In order to avoid overloading servers, the client may set the TTL/Hop
Limit to a value that allows to cross the CNE, but then discarded
before reaching the server. For example, the host sets the TTL to
"min-ttl" that is returned during CNE discovery.
Figure 6 shows a summarized message flow obtaining the nonce and HMAC
secret from the CNE (steps 1-2) which is performed on network attach.
The CNE also sends active_cidfi_connection_id_limit in step 2.
QUIC CIDFI-aware QUIC
client edge router server
| | |
| 1. HTTPS: Enroll CIDFI router to participate |
+----------------------------------->| |
| 2. HTTPS: Ok. nonce=12345 | |
| active_cidfi_connection_id_limit |
|<-----------------------------------+ |
| | |
Figure 6: Example of Flow Exchange
Later, when connecting to a new QUIC server, the client determines if
there are on-path CIDFI Network Elements by sending the nonce and
HMAC in the same UDP 4-tuple as the QUIC connect (step 2). This is
necessary to deal with both IP address spoofing and with multiple
QUIC+CIDFI implementations running on the same host; each QUIC+CIDFI
implementation pair should only be able to modify treatment of its
own flows, not of other flows to other UDP flows running on that same
host.
If a CIDFI Network Element is present on the path it processes the
STUN Indication and sends a response to the client over HTTP using
the HTTP channel established above. It decrements the IPv4 TTL or
IPv6 Hop Limit and forwards the STUN Indication along its normal
path, to accommodate another CIDFI Network Element farther away from
the client.
Wing, et al. Expires 17 June 2024 [Page 16]
Internet-Draft CIDFI December 2023
QUIC CIDFI-aware QUIC
client edge router server
| | |
| 1. QUIC Initial, transport parameter=enable_cidfi |
+------------------------------------------------------>|
| 2. STUN Indication, nonce=12345, hmac=e8FEc |
+------------------------------------------------------>|
| | |
| | 3. discarded
| | |
| 4. "I saw my nonce, HMAC is valid" |
| | |
| 5. Valid STUN Indication processed| |
|<-----------------------------------+ |
| | |
| 6. HTTPS: "Map DCID=xyz as high importance" |
+----------------------------------->| |
| 7. QUIC Initial, transport parameter=enable_cidfi |
|<------------------------------------------------------+
| 8. HTTPS: Ok | |
|<-----------------------------------+ |
Figure 7: Example of Flow to New Server
Note the above message flow shows an initial QUIC handshake for
simplicity (steps 1 and 7) but because of QUIC connection
migration (Section 9 of [QUIC]) the QUIC messages might appear
later.
Also, "Map DCID=xyz as high importance" refers to a CID chosen by
the client (for traffic destined towards the client) and not the
DCID used by the client to communicate with the server.
The short header's Destination Connection ID (DCID) can be 0 bytes or
as short as 8 bits, so multiple QUIC clients on the same host or on
different hosts behind a NAT are likely to use the same incoming
Destination CID on their own UDP 4-tuple (Birthday Paradox). The
STUN Indication message allows the CIDFI network element to
distinguish each QUIC client's UDP 4-tuple -- both between hosts and
between QUIC+CIDFI implementations on the same host (implemented
within an application).
To reduce CIDFI setup time the client STUN Indication MAY be sent at
the same time as it establishes connection with the QUIC server.
Wing, et al. Expires 17 June 2024 [Page 17]
Internet-Draft CIDFI December 2023
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 CNE won't apply any CIDFI behavior to that
newly-migrated connection. The client will have to restart CIDFI
procedures at the beginning (Section 6).
After the CIDFI Network Element receives the STUN Indication it
informs the client by sending an HTTP message to the client. Details
TBD.
As the proof of ownership of its UDP 4-tuple is only useful to CIDFI
Network Elements near the client, the client MAY reduce traffic to
the server by modulating the IPv4 TTL or IPv6 Hop Limit of its STUN
Indication messages. The client SHOULD set TTL/Hop Limit to "min-
ttl". The client MAY use other values (e.g., explicit configuration,
inferred from probe messages).
Processing continues with the next step.
7.2.1. STUN CIDFI-NONCE Attribute
The format of the STUN CIDFI-NONCE attribute is shown in Figure 8.
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 8: Format of STUN 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.
Wing, et al. Expires 17 June 2024 [Page 18]
Internet-Draft CIDFI December 2023
HMAC-output = HMAC-SHA256( hmac-secret, nonce | "cidfi" )
When there are multiple CIDFI Network Elements on the network,
multiple CIDFI-NONCE attributes are sent in a single STUN Indication
message.
7.3. Initial Metadata Exchange
If the server indicated support for CIDFI during the QUIC handshake,
the client uses its HTTPS channel with each of the CNEs it previously
authorized for CIDFI participation to map client-chosen Destination
CIDs to metadata for that CID. As server support of the QUIC CIDFI
transport parameter is remembered for 0-RTT, the client can
immediately send the nonce.
Over the QUIC connection with the server, the client sends QUIC
CIDFI_NEW_CONNECTION_ID_MAPPING frames which map the destination CID
to its metadata (e.g., high priority), not to exceed
active_cidfi_connection_id_limit.
As with NEW_CONNECTION_ID, the client should allocate additional
connection IDs retain client privacy during connection migration
(Section 9.5 of [QUIC]) and those additional CIDs should also be
communicated via CIDFI_NEW_CONNECTION_ID. In anticipation of
connection migration those additional connection IDs are not
communicated to the existing network's CNEs, but only to the new
network's CNEs.
Connection IDs which are communicated using NEW_CONNECTION_ID do not
receive per-packet CIDFI treatment. But their contribution to
bandwidth consumption is considered by the CNE.
Note that 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 in
Figure 9.
Wing, et al. Expires 17 June 2024 [Page 19]
Internet-Draft CIDFI December 2023
CIDFI-aware QUIC
client edge router server
| | |
| HTTPS: Enroll CIDFI router to participate |
+----------------------------------->| |
| HTTPS: Ok. nonce=12345 | |
|<-----------------------------------+ |
| | |
: : :
| | |
| QUIC Initial, transport parameter=enable_cidfi |
+------------------------------------------------------>|
| STUN Indication, nonce=12345, HMAC=8f93e |
+--------------------> X (lost) | |
| | |
| HTTPS: "Map DCID=xyz as high importance" |
+----------------------------------->| |
| HTTPS: 403, new Nonce=5678 | |
|<-----------------------------------| |
| STUN Indication, nonce=5678, HMAC=8f93e |
+------------------------------------------------------>|
| | discarded
| | |
| "I saw my nonce, HMAC is valid" |
| | |
| HTTPS: "Map DCID=xyz as high importance" |
+----------------------------------->| |
| Ok | |
|<-----------------------------------+ |
Figure 9: Example of a Client Re-transmitting Lost Nonce
After the initial metadata is exchanged, processing continues with
ongoing host-to-network and network-to-host updates as described in
Section 8.
There are two types of metadata exchanged, described in the following
sub-sections.
7.3.1. Host to Network Signaling
The server communicates to CNEs via the client which then
communicates with the CNE(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.
Wing, et al. Expires 17 June 2024 [Page 20]
Internet-Draft CIDFI December 2023
The communication from the client to the server are using a CIDFI-
dedicated QUIC stream over the same QUIC connection as their primary
communication (Figure 10).
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 | |
+------------------------------------------------------>|
Figure 10: Example of CIDFI Communication
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 Section 12).
7.3.2. Network to Host Signaling
The CNE 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 Figure 11, the CNE
informs the client of reduced bandwidth and the client informs the
server using CIDFI.
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 | | |
+----------------------------------->| |
Figure 11: Example of CIDFI Communication with Metadata Sharing
Wing, et al. Expires 17 June 2024 [Page 21]
Internet-Draft CIDFI December 2023
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 12.
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].
Wing, et al. Expires 17 June 2024 [Page 22]
Internet-Draft CIDFI December 2023
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.
Wing, et al. Expires 17 June 2024 [Page 23]
Internet-Draft CIDFI December 2023
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.
12.1. Server to CIDFI-aware Network Element
Because there is no direct communication from the server to a CNE,
the communication is relayed through the client.
The communications from servers to CNEs do not occur directly, but
rather through the client.
Two types of mapping metadata are described in the following sub-
sections: metadata parameters and DSCP values.
12.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
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. An example is shown in Figure 12.
Wing, et al. Expires 17 June 2024 [Page 24]
Internet-Draft CIDFI December 2023
{
"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
]
}
]
}
]
}
Figure 12: Example JSON for Flow Importance
Note: Figure 12 lists sample attributes and they will be discussed
in detail in a separate document.
Wing, et al. Expires 17 June 2024 [Page 25]
Internet-Draft CIDFI December 2023
12.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.
An example is shown in Figure 13.
{
"dscp":[
{
"quicversion":1,
"dcidlength":3,
"map":[
{
"dscp":10,
"dcids":[
123,
456
]
},
{
"dscp":46,
"dcids":[
998,
183
]
}
]
}
]
}
Figure 13: Example JSON for DSCP Mapping
Wing, et al. Expires 17 June 2024 [Page 26]
Internet-Draft CIDFI December 2023
12.2. CIDFI-aware Network Element to Server
The CIDFI-aware client informs the CNE of the client's received
Destination CIDs. As bandwidth availability to that client changes,
the CNE updates the client with new metadata.
{
"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.
13. Privacy Considerations
13.1. Privacy-Aware Metadata Sharing in Network Relationships
If the network operator and the server have a business relationship,
the server can sign or attest the metadata using, e.g., JSON Web
Token (JWT) [RFC7519] or CBOR Web Token (CWT) [RFC8392]. The
attested metadata will be sent from the server to the client. The
client will decide whether to convey the attested metadata to the
CNE, considering privacy reasons, as it may reveal the identity of
the server to the network. The client may use any local policy or
involve the end-user in the decision-making process regarding whether
to reveal the identity of the server to the network or not. If the
attested metadata is sent to the CNE from the client, the attestation
will be utilized by the CNE, acting as a Relying Party (e.g.,
Section 7.1 of [RFC9334]), to determine the level of trust it wishes
to place in the attested metadata. The relying party may choose to
trust or not trust the attestation.
14. Discussion Points
This section discusses known issues that would benefit from wider
discussion.
14.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.
Wing, et al. Expires 17 June 2024 [Page 27]
Internet-Draft CIDFI December 2023
14.2. Overhead of QUIC DCID Packet Examination
If CID-to-importance metadata was signaled by the server as described
in Section 7.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.
14.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.
14.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.
14.5. Improve CIDFI Initialization Time
Find approaches to further reduce network communications to start
CIDFI.
14.6. Primary QUIC Channel 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?
Wing, et al. Expires 17 June 2024 [Page 28]
Internet-Draft CIDFI December 2023
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.
Wing, et al. Expires 17 June 2024 [Page 29]
Internet-Draft CIDFI December 2023
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
Wing, et al. Expires 17 June 2024 [Page 30]
Internet-Draft CIDFI December 2023
18.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 | enable_cidfi | This-Document |
+-------+----------------+---------------+
Table 1: New QUIC Transport Parameter
18.2. New QUIC Frame Type
This document requests IANA to register a new value in in the "QUIC
Frame Types" registry under the "QUIC" registry group available at
[IANA-QUIC]:
Value: TBDF2
Frame Name: CIDFI_NEW_CONNECTION_ID_MAPPING
Status: permanent
Specification: This-Document
18.3. 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].
18.4. New Special-use Domain Name
Register new special-use domain name cidfi.arpa for DNS SVCB
discovery.
18.5. 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].
The document also requests IANA to register the following service
parameter in the "Service Parameter Keys (SvcParamKeys)" registry
[IANA-SVCB]:
Wing, et al. Expires 17 June 2024 [Page 31]
Internet-Draft CIDFI December 2023
Number: TBD
Name: min-ttl
Meaning: :The minimum IPv4 TTL or IPv6 Hop Limit to use for a
connection.
Reference: This-Document
18.6. New STUN Attribute
This document requests IANA to register the new STUN attribute
"CIDFI-NONCE" in the "STUN Attributes" registry available at
[IANA-STUN].
18.7. New Provisioning Domain Additional Information Key
This document requests IANA to register a new JSON key 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"]
Additionally, this document requests creating a new registry,
entitled "CIDFI JSON Keys" under the Provisioning Domains Additional
Information registry group [IANA-PVD]. The policy for assigning new
entries in this registry is Expert Review Section 4.5 of [RFC8126].
The structure of this registry is identical to the Provisioning
Domains Additional Information registry group. The initial content
of this registry is provided below:
Wing, et al. Expires 17 June 2024 [Page 32]
Internet-Draft CIDFI December 2023
JSON key: cidfinode
Description: FQDN of CIDFI node
Type: string
Example: service.example.net
JSON key: min-ttl
Description: The minimum TTL or Hop Limit to reach a CNE
Type: Unsigned integer
Example: 5
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"
19. References
19.1. Normative References
[CBOR] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/rfc/rfc2131>.
[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,
<https://www.rfc-editor.org/rfc/rfc2474>.
Wing, et al. Expires 17 June 2024 [Page 33]
Internet-Draft CIDFI December 2023
[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, <https://www.rfc-editor.org/rfc/rfc2827>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/rfc/rfc4787>.
[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,
<https://www.rfc-editor.org/rfc/rfc6620>.
[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,
<https://www.rfc-editor.org/rfc/rfc7513>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/rfc/rfc8415>.
[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,
<https://www.rfc-editor.org/rfc/rfc8801>.
[RFC9221] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
Datagram Extension to QUIC", RFC 9221,
DOI 10.17487/RFC9221, March 2022,
<https://www.rfc-editor.org/rfc/rfc9221>.
Wing, et al. Expires 17 June 2024 [Page 34]
Internet-Draft CIDFI December 2023
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
[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, <https://www.rfc-editor.org/rfc/rfc8489>.
19.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,
<https://www.rfc-editor.org/rfc/rfc9335>.
[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,
<https://www.rfc-editor.org/rfc/rfc3168>.
[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-07, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-
rtp-over-quic-07>.
[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-02, 29 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-moq-
requirements-02>.
[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-17, 15 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
load-balancers-17>.
[I-D.ietf-teas-5g-ns-ip-mpls]
Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M.,
and L. M. Contreras, "A Realization of RFC XXXX Network
Slices for 5G Networks Using Current IP/MPLS
Wing, et al. Expires 17 June 2024 [Page 35]
Internet-Draft CIDFI December 2023
Technologies", Work in Progress, Internet-Draft, draft-
ietf-teas-5g-ns-ip-mpls-02, 30 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-
ns-ip-mpls-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-joras-sadcdn-
01>.
[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-01, 8
November 2023, <https://datatracker.ietf.org/doc/html/
draft-zmlk-quic-te-01>.
[IANA-PVD] "Provisioning Domains (PvDs)", 13 August 2020,
<https://www.iana.org/assignments/pvds/
pvds.xhtml#additional-information-pvd-keys>.
[IANA-QUIC]
"QUIC", 26 July 2023,
<https://www.iana.org/assignments/quic/quic.xhtml>.
[IANA-STUN]
"STUN Attributes", 20 March 2023,
<https://www.iana.org/assignments/stun-parameters/stun-
parameters.xhtml>.
[IANA-SVCB]
"DNS Service Bindings (SVCB)", 13 June 2023,
<https://www.iana.org/assignments/dns-svcb/dns-
svcb.xhtml>.
[IANA-WKU] "Well-known URIs", 20 June 2023,
<https://www.iana.org/assignments/well-known-uris/well-
known-uris.xhtml>.
[NAPT] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/rfc/rfc3022>.
Wing, et al. Expires 17 June 2024 [Page 36]
Internet-Draft CIDFI December 2023
[NAT] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999,
<https://www.rfc-editor.org/rfc/rfc2663>.
[pathologies]
Custura, A., Secchi, R., and G. Fairhurst, "Exploring DSCP
modification pathologies in the Internet", May 2018,
<https://www.sciencedirect.com/science/article/pii/
S0140366417312835>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[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,
<https://www.rfc-editor.org/rfc/rfc6105>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7649] Saint-Andre, P. and D. York, "The Jabber Scribe Role at
IETF Meetings", RFC 7649, DOI 10.17487/RFC7649, September
2015, <https://www.rfc-editor.org/rfc/rfc7649>.
[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,
<https://www.rfc-editor.org/rfc/rfc7839>.
[RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley,
N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner,
"An IPv6 Profile for 3GPP Mobile Devices", RFC 7849,
DOI 10.17487/RFC7849, May 2016,
<https://www.rfc-editor.org/rfc/rfc7849>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
Wing, et al. Expires 17 June 2024 [Page 37]
Internet-Draft CIDFI December 2023
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
<https://www.rfc-editor.org/rfc/rfc8512>.
[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
Jacquenet, "An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective",
RFC 8517, DOI 10.17487/RFC8517, February 2019,
<https://www.rfc-editor.org/rfc/rfc8517>.
[RFC9146] 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,
<https://www.rfc-editor.org/rfc/rfc9146>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[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, <https://www.rfc-editor.org/rfc/rfc3550>.
[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,
<https://www.rfc-editor.org/rfc/rfc3711>.
[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,
<https://www.usenix.org/conference/atc17/technical-
sessions/presentation/hoilan-jorgesen>.
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.
Wing, et al. Expires 17 June 2024 [Page 38]
Internet-Draft CIDFI December 2023
A.1. DTLS
DTLS is used by WebRTC and SIP for establishing interactive real-time
audio, video, and screen sharing, which benefit from knowing network
characteristics (n2h signaling) and benefit from prioritizing audio
over video (h2n signaling). [RFC9146] defines an extension to add a
Connection ID (CID) to the DTLS record layer. DTLS CID can be
leveraged by CIDFI to communicate per-connection information from
endpoint to CNE and vice-versa.
A.2. 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.
A.3. 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 7.2 can be performed.
Wing, et al. Expires 17 June 2024 [Page 39]
Internet-Draft CIDFI December 2023
A.4. 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.5. Bespoke UDP Application Protocols
To work with CIDFI, other UDP application protocols would have to
prove ownership of their UDP 4-tuple (Section 7.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].
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
Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
Email: danwing@gmail.com
URI: https://www.cloud.com
Wing, et al. Expires 17 June 2024 [Page 40]
Internet-Draft CIDFI December 2023
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 17 June 2024 [Page 41]