| Internet-Draft | Telemetry over QUIC | July 2026 |
| Claise, et al. | Expires 4 January 2027 | [Page] |
This document describes the use of the QUIC transport protocol as a common transport substrate for operational Network Telemetry protocols that currently rely on UDP. Specifically, it discusses carrying protocols such as IPFIX, Syslog, YANG-Push UDP-Notif, and RADIUS Accounting over QUIC connections. For telemetry protocols whose data plane is inherently loss-tolerant (where a missing sample is preferable to a delayed retransmission) this document recommends use of the Unreliable Datagram Extension to QUIC (DATAGRAM frames).¶
A primary motivation for this work is the unification of transport- layer security across heterogeneous telemetry protocols. Protocols that currently have no mandatory transport security (syslog over UDP) or optional-only security (IPFIX over UDP with DTLS) or weak security (RADIUS with MD5 obfuscation) would all benefit from the mandatory TLS 1.3 mutual authentication that QUIC provides. This document specifically addresses the operational advantages of managing a single PKI certificate lifecycle per Network Node to authenticate all telemetry streams.¶
This document is intended as a framework and applicability statement. Per-protocol bindings that require normative specification are expected to be chartered in their respective IETF working groups.¶
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 4 January 2027.¶
Copyright (c) 2026 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.¶
Network operators depend on a diverse set of telemetry protocols to
monitor and manage their infrastructure, exporting operational data on which
capacity planning, fault detection, and security analysis depend.
Some of the protocols are connectionless, such as YANG-Push UDP-Notif [RFC8639] [RFC8641] [I-D.ietf-netconf-udp-notif],
IP Flow Information Export (IPFIX) [RFC7011], Syslog [RFC5424], RADIUS [RFC2865] or RADIUS Accounting
[RFC2866] while some others are connection-oriented, such as BMP [RFC7854] or NETCONF [RFC6241].¶
These protocols share a common characteristic: many of their current deployments use UDP as the transport, accepting the possibility of packet loss in exchange for low overhead and high throughput. This is a rational design choice for telemetry data where a stale or retransmitted sample provides less value than a fresh one received in a timely manner.¶
However, this same UDP deployment model brings significant operational liabilities:¶
No mandatory transport-layer security. An attacker on the path can inject or spoof telemetry records. Syslog over UDP has no transport security at all. IPFIX over UDP optionally supports DTLS [RFC6347] but deployment is uncommon; plain UDP is the norm.¶
No confidentiality. Telemetry data, which may include flow records, routing state, and accounting data, is transmitted in the clear.¶
Weak authentication. RADIUS [RFC2865] uses MD5 to obfuscate the User-Password attribute, and both RADIUS [RFC2865] and RADIUS Accounting [RFC2866] use an MD5-based shared-secret mechanism to compute the Request/Response Authenticator field. These MD5 uses are widely acknowledged to be cryptographically inadequate.¶
[I-D.ietf-radext-radiusdtls-bis] defines TLS as a transport for RADIUS, but still uses MD5. [RFC9765] uses TLS as a transport, removes the use of MD5, but is experimental.¶
Fragmented certificate management. When operators do deploy security (e.g., DTLS for IPFIX [RFC6347] or [RFC9147]), each protocol requires a separate security association and a separate certificate or key lifecycle.¶
The QUIC protocol [RFC9000], with its mandatory TLS 1.3 integration [RFC9001], addresses all of these liabilities. The Unreliable Datagram Extension to QUIC [RFC9221] further allows applications to send data without retransmission semantics while retaining the security, congestion awareness, and connection migration properties of the QUIC connection. This combination makes QUIC DATAGRAM frames a natural replacement for the UDP transport used by loss-tolerant telemetry protocols. For example, losing a YANG-Push UDP-Notif Notification Message is generally acceptable for network monitoring applications, but may not be for security-sensitive applications.¶
This document is motivated by the observation that the IETF community is producing several independent drafts mapping specific protocols to QUIC (see Section 1.2). Rather than leaving certificate management, connection lifecycle, and operational guidance to be re-specified independently in each protocol draft, this document defines a common framework, or at least a common problem space.¶
This document covers protocols that satisfy all three of the following criteria:¶
The protocol currently has a defined UDP transport profile.¶
The protocol's data plane is inherently loss-tolerant; that is, retransmission of a missing record either provides no value (stale sample), is already handled at the application layer (e.g., IPFIX Template Record retransmission), or occasional record loss is acceptable for the target application (e.g., network monitoring).¶
The protocol does not require sub-millisecond latency for telemetry data transmission that would be defeated by the QUIC software stack.¶
Protocols that do not satisfy criterion 3 (e.g., NTP, PTP) are out of scope for this document.¶
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.¶
As in [RFC7011], the first letter of each term defined in this section is capitalized throughout this document.¶
The following term is used as defined in [RFC9232]:¶
The process and instrumentation for acquiring and utilizing network data remotely for network monitoring and operation. A general term for a large set of network visibility techniques and protocols, concerning aspects like data generation, collection, correlation, and consumption.¶
The following terms are used as defined in [RFC7011]:¶
A record that contains values of the parameters corresponding to a Template Record.¶
A Set that contains one or more Data Records defined by the same Template Record.¶
A device that runs an Exporting Process, sending IPFIX Messages to one or more Collecting Processes.¶
A record that contains information about a specific Flow.¶
A protocol-independent description of an attribute that has been observed or metered.¶
The largest set of Observation Points for which Flow information can be aggregated by a Metering Process.¶
A collection of one or more Options Template Records that have been grouped together in an IPFIX Message.¶
A record that defines the structure of a Data Record.¶
A collection of one or more Template Records that have been grouped together in an IPFIX Message.¶
The following terms are used as defined in [RFC8639], [RFC8641], and [I-D.ietf-netconf-udp-notif]:¶
A field in the UDP-Notif shim header that identifies the originating publisher process within a distributed notification architecture (for example, a line card process).¶
A subscription that delivers information to a Receiver whenever a change in a datastore is detected.¶
A subscription that delivers information to a Receiver at periodic intervals.¶
Information intended for a Receiver indicating that one or more events have occurred.¶
An actor that pushes subscribed event stream data to Receivers. In this document, the Publisher corresponds to the network device exporting Network Telemetry.¶
An actor that receives subscribed event stream data. In this document, the Receiver corresponds to the Network Telemetry collector.¶
The following terms are used as defined in [RFC9000] and [RFC9221]:¶
An identifier assigned to a QUIC connection that decouples the connection from the underlying network address (IP address and port tuple), enabling connection migration.¶
An unreliable, unordered data unit defined in [RFC9221] and carried within a QUIC connection. Lost DATAGRAM frames are not retransmitted by the transport; however, they are subject to congestion control.¶
A reliable, ordered data unit defined in [RFC9000] and carried within a QUIC connection. Lost STREAM frame data is retransmitted transparently by the QUIC transport.¶
The following terms are used in later in this document:¶
The Network Node that actively opens the QUIC session; the session initiator is responsible for starting the connection, performing the TLS handshake, and for detecting and recovering from session silence by re-establishing the session when required. The following term is defined in this document:¶
Any IP-connected network element -- including routers, switches, servers, and appliances -- that generates and exports Network Telemetry data. In this document, Network Node is the entity that acts as Publisher ([RFC8639], in YANG-Push contexts), Exporter ([RFC7011], in IPFIX contexts), Originator ([RFC5424], in syslog contexts), or RADIUS client (in RADIUS contexts), originating telemetry data and transmitting it to a collector over QUIC.¶
QUIC [RFC9000] is a UDP-based, multiplexed, secure transport protocol. Every QUIC connection requires completion of a TLS 1.3 handshake [RFC9001], which authenticates both endpoints (optionally mutual) and derives the session keys used to protect all subsequent packets.¶
QUIC supports two data-carrying abstractions:¶
STREAM frames: provide reliable, ordered delivery semantics equivalent to TCP. Lost packets are detected and retransmitted.¶
DATAGRAM frames ([RFC9221]): provide unreliable delivery within the established, encrypted, congestion- aware QUIC connection. Lost packets are not retransmitted. The application is optionally notified of loss (implementation- dependent).¶
Support for DATAGRAM frames is negotiated via the max_datagram_frame_size transport parameter during the QUIC handshake. Endpoints that do not include this parameter do not support DATAGRAM frames on that connection.¶
Telemetry data streams such as IPFIX Flow Records, syslog messages, YANG-Push UDP-Notif periodic notifications, or RADIUS accounting share the property that a delayed retransmission has less value than a fresh observation. For these streams, DATAGRAM frames are the correct primitive:¶
Loss of a DATAGRAM frame does not block delivery of subsequent frames (no head-of-line blocking at the transport layer).¶
Unlike raw UDP, DATAGRAM frames are subject to the connection's congestion controller ([RFC9002]). A Network Node under load will back off rather than continue to flood the network.¶
DATAGRAM frames are encrypted, authenticated, and integrity-protected by the same TLS 1.3 session keys as all other QUIC packets. The QUIC handshake authenticates the communicating parties via TLS 1.3 certificates. IPFIX Flow Records and syslog messages carried over plain UDP are designed for use within limited domains ([RFC8799]) where the network path is considered trusted; they are neither encrypted nor source-authenticated. Where such records drive traffic engineering decisions -- route optimization, load balancing, anomaly-triggered policy changes -- or inform network monitoring, an on-path attacker within or at the boundary of the limited domain can inject forged records to influence those decisions or simply discredit monitoring results by introducing spurious data. Once the QUIC handshake completes, every DATAGRAM frame is automatically confidential, its origin cryptographically authenticated, and any in-transit modification is detected and discarded, at no additional configuration cost.¶
A single QUIC connection may carry multiple logical telemetry streams, distinguished by application-layer demultiplexing within the DATAGRAM payload. This eliminates the need for per-protocol UDP sockets and separate security associations.¶
All telemetry protocols multiplexed on a single QUIC connection share one TLS 1.3 handshake and one certificate lifecycle. A Network Node exporting IPFIX, syslog, and YANG-Push notifications simultaneously via a single QUIC connection requires only one set of cryptographic keys and one certificate, rather than separate TLS contexts and key material per protocol.¶
The cost of issuing and maintaining certificates may depend on the number of certificates required. In large-scale deployments, requiring separate certificates for each protocol or application instead of a single certificate per Network Node can significantly increase operational costs, particularly when certificate licensing or management fees are charged on a per-certificate basis. These cost implications SHOULD be considered when defining certificate deployment models, especially for deployments consisting of a large number of Network Nodes.¶
With UDP-based telemetry, the Collector identifies the originating Network Node by the source IP address of the UDP socket -- typically the IP address of the outgoing interface. If that interface fails over, the source IP changes and the Collector loses track of the Network Node, unless the Network Node is explicitly configured to bind to a stable address (e.g., "source interface loopback0"). The QUIC Connection ID ([RFC9000]) provides a stable, transport-layer Network Node identifier that persists across address changes, eliminating this source-address configuration dependency.¶
For protocol components that require reliability (notably IPFIX Template Records), QUIC STREAM frames on the same connection provide reliable delivery without a separate TCP connection.¶
DTLS [RFC6347] has been specified as a security layer for UDP-based telemetry (e.g., IPFIX over DTLS [RFC7011]). DTLS 1.2 [RFC6347] is the version referenced in existing protocol security specifications; DTLS 1.3 [RFC9147] is the current specification. QUIC mandates TLS 1.3 [RFC9001] for all connections, and as a result offers the following advantages relative to DTLS 1.2, with notes where DTLS 1.3 narrows the gap:¶
QUIC's 1-RTT handshake for new connections is faster than the 2-RTT full handshake required by DTLS 1.2 [RFC6347]. DTLS 1.3 [RFC9147] also achieves 1-RTT for new connections, so this advantage applies primarily to deployments that have not yet migrated to DTLS 1.3.¶
QUIC's 0-RTT resumption allows loss-tolerant data to begin flowing before the handshake completes for resumed connections. DTLS 1.2 [RFC6347] does not support 0-RTT resumption. DTLS 1.3 [RFC9147] does support 0-RTT resumption (Section 5 of [RFC9147]), so this advantage does not apply when comparing against DTLS 1.3 deployments.¶
Connection migration, driven by the Connection ID mechanism, allows telemetry streams to survive network address changes (e.g., line card failover, management plane IP renumbering) without session restart.¶
A single QUIC connection replaces multiple parallel DTLS sessions when a Network Node exports several telemetry streams to the same collector.¶
Syslog over UDP [RFC5426] defines no transport security in its base UDP profile. IPFIX over UDP (RFC 7011 Section 10.4) optionally supports DTLS [RFC9147] for transport security, but this is not mandatory and in practice most deployments use plain UDP without DTLS, relying instead on network-layer access control (ACLs, routing policy) as a substitute for authentication. This provides no protection against on-path attackers and is invisible to the receiving collector, which cannot verify the origin of records.¶
RADIUS [RFC2865] uses MD5 with a shared secret to obfuscate the User-Password attribute. Both RADIUS [RFC2865] and RADIUS Accounting [RFC2866] derive the Request Authenticator and Response Authenticator fields using an MD5 hash of the packet contents and the shared secret. The MD5 weaknesses involved are well-documented and widely acknowledged. While RADIUS over TLS (RadSec, [I-D.ietf-radext-radiusdtls-bis]) exists, adoption has been limited by operational complexity and the need to manage separate TLS contexts for RADIUS alongside existing TLS deployments on the same Network Node.¶
[I-D.ietf-radext-radiusdtls-bis] also maintains the use of MD5, which is only removed in [RFC9765], which is experimental.¶
Even where individual protocols support transport security, operators face the burden of managing separate security contexts per protocol:¶
A Network Node exporting IPFIX over DTLS, syslog over TLS ([RFC5425]), and YANG-Push over HTTPS requires three separate certificate deployments, three renewal cycles, and three independent revocation verification paths (whether via Certificate Revocation Lists (CRL) or Online Certificate Status Protocol (OCSP) queries) for what is functionally the same Network Node identity.¶
Certificate rotation in one protocol does not benefit the others.¶
Monitoring certificate expiry requires per-protocol tooling.¶
This fragmentation is a significant operational burden, particularly at scale.¶
A QUIC connection for Network Telemetry is established from the Network Node to the telemetry collector (Receiver). This follows the same direction as the data flow for push-based Network Telemetry.¶
QUIC mandates TLS 1.3 ([RFC9001]). Mutual authentication (both client and server certificates) SHOULD be used. The Network Node certificate authenticates the Exporter; the collector certificate authenticates the Receiver.¶
The QUIC connection carries all telemetry streams between a given Network Node-to-collector pair. STREAM frames and DATAGRAM frames co-exist on the same connection. The application layer MUST provide a demultiplexing header in the DATAGRAM payload to identify the protocol and stream identity (see Section 5.3).¶
Each telemetry protocol using this framework SHOULD register a dedicated ALPN [RFC9001] identifier. Recommended identifiers are specified in Section 10. An implementation MAY use the generic "telq" ALPN when multiplexing multiple protocols on a single connection, with per-protocol identification delegated to the DATAGRAM payload header.¶
A two-byte Telemetry Type field prepended to each QUIC frame payload identifies the encapsulated telemetry protocol. This header applies to both DATAGRAM frames (unreliable telemetry data) and STREAM frames (reliable control and state-change data, such as IPFIX Template Records, YANG-Push on-change notifications, and subscription state change notifications). This allows a single QUIC connection to carry multiple telemetry protocols without ambiguity, regardless of the reliability mechanism used.¶
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Telemetry Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-Specific Payload | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Telemetry Type values are defined in Section 10. The protocol-specific payload for each protocol is identical to the payload that would be transmitted in the corresponding UDP datagram. No further encapsulation is required. This design allows existing encoder/decoder implementations to function without modification when the UDP socket is replaced by a QUIC DATAGRAM or STREAM API.¶
For protocols that mix reliable and unreliable data, the following split applies:¶
Protocol control information, Template Records, and configuration messages MUST be carried on QUIC STREAM frames to ensure reliable delivery.¶
Telemetry data records (Flow Records, log messages, notification updates, accounting records) SHOULD be carried on QUIC DATAGRAM frames.¶
An implementation MAY carry all data on QUIC STREAM frames if the application requires guaranteed delivery. This is a per-deployment configuration choice, not a protocol violation.¶
Endpoints MUST advertise a max_datagram_frame_size sufficient to accommodate the largest expected telemetry record without fragmentation. A value of 65535 is RECOMMENDED as a safe upper bound. Per [RFC9221], DATAGRAM frames larger than the negotiated maximum may not be sent; implementations MUST either fragment at the application layer or fall back to STREAM frames for oversized records.¶
Unlike TCP-based telemetry protocols (gRPC/gNMI, NETCONF), a QUIC connection silently expires when no packets are exchanged within the idle timeout. The Session Initiator SHOULD monitor for the absence of expected telemetry and re-establish the QUIC session when the peer remains silent beyond its configured reporting interval.¶
QUIC idle timeout is configured via the max_idle_timeout transport parameter. For long-lived telemetry sessions, implementations SHOULD send QUIC PING frames at an interval not exceeding half the max_idle_timeout to maintain the connection and any intermediate NAT bindings. According to section 3.2 of [RFC9308], it is recommended to set the interval to 30 seconds to ensure that possible NAT states in transit remain active, while section 10.1 of [RFC9000] states that the PING frames interval should be set so that at least 3 PING frames can be sent before max_idle_timeout is reached. Therefore, a recommended idle timeout for telemetry connections is 120 seconds, with PING frames sent at 30-second intervals.¶
This section describes the specific operational improvements that arise from consolidating UDP-based Network Telemetry under a single QUIC connection with TLS 1.3 mutual authentication.¶
A Network Node that currently exports IPFIX, Syslog, and YANG-Push UDP-Notif over UDP has no cryptographic Network Node identity in those channels. Under this framework, a single X.509 certificate issued to the Network Node (identified by its Common Name or Subject Alternative Name) authenticates the Network Node for all telemetry streams carried on the QUIC connection. The collector need only maintain one trust anchor per Network Node, independent of how many telemetry protocols that Network Node exports.¶
Certificate issuance, renewal, and revocation are managed once per Network Node, not once per protocol. This has direct operational consequences:¶
Automated certificate management tools (e.g., ACME, EST) need to manage one certificate per Network Node for all Network Telemetry, rather than one per protocol per Network Node.¶
Certificate expiry monitoring requires one alert per Network Node.¶
Key rotation is performed once; all telemetry protocols on the renewed connection immediately benefit from the new key material via QUIC's post-handshake key update mechanism.¶
OCSP stapling (supported in TLS 1.3 and thus in QUIC [RFC9001]) provides revocation status to the collector without requiring the collector to independently query an OCSP responder per protocol.¶
RADIUS Accounting [RFC2866] derives the Accounting-Request Authenticator as an MD5 hash over the packet contents and the shared secret ([RFC2866] Section 3), providing only weak integrity protection. By mapping RADIUS Accounting messages to QUIC DATAGRAM frames, this MD5-based shared-secret dependency is replaced by AEAD encryption (AES-128-GCM or ChaCha20-Poly1305) derived from the TLS 1.3 handshake. No shared secret configuration is required. The collector authenticates the Network Node by its certificate; the Network Node authenticates the collector by its certificate.¶
When a Network Node's management plane IP address changes -- due to interface failover or ECMP re-hashing -- a TCP-based telemetry session breaks and requires a new TLS handshake (and certificate verification) on the replacement connection. Under QUIC, Connection IDs decouple the session identity from the underlying IP/port 4-tuple. The connection, and its associated authenticated identity, survives the address change. No certificate re-validation is required for the migrated path.¶
| Protocol | Current UDP Security | Under This Framework |
|---|---|---|
| IPFIX | DTLS (optional, [RFC6347] / [RFC9147]) | TLS 1.3 mutual auth, AEAD |
| Syslog | None ([RFC5426] UDP) | TLS 1.3 mutual auth, AEAD |
| YANG-Push UDP-Notif | Optional DTLS | TLS 1.3 mutual auth, AEAD |
| RADIUS Acct | MD5 obfuscation | TLS 1.3 mutual auth, AEAD |
IPFIX [RFC7011] uses a Template/Data Record architecture. Template Records define the Information Elements present in Data Records. A Receiver that has not received the relevant Template Record cannot decode Data Records.¶
Template Records MUST be carried on QUIC STREAM frames. The stream MUST be a unidirectional stream initiated by the Exporter. Template Records within this stream follow the normal IPFIX encoding with Set ID 2 (Template Set) or Set ID 3 (Options Template Set). The reliable delivery semantics of QUIC streams ensure that the Receiver obtains all templates before or concurrent with the first Data Records referencing them.¶
This is architecturally equivalent to the TCP-based IPFIX transport (RFC 7011 Section 10.3), replacing the TCP byte stream with a QUIC stream.¶
IPFIX Data Records SHOULD be carried on QUIC DATAGRAM frames. Each DATAGRAM frame payload, after the two-byte Telemetry Type header defined in Section 5.3, contains one or more IPFIX Data Sets encoded according to RFC 7011.¶
Loss of a DATAGRAM frame results in loss of the contained Flow Records, consistent with the existing behavior of the IPFIX UDP transport (RFC 7011 Section 10.2).¶
The Observation Domain ID is preserved in each IPFIX Message Header within the DATAGRAM payload. No mapping between QUIC stream identifiers and IPFIX Observation Domain IDs is required.¶
[I-D.llg-opsawg-ipfix-over-quic] defines a more complete IPFIX binding to QUIC, potentially including stream-per-template-set designs. This document focuses on the DATAGRAM-based data plane as the direct replacement for the UDP export profile, and defers normative detail to that draft.¶
Syslog over UDP [RFC5426] sends syslog messages as individual UDP datagrams. Each syslog message is self-contained, making it directly suitable for DATAGRAM frame transport.¶
Each DATAGRAM frame payload, after the Telemetry Type header, contains exactly one syslog message encoded per RFC 5424 [RFC5424]. The message format is unchanged from the UDP transport.¶
Syslog over TLS [RFC5425] provides a reference for certificate- based authentication of syslog. Under this framework, the same PKI infrastructure is used, but via the QUIC connection rather than a separate TLS-over-TCP session.¶
This section covers YANG-Push exclusively in its UDP-based transport variant: YANG-Push UDP-Notif [I-D.ietf-netconf-udp-notif]. Other YANG-Push transports (HTTPS-Notif, NETCONF) are TCP-based and out of scope for this document. YANG-Push UDP-Notif sends Notification Messages as UDP datagrams with a shim header providing message segmentation and sequence numbering.¶
Under this framework, YANG-Push UDP-Notif messages are carried in QUIC DATAGRAM frames using the UDP-Notif shim header unchanged. The shim header's sequence number field provides loss detection at the application layer, consistent with its use in the UDP transport.¶
Three notification types warrant different treatment:¶
push-update notifications: data samples are time-bound and stale if retransmitted. DATAGRAM frames SHOULD be used.¶
push-change-update notifications: missed change notifications result in the collector maintaining an incorrect view of Network Node state. For On-Change Subscriptions, implementations SHOULD use QUIC STREAM frames to ensure reliable delivery.¶
subscription state change notifications: missed subscription state change notifications result in the collector maintaining an incorrect view of YANG-Push subscription state. For subscription state change notifications, implementations SHOULD use QUIC STREAM frames to ensure reliable delivery.¶
This per-subscription-type split is the primary rationale for using this framework for YANG-Push: the DATAGRAM/STREAM choice maps directly onto the existing periodic/on-change distinction, while the UDP-Notif shim header is preserved unchanged.¶
The Distributed Notifications architecture [I-D.ietf-netconf-distributed-notif] allows line card processes to export directly to collectors without routing through the Route Processor. QUIC DATAGRAM frames are well-suited to this model: each line card process opens a QUIC connection to the collector and sends DATAGRAM frames. The Message Publisher ID in the shim header identifies the originating process.¶
RADIUS Accounting [RFC2866] uses UDP transport with MD5-based message authentication. Accounting-Request and Accounting-Response messages are self-contained.¶
Under this framework:¶
Accounting-Request messages are carried in QUIC DATAGRAM frames.¶
The base RADIUS protocol is updated to use RADIUS/1.1 [RFC9765]. Most notably:¶
RADIUS packets no longer use MD5 for authentication ([RFC9765], Section 4).¶
RADIUS attributes are no longer obfuscated [RFC9765], Section 5.¶
RADIUS/1.1 allows more than 256 packets to be outstanding over one connection.¶
Accounting-Response messages from the collector to the Network Node travel in the reverse direction. As QUIC DATAGRAM frames are bidirectional, the collector responds using a DATAGRAM frame on the same connection.¶
[I-D.yl-radext-quic-transport] defines an alternative RADIUS mapping over QUIC STREAM frames, providing reliable delivery semantics for RADIUS. The present document's DATAGRAM approach is appropriate for high-volume accounting scenarios where occasional record loss is acceptable. Implementations MUST choose one approach per connection based on deployment requirements.¶
RADIUS can also transport Access-Request packets, and responses to those packets. While it is possible to transport those packets via this specification, that behavior is not addressed here.¶
RADIUS also provides for connection oriented status checks via the Status-Server packet [RFC5997]. Where implementations of this specification need [RFC3539] application-layer watchdog signaling, QUIC PING frames MUST be used instead of Status-Server packets.¶
A single collector may receive QUIC connections from a large number of Network Nodes. Each QUIC connection carries its own TLS context. Collectors MUST be designed to handle large numbers of concurrent QUIC connections efficiently. Connection-level flow control (MAX_DATA) SHOULD be tuned to accommodate bursty telemetry export patterns.¶
If a QUIC connection is lost (idle timeout, network failure, Network Node reboot), the Network Node MUST re-establish the connection and re-transmit any stateful protocol information (e.g., IPFIX Template Records) before resuming DATAGRAM-based data export. Network Nodes SHOULD implement exponential backoff for re-establishment attempts.¶
In distributed architectures (e.g., line card direct export), each line card process MAY maintain a separate QUIC connection to the collector, or MAY share a connection with the Route Processor. The Message Publisher ID in YANG-Push UDP-Notif [I-D.ietf-netconf-udp-notif] identifies the originating Publisher process (e.g., a line card process) regardless of the connection topology. Similarly, in a distributed router architecture, IPFIX [RFC7011] deployments have each line card run its own Metering Process with a distinct Observation Domain ID carried in each IPFIX Message Header, identifying the originating Observation Domain regardless of the connection topology.¶
QUIC connections consume memory and CPU for TLS context, congestion state, and Connection ID management. Network Nodes with high line card counts and multiple telemetry protocols should evaluate the resource impact of maintaining one QUIC connection per collector per line card against the resource savings of multiplexing protocols on fewer connections.¶
Network Nodes that do not support QUIC MUST continue to support their existing UDP transport profiles. This framework does not deprecate UDP transport for any protocol. QUIC transport availability SHOULD be advertised via the YANG capabilities model [RFC9196] to allow collectors to negotiate the preferred transport.¶
A telemetry collector MAY be reachable via an anycast address for initial QUIC rendezvous, with the connection subsequently migrated to a stable unicast address using QUIC Preferred Address. This document refers to that deployment model as Quasi-Anycast. The term describes an operational pattern, not a new anycast routing semantic, and is consistent with the service and routing terminology of [RFC4786] and [RFC7094].¶
In such deployments, the server SHOULD advertise a Preferred Address only when the backend can accept the migrated connection state and the client can successfully validate the new path. The client MUST validate the new path before sending non-probing packets to it. Operators SHOULD use this pattern when anycast is desirable for discovery or nearest-ingress selection, but a long-lived telemetry session benefits from stable backend affinity. ## Manual Certificate Lifecycle¶
In smaller deployments, automated certificate lifecycle management may not be available, and certificate provisioning, renewal, and replacement are performed manually. A single Network Node may use multiple certificates for different applications or protocol stacks. Since certificates are commonly managed and activated independently by each consuming application, certificate rollover may occur at different points in time. During such transition periods, some applications may continue to rely on legacy configurations, including unsecured UDP-based transport, until certificate updates have been completed consistently across all consumers. Implementations SHOULD minimize the duration of such transition periods and SHOULD provide mechanisms to coordinate certificate replacement across all affected applications.¶
The security properties of all telemetry data transported using this framework are determined by the QUIC connection's TLS 1.3 handshake. The considerations in [RFC9000], [RFC9001], and [RFC9221] apply.¶
Mutual certificate authentication SHOULD be used for all deployments. A collector that does not authenticate the Network Node certificate cannot trust the origin of telemetry records. A Network Node that does not authenticate the collector certificate may export sensitive operational data to an adversary.¶
Certificate revocation MUST be checked. OCSP stapling is RECOMMENDED as the revocation mechanism because it allows the Network Node to provide proof of validity at connection establishment without requiring the collector to query an OCSP responder separately.¶
DATAGRAM frames, like all QUIC packet payloads, are AEAD-protected. An on-path observer cannot read or modify DATAGRAM frame contents. The QUIC invariants (Connection IDs, packet type bits) are observable but do not reveal telemetry content.¶
0-RTT connection resumption ([RFC9001] Section 4.6.1) allows early data, including telemetry DATAGRAM frames, to be sent before the handshake completes. 0-RTT data does not provide forward secrecy and is susceptible to replay attacks. For telemetry protocols, replay of a periodic sample record is generally harmless but implementations SHOULD document their 0-RTT behavior and MAY disable 0-RTT for security-sensitive deployments.¶
The replacement of RADIUS Accounting's MD5-based message authenticator (Section 7.4) with QUIC's AEAD protection is a security improvement. Implementations should ensure that existing RADIUS processing pipelines do not rely on the MD5 Message-Authenticator for any purpose other than transport-level authentication.¶
Using a single certificate across multiple protocols or applications increases the impact of a certificate compromise. An attacker obtaining the corresponding private key can potentially impersonate the Network Node towards all relying parties that trust this certificate, instead of only affecting a single protocol or application. Conversely, using separate certificates can limit the scope of a compromise, but increases the operational effort required for certificate lifecycle management and incident response. A Network Node may communicate with multiple client systems, such as telemetry collectors, management systems, and application-specific consumers. When a compromised certificate is replaced, all affected relying parties need to update their trust configuration in a coordinated manner to maintain authenticated communication. This coordination is particularly relevant when migrating unreliable UDP-based communication to QUIC DATAGRAM. [RFC9221] specifies that DATAGRAM frames do not provide explicit flow control and may be dropped by the receiver if they cannot be processed. It also specifies that DATAGRAM frames are subject to QUIC congestion control and may be delayed or dropped when congestion control does not allow immediate transmission. Consequently, applications using QUIC DATAGRAM cannot assume that certificate-related transition messages, telemetry data, or other operational signals carried over DATAGRAM frames are reliably delivered. Therefore, certificate rollover and compromise recovery procedures SHOULD NOT rely solely on unreliable datagram delivery for critical state synchronization. Implementations SHOULD provide a reliable and authenticated mechanism, for example using QUIC streams or another reliable management channel, to coordinate certificate replacement, revocation handling, and trust-store updates across affected Network Nodes and client systems. While certificate renewal due to expiration is a routine operational process, emergency certificate replacement following a compromise typically requires substantially greater coordination and operational effort. These considerations SHOULD be taken into account when selecting between per-Network Node and per-protocol certificate deployment models.¶
This document requests that IANA register the following Application- Layer Protocol Negotiation (ALPN) protocol identifiers in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry:¶
| Identification Sequence | Protocol | Reference |
|---|---|---|
| 0x69 0x70 0x66 0x78 0x71 ("ipfxq") | IPFIX over QUIC | This document |
| 0x73 0x79 0x73 0x71 ("sysq") | Syslog over QUIC | This document |
| 0x79 0x70 0x71 ("ypq") | YANG-Push over QUIC | This document |
| 0x72 0x61 0x64 0x71 ("radq") | RADIUS over QUIC | This document |
| 0x74 0x65 0x6c 0x71 ("telq") | Generic Telemetry | This document |
This document requests that IANA create a new registry "QUIC Telemetry Type Values" under the "QUIC" registry group with the following initial values:¶
| Value | Protocol | Reference |
|---|---|---|
| 0x0001 | IPFIX | [RFC7011] |
| 0x0002 | Syslog | [RFC5424] |
| 0x0003 | YANG-Push UDP-Notif | [I-D.ietf-netconf-udp-notif] |
| 0x0004 | RADIUS Accounting | [RFC2866] |
| 0xFFFF | Reserved | This document |
New values are assigned by Expert Review.¶
This document does not request new UDP port numbers. QUIC-based Network Telemetry operates over existing QUIC port allocations.¶
The authors would like to thank the authors and contributors of the related drafts referenced in this document, particularly those working on IPFIX over QUIC, NETCONF over QUIC, and UDP-Notif, for their foundational work that motivates this framework document.¶
The authors also thank the QUIC Working Group for the development of RFC 9221, without which this framework would not be possible.¶
The following issues are identified for future resolution:¶
Should this document define normative per-protocol bindings, or remain informational and defer normative content to individual WG-chartered documents?¶
The Telemetry Type header format (Section 5.3) should be discussed with the relevant WGs to avoid conflicts with existing shim headers (e.g., the UDP-Notif shim, IPFIX Message Header).¶
The RADIUS Accounting mapping (Section 7.4) interacts with work in RADEXT WG. Coordination with [I-D.yl-radext-quic-transport] is needed to determine whether DATAGRAM and STREAM profiles should be in separate documents.¶
YANG module augmentations for advertising QUIC telemetry transport capability per [RFC9196] are not defined in this version and should be added in a future revision.¶