IPFIX Protocol over QUIC

specifies a protocol called IP Flow Information Export (IPFIX) that specifies how IPFIX Data Records and corresponding (Options) Template Records are carried via a few of transport protocols from an Exporter to a Collector. specifies "SCTP using the PR-SCTP extension as specified in MUST be implemented by all compliant implementations. UDP MAY also be implemented by compliant implementations. TCP MAY also be implemented by compliant implementations." However, in practice, the UDP transport is used. The IPFIX protocol specifications cover the specifics and mappings per transport protocol (see Section 8, 9, 10 of ). For example, the Template management differs based on the transport protocol. To prevent potential security threats (such as DoS attacks), it is highly desirable to ensure the confidentiality and integrity of IPFIX data transferred from an Exporter to a Collector. An authentication mechanism is also desirable to prevent the collection of data from an unauthorized Exporting Process or the export of data to an unauthorized Collecting Process. QUIC conforms to the above requirements and is therefore also an appropriate transport protocol for the IPFIX protocol. QUIC is a UDP-based multiplexed and secure transport protocol that provides connection-oriented and stateful interaction between a client and server. QUIC uses multiple simultaneous streams to carry data in one direction. Each stream is a separate unidirectional or bidirectional channel consisting of an ordered stream of bytes. In addition, each stream has its own flow control, which limits bytes sent on a stream, together with flow control of the connection. Moreover, QUIC does not have the TCP shortcomings such as head of line blocking. Compared to the transport protocols already supported by IPFIX , QUIC offers the following advantages: QUIC provides reliability and congestion control for in-order delivery of data, similar to SCTP and TCP. It is more universally used and supported across the global Internet environment because QUIC is a UDP-based protocol. QUIC has built-in TLS encryption (typically TLS 1.3), offering end-to-end security to ensure data confidentiality and integrity. In contrast, encryption for SCTP, UDP, and TCP requires additional protocols such as DTLS, increasing configuration complexity. QUIC supports multi-streaming similar to SCTP, allowing multiple data streams to be multiplexed within a single connection. Each stream transmits data independently, avoiding the head-of-line blocking issue found in TCP. QUIC has a faster connection establishment speed than TCP and SCTP. QUIC requires 1-2 handshakes, TCP requires 3 handshakes, and SCTP requires 4 handshakes. QUIC supports MTU discovery similar to SCTP and TCP, which can dynamically optimize packet fragmentation, reduce data loss caused by fragmentation failure. This gives QUIC strong adaptability to different MTU conditions. The QUIC connection migration feature can make it easy to maintain sessions seamlessly even when IP addresses change (e.g., during Wi-Fi to cellular handover), making it well-suited for IPFIX collection in mobile networks. SCTP connection migration is more complicated, and all backup addresses must be exchanged in advance. QUIC based on UDP is a pure user-mode implementation that does not require operating system kernel support. QUIC is flexible to deploy and easy to expand. QUIC traffic is less likely to be blocked by enterprise firewalls/NAT than TCP and SCTP. Therefore, QUIC is a proper secure and reliable transport protocol for the message transmission mechanism of the IPFIX protocol. This document specifies how to use QUIC as the transport protocol for the IPFIX protocol.

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. This document makes use of the terms defined in . The following terms are used as defined in : Flow Record Exporting Process Exporter Collecting Process Collector Template IPFIX Message Template Record Data Record Options Template Record Set Template Set Transport Session Options Template Set Data Set In this document, the terms "client" and "server" are used to refer to the two ends of the QUIC connection. The client actively initiates the QUIC connection. The terms "Exporter" and "Collector" are used to refer to the two ends of the IPFIX protocol session. An Exporter establishes and keeps open a connection to one or more Collectors, generally, an "Exporter" is a "client" while a "Collector" is a "server". Client: The endpoint that initiates a QUIC connection, the Exporter or Exporting Process. Server: The endpoint that accepts a QUIC connection, the Collector or Collecting Process.

