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 their QUIC and DTLS streams can be augmented with
information about network conditions and packet importance to meet both
intentional and reactive management policies. With
optional server support individual packets can receive differentiated
service. The proposed approach covers both directions of a flow.¶
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."¶
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.¶
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 and application protocols using DTLS.¶
This document defines CIDFI (pronounced "sid fye") which is a system
of several protocols that allow communicating about a [QUIC]
connection or a DTLS connection [DTLS-CID] from the network to the
server and the server to the network. The information exchanged
allows the server to know about network conditions and allows the
server to signal packet importance. 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 11
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.¶
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 or DTLS)
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.¶
CIDFI brings benefits to QUIC and DTLS because those protocols are 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, supplanting TCP. Applications can take
advantage of QUIC's unreliability to help networks provide reasonable
service to clients on constrained links, especially as the user
transitions from a high quality wireless reception to lower quality
reception (e.g., entering a building). 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). That said, CIDFI can be extended to other protocols
as discussed in Appendix A.¶
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.¶
With reliable transport such as TCP, the 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.¶
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.¶
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.¶
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.¶
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].¶
This section highlights the design goals of this specification.¶
Client Authorization:
The client authorizes each CIDFI-aware network element (CNE) to participate in CIDFI
for each QUIC (or DTLS) flow.¶
Same Server 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 (or DTLS) 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 (or DTLS) CIDs.¶
Internet Survival:
The QUIC (or DTLS) communications between clients
and servers are not changed so CIDFI is expected to work wherever QUIC
(or DTLS) works. The elements involved are only the QUIC (or DTLS)
client and server and with the participating CIDFI-aware network elements.¶
CIDFI can operate over IPv4, IPv6, IPv4/IPv4 translation (NAT), and IPv6/IPv4
translation (NAT64).¶
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.¶
This document defines a new DNS Service Binding parameter "cidfi-aware" in
Section 17.4 and a new Special-Use Domain Name "cidfi.arpa" in
Section 17.3.¶
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).¶
When multihoming, the multihome-capable CPE aggregates all upstream
networks' "_cidfi-aware.cidfi.arpa" responses into the response sent to
its locally-connected clients.¶
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.¶
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.¶
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).¶
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].¶
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].¶
The response from the previous step in Section 6.1 will contain one or more
CNEs.¶
The client authorizes each of the CNEs using
a local policy. This policy is implementation-specific. An
implementation example might have the users authorize their ISP's CIDFI server
(e.g., allow "cidfi.example.net" if a user's ISP is configured with
"example.net"). Similarly, if none of the CNEs are recognized by the client, the client
might silently avoid using CIDFI on that network.¶
After authorizing that subset of CNEs, the
client makes a new HTTPS connection to each of those CNEs
and performs PKIX validation of their certificates.
The client MAY have to authenticate itself to the 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.¶
When a QUIC client (or DTLS-CID) client connects to a QUIC (or DTLS-CID) server, the client:¶
learns if the server supports CIDFI
and obtains its mapping of transmitted Destination CIDs to metadata, described
in Section 7.1.¶
proves ownership of its UDP 4-tuple to
the on-path CNEs, described in Section 7.2.¶
performs initial metadata exchange
with the CIDFI network element and server, and server and network element,
described in Section 7.3.¶
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.¶
On initial connection to a QUIC server, the client includes a new QUIC
transport parameter CIDFI (Section 17.1) which is remembered for 0-RTT.¶
If the server does not indicate CIDFI support, the client can still
perform CIDFI -- but does not expect different CIDs to indicate
differentiated behavior. The client can still signal 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 the 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.¶
If the server indicates CIDFI support, then the server creates a
new Server-Initiated, Bidirectional QUIC stream which is dedicated to
CIDFI communication. This stream number is communicated in the
CIDFI transport response during the QUIC handshake.¶
TODO: Specify how CIDFI stream number is communicated to client.¶
The QUIC client and server exchange CIDFI information over
this CIDFI-dedicated stream as described in Section 7.3.¶
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] indication (STUN
class of 0b01) containing one or more CIDFI-NONCE attributes
(Section 17.5). 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 dicarded 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.¶
Later, when connecting to a new QUIC or DTLS 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 or DTLS connect
(step 2). If a CIDFI Network Element is present it processes the STUN
Indication and sends a response to the client over HTTP using the
HTTP channel established above.¶
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.¶
The short header's Destination Connection ID (DCID) can be 0 bytes or
as short as 8 bits, so multiple QUIC clients are likely to use the
same incoming Destination CID on their own UDP 4-tuple. The STUN
Indication message allows the CIDFI network element to distinguish
each QUIC client's UDP 4-tuple.¶
Because multiple QUIC clients may use the same incoming Destination CID on
their own UDP 4-tuple, the STUN Indication message allows a CNE
to distinguish each QUIC client's UDP 4-tuple.¶
To reduce CIDFI setup time the client STUN Indication MAY be sent at
the same time as it establishes connection with the QUIC or DTLS server.¶
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).¶
The format of the STUN CIDFI-NONCE attribute is shown in Figure 8.¶
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.¶
Using its HTTPS channel with each of the CNEs it
previously authorized for CIDFI participation, the client signals the
mapping of the server's transmitted short Destination Connection ID
and its length to the CNE. As server support
of the QUIC CIDFI transport parameter is remembered for 0-RTT, the
client can immediately send the nonce.¶
The primary purpose of a second Connection ID is connection migration
(Section 9 of [QUIC]). With CIDFI, additional Connection IDs are
necessary to:¶
maintain CIDFI operation when topology remains the same.¶
use Destination Connection ID to indicate packet importance¶
To maintain CIDFI operation when topology remains the same, the
CIDFI client signals the CNEs of that 'next'
Destination CID. When QUIC detects a topology change, however, that
Destination CID MUST NOT be used by the peer, otherwise it links
the communication on the old topology to the new topology (Section 9.5 of [QUIC]).
Thus, an additional Connection ID is purposefully not communicated
from the CIDFI client to its CNEs, so that
Connection ID can be immediately used by the peer during connection
migration when the topology changes.¶
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.¶
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.¶
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.¶
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).¶
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 11).¶
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.¶
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 11.¶
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.¶
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.¶
When the topology changes the client will transmit from a new IP
address -- such as switching to a backup WAN connection, or such as
switching from Wi-Fi to 5G. If using QUIC, 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.¶
todo: include discussion of [DTLS-CID] client and discussion
of its ICE interaction, if any?¶
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.¶
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.¶
Note: Figure 12 lists sample attributes and they will be discussed in detail in a separate document.¶
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.¶
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.¶
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.¶
Need to evaluate number of round trips (and other overhead) of client
signaling CID-to-importance mapping or server signaling CID-to-importance
mapping.¶
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.¶
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.¶
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.¶
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?¶
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.¶
For each QUIC or DTLS stream requiring differentiated service, the QUIC or DTLS stack can
map that stream to a different Destination CID. The application-level code
would require an API to instruct the QUIC or DTLS 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 or DTLS 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.¶
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.¶
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]:¶
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:¶
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"
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
[DTLS-CID]
Rescorla, E., Ed., Tschofenig, H., Ed., Fossati, T., and A. Kraus, "Connection Identifier for DTLS 1.2", RFC 9146, DOI 10.17487/RFC9146, , <https://www.rfc-editor.org/rfc/rfc9146>.
[QUIC]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <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, , <https://www.rfc-editor.org/rfc/rfc2119>.
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, , <https://www.rfc-editor.org/rfc/rfc2474>.
[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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc8801>.
[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, , <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, , <https://www.rfc-editor.org/rfc/rfc8489>.
Uberti, J., Jennings, C., and S. Murillo, "Completely Encrypting RTP Header Extensions and Contributing Sources", RFC 9335, DOI 10.17487/RFC9335, , <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, , <https://www.rfc-editor.org/rfc/rfc3168>.
Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, , <https://www.rfc-editor.org/rfc/rfc3022>.
[NAT]
Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, , <https://www.rfc-editor.org/rfc/rfc2663>.
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <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, , <https://www.rfc-editor.org/rfc/rfc6105>.
Bhandari, S., Gundavelli, S., Grayson, M., Volz, B., and J. Korhonen, "Access-Network-Identifier Option in DHCP", RFC 7839, DOI 10.17487/RFC7839, , <https://www.rfc-editor.org/rfc/rfc7839>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/rfc/rfc8392>.
[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, , <https://www.rfc-editor.org/rfc/rfc8517>.
[RFC9221]
Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", RFC 9221, DOI 10.17487/RFC9221, , <https://www.rfc-editor.org/rfc/rfc9221>.
[RFC9334]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc3711>.
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,¶
send TCP SYN + CIDFI option (including Nonce bits 0-63)¶
if received TCP SYNACK does not indicate CIDFI support, stop sending CIDFI option¶
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.¶
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].¶
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] or [DTLS-CID].¶
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.¶