]> Everything OPS & Arrcus

Belgium benoit@everything-ops.net

Swisscom

thomas.graf@swisscom.com

NTT

paolo@ntt.net

Deutsche Telekom

holger.keller@telekom.de

InkBridge Networks

alan.dekok@inkbridge.io

Operations and Management OPSAWG QUIC Network Telemetry IPFIX syslog YANG-Push RADIUS RFC 9221 DATAGRAM 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.

Introduction 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 , IP Flow Information Export (IPFIX) , Syslog , RADIUS or RADIUS Accounting while some others are connection-oriented, such as BMP or NETCONF . 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 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 uses MD5 to obfuscate the User-Password attribute, and both RADIUS and RADIUS Accounting use an MD5-based shared-secret mechanism to compute the Request/Response Authenticator field. These MD5 uses are widely acknowledged to be cryptographically inadequate. defines TLS as a transport for RADIUS, but still uses MD5. 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 or ), each protocol requires a separate security association and a separate certificate or key lifecycle.

The QUIC protocol , with its mandatory TLS 1.3 integration , addresses all of these liabilities. The Unreliable Datagram Extension to QUIC 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 ). 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.

Applicability This document covers protocols that satisfy all three of the following criteria:

1. The protocol currently has a defined UDP transport profile.
2. 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).
3. 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.

Related Work The following IETF drafts address individual protocol mappings to QUIC:

• NETCONF over QUIC : uses QUIC streams for reliable NETCONF messaging.
• BMP over QUIC : BGP Monitoring Protocol over QUIC streams.
• RPKI-RTR over QUIC : RPKI to Router Protocol over QUIC.
• IPFIX over QUIC : IPFIX over QUIC.
• BGP over QUIC : BGP session over QUIC.
• RADIUS over QUIC : RADIUS transport over QUIC streams.
• PCEP over QUIC : Path Computation Element Communication Protocol over QUIC.

This document complements those drafts by providing a shared framework specifically for the UDP-based, loss-tolerant telemetry subset.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology As in , the first letter of each term defined in this section is capitalized throughout this document. The following term is used as defined in :

Network Telemetry:

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 :

Data Record:

A record that contains values of the parameters corresponding to a Template Record.

Data Set:

A Set that contains one or more Data Records defined by the same Template Record.

Exporter:

A device that runs an Exporting Process, sending IPFIX Messages to one or more Collecting Processes.

Flow Record:

A record that contains information about a specific Flow.

Information Element:

A protocol-independent description of an attribute that has been observed or metered.

Observation Domain:

The largest set of Observation Points for which Flow information can be aggregated by a Metering Process.

Options Template Set:

A collection of one or more Options Template Records that have been grouped together in an IPFIX Message.

Template Record:

A record that defines the structure of a Data Record.

Template Set:

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 , , and :

Message Publisher ID:

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

On-Change Subscription:

A subscription that delivers information to a Receiver whenever a change in a datastore is detected.

Periodic Subscription:

A subscription that delivers information to a Receiver at periodic intervals.

Notification Message:

Information intended for a Receiver indicating that one or more events have occurred.

Publisher:

An actor that pushes subscribed event stream data to Receivers. In this document, the Publisher corresponds to the network device exporting Network Telemetry.

Receiver:

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 and :

Connection ID:

An identifier assigned to a QUIC connection that decouples the connection from the underlying network address (IP address and port tuple), enabling connection migration.

DATAGRAM frame:

An unreliable, unordered data unit defined in and carried within a QUIC connection. Lost DATAGRAM frames are not retransmitted by the transport; however, they are subject to congestion control.

STREAM frame:

A reliable, ordered data unit defined in 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:

Session Initiator:

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:

Network Node:

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 (, in YANG-Push contexts), Exporter (, in IPFIX contexts), Originator (, in syslog contexts), or RADIUS client (in RADIUS contexts), originating telemetry data and transmitting it to a collector over QUIC.

Background

QUIC and RFC 9221 DATAGRAM Frames QUIC is a UDP-based, multiplexed, secure transport protocol. Every QUIC connection requires completion of a TLS 1.3 handshake , 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 (): 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.