QUIC connection establishment is described in . During connection establishment, IPFIX over QUIC (IPFIXoQUIC) support is indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token, as registered in Section 7, during the TLS handshake. The Exporter MUST act as the client and the Collector MUST act as the server. If the QUIC connection is not yet established, the Exporter MUST be the initiator of the QUIC connection to the Collector while the Collector acts as the connection acceptor. The Exporter MAY support more than one active connection to different Collectors. The Exporter MAY also support more than one active connection to the same Collector. If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, the Exporting Process MUST retry connection establishment. The Exporting Process MAY record an alarm if the underlying QUIC connection establishment times out; this timeout SHOULD be configurable on the Exporter. When an Exporting Process detects the abnormal interruption of the QUIC connection to the Collecting Process, it SHOULD also try to re-establish the connection. Retry schedules SHOULD be configurable. To ensure network stability and mitigate denial-of-service attacks, an Exporting Process MUST NOT, by default, attempt to establish a new QUIC connection to the same Collecting Process more frequently than once per minute (60 seconds). IPFIX Exporting Processes MUST NOT be configured to establish QUIC connections to an anycast IP address. The stateful nature of QUIC is fundamentally incompatible with the stateless, per-packet routing decisions of anycast, which will prevent connection establishment. To deploy a Collecting Process using an anycast address, the UDP transport protocol MUST be used. If QUIC's features are required, implementers MUST use a unicast architecture with stateful load balancers instead of anycast.

The QUIC protocol uses TLS 1.3 messages to secure the transport, and TLS 1.3 supports Early Data (also known as 0-RTT data) . Early Data is a mechanism defined in TLS 1.3 that enables a client to transmit data during the initial handshake when resuming a previous session. Note that TLS 1.3 can be used without Early Data as per Appendix F.5 of . This functionality is only available when the client and server share a Pre-Shared Key (PSK), obtained either externally or through a prior handshake. As detailed in Section 2.3 of , Early Data provides weaker security than standard TLS, lacking forward secrecy and replay attack protection while requiring pre-established PSK credentials. For IPFIXoQUIC, these security limitations present significant concerns: Flow Records frequently contain sensitive operational data that could be exploited if modified or replayed. Duplicate Flow Records reporting could corrupt traffic analysis and monitoring systems. The stateful nature of flow collection (which relies on past data to interpret new traffic) amplifies its vulnerability to replay-based manipulation. The marginal latency improvements offered by 0-RTT provide insufficient justification for accepting these risks in monitoring applications. In accordance with Appendix F.5 of , which mandates explicit profiling for Early Data usage, this document specifies that IPFIXoQUIC implementations MUST NOT utilize Early Data (0-RTT). Clients MUST NOT include early_data extensions in ClientHello messages, and servers MUST reject such extensions if presented. Implementations MUST configure their TLS 1.3 stacks to disable 0-RTT functionality.

The typical QUIC connection termination process is described in .

When an IPFIX Transport Session is implemented based on a QUIC connection, the idle timeout SHOULD be disabled or the QUIC max_idle_timeout SHOULD be set appropriately in order to keep the QUIC connection persistent even if the IPFIX session is idle. Idle expiry of the QUIC connection ends the IPFIX Transport Session with the state consequences defined in . When an Exporting Process is shut down, it MUST shut down the corresponding QUIC connection. When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process has closed its end. When detecting abnormal termination of a QUIC connection established with the Exporting Process, the Collecting Process MUST retain its ability to accept new incoming QUIC connections.

QUIC uses multiple simultaneous streams to carry data in one direction. QUIC Streams provide a lightweight, ordered byte- stream abstraction to an application. Streams can be unidirectional or bidirectional, and streams can be initiated by either the client or the server. Unidirectional streams carry data in one direction: from the initiator of the stream to its peer. Bidirectional streams allow for data to be sent in both directions. QUIC uses Stream ID to identify the stream. The least significant bit (0x1) of the stream ID identifies the initiator of the stream (client with the bit set to 0). The second least significant bit (0x2) of the stream ID distinguishes between bidirectional streams (with the bit set to 0) and unidirectional streams .

According to the architecture for the export of measured IP flow information defined in , IPFIX Data Records and Templates are carried via a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. Therefore, the IPFIX connection is unidirectional from Exporter to Collector. The Exporter MUST act as the QUIC client and the Collector MUST act as the QUIC server. IPFIX Messages MUST be carried on one or more client-initiated unidirectional QUIC streams. Such Stream IDs have low-order type bits 0x2 (see Section 2.1 of ). This specification does not assign a fixed Stream ID.

