IPFIX Protocol over QUIC

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. specifies a protocol called IP Flow Information Export (IPFIX) Protocol, and describes how the IPFIX Data and Template Records of IPFIX Protocol are carried over a few of transport protocols from an Exporter to a Collector. The IPFIX Protocol Specification has been designed to be transport protocol independent, and allows a mapping to define how it could be implemented over any specific transport protocol. In other words, the Exporter can export to multiple Collectors using independent transport protocols. At present, some transport protocols are defined to carry IPFIX Protocol: SCTP transport , UDP transport , TCP transport . As the network continues to expand, the data traffic it carries is increasing, placing a significant load challenge on the IPFIX transport protocol. To prevent potential security threats (such as DoS attacks), it is highly desirable that it must ensure the confidentiality and integrity of IPFIX data transferred from an Exporting Process to a Collecting Process. 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, therefore is also an appropriate transport protocol for IPFIX Protocol. QUIC is UDP- based multiplexed and secure transport protocol that provides connection-oriented and stateful interaction between a client and server. It can provide low latency and encrypted transport with resilient connections. 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 limit 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 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. QUIC's 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 has strong penetration and is less likely to be intercepted by enterprise firewalls/NAT than TCP and SCTP. Therefore, QUIC is a proper secure and reliable transport protocol for the message transmission mechanism of IPFIX Protocol. This document specifies how to use QUIC as the transport protocol for 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. 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" meanwhile 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 establishing connection, IPFIXoQUIC support is indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token as listed in the IANA Section 7 in the TLS handshake. The Exporter MUST also act as the client meanwhile the Collector must also act as the server. The Exporter should be the initiator of the QUIC connection to the Collector meanwhile the Collector acts as a connection acceptor. The Exporter MAY support more than one active connection to different Collector. The Exporter MAY also support more than one active connection to the same Collector to avoid head-of-line blocking across Observation Domains. The Exporter MAY record an alarm if the underlying QUIC connection establishment time out; this timeout should be configurable on the Exporter. If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, QUIC will automatically retry connection establishment using exponential backoff. The Exporting Process MAY open a backup QUIC connection to a Collecting Process in advance, if it supports Collecting Process failover.

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 flow records 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 replayed. Duplicate flow reporting could corrupt traffic analysis and monitoring systems. The stateful nature of flow collection amplifies 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 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. When an Exporting Process is shut down, it SHOULD shut down the 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. When an Exporting Process is detecting the abnormal interruption of the QUIC connection to the Collecting Process, it SHOULD try to re- establish the connection. Connection timeouts and retry schedules SHOULD be configurable. The default configuration is that an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute.

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 meanwhile 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 IPFIX Exporting Process to IPFIX Collecting Process. Therefore, the IPFIX connection is unidirectional from Exporter to Collector. Based on the above description, The IPFIX messages are initiated by the Exporter and no reply is needed from the Collector. So the IPFIX messages MAY be mapped into one unidirectional stream whose stream type is 0x3 according to section 2.1 of .

For achieving much better Transmission efficiency and performance for Exporter and Collector, 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, Template Sets, and/or Options Template Sets. IPFIX messages can be differentiated by various characteristics, such as five-tuple information (Source IP address, source port, destination IP address, destination port, and transport layer protocol), only transport layer protocol (UDP and TCP), ranges of source or destination IP addresses, and method per Template, and carried over different QUIC streams accordingly. For five-tuple information, each five-tuple's IPFIX messages are transmitted through a QUIC stream. If there are many five-tuples, a large number of QUIC streams must be created, so this approach should be used with caution. For only transport layer protocol, IPFIX messages of each protocol are transmitted through a QUIC stream. For ranges of source or destination addresses, IPFIX messages with specified source or destination IP address segment are transmitted through a QUIC stream. The size of the IP address range can be determined by the configuration. For the method for exporting a Template Record and its associated Data Sets in a single SCTP stream (as specified in ), both each Template and its corresponding Data Records can also be exported within a single QUIC stream. Moreover, if the specified feature's IPFIX message is binding to a QUIC stream ID, meaning that the IPFIX message with fixed features is only transmitted through a QUIC stream of fixed ID, the collector will only receive the specified feature's IPFIX message from the designated stream ID. This may simplify the implementation of the collector. According to one of the features, the number of streams created may exceed the limit of a QUIC connection, in which case a new QUIC connection needs to be created.

IPFIXoQUIC uses QUIC which uses TLS version 1.3 or greater. Therefore, the TLS handshake process can be used for IPFIXoQUIC endpoint authentication. A third-party authentication mechanism can also be applied for IPFIXoQUIC endpoint authentication, such as a TLS client certificate.

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 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 should be determined by configuration. Some connectivity problems (such as blocking UDP) could result in a failure to establish a QUIC connection. When this happens, the Exporter SHOULD attempt to establish an IPFIX session via other transport protocols.

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

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.

If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, QUIC will automatically retry connection establishment using exponential back off. The Exporter MAY log an alarm if the underlying QUIC connection establishment times out; this timeout should be configurable on the Exporter. The Exporting Process MAY open a backup QUIC connection to a Collecting Process in advance, if it supports Collecting Process failover. QUIC identifies connections using connection IDs instead of relying on the IP address and port at the network layer. This allows QUIC to continue data transmission without reconstructing the connection when the network path changes.

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, it is requested for IANA to reserve a UDP port TBD for 'IPFIX over QUIC'.

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 the new security risks are not introduced to the basic IPFIX protocol. The security considerations of are applicable to this document. IPFIXoQUIC enhances transport-layer security for IPFIX session according to . This document does not require to support third-party authentication (e.g., backend Authentication) due to the fact that TLS does not specify this way of authentication. If third- party authentication is needed, TLS client certificates are recommended to be used here.