Why DATAGRAM Frames for Telemetry 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 (). 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 () 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 () 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.

Relationship to DTLS DTLS has been specified as a security layer for UDP-based telemetry (e.g., IPFIX over DTLS ). DTLS 1.2 is the version referenced in existing protocol security specifications; DTLS 1.3 is the current specification. QUIC mandates TLS 1.3 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 . DTLS 1.3 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 does not support 0-RTT resumption. DTLS 1.3 does support 0-RTT resumption (Section 5 of ), 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.

Problem Statement: Security Gaps in UDP Telemetry

Protocols with No or Optional Transport Security Syslog over UDP defines no transport security in its base UDP profile. IPFIX over UDP (RFC 7011 Section 10.4) optionally supports DTLS 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 Authentication Weakness RADIUS uses MD5 with a shared secret to obfuscate the User-Password attribute. Both RADIUS and RADIUS Accounting 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, ) 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. also maintains the use of MD5, which is only removed in , which is experimental.

Absence of Unified Certificate Management 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 (), 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.

Framework: Telemetry over QUIC DATAGRAM Frames

Connection Model 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 (). 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 ).

Application-Layer Protocol Negotiation (ALPN) Identification Each telemetry protocol using this framework SHOULD register a dedicated ALPN identifier. Recommended identifiers are specified in . 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.

Telemetry Payload Format 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.

QUIC Frame Payload Format

Telemetry Type values are defined in . 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.

Stream/Datagram Split 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.

max_datagram_frame_size Negotiation 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 , 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.

Connection Lifecycle and Keepalive 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 , 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 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.

Certificate Management Advantages 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.

Unified Network Node Identity 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.

Single Certificate Lifecycle 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 ) provides revocation status to the collector without requiring the collector to independently query an OCSP responder per protocol.