defines the baseline: IPFIX Messages MUST be carried on one or more client-initiated unidirectional QUIC streams within a single connection. The state where exactly one such stream carries all IPFIX Messages is referred to as single-stream mode. A state where IPFIX Messages are distributed across multiple such streams is referred to as multi-stream mode. To improve management scalability for Exporters and Collectors, an Exporting Process MAY create more than one QUIC stream per connection. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, and the corresponding Template Sets and Options Template Sets. When partitioning is based on the transport-layer protocol, IPFIX Messages of each protocol are transmitted through a separate QUIC stream. When partitioning is based on ranges of source or destination addresses, IPFIX Messages with a specified source or destination IP address range are transmitted through a QUIC stream. The size of the IP address range SHOULD be determined by the configuration. specifies a method of exporting a Template Record and its associated Data Sets in a single SCTP stream. For IPFIXoQUIC, the following same-stream rules apply. In through , rules for Template Records and Template Withdrawals also apply to Options Template Records and Options Template Withdrawals, respectively. Within one Transport Session and Observation Domain, when an Exporting Process first sends a Template Record for a Template ID, it MUST assign that Template ID to exactly one client-initiated unidirectional QUIC stream. The Template Record, every Data Set that depends on it, and its Template Withdrawal MUST use the assigned stream. The Template ID remains bound to that stream for the remainder of the Transport Session. Cross-stream Template dependencies and cross-stream Template ID rebinding are not permitted by this specification. Template lifecycle operations, including Template creation, retransmission, redefinition, withdrawal, and reuse of Template IDs, continue to follow the rules of , but MUST occur on the assigned stream. A Template Withdrawal that withdraws multiple Template IDs, including an All Templates Withdrawal or All Options Templates Withdrawal, MUST be sent only when every affected Template ID is assigned to the stream carrying the withdrawal. Furthermore, IPFIX Messages sharing common characteristics (e.g., matching a specific Template or flow characteristics) MAY be mapped to a dedicated QUIC stream. This allows the Collecting Process to receive and process messages by type directly from their assigned streams, simplifying its logic. If the number of distinct streams required exceeds the maximum stream limit of a single QUIC connection, the Exporting Process MUST establish a new connection.

The following normative mapping between QUIC constructs and IPFIX constructs applies to IPFIXoQUIC: One QUIC connection on which the IPFIXoQUIC Application-Layer Protocol Negotiation (ALPN) token is selected is one IPFIX Transport Session as defined in . Connection migration and Connection ID rotation (see Section 9.5 of ) preserve the Transport Session. Every newly established QUIC connection, including a resumed or backup connection, is a new Transport Session and MUST NOT inherit Template state from an earlier connection. An Exporting Process connecting to a Collecting Process over a new connection MUST transmit the required Template Records and Options Template Records before dependent Data Records on that connection. Each client-initiated unidirectional QUIC stream is a distinct IPFIX stream for Sequence Number processing. The Exporting Process MUST maintain a separate Sequence Number counter for each (Transport Session, QUIC Stream ID, Observation Domain ID) tuple. The Collecting Process MUST track separate Sequence Number state for the same tuple. A newly opened stream, including a replacement stream, has independent Sequence Number state and MUST NOT continue the counter of a terminated stream. Because QUIC provides ordering only within a single stream, a Collecting Process MUST NOT expect cross-stream Data Record ordering from the transport. Template IDs are scoped to the QUIC connection (i.e., the IPFIX Transport Session) and the Observation Domain, as required by . They are not independently namespaced per stream. The same-stream rules in bind each (Transport Session, Observation Domain ID, Template ID) tuple to exactly one QUIC stream for the remainder of the Transport Session. When a QUIC stream terminates in any way (see ), Template state for that stream is affected as defined in .

QUIC uses FIN for normal completion of the sending part of a stream and RESET_STREAM for abrupt termination. STOP_SENDING requests that the sender reset the stream; it does not itself terminate the stream or establish which data was delivered. QUIC also defines connection termination through idle expiry, stateless reset, and CONNECTION_CLOSE (see Sections 3, 10, and 20 of ). This section defines the state consequences for IPFIXoQUIC. The Exporting Process MUST send FIN only at an IPFIX Message boundary. When the Collecting Process receives all stream data and FIN, it MUST verify that the final stream offset is at an IPFIX Message boundary. If the final stream offset is not at such a boundary, the Collecting Process MUST discard the incomplete trailing IPFIX Message; preceding otherwise-valid complete IPFIX Messages are unaffected by the FIN. Template state established by accepted complete IPFIX Messages on that stream remains valid for the Transport Session per . FIN does not by itself withdraw any Template. Receipt of STOP_SENDING by the Exporting Process does not by itself change IPFIX state. If the Exporting Process sends RESET_STREAM in response, the RESET_STREAM rules below apply. When QUIC reports RESET_STREAM to the receiving application, the Collecting Process MUST discard any incomplete trailing IPFIX Message. It MUST NOT invalidate an otherwise-valid complete IPFIX Message accepted before the reset indication solely because the stream was reset. A reset does not tell the Exporting Process which complete IPFIX Messages the Collecting Process accepted. This specification defines neither application-level acknowledgment nor duplicate suppression for Data Records. Therefore, the Exporting Process MUST NOT retransmit on another stream any Data Record that it submitted to QUIC on the reset stream. This restriction does not affect QUIC transport-layer retransmission on the original stream. A Template ID assigned to the reset stream MUST NOT be rebound to a replacement stream. To continue export that depended on the affected Template, the Exporting Process MUST use a Template ID that has not previously been assigned in the same Transport Session and Observation Domain. It MUST send the defining Template Record on the replacement stream before it sends dependent Data Records. The replacement stream has independent Sequence Number state as specified in . When a QUIC connection is terminated in any way, including by CONNECTION_CLOSE, idle expiry, or a stateless reset, the IPFIX Transport Session ends. The Collecting Process MUST consider all Template state received on that Transport Session as ended in accordance with the Template lifetime rules of . Any subsequent connection to the same Collecting Process is a new Transport Session as defined in , and the Exporting Process MUST again transmit the required Template Records and Options Template Records before dependent Data Records. Under the same-stream rules in , the receipt of a FIN on a stream that carries Templates implies that no further Template Records or withdrawals for the Template IDs bound to that stream will be sent on that stream. A Collecting Process MAY act on this signal for local resource management; Template expiry still follows and connection end per .

