OPSAWG Y. Liu, Ed. Internet Draft China Mobile Intended status: Standards Track C. Lin, Ed. Expires: May 28, 2025 New H3C Technologies T. Graf, Ed. Swisscom November 28, 2024 IPFIX Protocol over QUIC draft-llg-opsawg-ipfix-over-quic-00 Abstract The IP Flow Information Export (IPFIX) Protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Data and Template Records can be carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. The supported transport protocols are SCTP, UDP and TCP. QUIC could provide useful, reliable and secure semantics for IPFIX Protocol in particular as a single connection could carry multiple traffic flows over streams, enabling much better efficiency and performance for Exporter and Collector. This document describes how to use IPFIX Protocol over the QUIC transport protocol, named IPFIXoQUIC. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 28, 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. llg, et al. Expire May 28, 2025 [Page 1] Internet-Draft IPFIX Protocol over QUIC November 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction...................................................2 2. Terminology and Definitions....................................4 3. Connection Management..........................................4 3.1. Connection Establishment..................................4 3.2. Connection Termination....................................5 3.2.1. QUIC Connection Termination Process..................5 3.2.2. IPFIXoQUIC Considerations for Connection Termination.5 4. Stream Mapping and Usage.......................................5 4.1. Unidirectional Stream from Exporter to Collector..........6 4.2. Multiple Stream Usage.....................................6 5. Endpoint Authentication........................................7 6. Operational Considerations.....................................7 6.1. Congestion Avoidance......................................7 6.2. Reliability...............................................8 6.3. MTU.......................................................8 6.4. Failover..................................................8 7. IANA Considerations............................................8 8. Security Considerations........................................9 9. References.....................................................9 9.1. Normative References......................................9 9.2. Informative References...................................10 Author's Address.................................................11 1. Introduction 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. [RFC7011] 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 llg, et al. Expires May 28, 2025 [Page 2] Internet-Draft IPFIX Protocol over QUIC November 2024 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 [RFC9260], UDP transport [UDP], TCP transport [TCP]. 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 [RFC9000] 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 [RFC7011], 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, with SCTP, UDP, and TCP, such encryption requires additional protocols like DTLS. * 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. llg, et al. Expires May 28, 2025 [Page 3] Internet-Draft IPFIX Protocol over QUIC November 2024 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. 2. Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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. 3. Connection Management 3.1. Connection Establishment QUIC connection establishment is described in [RFC9000]. During establishing connection, IPFIXoQUIC support is indicated by selecting the Application-Layer Protocol Negotiation (ALPN) [RFC7301] 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. llg, et al. Expires May 28, 2025 [Page 4] Internet-Draft IPFIX Protocol over QUIC November 2024 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. 3.2. Connection Termination 3.2.1. QUIC Connection Termination Process The typical QUIC connection termination process is described in [RFC9000]. 3.2.2. IPFIXoQUIC Considerations for Connection Termination 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 a Collecting Process detects that the QUIC connection to the Exporting Process has terminated abnormally, it MUST continue to listen for a new connection. 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. 4. Stream Mapping and Usage QUIC [RFC9000] 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 llg, et al. Expires May 28, 2025 [Page 5] Internet-Draft IPFIX Protocol over QUIC November 2024 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 [RFC9000]. 4.1. Unidirectional Stream from Exporter to Collector According to the architecture for the export of measured IP Flow information defined in [RFC5470], 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 [RFC9000]. 4.2. Multiple Stream Usage 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), and ranges of source or destination IP addresses, 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. llg, et al. Expires May 28, 2025 [Page 6] Internet-Draft IPFIX Protocol over QUIC November 2024 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. 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. 5. Endpoint Authentication 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. 6. Operational Considerations The decision to use IPFIXoQUIC instead of the SCTP-based/TCP- based/UDP-based mechanism in [RFC7011] is an operational decision, and an implementation MUST provide a configuration mechanism to enable IPFIXoQUIC on the IPFIX session. 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. 6.1. Congestion Avoidance 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. llg, et al. Expires May 28, 2025 [Page 7] Internet-Draft IPFIX Protocol over QUIC November 2024 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. The dropped Data Records MUST be accounted for, so that the number of lost records can later be reported as described in Section 4.3 of [RFC7011]. 6.2. Reliability QUIC ensures reliable delivery of data from the Exporting Process to the Collecting Process. 6.3. MTU 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. 6.4. Failover 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. 7. IANA Considerations This document creates a new registration for the identification of IPFIXoQUIC in the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [RFC7301]. The "IPFIXoQ" string identifies IPFIXoQUIC: * Protocol: IPFIXoQUIC * Identification Sequence: 0x49 0x50 0x46 0x49 0x58 0x6f 0x51 ("IPFIXoQ") llg, et al. Expires May 28, 2025 [Page 8] Internet-Draft IPFIX Protocol over QUIC November 2024 * Specification: This document In addition, it is requested for IANA to reserve a UDP port TBD for 'IPFIX over QUIC'. 8. Security Considerations 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 [RFC7011] are applicable to this document. IPFIXoQUIC enhances transport-layer security for IPFIX session according to [RFC9000]. 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. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9260] Stewart, R., Tuxen, M., and K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, June 2022, . llg, et al. Expires May 28, 2025 [Page 9] Internet-Draft IPFIX Protocol over QUIC November 2024 [TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . 9.2. Informative References [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, DOI 10.17487/RFC5470, March 2009, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . llg, et al. Expires May 28, 2025 [Page 10] Internet-Draft IPFIX Protocol over QUIC November 2024 Author's Address Yisong Liu (editor) China Mobile China Email: liuyisong@chinamobile.com Changwang Lin (editor) New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Thomas Graf (editor) Swisscom Binzring 17 CH- Zurich 8045 Switzerland Email: thomas.graf@swisscom.com llg, et al. Expires May 28, 2025 [Page 11]