Elimination of RADIUS MD5 Dependency RADIUS Accounting derives the Accounting-Request Authenticator as an MD5 hash over the packet contents and the shared secret ( 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.

Connection Migration and Failover 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.

Comparison with Current Security Mechanisms Security Comparison for UDP Telemetry Protocols

Protocol	Current UDP Security	Under This Framework
IPFIX	DTLS (optional, / )	TLS 1.3 mutual auth, AEAD
Syslog	None ( 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

Per-Protocol Mappings

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

Data Records IPFIX Data Records SHOULD be carried on QUIC DATAGRAM frames. Each DATAGRAM frame payload, after the two-byte Telemetry Type header defined in , 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.

Relationship to draft-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 Syslog over UDP 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 . The message format is unchanged from the UDP transport. Syslog over TLS 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.

YANG-Push UDP-Notif This section covers YANG-Push exclusively in its UDP-based transport variant: YANG-Push 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.

Distributed Notifications The Distributed Notifications architecture 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 RADIUS Accounting 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 . Most notably:
• RADIUS packets no longer use MD5 for authentication ().
• RADIUS attributes are no longer obfuscated .
• 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.

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 Authentication Requests 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 Status-Server RADIUS also provides for connection oriented status checks via the Status-Server packet . Where implementations of this specification need application-layer watchdog signaling, QUIC PING frames MUST be used instead of Status-Server packets.

Operational Considerations

Collector Scalability 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.

Connection Re-establishment 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.

Interaction with Distributed Export 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 identifies the originating Publisher process (e.g., a line card process) regardless of the connection topology. Similarly, in a distributed router architecture, IPFIX 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.

Impact on Network Node Resources 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.

Legacy UDP Interoperability 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 to allow collectors to negotiate the preferred transport.

Quasi-Anycast 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 and . 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.

Security Considerations 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 , , and 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 ( 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 () 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. 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.

IANA Considerations

ALPN Protocol Identifiers 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: Requested ALPN Identifiers

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

Telemetry Type Registry This document requests that IANA create a new registry "QUIC Telemetry Type Values" under the "QUIC" registry group with the following initial values: QUIC Telemetry Type Values

Value	Protocol	Reference
0x0001	IPFIX
0x0002	Syslog
0x0003	YANG-Push UDP-Notif
0x0004	RADIUS Accounting
0xFFFF	Reserved	This document

New values are assigned by Expert Review.

UDP Port Numbers This document does not request new UDP port numbers. QUIC-based Network Telemetry operates over existing QUIC port allocations.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document describes loss detection and congestion control mechanisms for QUIC. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. Informative References This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols. This includes usage of standards-track RFCs as well as experimental proposals. [STANDARDS-TRACK] As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK] This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages. This document describes the security threats to syslog and how TLS can be used to counter such threats. This document describes the transport for syslog messages over UDP/ IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. [STANDARDS-TRACK] This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. This document is not an Internet Standards Track specification; it is published for informational purposes. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols. This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities". The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format. The module "ietf-notification-capabilities" augments "ietf-system-capabilities" to specify capabilities related to "Subscription to YANG Notifications for Datastore Updates" (RFC 8641). There is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes. This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus. Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols. This document defines Application-Layer Protocol Negotiation (ALPN) extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an application protocol variant of RADIUS called "RADIUS/1.1". No changes are made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet authentication and attribute obfuscation methods are removed. This document updates RFCs 2865, 2866, 5176, 6613, 6614, and 7360. INSA-Lyon INSA-Lyon Huawei Swisscom NTT This document describes a UDP-based transport for YANG notifications to collect data from network nodes within a controlled environment. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. Huawei Huawei Cisco Systems Swisscom INSA-Lyon This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system of a network node. Fiberhome Telecom LTD./CICT. China PCL. China Mobile Viagenie Ionio Systems This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. NETCONF over QUIC allows to take advantage of QUIC streams, for example, to eliminate some TCP head-of-line blocking issues. NETCONF over QUIC provides security properties similar to NETCONF over TLS. This document also defines a YANG module which augments the ietf- netconf-client and ietf-netconf-server YANG modules. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server China Mobile New H3C Technologies Swisscom Everything OPS The IP Flow Information Export (IPFIX) protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Flow Records and Template Records can be carried over a number of transport protocols from an IPFIX Exporter to an IPFIX Collector. The supported transport protocols are SCTP, UDP and TCP. QUIC provides inherently secure, stream-multiplexed, and reliable connections for IPFIX protocol. Especially, a single QUIC connection can carry multiple independent streams, which can improve management scalability between Exporters and Collectors. This document describes how to use IPFIX protocol over the QUIC transport protocol, named IPFIXoQUIC. China Mobile New H3C Technologies Swisscom NTT Hewlett Packard Enterprise The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. China Mobile New H3C Technologies HPE Networking ZDNS China Mobile The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides practical and secure semantics for the RTR protocol, particularly fast connection establishment and multi-stream carrying, thereby reducing the time required to complete RTR data synchronization. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. Futurewei Technologies Futurewei Technologies Juniper Networks Huawei Technologies Nvidia This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. China Mobile New H3C Technologies China Mobile The Remote Authentication Dial-In User Server (RADIUS) Protocol can use the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP) as its underlying transport layer. But it permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. QUIC inherently supports encryption (using TLS 1.3), which could provide a higher level of security. And QUIC supports multiple streams over a single connection, enhancing throughput and efficiency. This document defines RADIUS over the QUIC transport protocol, named RADIUSoQUIC. China Mobile New H3C Technologies Cisco Systems, Inc. China Mobile This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. Deutsches Forschungsnetz | German National Research and Education Network Painless Security Fondation Restena | Restena Foundation This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS.

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

Open Issues The following issues are identified for future resolution:

1. Should this document define normative per-protocol bindings, or remain informational and defer normative content to individual WG-chartered documents?
2. The Telemetry Type header format () should be discussed with the relevant WGs to avoid conflicts with existing shim headers (e.g., the UDP-Notif shim, IPFIX Message Header).
3. The RADIUS Accounting mapping () interacts with work in RADEXT WG. Coordination with is needed to determine whether DATAGRAM and STREAM profiles should be in separate documents.
4. YANG module augmentations for advertising QUIC telemetry transport capability per are not defined in this version and should be added in a future revision.