IPFIXoQUIC uses QUIC, which uses TLS 1.3 or greater as specified in . Consistent with the mutual authentication requirement of Section 11.3 of , both endpoints MUST authenticate and authorize their peer before any IPFIX Message is sent, accepted, or processed. The Collecting Process MUST NOT accept IPFIX Messages from an unverified Exporting Process, and the Exporting Process MUST NOT export IPFIX Messages to an unverified Collecting Process. The authenticated peer identity is bound to the QUIC connection and thereby to the IPFIX Transport Session as mapped in . TLS server authentication is provided by QUIC by default, and the Exporting Process MUST verify the identity of the Collecting Process. Because the Exporter acts as the QUIC client, client authentication is application-profile behavior: the Collecting Process MUST authenticate the Exporting Process using a TLS client certificate requested and validated during the initial TLS handshake. Post-handshake client authentication MUST NOT be used, as prohibited by Section 4.4 of . Any alternative application-layer authentication mechanism would need to be explicitly specified and MUST complete before any IPFIX Message is accepted. When certificate-based authentication is used, both endpoints MUST verify the reference identifiers of their peer against those stored in the peer's certificate, following the mutual authentication and reference-identifier verification rules of Section 11.3 of . A TLS client certificate is native TLS peer authentication of the Exporting Process, not a separate third-party authentication mechanism.

The decision to use IPFIXoQUIC instead of the SCTP-based/TCP-based/ UDP-based mechanism in is an operational decision, and an implementation MUST provide a configuration mechanism to enable IPFIXoQUIC as an optional transmission protocol on the IPFIX session. A configuration mechanism SHOULD be implemented to enable selection between single-stream or multi-stream QUIC transmission for IPFIX Messages. For multi-stream QUIC transmission, the characteristics of IPFIX Messages exported in a single stream (e.g., by Template type) SHOULD be determined by configuration. Some connectivity problems (such as blocking UDP) could result in repeated persistent failures to establish a QUIC connection. When this happens, the Exporter SHOULD be configurable to attempt to establish an IPFIX session via other transport protocols besides QUIC, such as IPFIX over UDP , for maintaining data export continuity.

QUIC controls the rate at which data can be sent from the Exporting Process to the Collecting Process, using a mechanism that considers both network congestion and the receiver's capabilities. Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate the Metering Process generates them, either due to network congestion or because the Collecting Process cannot process IPFIX Messages quickly enough. As long as congestion is transient, the Exporting Process can buffer IPFIX Messages for transmission. However, buffering is inherently limited due to both resource constraints and timeliness requirements, so persistent and/or severe congestion may lead to a situation where the Exporting Process is blocked. Such a situation MUST generate an alert. When an Exporting Process has Data Records to send but the transmission buffer is full and wants to avoid blocking, it can choose to drop some Data Records. Dropped Data Records MUST be accounted for, so that lost record counts can later be reported as described in Section 4.3 of . Data Records dropped in this way are permanently lost; the Exporting Process SHOULD NOT delete Data Records solely to avoid blocking when doing so would silently degrade the fidelity of the exported dataset. Persistent unacceptably high drop rates indicate that the export path is undersized or the Collecting Process is under-provisioned; this condition is covered by the alert requirement above, and operators SHOULD resolve it by capacity planning, aggregation, or sampling at the Metering Process rather than by degrading transport reliability. Reverting to raw UDP SHOULD only be considered when absolutely necessary, but this will completely forfeit all QUIC functionality.

