Internet-Draft Export of QUIC Information in IPFIX October 2025
Lin, et al. Expires 19 April 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-lin-opsawg-ipfix-quic-header-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
C. Lin
New H3C Technologies
Y. Liu
China Mobile
Y. Liu
ZTE

Export of QUIC Information in IP Flow Information Export (IPFIX)

Abstract

This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related and unencrypted information, which contained in QUIC Header that traffic is being forwarded along with.

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 19 April 2026.

Table of Contents

1. Introduction

QUIC Packets are carried in UDP datagrams and exchanged for communication of QUIC endpoints [RFC9000]. A QUIC packet normally consists of a QUIC Header and a QUIC Payload.

QUIC Header is divided into Long Header and Short Header. Long Headers are used for packets that are sent prior to the establishment of 1-RTT keys. The Long Header contains an 8-bit Public Flag, a 32-bit QUIC Version, a variable-length Destination Connection ID, a variable-length Source Connection ID and Type-Specific field which has different content based on the Packet type. The Packet types that use the Long Header contain Version Negotiation Packet, Initial Packet, 0-RTT Packet, Handshake Packet and Retry Packet. Once 1-RTT keys are available, a sender switches to sending 1-RTT packets using the Short Header. The Short Header includes an 8-bit Public Flag, a variable-length Destination Connection ID and a Packet Number.

QUIC packets provide varying levels of cryptographic protection depending on their type [RFC9000]. While the entire QUIC Payload MUST be encrypted, only certain fields in the QUIC Header are protected. For details on QUIC's packet protection mechanisms, refer to Section 5 of [RFC9001].

This document specifies several new IPFIX Information Elements (IEs) within the "IPFIX Information Elements" registry [RFC7012] for purposes of getting QUIC related information. These IEs are used to export the unencrypted parameters of QUIC Header in QUIC packet.

2. Terminology

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.

This document makes use of the terms defined in [RFC7011] and [RFC9000].

The following terms are used as defined in [RFC7011]:

The following terms are used as defined in [RFC9000]:

3. New IPFIX QUIC Information Elements

This section specifies the new IPFIX QUIC IEs.

quicHeaderFlag
8-bit flag defined in the QUIC Header (Section 17.2 and 17.3 of [RFC9000]), as the first byte of QUIC Packet. Base on the first four bits of the Long Header flag and the first three bits of the Short Header flag, the QUIC Packet Type can be obtained.
quicVersion
32-bit QUIC Version that is in use or negotiation in QUIC Long Header Packets during connection establishment. For Version Negotiation Packet, This Version is used to indicate the Supported Version, because the Version field of a Version Negotiation Packet MUST be set to 0x00000000.
quicDestinationConnectionID
The Destination Connection ID included in the Long Header or Short Header of QUIC Packet. The Destination Connection ID is chosen by the recipient of the packet and is used to provide consistent routing. Since the length of the Destination Connection ID is not included in 1-RTT Packet (Short Header), the Destination Connection ID of a 1-RTT Packet could be obtained by matching only if when the Destination Connection ID is known and preconfigured on the device.
quicSourceConnectionID
The Source Connection ID included by the Long Header of QUIC Packet. The Source Connection ID is used to set the Destination Connection ID used by the peer during connection establishment.

4. Sample Use Cases

The IPFIX IEs listed in the Section 3, forwardingStatus (89) [RFC7270] and some existing counter information [IANA-IPFIX] provide answers to the following questions (amongst others).

5. Security Considerations

There exists no extra security considerations regarding allocation of these new IPFIX IEs compared to [RFC7012].

6. IANA Considerations

6.1. New IPFIX QUIC Information Elements

This document requests IANA to add new IPFIX QUIC IEs to the "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX].

Table 1 lists the new IPFIX QUIC IEs:

    +============+=============================+===============+
    | Element ID | Name                        | Reference     |
    +============+=============================+===============+
    | TBD1       | quicHeaderFlag              | This document |
    +------------+-----------------------------+---------------+
    | TBD2       | quicVersion                 | This document |
    +------------+-----------------------------+---------------+
    | TBD3       | quicDestinationConnectionID | This document |
    +------------+-----------------------------+---------------+
    | TBD4       | quicSourceConnectionID      | This document |
    +------------+-----------------------------+---------------+

 Table 1: New QUIC IEs in the "IPFIX Information Elements" Registry

6.1.1. quicHeaderFlag

Name:
quicHeaderFlag
ElementID:
TBD1
Description:
The 8-bit flag defined in the QUIC Header (Section 17.2 and 17.3 of [RFC9000]). The meanings of the flag are provided in the first byte of the QUIC Header Packet [RFC9000].
Abstract Data Type:
unsigned8
Data Type Semantics:
flags
Additional Information:
See RFC9000 for the QUIC Header first byte specification.
Reference:
[this document]

6.1.2. quicVersion

Name:
quicVersion
ElementID:
TBD2
Description:
32-bit unsigned integer defining the number of Version, which is in use and negotiation. Its values are provided in the "QUIC Versions" IANA registry.
Abstract Data Type:
unsigned32
Data Type Semantics:
default
Additional Information:
See the assignments in the "QUIC Versions" IANA registry at https://www.iana.org/assignments/quic/quic.xhtml#quic-versions. See also RFC9000 for the QUIC Versions specification.
Reference:
[this document]

6.1.3. quicDestinationConnectionID

Name:
quicDestinationConnectionID
ElementID:
TBD3
Description:
The Destination Connection ID as defined in Section 7.2 of [RFC9000] as a series of octets in IPFIX. In QUIC version 1, this value MUST NOT exceed 20 bytes.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
See Section 7.2 of [RFC9000] for more details about The Destination Connection ID.
Reference:
[this document]

6.1.4. quicSourceConnectionID

Name:
quicSourceConnectionID
ElementID:
TBD4
Description:
The Source Connection ID as defined in Section 7.2 of [RFC9000] as a series of octets in IPFIX. In QUIC version 1, this value MUST NOT exceed 20 bytes.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
See Section 7.2 of [RFC9000] for more details about The Source Connection ID.
Reference:
[this document]

7. Operational Considerations

The quicDestinationConnectionID can be used to track flow path consistency, but the Destination Connection ID in the Short Header Packet lacks a length indication, making it difficult to match on intermediate devices. Therefore, the Destination Connection ID or its length must be preconfigured on the intermediate devices.

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[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, , <https://www.rfc-editor.org/info/rfc7011>.
[RFC7012]
Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, , <https://www.rfc-editor.org/info/rfc7012>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/info/rfc9000>.
[RFC9001]
Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, , <https://www.rfc-editor.org/info/rfc9001>.

8.2. Informative References

[IANA-IPFIX]
"IANA, "IP Flow Information Export (IPFIX) Entities"", <https://www.iana.org/assignments/ipfix/ipfix.xhtml>.
[RFC7270]
Yourtchenko, A., Aitken, P., and B. Claise, "Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)", RFC 7270, DOI 10.17487/RFC7270, , <https://www.rfc-editor.org/info/rfc7270>.

Authors' Addresses

Changwang Lin
New H3C Technologies
8 Yongjia North Road
Beijing
Haidian District, 100094
China
Yisong Liu
China Mobile
32 Xuanwumen West Street
Beijing
Xicheng District, 100053
China
Yao Liu
ZTE
Nanjing
China