New H3C Technologies

8 Yongjia North Road Beijing Haidian District 100094 China linchangwang.04414@h3c.com

China Mobile

32 Xuanwumen West Street Beijing Xicheng District 100053 China liuyisong@chinamobile.com

ZTE

Nanjing China liu.yao71@zte.com.cn

China Telecom

Beiqijia Town, Changping District Beijing Beijing 102209 China lixt2@foxmail.com

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

QUIC Packets are carried in UDP datagrams and exchanged for communication of QUIC endpoints . 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 payload MAY contain a sequence of Frames which begin with a Frame Type. In the generic Frame Layout, the Frame Type is followed by additional type-dependent fields. Since Stream in QUIC is the one core component to provide a lightweight, ordered byte-stream abstraction to an application, the Stream ID of Frames related to Stream is an important information that indicates the stream in which the Frame is located or that the Frame affects. QUIC packets provide varying levels of cryptographic protection depending on their type . While the entire QUIC payload MUST be encrypted, certain fields in the QUIC Header are not protected, as described in the Section 2.1 of . For details on QUIC's packet protection mechanisms, refer to Section 5 of . The protected fields of QUIC packets can only be accessed after successful decryption. This document specifies several new IPFIX Information Elements (IEs) within the "IPFIX Information Elements" registry for purposes of getting QUIC related information. These IEs are used to export the main fields of QUIC Header and Payload in QUIC packet. The protected values of some new IEs are accessible exclusively to devices capable of decrypting QUIC packets, specifically, the endpoints of a QUIC connection.

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 and . The following terms are used as defined in : IPFIX IPFIX Information Elements The following terms are used as defined in : QUIC Endpoint Server QUIC packet Connection ID Frame Stream The term "flow" in this document aligns with the IPFIX definition, not the QUIC definition.

This section specifies the new IPFIX QUIC IEs. 8-bit flag defined in the QUIC Header (Section 17.2 and 17.3 of ), 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. the last four bits of the Long Header flag and last five bits of the Short Header flag are protected or encrypted, and the remaining bits are not protected. 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. The version field is not protected in QUIC packet. The unprotected 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. The unprotected 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. The protected Packet Number that appears in some QUIC packet types such as Initial packet, 0-RTT packet and Handshake packet. The underlying packet number increases with each packet sent in a given packet number space. The Packet Number is an integer in the range 0 to 262-1. When present in a Long or Short Header, packet numbers are reduced and encoded in 1 to 4 bytes. The protected Frame Type that indicates the type of Frame contained in the Payload of QUIC Packet. The Frame Type value uses a variable-length integer encoding which means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values, respectively. Some Frame Types are defined in section 12.4 of . The protected Stream ID included in the Frame related to Stream such as RESET_STREAM frame, STOP_SENDING frame, STREAM frame and MAX_STREAM_DATA frame. A stream ID is a 62-bit integer (0 to 262-1) that is unique for all streams on a connection. Stream IDs are encoded as variable-length integers, which means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values, respectively. The two least significant bits from a stream ID identify the stream types defined in section 2.1 of .

The IPFIX IEs listed in the Section 3, forwardingStatus (89) and some existing counter information provide answers to the following questions (amongst others). How many packets are forwarded or dropped using QUIC in a network? If dropped, for which reasons? These monitoring requirements align with the broader discard monitoring framework and its associated IPFIX IEs , which provide standardized approaches for classifying and reporting packet discard events. What is the type of QUIC packet? What is the QUIC version that is in use or negotiation? What is the Destination or Source Connection ID of QUIC packet? Have all the QUIC packets been fully received? Which frames does the QUIC packet carry? Which stream is the QUIC packet located in? For QUIC Long Header Packets observed in the network, the Information Elements of following parameters can be exported in IPFIX Flow Records to provide QUIC-layer identification: Five-tuple (protocol, source and destination IP address, source and destination port) Source Connection ID. Destination Connection ID. Example: When a QUIC Long Header Packet is observed within an IPFIX Flow, the corresponding Flow Record MAY include the following identifying parameters: Five-tuple + Source Connection ID + Destination Connection ID + Header Flag For QUIC Short Header Packets observed in the network, the Information Elements of following parameters can be exported in IPFIX Flow Records to provide QUIC-layer identification: Five-tuple (protocol, source and destination IP address, source and destination port) Destination Connection ID. Example: When a specific QUIC frame type is observed within an IPFIX Flow, the corresponding Flow Record MAY include: Five-tuple + Destination Connection ID + Frame Type Similarly, when Stream ID information is available from observed frames, the corresponding Flow Record MAY include: Five-tuple + Destination Connection ID + Stream ID

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

This document requests IANA to add new IPFIX QUIC IEs to the "IPFIX Information Elements" registry available at . Table 1 lists the new IPFIX QUIC IEs:

Name:

quicHeaderFlag

ElementID:

TBD1

Description:

The 8-bit flag defined in the QUIC Header (Section 17.2 and 17.3 of ). The meanings of the flag are provided in the first byte of the QUIC Header Packet .

Abstract Data Type:

unsigned8

Data Type Semantics:

flags

Additional Information:

See RFC9000 for the QUIC Header first byte specification.

Reference:

[this document]

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]

Name:

quicDestinationConnectionID

ElementID:

TBD3

Description:

The Destination Connection ID as defined in Section 7.2 of 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 for more details about The Destination Connection ID.

Reference:

[this document]

Name:

quicSourceConnectionID

ElementID:

TBD4

Description:

The Source Connection ID as defined in Section 7.2 of 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 for more details about The Source Connection ID.

Reference:

[this document]

Name:

quicPacketNumber

ElementID:

TBD5

Description:

8~32-bit unsigned integer defining the packet number of QUIC Header, which is used in determining the cryptographic nonce for packet protection.

Abstract Data Type:

unsigned32

Data Type Semantics:

default

Additional Information:

See Section 12.3 of for more details about The Packet Number.

Reference:

[this document]

Name:

quicFrameType

ElementID:

TBD6

Description:

62-bit unsigned integer defining the value of Frame Type, which indicates the type of QUIC Frame. Its values are provided in the "QUIC Frame Types" IANA registry.

Abstract Data Type:

unsigned64

Data Type Semantics:

default

Additional Information:

See the assignments in the "QUIC FrameTypes" IANA registry at https://www.iana.org/assignments/quic/quic.xhtml#quic-frame-types. See also RFC9000 for the Frame Types specification of QUIC.

Reference:

[this document]

Name:

quicStreamID

ElementID:

TBD7

Description:

62-bit unsigned integer defining the value of Stream ID, which identifies a Stream. The two least significant bits from a stream ID identify the stream types defined in section 2.1 of .

Abstract Data Type:

unsigned64

Data Type Semantics:

identifier

Additional Information:

See Section 2.1 of for more details about The Stream ID.

Reference:

[this document]

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. The protected packet fields must be decrypted before they can be obtained. quicHeaderFlag, quicVersion, quicDestinationConnectionID, and quicSourceConnectionID can be obtained in all on-path devices. quicPacketNumber, quicFrameType, and quicStreamID can be obtained in endpoint devices or on-path devices which are capable of decrypting QUIC packets.