QUIC ensures reliable delivery of data from the Exporting Process to the Collecting Process.

QUIC uses path MTU discovery to determine the maximum packet size suitable for transmission of IPFIX Messages, aiming to ensure that packets can be delivered to the destination by all nodes in the network path without fragmentation.

The Exporting Process MAY open a backup QUIC connection to a Collecting Process in advance, if it supports Collecting Process failover.

QUIC uses connection IDs instead of network-layer addresses and ports to route packets to the correct endpoint. This enables connection migration, allowing data transmission to continue without re-establishment when the network path changes. A QUIC connection can use multiple Connection IDs, which can be retired and replaced during the connection, zero-length Connection IDs are permitted, and each endpoint selects the Connection IDs its peer uses to address it (see Section 5.1 of ). Connection IDs are connection-routing tokens, not stable authenticated application principals. Consequently, the source IP address of IPFIX exported packets MAY change during an active session, and neither the source IP address nor the QUIC Connection ID is a stable device identity. Collectors MUST NOT use the source IP address or the QUIC Connection ID as an Exporter or device identity. Instead, the Collecting Process MUST bind each QUIC connection to the authenticated peer identity established per ; changes of Connection ID, including those during connection migration, MUST NOT change that binding. If cross-connection device correlation is required, the Collecting Process MUST derive that correlation from the authenticated Exporting Process identity established for each connection under and from configured local policy.

This document creates a new registration for the identification of IPFIXoQUIC in the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in . The "IPFIXoQ" string identifies IPFIXoQUIC: Protocol: IPFIXoQUIC Identification Sequence: 0x49 0x50 0x46 0x49 0x58 0x6f 0x51 ("IPFIXoQ") Specification: This document In addition, this document requests a new assignment in the "Service Name and Transport Protocol Port Number Registry" (see Section 8.1.1 of ), as follows: Service Name: IPFIXoQUIC Transport Protocol: UDP Port Number: TBD Description: IPFIX Protocol over QUIC (IPFIXoQUIC). The assigned port is the default listening port of the Collecting Process for QUIC connections on which the IPFIXoQUIC ALPN token ("IPFIXoQ") is selected. Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Reference: RFC AAAA

This document replaces the transport protocol layer of IPFIX from other transport protocols to QUIC. The basic protocol specification of IPFIX is not modified, and therefore no new security risks are introduced to the basic IPFIX protocol. The security considerations of are applicable to this document. IPFIXoQUIC enhances transport-layer security for IPFIX sessions according to . In accordance with the mutual authentication requirement of Section 11.3 of and the endpoint authentication requirements of , both endpoints MUST authenticate their peer before any IPFIX Message is sent, accepted, or processed. The Exporting Process is authenticated with a TLS client certificate during the initial TLS handshake; post-handshake client authentication MUST NOT be used, as prohibited by Section 4.4 of . Replay attack protection: IPFIXoQUIC implementations MUST NOT use Early Data (0-RTT), as required in . As analyzed there, Early Data lacks replay attack protection, and replayed Early Data could inject duplicate Flow Records and corrupt traffic analysis and monitoring systems. Prohibiting Early Data removes this attack vector: all IPFIX Messages are carried in TLS 1.3 application data protected with fresh keys derived from a completed handshake, and servers MUST reject early_data extensions as specified in . Denial-of-Service (DoS) considerations: QUIC connection establishment and IPFIXoQUIC operation can be targeted by DoS attacks in several ways, and mitigations are specified elsewhere in this document. To mitigate amplification and connection-establishment floods, QUIC incorporates address validation and anti-amplification measures (see Sections 8 and 21 of ); the reconnection rate limit for Exporting Processes (no more than once per 60 seconds by default, see ) bounds the load an exporting device places on a Collecting Process. Regarding connection migration, an attacker could attempt to trigger spurious migrations (e.g., by spoofing source addresses); QUIC path validation (see Section 8.2 of ) prevents data from being sent on an unvalidated path, and per , Collectors MUST NOT treat source IP addresses or Connection IDs as device identity and MUST bind connections to the authenticated peer identity, so migration cannot change the identity binding of an IPFIX Transport Session. Supporting IPFIXoQUIC fallback to UDP introduces the risk of protocol degradation attacks: attackers can force a connection degradation by interfering with QUIC, causing subsequent traffic to be transmitted in unencrypted UDP, making it vulnerable to eavesdropping and tampering. To mitigate this risk, it is RECOMMENDED to enable DTLS to ensure data integrity after the fallback. All degradation events MUST be monitored, and frequent fallbacks SHOULD be considered a security alert.

The authors would like to thank Paul Aitken for their valuable review and comments.