Export of QUIC Information in IP Flow Information Export (IPFIX)New H3C Technologies8 Yongjia North RoadBeijingHaidian District100094Chinalinchangwang.04414@h3c.comChina Mobile32 Xuanwumen West StreetBeijingXicheng District100053Chinaliuyisong@chinamobile.comZTENanjingChinaliu.yao71@zte.com.cnChina TelecomBeiqijia Town, Changping DistrictBeijingBeijing102209Chinalixt2@foxmail.comCisco SystemsSarjapur Outer Ring RoadBangalore560103KarnatakaIndiaaddogra@cisco.com
Operations and Management
Operations and Management Area Working GroupIPFIXQUIC
This document defines IP Flow Information Export (IPFIX) Information
Elements and export profiles for QUIC packet, header, frame, aggregate, and
connection observations. It distinguishes wire-visible information from
values requiring version-specific parsing, packet-protection processing, or
endpoint state, and reports observation provenance, processing outcome, and
export completeness.
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.
The QUIC header is divided into the Long Header and the Short Header. While some properties (e.g., header form bit)
are version-independent per , the overall structure, especially
the interpretation of packet type bits, is version-specific. The Long
Header contains an 8-bit first octet, a 32-bit QUIC Version,
a variable-length Destination Connection ID, and a variable-length
Source Connection ID. In a Version Negotiation packet, only the Header
Form bit of the first octet has invariant meaning; the other seven bits
are arbitrary. In QUIC versions 1 and 2 packets other than Version
Negotiation, the first octet contains the Header Form bit, Fixed Bit,
packet-type bits, and type-specific bits, and fields following the
Connection IDs vary by packet type, for example the Token in Initial and
Retry packets .
For QUIC versions 1 and 2, Version Negotiation, Initial, 0-RTT,
Handshake, and Retry packets use the Long Header, while 1-RTT packets use
the Short Header. A sender can continue to send Long Header packets while
the corresponding encryption levels remain in use; availability of 1-RTT
keys does not by itself imply that all Long Header traffic has stopped.
The Short Header includes an 8-bit first octet,
a variable-length Destination Connection ID and a Packet Number.
The 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. A Stream provides a lightweight,
ordered byte-stream abstraction to an application. A QUIC connection
can carry many concurrent Streams, so the Stream ID carried by a
Frame is important: it identifies the Stream whose data the Frame
carries (e.g., a STREAM frame), or the Stream that the Frame affects
(e.g., RESET_STREAM, STOP_SENDING, or MAX_STREAM_DATA frame).
QUIC packets provide varying levels of cryptographic protection depending
on their type . Version Negotiation packets have
no cryptographic protection. Retry packets are neither encrypted nor
header-protected, but carry a version-specific Retry Integrity Tag.
Initial packets use packet-protection keys that are publicly derivable from
the Destination Connection ID of the applicable client Initial packet.
Handshake, 0-RTT, and 1-RTT packets use keys derived from TLS. Header fields
that remain visible on the wire can nevertheless be authenticated as AEAD
associated data; this document therefore distinguishes fields that are
encrypted, fields that are masked by header protection, and fields that are
wire-visible.
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 the QUIC header and payload in a QUIC packet.
Some values are normally available only to QUIC endpoints or authorized
devices holding the applicable traffic keys. For supported QUIC versions,
an observer with the required connection context can also derive Initial
keys and process Initial packets; successful Initial processing is not peer
authentication.
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 :
IPFIXIPFIX Information Elements
The following terms are used as defined in :
QUICEndpointServerQUIC packetConnection IDFrameStreamThe term "flow" in this document aligns with the IPFIX definition, not the QUIC definition.
QUIC introduces multiple layers of encapsulation that do not map one-to-one
to traditional IPFIX flow records. A UDP datagram can contain multiple QUIC
packets (via coalescing), a QUIC packet can contain multiple frames, and
frames can belong to different streams. This section defines explicit export
profiles to clarify the observation hierarchy and avoid semantic ambiguity.
The following hierarchy describes the relationship between observed QUIC
entities:
IP Flow: A sequence of IP packets sharing common
properties (e.g., 5-tuple). An IP flow may carry multiple UDP datagrams.
UDP Datagram: A single UDP payload that may contain one
or more QUIC packets (coalesced).
QUIC Packet: A QUIC-layer unit with its own header and
payload. Multiple QUIC packets can be coalesced into one UDP datagram.
Initial, 0-RTT, Handshake, and 1-RTT packets belong to a packet
number space. Version Negotiation and Retry packets do not carry packet
numbers, and a confirmed Stateless Reset has no semantic packet number.
QUIC Frame: A structured protocol element carried in a
QUIC packet payload. A QUIC packet can contain multiple frames of
different types (e.g., STREAM, ACK, CRYPTO).
QUIC Stream: An ordered byte stream multiplexed within a
QUIC connection. Multiple streams can be interleaved via STREAM frames
within a single QUIC packet.
In the unsampled variants, each top-level Data Record defined by the export
profiles in represents exactly one entity
of the hierarchy above: one IP/UDP datagram (Network-Wire Observation
Profile), one QUIC packet (Endpoint Packet Observation Profile), one IP Flow
or aggregation window (Flow-Aggregate Profile), or one QUIC connection
(Connection-State Profile). When PSAMP packet selection is active, the
sampled Network-Wire and Endpoint variants instead emit exactly one
Extended Packet Report for each selected outer IP packet. Ordered child
records within that report preserve the one-record-per-inner-QUIC-packet
semantics and identify each child with quicPacketOffset.
RFC 7012 specifies that a non-key Information Element whose value
varies within a Flow is, by default, taken from the first observed
packet of the Flow (Section 5 of ). For
packet-derived QUIC IEs this default is insufficient, because "the
first observed packet" does not identify which QUIC packet supplies
the value when the datagram carries multiple coalesced QUIC packets,
or which frame occurrence supplies the value when a QUIC packet
contains multiple frames or references multiple streams. This
document therefore defines, per profile, the observation unit of each
Data Record and the explicit ordinal or offset fields that identify
each occurrence: quicPacketOffset (TBD15) locates an inner QUIC
packet within its UDP payload, quicFrameOffset (TBD13) locates a
frame within its packet payload, and sub-templates are ordered by
these offsets. Where a scalar IE with per-observation cardinality
would otherwise be reported at a coarser granularity, the profile
either reports every occurrence (as list entries) or excludes the IE
from that profile; "first observed value" is used only where a
profile explicitly states it (e.g., the Flow-Aggregate Profile).
Existing IPFIX packet counters (for example, packetDeltaCount and
droppedPacketDeltaCount) describe the outer IP/Flow packet layer and cannot
implicitly count coalesced inner QUIC packets. Likewise, forwardingStatus
(89) describes forwarding disposition at that
outer layer. If
counting at the QUIC packet layer is required, exporters MUST use the
dedicated quicPacketDeltaCount Information Element (TBD16, defined in
) rather than
packetDeltaCount. Discard-related monitoring
(e.g., why QUIC-carrying packets are forwarded or dropped) aligns with the
broader discard monitoring framework and its
associated IPFIX IEs .
As noted in Section 3.1 of , there is no general
passive method to distinguish QUIC from arbitrary UDP traffic, and the
QUIC fixed bit is subject to greasing . A UDP
datagram that looks like QUIC may not be QUIC, and an exporter that relies
on a fixed-bit or port heuristic MUST NOT treat that classification as
authoritative.
Observation provenance and processing outcome are independent. Each packet
observation in the Network-Wire and Endpoint Packet profiles therefore
carries both quicObservationSource (TBD17) and quicProcessingStatus
(TBD18). quicObservationSource states whether the values came from passive
wire observation, endpoint protocol state, or an authorized cooperating
device. quicProcessingStatus states what processing was completed or why it
stopped. quicExportFlags (TBD24) independently reports whether otherwise
available information was suppressed by configured export policy or
truncated by a local resource or size limit. The processing result is not
overwritten by an export-completeness condition. The status values are not
an ordered confidence scale. In
particular, endpoint-originated Version Negotiation and Retry observations
do not require decryption, and a passive observer can successfully process
a supported-version Initial packet when it has the required context. The
Flow-Aggregate and Connection-State profiles carry the same two IEs to
identify the particular admission evidence that first caused the exporter
to classify the flow or connection as QUIC.
A Data Record encoded by a Template contains a value for every Field
Specifier in that Template . Consequently, an
exporter cannot omit one field from an individual record while continuing
to use the same Template. A profile in this document handles a field that
is absent or unavailable in one of two ways:
use another announced Template that does not contain the field; or
include quicFieldPresence (TBD21) in the record. When the bit assigned
to an accompanying field is clear, the exporter encodes the canonical
placeholder required by the fixed Template (zero for a numeric field,
an empty value for an octetArray, or an empty list), and the collector
MUST ignore that placeholder. When the bit is set, the encoded value is
semantically present; an empty octetArray can therefore represent a
genuine zero-length QUIC field without being confused with absence.
quicPacketType uses its Unknown value when a type cannot be determined.
Malformed, capture-truncated, unsupported-version, and
authentication-failed observations use distinct quicProcessingStatus values;
local suppression or truncation uses quicExportFlags. An exporter MUST NOT
mark fields derived from an unsuccessful parse
or failed packet-protection operation as present. Successful Initial packet
protection processing under publicly derivable keys indicates that the
packet is internally consistent under those keys; it is not peer
authentication and does not provide integrity against an active on-path
attacker.
Template IDs are dynamically scoped to the (Observation Domain ID,
Exporting Process, Transport Session) tuple in which they were announced.
Collectors MUST NOT infer record content, provenance, or validation result
from a numeric Template ID. These properties are carried in-band by the IEs
defined above and, for Destination Connection ID length context, by
quicDestinationConnectionIdLengthSource (TBD19).
This document defines the following export profiles. Each profile
specifies its Flow Keys, granularity, sampling behavior, observation
time, direction, and unavailable-field behavior, and provides an
illustrative Template field layout and Data Record example. Where more than one
encapsulation layer is reported (inner QUIC packets within a UDP
datagram, frames within a QUIC packet), a subTemplateList
is used so that the hierarchy remains
explicit. Except for fields whose first-observed aggregation is explicitly
defined by the Flow-Aggregate Profile, per-packet scalar values are not
flattened into fields of a record that covers several such objects. The
Template IDs shown in the figures are examples only; actual Template IDs
are dynamically assigned, and collectors MUST NOT infer the content
or provenance of a record from its Template ID (see
). The figures list fields and abstract
data types, not byte-level Template encodings. An exporter MUST encode the
actual Template Field Specifiers as required by .
In the illustrated profiles, octetArray, basicList, and subTemplateList
fields use the variable-length Field Length 65535. A numeric Field Length,
including any reduced-size encoding, MUST accommodate every value sent with
that Template.
Except for the order of elements within an ordered structured-data list,
the order of Information Elements in a Template is not significant.
Exporters MAY add other Information Elements or export records using other
Templates. A collector that supports a profile in this document MUST accept
reordered fields, additional Information Elements, and unrelated Data
Records.
Every ordinary Data Record in these profiles is scoped by the Observation
Domain ID in the IPFIX Message Header. It is not repeated as
observationDomainId (149) in an ordinary Data Template and is not a
packet-derived Flow Key. The Connection-State Options Template uses
observationDomainId as an Options Scope field, as explicitly shown. For
purposes of flowId correlation, the Observation
Domain ID is the Message Header value for an Endpoint Packet record and the
explicit Options Scope value for a Connection-State record.
Every basicList and subTemplateList in these profiles that preserves wire
order MUST use the ordered structured-data semantic defined by
. The field-presence and processing-status IEs are
part of the record contract and are not inferred from the selected Template
ID. quicExportFlags is zero when export is complete under the profile and
carries independent bits when local policy suppresses otherwise available
values or a local resource/size limit truncates export.
This profile is intended for passive on-path observation. It reports
wire-visible fields and packet boundaries; although an exporter can process
supported-version Initial protection when it has the required context, this
profile does not export packet numbers or frame contents.
Export wire-visible QUIC header fields for every QUIC packet that
the exporter can successfully delimit within an observed IP/UDP
datagram, for
network-level traffic analysis, QUIC version and packet-type
distribution, and Connection ID tracking.
One Data Record per IP/UDP datagram. Successfully delimited inner
QUIC packets of a possibly coalesced datagram are reported as an
ordered subTemplateList of inner QUIC-packet observations, each
identified by its quicPacketOffset within the UDP payload. The
parent record carries quicDatagramParseStatus (TBD22), so a collector
can distinguish a complete parse from one that stopped at an
unsupported version, malformed or capture-truncated data, or a local
parser or processing-resource limit. For an unsupported nonzero version,
the invariants in
do not expose the packet boundary after the
Connection IDs. Unless the exporter has additional version-specific
or out-of-band knowledge, it reports any preceding completely delimited
packets and MAY report one terminal invariant-prefix observation at the
offset where parsing stopped. It marks the datagram parse as partial and
MUST NOT claim that later coalesced packets were absent.
A Stateless Reset is identified from the entire UDP datagram, not from
a candidate child-packet suffix. When the exporter confirms a Stateless
Reset as specified in Section 10.3.1 of , the
child list MUST contain exactly one observation: quicPacketOffset is
zero, quicPacketLength is the UDP payload length, quicPacketType is 6,
quicProcessingStatus is 14, and quicDatagramParseStatus is 1 (Complete).
Any tentative parsing of apparent coalesced packets is superseded by
that datagram-level result.
source address, destination address, protocolIdentifier, udpSourcePort,
udpDestinationPort. An IPv4
Template uses sourceIPv4Address and destinationIPv4Address; an IPv6
Template uses sourceIPv6Address and destinationIPv6Address. The two
address-family variants use separately assigned Template IDs. The
Connection IDs are NOT Flow Keys. They are not a stable property
of a connection: the Destination Connection ID that a peer uses
may change with Connection ID rotation or connection migration.
In addition, a passive observer cannot rely on the sender having
honored the coalescing rules, so the inner packets of a single
datagram cannot be assumed to belong to the same connection. The
Connection IDs are therefore reported per inner packet.
One record per observed datagram (1:1). The base parent Template MUST
be used only when packet selection is not active. If packet selection is
active and this profile is emitted, the exporter MUST use a distinct
PSAMP Extended Packet Report Template that adds
selectionSequenceId (301) while retaining the ordered QUIC child-list
structure below. For every selectionSequenceId in use,
the exporter MUST also export the applicable Selection Sequence,
Selector, Selection Sequence Statistics, and Accuracy Report
Interpretations required by Section 6.5 of .
Per Section 6.4 of ,
one Packet Report is exported for each selected packet in each
Selection Sequence; a Packet Report includes selectionSequenceId
and SHOULD include an observation-time Information Element.
This profile's sampled Template applies only to a selected unfragmented
IP packet carrying a complete UDP datagram admitted to the QUIC profile.
If the Selection Sequence can select other protocols or IP fragments,
the exporter MUST use another applicable Packet Report Template for
those selected packets.
selectionSequenceId identifies the Observation Point and the
selector sequence, not an individual packet occurrence: when a
selected packet contains a complete UDP datagram with multiple
coalesced QUIC packets, this profile exports the decoded QUIC
packets as ordered child records within the Extended Packet
Report (each child record carrying its quicPacketOffset), rather
than as separate top-level Data Records. Emitting each inner QUIC packet
as a separate top-level Data Record does not conform to this profile. A
separately specified profile using that model would need an explicitly
scoped parent-observation identifier together with quicPacketOffset;
selectionSequenceId or observationPointId alone cannot identify the
containing datagram because several selected datagrams can share both
values.
This profile MUST be emitted only for a UDP datagram carried in one
unfragmented IP packet. Individual IP fragments and reassembled IP
datagrams are outside this profile because its timestamp and standard
packet/octet counters describe one observed outer IP packet. A separate
reassembly profile would need to define its logical Observation Point,
timestamp, and counter semantics. Fragmentation alone is neither capture
truncation nor malformed input. quicDatagramParseStatus 3 applies only
when missing captured octets prevent complete packet-boundary
enumeration. If a capture-truncated packet still has a known complete
boundary, the parent uses quicDatagramParseStatus 1 and that child uses
quicProcessingStatus 9. quicDatagramParseStatus 4 applies only when a
structural violation prevents complete packet-boundary enumeration. If
a malformed packet still has a known complete boundary, the parent uses
quicDatagramParseStatus 1 and that child uses quicProcessingStatus 8.
observationTimeMilliseconds (323) of the outer IP packet; the inner
observations do not carry separate timestamps.
flowDirection (61) of the outer IP packet.
quicPacketNumber, quicFrameType, and quicStreamId are not carried in
this profile. quicPacketType is set to 0 (Unknown) when the exporter
cannot apply a supported version's packet-type rules. quicVersion is
present only for a Long Header packet; for a Short Header packet its
quicFieldPresence bit is clear and the fixed-field placeholder is zero.
quicSupportedVersion is present only for Version Negotiation and is
encoded as specified in .
The Connection ID and Token presence bits distinguish a genuine
zero-length field from a field that is absent or unavailable. A
successfully delimited packet has its Packet Length bit set unless the
otherwise available value is omitted for an export condition reported
by quicExportFlags. For the partial terminal observation permitted when
an unsupported version prevents boundary determination, that bit is
clear and quicPacketLength is an ignored zero placeholder. Each
inner observation carries quicObservationSource, quicProcessingStatus,
and quicExportFlags. The parent quicExportFlags reports local omission
from the child list; it does not change quicDatagramParseStatus when the
UDP payload was parsed completely. A local parser or processing-resource
limit that prevents complete packet-boundary enumeration instead produces
quicDatagramParseStatus 5. If the Destination Connection ID length of a
Short Header packet cannot be determined, the Destination Connection ID
presence bit is clear and quicDestinationConnectionIdLengthSource is 4
(Unknown). A successfully processed supported-version Initial packet
can use the passive-source and Initial-processed status combination;
this does not authenticate its sender.
A confirmed Stateless Reset has no semantic Version, Destination
Connection ID, Source Connection ID, or Initial/Retry Token field; their
presence bits are clear, their fixed-field placeholders are ignored,
and quicDestinationConnectionIdLengthSource is 0 (Not applicable).
Bytes that merely occupy the apparent Short Header Destination
Connection ID position are unpredictable reset bytes and MUST NOT be
exported as quicDestinationConnectionId.
The two QUIC packet lengths total 1256 octets. With an assumed
8-octet UDP header and a 20-octet IPv4 header without options, the
outer octetDeltaCount is therefore 1284.
This profile is intended for QUIC endpoints, authorized devices that
legitimately possess the relevant traffic keys, and passive observers that
successfully process supported-version Initial packets with the required
context. It exports fields available after successful packet processing or
directly from endpoint protocol state.
Export per-QUIC-packet observations for Initial, 0-RTT, Handshake, and
1-RTT packets, including protected fields
(packet number, frame types, stream IDs), for connection-level
analysis such as packet sequencing and stream behavior. Packet
numbers alone do not provide reliable loss measurement, since
passive observation cannot determine whether all sent packets
were received (see Section 4.1 of ).
Endpoint-derived ACK or loss events and counters MAY be exported
separately, with explicit completeness and sampling semantics;
such export is out of scope for this document.
In the unsampled base variant, one top-level Data Record is emitted per
packet that carries a packet number, with an ordered
subTemplateList of
frame-observation subrecords, one per completely parsed frame carried by
that packet. If an unsupported frame format or local processing limit
stops enumeration, the list contains the completely parsed prefix and
quicProcessingStatus is respectively 12 or 13.
Each frame observation carries its own quicFrameType and,
where the frame type carries one, its quicStreamId. The frame
subrecords are exported in the order the frames appear in the
QUIC packet payload; quicFrameOffset indicates the byte position
of each frame and thereby the frame order.
flowId (148), quicSenderDirection,
quicPacketNumberSpace, and the full quicPacketNumber. The Observation
Domain ID in the IPFIX Message Header additionally scopes the record.
These keys apply to the top-level packet record in the base variant and
to each QUIC-packet child record in the sampled variant.
Version
Negotiation and Retry packets, and a confirmed Stateless Reset, are
outside this profile because they have no semantic packet number. A
packet number
is unique within a (connection, direction, packet number space)
tuple, so it is a natural key at this granularity;
flowId provides the registered correlation identifier for the QUIC
connection observation. For this profile, the exporter assigns one
flowId that is unique within the Observation Domain and keeps it
unchanged for the lifetime of that connection observation, including
across path migration and IPFIX Transport Session changes.
The base Template is 1:1 (one record per eligible QUIC packet) and MUST
be used only when packet selection is not active. PSAMP selects outer
IP packets, not individual coalesced QUIC packets. If packet selection
is active, the exporter MUST use a distinct Extended Packet Report
Template with one parent Data Record for each selected unfragmented
outer IP packet that carries a complete UDP datagram admitted to this
QUIC profile, as required by Section 6.4 of
. The parent carries selectionSequenceId (301),
the outer address and UDP fields, observationTimeMilliseconds,
quicDatagramParseStatus, quicExportFlags, and an ordered
subTemplateList. That list contains one child record for every eligible
packet-number-bearing QUIC packet in the selected UDP datagram, in wire
order. Each child adds quicPacketOffset to the fields of the base
Endpoint Packet Template; the timestamp is inherited from the parent.
A selected qualifying UDP packet with no eligible Endpoint child still
produces its required Packet Report with an empty child list. If the
Selection Sequence can select other protocols or IP fragments, the
exporter MUST satisfy the one-report-per-selected-packet requirement of
Section 6.4 of for those packets using another
applicable Packet Report Template. A fragmented outer
IP packet is outside this sampled variant because one selected fragment
does not represent a complete UDP datagram.
For every selectionSequenceId in use, the exporter MUST export the
applicable Selection Sequence, Selector, Selection Sequence Statistics,
and Accuracy Report Interpretations required by Section 6.5 of
. Selection probabilities and accuracy describe
the outer IP-packet population; they MUST NOT be presented as direct
selection probabilities for inner QUIC packets.
observationTimeMilliseconds (323) per QUIC packet in the base variant;
in the sampled variant, all QUIC-packet children inherit the timestamp
of their enclosing selected outer IP-packet report.
quicSenderDirection (TBD11): 0 = client-to-server, 1 =
server-to-client.
quicPacketNumberSpace and quicPacketNumber are always present because
this profile contains only packet-number-bearing types. The
quicFieldPresence bitmap states whether quicVersion, either Connection
ID, quicToken, quicPacketLength, and a frame's quicStreamId are
semantically present. A
Short Header packet therefore carries a zero placeholder for
quicVersion and an empty placeholder for quicSourceConnectionId, with
both presence bits clear. A frame that does not carry a Stream ID uses a
zero placeholder with the Stream ID presence bit clear; Stream ID zero
on a frame that carries a Stream ID has the bit set. Packet-protection
failure cannot supply the mandatory packet number and therefore MUST
NOT be encoded with this Endpoint Packet Template. It can be reported
with the Network-Wire profile or with a separately announced failure
Template that omits unavailable protected fields and carries
quicProcessingStatus. If plaintext is available but an unsupported frame
type or frame format prevents the exporter from determining the next
frame boundary, the exporter emits only the preceding completely parsed
frame records and sets quicProcessingStatus to 12. A local parser or
processing-resource limit that stops frame enumeration similarly uses
status 13. The exporter MUST NOT classify the packet as malformed solely
because its local decoder does not support that frame or exhausts a local
processing limit. If otherwise available optional fields or frame
child records are suppressed or truncated during export, quicExportFlags
reports that independently of the processing result. In the sampled
variant, the parent quicDatagramParseStatus reports whether the exporter
completely enumerated packet boundaries in the selected UDP datagram,
and the parent quicExportFlags reports local omission from the QUIC-packet
child list. A child status and flags continue to describe only that
child packet and its nested frame list.
The three frame extents total 466 plaintext octets. The example assumes
a 10-octet Short Header (first octet, 8-octet Destination Connection ID,
and 1-octet truncated packet number) and a 16-octet authentication tag,
giving a 492-octet QUIC packet.
This profile is intended for aggregated statistics over a flow
lifetime or a fixed time window, reducing export overhead. It
carries counters, timing, explicitly identified first-observed context,
and the evidence used to classify the flow as QUIC; other per-packet
scalar fields are not exported.
Export aggregated counters and timing with explicit aggregation
semantics, avoiding ambiguity from the default "first observed
value" semantics for non-key properties in
Section 5 of .
source address, destination address, protocolIdentifier, udpSourcePort,
udpDestinationPort. The Observation Domain ID in the IPFIX Message
Header additionally scopes the record. IPv4 and IPv6
use separate Templates with the corresponding address IEs.
This profile is unidirectional. The ordered source/destination 5-tuple
identifies one direction, and flowDirection (61) reports ingress or
egress relative to the Observation Point. An exporter that implements a
true biflow representation instead MUST use the direction-assignment,
reverse-IE, reverse-counter, and biflowDirection conventions of
and a separately defined Template.
The interval is either the full flow lifetime (from the first to
the last observed packet of the flow at the Observation Point) or
a fixed aggregation window configured on the exporter;
flowStartMilliseconds (152) and flowEndMilliseconds (153) report the
first and last observed packet times within the exported interval, per
their registered definitions. If the interval is a fixed window, a flow
spanning several windows yields one record per window, but
flowEndMilliseconds remains the time of the last observed packet in that
window. A configured window-closing time, if exported, uses a separate
IE defined for that purpose and MUST NOT be substituted for
flowEndMilliseconds. Every record includes flowEndReason (136). A fixed
window that closes while the Flow continues uses value 2 (active
timeout); a full-lifetime record uses the actual registered end reason.
The base Template is used only when packet selection is not active. If
selection is active at the Observation Point, the exporter MUST use a
distinct sampled Template that adds selectionSequenceId (301) to the
record and to the sampled variant's Flow Key. It MUST create a separate
aggregate for each Selection Sequence and MUST NOT combine packets from
different selectionSequenceId values. For every selectionSequenceId in
use, the exporter MUST export the applicable Selection Sequence,
Selector, Selection Sequence Statistics, and Accuracy Report
Interpretations required by Section 6.5 of .
This aggregate record supplements and MUST NOT replace the Packet Report
that Section 6.4 of requires for every selected
outer IP packet in every Selection Sequence. Those Packet Reports use
the sampled Network-Wire or Endpoint variant when applicable, or another
suitable Packet Report Template.
The counters are
not compensated for unselected packets. Counters, context-packet values,
classification evidence, and start/end times all describe the selected
packet stream for that Selection Sequence.
The exporter MUST NOT emit this profile based solely on a port, fixed-bit
heuristic, or version-independent prefix parse. It MUST first obtain
endpoint evidence or parse a packet using a supported QUIC version. The
record carries quicObservationSource and quicProcessingStatus for the
first observation that satisfied that admission rule. These IEs describe
classification evidence; they do not assert that every packet included in
the counters received the same processing.
This aggregate Template does not itself provide per-packet export;
packets in the applicable unselected or selected stream are aggregated,
and the record is exported at Flow end or at the end of a fixed
aggregation window. The separate PSAMP Packet Reports required above
remain mandatory when selection is active.
Existing IPFIX packet counters count the packets of the defined
Flow at the Observation Point; they do not implicitly count the
QUIC packets coalesced within a UDP datagram. The semantics below
make each counter's layer explicit:
sum of outer IP packets.
number of successfully delimited inner QUIC packets during the
interval. The value is present only when the exporter can provide a
complete count under the stated selection method.
sum of outer IP packet lengths in octets.
values from one context packet: the first completely parsed,
supported-version Long Header packet included in the record's
unselected or selected packet stream. These three fields are
exported atomically, and their presence bits are all set even when
either Connection ID has a genuine zero length. If no such context
packet exists, or if any member of the tuple cannot be exported,
all three presence bits are clear and the fixed fields carry ignored
placeholders. The Version is the packet's exact wire Version field,
not a negotiated or inferred connection-version value. If the
Connection IDs rotate later, those later values are not reported in
this profile.
quicFirstOctet, quicPacketType, quicPacketNumber, quicFrameType,
and quicStreamId vary per packet and MUST NOT be exported in this
profile. quicDestinationConnectionIdLengthSource is not exported in
this profile because the aggregate Destination Connection ID, when
present, always comes from the explicit length field in the context
Long Header packet. If
the exporter does not count inner QUIC packets,
or cannot assert that its count is complete under the stated selection
method, the quicPacketDeltaCount presence bit is clear and the fixed
field carries zero as an ignored placeholder. The presence bitmap also
identifies whether the complete Version and Connection ID tuple from
the context Long Header packet was exported. A nonzero quicExportFlags value
indicates that at least one otherwise available field in the record was
suppressed by local export policy or truncated by an export-resource or
size limit; it does not identify which clear presence bit was affected.
This optional profile uses an Options Template
to export connection-level metadata that
does not fit into per-packet or per-flow records.
Export QUIC connection observations, such as the first Long Header
Version field seen, a complete observed QUIC-packet count when
available, and the first and last observation times, correlated to the
initial client-to-server 5-tuple. The Original, Chosen, and Negotiated
Versions defined by are distinct endpoint
connection state and are not represented by quicVersion. Additional
connection-state IEs
(e.g., ALPN, migration and Connection ID rotation counters) are
out of scope for this document and MAY be added by future work.
observationDomainId, the initial client-to-server 5-tuple, and
flowId (148). IPv4 and IPv6 use separate Options
Templates with their corresponding address IEs. The scoped
observationDomainId identifies the Observation Domain of the correlated
Endpoint Packet records, and flowId MUST equal the value carried by
those records. The exporter assigns flowId from connection-specific
state, keeps it unchanged for the lifetime of the connection observation
(including across migration and IPFIX Transport Session changes), and
MUST NOT derive it solely from a 5-tuple or Connection ID. The
Observation Domain ID in the IPFIX Message
Header carrying this Options Record MUST be zero or equal to the scoped
observationDomainId; a different nonzero value would create a
contradictory implicit scope.
quicVersion (first observed Long Header Version field),
quicPacketDeltaCount (total successfully delimited QUIC packets when
the exporter can provide a complete count), and
flowStartMilliseconds and flowEndMilliseconds (first and last observed
packet times), and flowEndReason (the reason this connection
observation interval ended).
The base Options Template covers the unselected observed packet stream.
If packet selection is active, the exporter MUST use a distinct sampled
Options Template that adds selectionSequenceId (301) to the Options
Scope, and MUST emit a separate Options Record for each represented
(connection observation, Selection Sequence) pair. For every
selectionSequenceId in use, the exporter MUST export the applicable
Selection Sequence, Selector, Selection Sequence Statistics, and
Accuracy Report Interpretations required by Section 6.5 of
.
This Options Record supplements and MUST NOT replace the Packet Report
that Section 6.4 of requires for every selected
outer IP packet in every Selection Sequence. Those Packet Reports use
the sampled Network-Wire or Endpoint variant when applicable, or another
suitable Packet Report Template.
Counters, first-observed values, classification evidence, and start/end
times in that sampled record describe only the selected packet stream.
One Options Record per scope is exported when the connection observation
terminates because the connection end was detected, the idle timer
expired, an external event forced termination, or resources were
exhausted. A value exported after idle timeout covers only the completed
observation interval represented by that record.
For purposes of flowEndReason (136), the scoped connection observation
is the Flow being terminated. The exporter MUST use value 1 (idle
timeout) when it expires connection state because no packet was observed
before the configured idle timeout. It MUST use value 3 (end of Flow
detected) only when endpoint state, authenticated packet evidence, or a
Stateless Reset confirmed by the token-matching procedure in Section
10.3.1 of indicates that the QUIC connection
ended. It uses value 4 (forced end)
or value 5 (lack of resources) when the corresponding registered reason
terminates the observation. The exporter MUST NOT report value 3 merely
because its idle timer expired.
The exporter MUST NOT create a connection observation from heuristic or
version-independent prefix evidence alone. The Options Record carries
quicObservationSource and quicProcessingStatus for the first endpoint
observation or supported-version parse that established the connection
as QUIC. These values describe admission evidence, not every packet in
the connection interval. A supported-version parse is sufficient only
to admit an individual packet as QUIC evidence; it does not establish
that packets observed across Connection ID rotation or path migration
belong to one connection. Before assigning
flowId or aggregating a packet into this profile,
the exporter MUST have connection-specific state sufficient to make
that association. It MUST NOT merge observations based only on packet
syntax, a 5-tuple, or a matching Connection ID.
quicFieldPresence identifies whether quicVersion and
quicPacketDeltaCount are present. A clear bit causes the corresponding
fixed field to contain an ignored zero placeholder. The time fields are
always the first and last observed packet times for the interval.
quicExportFlags independently reports local suppression or truncation of
otherwise available values.
2001:db8::2,
protocolIdentifier 17, udpSourcePort 53924,
udpDestinationPort 443, flowId 4096
quicFieldPresence 0x00000041
(Version, QUIC Packet Count)
quicObservationSource 2 (Endpoint protocol state)
quicProcessingStatus 5 (Protected content available)
quicExportFlags 0 (Complete)
quicVersion 0x00000001
quicPacketDeltaCount 1894
flowStartMilliseconds 1726200000000
flowEndMilliseconds 1726200030000
flowEndReason 3 (end of Flow detected)
]]>
This section specifies the new IPFIX QUIC IEs.
The raw first octet of the observed QUIC packet, as seen on the
wire, before any header protection removal; this is evidence, not
an interpreted value. For protected v1 and v2 Long Header packets,
the low four bits are masked by header protection; for a protected
Short Header packet, the low five bits are masked. Retry is not
header-protected, and only the most significant bit of a Version
Negotiation first octet has invariant meaning. The packet-type mapping
is version-specific, so the raw value SHOULD NOT be interpreted
using the mapping of a version that is not known to be in use
(e.g., QUIC v2 intentionally remaps type bit values relative to
QUIC v1). For Short Header packets, the first octet has no
packet-type field, and a passive observer generally
cannot distinguish a Stateless Reset from a normal Short Header
packet without the reset token and connection state. Consumers
that need a normalized packet type SHOULD use quicPacketType,
which is only populated when the version and the required context
are known.
The exact 32-bit Version field present in the Long Header of the
observed QUIC packet. The Version field is wire-visible. For a
Version Negotiation packet, this field is 0x00000000; the
supported versions advertised in the Version Negotiation payload
are a separate repeated quantity and are exported with
quicSupportedVersion. Short Header packets do not carry this field;
their quicVersion presence bit is clear. The Original, Chosen, and
Negotiated Versions of a connection are distinct endpoint state
and are not exported by this IE.
The normalized QUIC packet type, populated only when the exporter
can determine it from quicFirstOctet and the QUIC version in use,
with the required context. Value 0 (Unknown) is used when the
version is not known or the type cannot be determined; the raw
first octet remains available in quicFirstOctet. Value
assignments: 0 = Unknown; 1 = Version Negotiation; 2 = Initial;
3 = 0-RTT; 4 = Handshake; 5 = 1-RTT (Short Header); 6 =
Stateless Reset (only when the exporter identifies the entire received
UDP datagram according to Section 10.3.1 of
and reports quicProcessingStatus 14); 7 = Retry. Confirmation requires
comparing the datagram's final 16 octets only with eligible tokens for
the remote address: tokens associated with Connection IDs that were used
and have not been retired. Version
Negotiation is identified by its invariant zero Version field. Retry is
identified only when the exporter supports the packet's version and its
type mapping. A Short Header is classified as 1-RTT only when endpoint
state or successful packet-protection processing establishes that
classification. These values are normalized categories, not the raw
Long Header type-bit values. The exporter applies the mapping defined by
the supported version; packets of unknown versions are exported as
Unknown rather than reinterpreted using another version's mapping.
The list of supported versions advertised in the payload of a
Version Negotiation packet, encoded as a basicList
. The list uses the ordered semantic, identifies
quicSupportedVersionValue (TBD5) as the contained IE, and uses an
element length of four octets. This is a separate repeated quantity
from the 32-bit Version field in the packet header (quicVersion),
which is 0x00000000 in a Version Negotiation packet. The list is
present only for Version Negotiation; a fixed Template uses an empty
placeholder and a clear presence bit for other packet types. The
negotiated and original versions of a connection are endpoint
connection state and are not exported by this IE.
One 32-bit version identifier contained in a quicSupportedVersion
basicList. It represents a Supported Version field from the Version
Negotiation packet payload and is not the packet header's Version
field.
The wire-visible Destination Connection ID included in the Long Header or Short Header of a 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 a 1-RTT packet (Short Header), its Destination Connection ID can be
obtained only from reliable connection- and direction-specific context,
such as a peer-issued Connection ID observed in an applicable Long Header,
endpoint state, successfully processed NEW_CONNECTION_ID frames, or
management configuration. Exporters MUST NOT infer it from an arbitrary
prior Long Header Destination Connection ID. Exporters of the Network-Wire
Observation Profile SHOULD report
quicDestinationConnectionIdLengthSource (TBD19) together with this
IE so that consumers can assess how the length and context of the
value were determined; in the Endpoint Packet Profile, the
provenance is indicated by quicObservationSource and
quicProcessingStatus.
The wire-visible Source Connection ID included in the Long Header of a QUIC packet.
The Source Connection ID is used to set the Destination Connection ID used by
the peer during connection establishment.
A Short Header packet does not carry a Source Connection ID. For such
a packet, a fixed record layout exports an empty placeholder and clears
the Source Connection ID bit in quicFieldPresence. An actually present
zero-length Source Connection ID is encoded as empty with that bit set.
A collector
MUST NOT supply a value for it when only Short Header packets of a
connection have been observed.
The full QUIC packet number assigned by the sending endpoint, or
reconstructed for a received packet according to the applicable
QUIC version's packet-number decoding procedure, an integer in the
range 0 to 2^62-1 as defined in Section 12.3 of . It does not carry the header-protection-masked
octets observed on the wire, nor the 1-to-4-byte truncated packet
number obtained after removing header protection. For a received
packet, removing header protection reveals the Packet Number
Length bits and the truncated packet number; a candidate full
packet number is then reconstructed using the expected
packet-number state and used to form the AEAD nonce. A
receiver-derived value MUST be exported as quicPacketNumber only
after packet-protection processing succeeds. The enclosing record
MUST unambiguously identify the QUIC connection observation,
sending endpoint or direction, and packet-number space; QUIC v1
and v2 have Initial, Handshake, and Application Data packet-number
spaces, and 0-RTT and 1-RTT packets share the Application Data
packet-number space. Extraction capability depends on the
supported QUIC version, sufficient captured bytes, connection
context, and access to the applicable keys: for QUIC v1 and v2,
the Packet Number Length bits and the encoded packet number field
are header-protected in Initial, Handshake, 0-RTT, and 1-RTT
packets. An observer supporting the applicable version and
possessing the relevant client Initial Destination Connection ID
can derive the version-specific Initial keys, but successful
Initial packet processing does not authenticate the peer because
those keys are publicly derivable; processing Handshake, 0-RTT,
and 1-RTT packets requires the corresponding traffic secrets or
keys derived from them; and locating the packet number field in a
Short Header packet additionally requires knowledge of the
Destination Connection ID length. A packet number field is present
in Initial, 0-RTT, Handshake, and 1-RTT packets; Version
Negotiation and Retry packets do not contain one. An identified
Stateless Reset has no semantic packet number, although it is
deliberately formatted to resemble a Short Header packet. These
rules apply to QUIC v1 and v2; they MUST NOT be applied to an
unknown future QUIC version without its version-specific
specification. If IPFIX reduced-size encoding is used, its field length is fixed in the
Template and MUST accommodate every value exported using that
Template; it is independent of QUIC's per-packet 1-to-4-byte
packet-number encoding. The exported value does not by itself
support loss inference: packet-number gaps alone do not prove loss
or incomplete reception, because packet numbers may be
intentionally skipped, packets may be reordered, and the
Observation Point or a sampling process may miss packets (see
Section 4.1 of ).
The Frame Type decoded from the plaintext payload of a successfully
processed QUIC packet. In supported versions, permitted Initial frame
types can be obtained by a passive observer that has the applicable
client Initial Destination Connection ID and sufficient capture and
packet-number context. Other encryption levels normally require the
corresponding traffic keys. 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. For frame types that do not carry a Stream
ID (e.g., ACK, CRYPTO), this IE is exported as a zero placeholder and
its quicFieldPresence bit is clear. A frame that carries Stream ID zero
exports zero with the bit set. A stream ID is a 62-bit integer (0 to
2^62-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
.
Indicates the sender direction of the QUIC packet within a
connection. Value 0 indicates client-to-server; value 1 indicates
server-to-client.
Indicates the QUIC packet number space of the observed packet.
Value 0 indicates Initial space; value 1 indicates Handshake
space; value 2 indicates Application Data space (0-RTT and
1-RTT).
The octet offset of a QUIC frame relative to the first plaintext octet
of the QUIC packet payload. It is used in the frame subTemplateList to indicate the
position of each frame and is distinct from quicPacketOffset,
which locates a coalesced QUIC packet within a UDP payload.
The total encoded plaintext extent of a QUIC frame, in octets, from the
first Frame Type octet through the final octet of that frame. This is
not a frame-specific Length field; QUIC has no generic frame-length
prefix.
The byte offset of a coalesced QUIC packet within the UDP payload
of the enclosing IP/UDP datagram. It is used in the inner QUIC-packet
subTemplateList of the Network-Wire Observation Profile and of the
sampled Endpoint Packet Observation Profile to identify each reported
QUIC packet carried by a (possibly coalesced) datagram. The first inner
packet has an offset of 0.
The number of completely delimited QUIC packets in the IP/UDP datagrams
included in the record's measurement interval. This counter is
independent of the number of structured-data child records and is
distinct from packetDeltaCount, which counts outer IP packets.
Identifies the source of the observation independently of processing
outcome: 0 = Unknown; 1 = Passive wire observation; 2 = Endpoint
protocol state; 3 = Authorized cooperating device supplied with the
applicable context or keys. In aggregate and connection records, it
identifies the source of the admission evidence defined by that profile.
Identifies the processing result independently of source. Values cover
heuristic classification, raw capture, supported-version parsing,
successful Initial processing, protected-content availability, Retry
Integrity Tag validation, Stateless Reset token confirmation,
unsupported versions, malformed and
capture-truncated input, packet-protection failure, Retry Integrity Tag
failure, incomplete frame parsing caused by an unsupported frame type or
format, and incomplete packet-field or frame parsing caused by a local
parser or processing-resource limit. These values are mutually
descriptive statuses, not an increasing confidence scale. In aggregate
and connection records, the value describes the admission evidence
defined by that profile.
Indicates how the exporter determined the length and context of a
Destination Connection ID field for the observed packet, or that no
applicable length was available. This is significant for Short Header
packets, whose header does not carry an explicit Destination Connection
ID length. Value assignments: 0 = Not applicable because the packet has
no semantic Destination Connection ID field; 1
= Explicit length field (the length was taken from the explicit
Destination Connection ID length field of the observed Long Header
packet); 2 = Learned from connection- and direction-specific protocol
context; 3 = Management
configuration (the value or its length was provisioned to the
exporter); 4 = Unknown (the length could not be determined; the
Destination Connection ID presence bit is then clear).
The raw Token octets carried in the type-specific field of the
observed Long Header packet, as present on the wire. In an Initial
packet, this is the Token following the Token Length field
(Section 17.2.2 of ); in a Retry packet,
this is the Retry Token. The Token is not header-protected and is
therefore observable by a passive exporter. For packets of other
types (Version Negotiation, Handshake, 0-RTT, Short Header), and
for Initial packets whose Token Length is zero, a fixed Template uses
an empty value and quicFieldPresence distinguishes absence from a
genuinely present zero-length Token. The Token content is chosen by the server
and MAY be encrypted or integrity-protected by the server; it can
encode client address-validation state, and its export raises
privacy considerations (see ).
This IE does not by itself allow the exporter
or the collector to validate the Token; it is exported as
observational evidence.
A flags IE that states which accompanying optional fields in the same
record are semantically present. It distinguishes valid zero values and
zero-length fields from fixed-Template placeholders.
Indicates whether a Network-Wire or sampled Endpoint parent record
completely enumerated and delimited the observed UDP payload or stopped
because of an unsupported version,
capture truncation, malformed input, or a local parser or
processing-resource limit. This status describes parsing, not whether
parsed child records were all exported.
The total wire length in octets of one successfully delimited QUIC
packet, from its first header octet through its final octet. It excludes
the enclosing UDP and IP headers.
Independent flags stating whether otherwise available information in
the same record or its child list was truncated by a local resource or
size limit in the export path, suppressed by configured export policy,
or both. A zero value means export was complete under the profile.
The security of the exported data depends on the security of the
IPFIX protocol and its transport. As described in Section 11 of
, the IPFIX protocol relies on the transport
layer for confidentiality and integrity, and it does not define an
in-band session authentication mechanism. Authentication of the
exporter by the collector MUST therefore be provided by the
underlying transport (e.g., IPFIX over TLS) or by a security gateway,
and the transport session SHOULD be protected against disclosure and
tampering. Beyond in-flight protection, deployments SHOULD apply
authentication and authorization to the collector itself: only
authorized consumers SHOULD be permitted to query, store, or forward
the exported Data Records, and the access controls applied to the
collector SHOULD reflect the sensitivity of the QUIC-specific values
exported through it.
QUIC packet types have different protection properties. Version
Negotiation has no intrinsic confidentiality or integrity protection.
Retry is neither encrypted nor header-protected; its version-specific Retry
Integrity Tag detects accidental corruption and limits valid generation to
an entity that observed the relevant Initial packet, but does not
authenticate the server against an active on-path attacker. Initial uses
packet protection under publicly derivable keys and is not considered to
provide confidentiality or integrity protection against attackers.
Handshake, 0-RTT, and 1-RTT packets use traffic secrets or keys derived from
TLS. Visible header bytes of a successfully protected packet can still be
authenticated as AEAD associated data. These distinctions are described in
.
See the Security and Privacy Considerations of
and the manageability considerations of
.
A sufficiently captured Long Header exposes both Connection IDs. A Short
Header exposes Destination Connection ID octets only to an observer that
knows the connection-specific length; it carries no Source Connection ID.
Connection IDs are useful, bounded correlation
evidence, but they are not a stable connection key: a QUIC endpoint may
maintain several active Connection IDs and may change the Destination
Connection ID it uses for a peer at any time during a connection, for
example during connection migration . CID-based
correlation is additionally limited by Connection ID rotation, address
and port migration (the same connection may be observed under different
CIDs before and after a path change), zero-length Connection IDs (which
provide no correlation evidence at all), and multiple observation points
(which may not agree on which packets belong to the same connection).
Exporting these identifiers can therefore create additional linkability:
a collector can use them to correlate packets belonging to the same QUIC
connection before and after an address or port change, including across
NAT rebinding and path migration. Deployments exporting these
identifiers SHOULD apply access control and retention policies
appropriate for identifiers that can correlate traffic belonging to the
same QUIC connection. Where endpoint-derived association is available,
flowId (148) provides the registered, explicitly scoped correlation
mechanism used by this document. An exporter MUST assign flowId from its
connection-observation state and MUST NOT derive it solely from a 5-tuple
or wire-visible Connection ID.
Endpoint- or key-derived quicStreamId and quicPacketNumber values likewise
require access controls appropriate to their additional linkability.
quicToken (TBD20) exports the raw Token octets of an Initial or Retry
packet. A Token is chosen by the server and can carry or index
address-validation state. Its content is opaque to an exporter or collector
that lacks the server's token-protection context, so exporting it does not
by itself enable the collector to interpret or validate that state.
Depending on the server's token construction, address binding, and token
lifetime, disclosure can nevertheless enable replay that bypasses address
validation and can contribute to amplification attacks; see Sections 8.1.4
and 21.3 of .
Nevertheless, repeated raw Token values and combinations with other
observations can add correlation capability across packets, connections,
or observation points. Deployments exporting quicToken
SHOULD treat it as sensitive correlation data and SHOULD apply
access control, minimization, and retention policies accordingly;
where token contents are not needed for the operational purpose,
exporters SHOULD NOT export quicToken.
Cross-observation-point correlation extends the linkability described
above. Because Connection IDs are wire-visible, the same QUIC
connection can be observed under the same or different Connection IDs
at multiple observation points (for example, at the network edge and
at a datacenter ingress, or before and after a client moves behind a
different NAT), and a collector that aggregates records from several
points can correlate the same connection across those points and
combine it with other data sources. flowId mitigates this by providing a
correlation value assigned from exporter connection state rather than from
wire-visible identifiers. It is unique only within its Observation Domain,
as specified by the registered IE definition, and is non-reversible under
. Collectors combining records from different
Exporting Processes or Observation Domains MUST NOT assume that equal
flowId values identify the same connection.
The Information Elements specified in this document can weaken this
protection when they are populated from plaintext QUIC content. In
particular, quicPacketNumber and quicFrameType can be obtained from a
supported-version Initial packet by a passive observer that has the
applicable client Initial Destination Connection ID, complete capture,
direction and packet-number context, and successful packet processing.
Processing Handshake, 0-RTT, and 1-RTT content requires the corresponding
traffic secrets or derived keys. Stream-related frames are not permitted in
Initial packets, so quicStreamId remains endpoint- or traffic-key-derived.
Exporting these values may
reveal information about user activity that QUIC is designed to protect,
and may make user activity linkable across flows and observation points.
Operators deploying these IEs SHOULD apply data minimization: export
only the Information Elements required for the intended use, limit
the retention period of exported QUIC-specific values (Connection
IDs, packet numbers, stream identifiers), and restrict access to the
exported records. Exporters MUST NOT export QUIC secrets or keying
material, including handshake secrets, traffic keys, Initial secrets,
header-protection keys, or Stateless Reset tokens.
Stateless reset tokens allow termination of the associated connection and
are therefore sensitive connection state. An exporter that confirms a
Stateless Reset MUST protect stored tokens, MUST perform the comparison
without leaking token values as required by Section 10.3.1 of
, and MUST NOT export the matched token as
quicToken. quicToken represents only the Initial or Retry Token field.
Several of the Information Elements defined in this document carry
variable-length or list data: quicDestinationConnectionId and
quicSourceConnectionId (octetArray), quicToken (octetArray),
quicSupportedVersion
(basicList), and the nested frame sub-template records
(subTemplateList). Unbounded values in these fields could be used to
consume excessive resources at the collector or to smuggle arbitrary
data through the export channel. Exporters SHOULD therefore impose local
limits on total structured-data bytes, the number of version entries,
frames and inner packets, nesting, and parser work. A 20-octet Connection
ID limit applies to packets encoded by QUIC v1 and v2, but the invariant
Long Header format of permits Connection ID lengths
from 0 through 255 octets in Version Negotiation or an unknown or future
version. Version Negotiation has no
separate protocol-defined entry-count maximum; its complete 32-bit entries
occupy the packet remainder after the Source Connection ID. A Token is
bounded by the bytes remaining in the observed packet. When a parser-work or
processing-resource limit prevents complete parsing of an emitted packet
observation, that observation uses quicProcessingStatus 13. If that limit also prevents
complete packet-boundary enumeration in the Network-Wire profile, the parent
record uses quicDatagramParseStatus 5. When otherwise available information
exceeds a local export or representation limit, the exporter MUST report
local truncation through quicExportFlags and clear any affected presence
bit. It MUST NOT label the packet malformed solely because of either local
limit. Collectors SHOULD validate the
lengths declared in templates and reject records whose implied size
is implausible, in order to protect against a misconfigured or
malicious exporter.
This document requests IANA to add new IPFIX QUIC IEs to the
"IPFIX Information Elements" registry
available at . The registration of
each IE follows the process and format specified in ,
and the encoding of list-typed elements (e.g., quicSupportedVersion) follows . The IE definitions in this document were
written following the guidelines in .
Each IE description in this document
independently states its derivation, applicability, scope,
aggregation behavior, range/length, and the behavior when the
value is unavailable, so that a reader can understand the IE
from its registry entry alone.
IANA is requested to assign the lowest available Element IDs in the
range specified by , replace every TBD label
appearing in Table 1 throughout these registrations, set the Status of every new IE to
current, set its initial Revision to 0, and set its Date to the date on
which the registration is made. The RFC Editor is requested to replace
each remaining such TBD label in this document with the corresponding
Element ID assigned by IANA.
Table 1 lists the new IPFIX QUIC IEs:
Name:
quicFirstOctet
ElementID:
TBD1
Description:
The raw first octet of the observed QUIC packet, as seen on
the wire, before any header protection removal; this is
evidence, not an interpreted value. The Header Form bit is
invariant, but the meaning of the other bits is
version-specific. For protected QUIC v1 and v2 Long Header
packets, the low four bits are masked by header protection;
for a protected Short Header packet, the low five bits are
masked. Retry and Version Negotiation packets are not
header-protected, and only the most significant bit of a
Version Negotiation first octet has invariant meaning. A
Short Header first octet has no packet-type field, and a
passive observer generally cannot distinguish a Stateless
Reset from a normal Short Header packet without the reset
token and connection state. For a normalized packet type,
see quicPacketType.
Abstract Data Type:
unsigned8
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the wire; no decryption
required. Applicability: all Long and Short Header QUIC
packets. Scope: one value per QUIC-packet observation in the
Network-Wire Observation and Endpoint Packet Observation
profiles. Aggregation: one value per observed packet. Range:
0x00-0xFF. The value is the on-wire octet; an exporter MUST
NOT replace it with the octet obtained after header-protection
removal. An exporter cannot create a packet observation when
capture truncation prevents access to the first octet. See
Section 5 of for header protection,
for invariant fields, and Sections
17.2 and 17.3 of for QUIC v1 packet
formats.
Reference:
[this document]
Name:
quicVersion
ElementID:
TBD2
Description:
The exact 32-bit Version field present in the Long Header of
the observed QUIC packet. The field is wire-visible and is
not header-protected. It is 0x00000000 in a Version
Negotiation packet. Short Header packets do not contain a
Version field; an exporter MUST NOT substitute a version
learned from connection state. The Original, Chosen, and
Negotiated Versions of a connection are distinct endpoint
state and are not exported by this
IE.
Abstract Data Type:
unsigned32
Data Type Semantics:
identifier
Additional Information:
Derivation: read directly from the Long Header (passive);
no decryption is required. Applicability: Long Header
packets only. Scope: one value per packet observation in a
profile that carries this IE. Aggregation: one value per
observed packet; a coarser-granularity profile defines
separately which packet supplies its value. Range:
0x00000000-0xFFFFFFFF; 0x00000000 means Version Negotiation
and MUST NOT be used to mean "unknown". In a fixed Template,
a Short Header packet or an unavailable Long Header field is
encoded with the numeric placeholder zero and the Version bit
in quicFieldPresence clear; a collector MUST ignore that
placeholder. A genuine Version Negotiation field has value
zero with the Version bit set. See the assignments
in the "QUIC Versions" IANA registry at
https://www.iana.org/assignments/quic/quic.xhtml#quic-versions.
See also for the invariant Long
Header Version field and for QUIC
v1 packet formats.
Reference:
[this document]
Name:
quicPacketType
ElementID:
TBD3
Description:
The normalized, version-independent category of the observed
QUIC packet. Assigned values are maintained in the
quicPacketType Values subregistry.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: derived (not read directly from the wire) by
interpreting invariant fields, quicFirstOctet, the supported
QUIC version's packet-type rules, and any required connection
context. Applicability: all observed QUIC packets. Scope: one
value per packet observation in the Network-Wire Observation
and Endpoint Packet Observation profiles. Aggregation: one
value per observed packet. Range: 0 to 254; value 255 is
Reserved and MUST NOT be exported. Assigned values are maintained
in the .
Exporters MUST NOT apply the type-bit
mapping of a known version to a packet of an unknown or
different version. In particular, QUIC v2
remaps the Long Header type bits
relative to QUIC v1. A Short Header packet is classified as
1-RTT only when endpoint protocol state or successful
packet-protection processing establishes that classification;
an apparent Short Header without that result is Unknown. A packet
that merely resembles a Stateless Reset, including a candidate
whose token does not match under Section 10.3.1 of
, is likewise not assigned value 6. Value 6
is reported only when the exporter identifies the entire received
UDP datagram using that procedure: its final 16 octets match an
eligible token associated with the remote address and a Connection
ID that was used and has not been retired. An observation with
value 6 MUST carry quicProcessingStatus value 14. A Stateless Reset consumes the
entire UDP datagram and has no semantic Destination Connection ID;
apparent Connection ID-position bytes are unpredictable reset
bytes and are not exported as quicDestinationConnectionId.
Reference:
[this document]
Name:
quicSupportedVersion
ElementID:
TBD4
Description:
The list of supported versions advertised in the payload of
a Version Negotiation packet, encoded as a basicList of
quicSupportedVersionValue (TBD5) elements. The basicList
uses the ordered semantic, and every element has a length of
four octets. Entries retain their wire order, including
duplicate and reserved-version values. This is a separate
repeated quantity from the 32-bit Version field in the packet
header (quicVersion), which is 0x00000000 in a Version
Negotiation packet.
Abstract Data Type:
basicList
Data Type Semantics:
list
Additional Information:
Derivation: parsed from the Version Negotiation payload
(passive); the list starts immediately after the Source
Connection ID and extends to the end of the packet. QUIC does
not encode a separate entry count or list length. The
remaining extent therefore has to be a non-zero multiple of
four octets for a valid Version Negotiation packet.
Applicability: Version Negotiation packets only. Scope: one
list per packet observation in the Network-Wire Observation
Profile. Aggregation: one ordered list per observed Version
Negotiation packet. In a fixed Template, other packet types
or an unavailable or malformed list use an empty-list
placeholder with the Supported Version bit in
quicFieldPresence clear; a collector MUST ignore that
placeholder. When the list is exported as present, the bit is set
and the list contains every complete 32-bit entry without
deduplication or filtering. If configured policy or an export-path
limit omits any otherwise available entry, the presence bit is
clear, the fixed Template carries an empty list, and the applicable
quicExportFlags bit is set. If a local parser or
processing-resource limit stops list parsing, the same empty-list
representation is used and quicProcessingStatus is 13. A partial
advertised list MUST NOT be represented as complete. A malformed
Version Negotiation list that occupies a known packet remainder
does not by itself make packet-boundary enumeration incomplete:
the parent uses quicDatagramParseStatus 1 and the child uses
quicProcessingStatus 8.
See Section 17.2.1 of for the
Version Negotiation packet format. See Section 4.5.1 of
for the basicList encoding.
Reference:
[this document]
Name:
quicSupportedVersionValue
ElementID:
TBD5
Description:
One exact 32-bit Supported Version value from the payload
of a QUIC Version Negotiation packet. It is the scalar
element contained by quicSupportedVersion and is distinct
from the packet header's Version field.
Abstract Data Type:
unsigned32
Data Type Semantics:
identifier
Additional Information:
Derivation: read as one four-octet entry from the Version
Negotiation packet payload after the Source Connection ID.
Applicability and scope: one list element for each complete
entry in quicSupportedVersion; it is not a standalone
negotiated-version assertion. Aggregation: not aggregated.
Range: 0 to 2^32-1. Each occurrence in the basicList MUST
use a field length of four octets. The exporter MUST preserve
the wire order, duplicates, and reserved or unrecognized
values in the enclosing list and MUST NOT substitute the
header Version field. A trailing payload fragment shorter
than four octets is malformed and is not exported as a
list element. Values are interpreted using the "QUIC Versions"
IANA registry at
https://www.iana.org/assignments/quic/quic.xhtml#quic-versions;
reserved and unrecognized values are nevertheless retained as
observed.
Reference:
[this document]
Name:
quicDestinationConnectionId
ElementID:
TBD6
Description:
The wire-visible Destination Connection ID field of the
observed QUIC packet, represented as an octetArray. Long
Headers carry an explicit Destination Connection ID length;
Short Headers do not, so their field can be exported only
when the exporter has reliable connection- and
direction-specific length context. QUIC v1 and v2 Connection IDs
are at most 20 octets. The version-independent Long Header permits
lengths from 0 through 255 octets, while
does not constrain the Short Header
Destination Connection ID length. An exporter MUST apply the
constraints of the applicable supported version and MUST NOT apply
the v1 or v2 limit to Version Negotiation or another version.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the Long Header (explicit
length field). For a Short Header, the field boundary is
obtained from reliable connection-specific context for the
receiving endpoint, such as endpoint state, management
configuration, or knowledge of a recipient-selected
Connection ID and its direction. An exporter MUST NOT assume
that the length of an arbitrary Connection ID seen in a
prior Long Header is the applicable Short Header length;
Connection ID rotation can require NEW_CONNECTION_ID or
equivalent endpoint context. Applicability: Long and Short
Header packets, including a genuinely zero-length field, and the
value from the context Long Header packet defined by the
Flow-Aggregate Profile. Scope: one
value per packet observation in the Network-Wire and Endpoint
Packet Observation profiles; in the Flow-Aggregate Profile, one
value from the record's context packet. Aggregation: one value per
observed packet in packet profiles; taken from the context packet
in the Flow-Aggregate Profile. Length: 0 to 20 octets for packets
encoded by QUIC v1 and v2; for another supported version, the
range specified by that version; 0 to 255 octets for Version
Negotiation or when parsing only the version-independent Long
Header structure of an unknown version. A Short Header value under
another supported version uses that version's range; the
version-independent Short Header format sets no limit.
When the field is present and has zero length, its
presence bit is set and an empty octetArray is the value.
When a Short Header field boundary cannot be determined, or
capture truncation prevents reading a declared Long Header
field, the Destination Connection ID presence bit is clear
and a fixed Template carries an empty placeholder that the
collector MUST ignore. quicDestinationConnectionIdLengthSource
(TBD19) reports the method used to obtain the field boundary.
See for the invariant Long Header
encoding and Sections 5.1, 17.2, and 17.3 of
for QUIC v1 Connection IDs.
Reference:
[this document]
Name:
quicSourceConnectionId
ElementID:
TBD7
Description:
The wire-visible Source Connection ID field of the observed
QUIC Long Header packet, represented as an octetArray. A
Short Header does not contain a Source Connection ID. QUIC
v1 and v2 Connection IDs are at most 20 octets. The
version-independent Long Header permits lengths from 0 through
255 octets. An exporter MUST apply the constraints of the
applicable supported version and MUST NOT apply the v1 or v2
limit to Version Negotiation or another version.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the Long Header; the Source
field boundary is given by its explicit length octet and no
decryption is required. Applicability: Long Header packets and
the value from the context Long Header packet defined by the
Flow-Aggregate Profile. Scope:
one value per packet observation in the Network-Wire and Endpoint
Packet Observation profiles; in the Flow-Aggregate Profile, one
value from the record's context packet. Aggregation: one value per
observed packet in packet profiles; taken from the context packet
in the Flow-Aggregate Profile. Length:
0 to 20 octets for packets encoded by QUIC v1 and v2; for another
supported version, the range specified by that version; 0 to 255
octets for Version Negotiation or when parsing only the
version-independent Long Header structure of an unknown version.
A present zero-length field has its
Source Connection ID presence bit set and an empty
octetArray value. A Short Header, or a capture-truncated Long
Header for which the declared field cannot be read, has the
presence bit clear; a fixed Template then carries an empty
placeholder that the collector MUST ignore. See
for the invariant Long Header
encoding and Sections 5.1 and 17.2 of
for QUIC v1 Connection IDs.
Reference:
[this document]
Name:
quicPacketNumber
ElementID:
TBD8
Description:
The full QUIC packet number assigned by the sending endpoint
or reconstructed for a received packet according to the
applicable QUIC version's packet-number decoding procedure,
an unsigned64 integer in the range 0 to 2^62-1. It does not
carry the header-protection-masked octets observed on the
wire, nor the 1-to-4-byte truncated packet number obtained
after removing header protection. A receiver-derived value
is exported only after packet-protection processing
succeeds. The enclosing record MUST unambiguously identify
the QUIC connection observation, sending endpoint or
direction, and packet-number space; QUIC v1 and v2 have
Initial, Handshake, and Application Data packet-number
spaces, and 0-RTT and 1-RTT packets share the Application
Data packet-number space. A packet number field is present
in Initial, 0-RTT, Handshake, and 1-RTT packets; Version
Negotiation and Retry packets do not contain one. An
identified Stateless Reset has no semantic packet number,
although it is deliberately formatted to resemble a Short
Header packet. If IPFIX reduced-size encoding is used, its
field length is fixed in the Template and must accommodate
every value exported using that Template; it is independent
of QUIC's per-packet 1-to-4-byte packet-number encoding.
This element does not by itself support loss inference (see
Section 4.1 of ).
Abstract Data Type:
unsigned64
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the sending endpoint, or for a
received packet reconstructed from the truncated packet
number revealed by header-protection removal according to
the applicable QUIC version's packet-number decoding
procedure; not the header-protection-masked wire octets and
not the 1-to-4-byte truncated value. A received or passively
observed value is valid only after packet-protection
processing succeeds and the exporter can track the
(connection, sender direction, packet-number space) state.
Version-specific Initial secrets are publicly derivable from
the client's Initial Destination Connection ID, so a passive
exporter can obtain an Initial packet number when it has the
required version and connection context; successful Initial
processing does not authenticate the peer. Handshake, 0-RTT,
and 1-RTT packets require the corresponding traffic secrets,
and locating the packet number in a Short Header additionally
requires reliable Destination Connection ID length context.
Applicability: Initial, 0-RTT, Handshake, and 1-RTT packets.
Version Negotiation and Retry have no packet-number field, and
a confirmed Stateless Reset has no semantic packet number.
These rules apply to QUIC v1 and v2 and MUST NOT be applied to
an unknown future version without its version-specific
specification. Scope: one value per QUIC-packet observation
record in the Endpoint Packet Observation Profile, whether a
top-level record in the base variant or a child record in the
sampled variant; that record identifies the
connection observation, sender direction, and packet-number
space. The Flow-Aggregate and Connection-State profiles do not
carry this IE. Aggregation: one value per observed packet.
Range: 0 to 2^62-1; the value is the reconstructed full packet
number. If the value cannot be obtained and validated, the
exporter MUST NOT emit an Endpoint Packet Observation record
containing it. If IPFIX reduced-size encoding is used, the
field length selected by the Template has to accommodate every
value exported with that Template and is independent of QUIC's
1-to-4-octet truncated encoding.
See Section 12.3 of for more
details about the Packet Number.
Reference:
[this document]
Name:
quicFrameType
ElementID:
TBD9
Description:
The QUIC variable-length integer that identifies the frame
type. It is represented as an unsigned64 value in the range
0 to 2^62-1. Values are assigned in the "QUIC Frame Types"
IANA registry.
Abstract Data Type:
unsigned64
Data Type Semantics:
identifier
Additional Information:
Derivation: parse the frame's type field from plaintext
supplied by the sending endpoint or obtained after successful
packet-protection processing of a received or passively
observed packet. An endpoint or authorized device with the
applicable traffic secrets can obtain this value. A passive
exporter can also obtain it from a supported-version Initial
packet after successful Initial packet-protection processing
with the publicly derivable Initial secrets; that success
does not authenticate the peer. Applicability: every
successfully parsed frame in an
Initial, 0-RTT, Handshake, or 1-RTT packet. A packet can
contain multiple frames, and each occurrence is reported in
its own frame-observation subrecord. Scope: one value per
frame in the Endpoint Packet Observation Profile.
Aggregation: one value per frame occurrence; frame order is
preserved by the containing profile. Range: 0 to 2^62-1,
subject to assignments in the "QUIC Frame Types" IANA
registry. If packet protection does not succeed, the exporter
MUST NOT emit frame-observation records derived from the
unauthenticated plaintext. If frame parsing stops after a prefix
of complete frames, the exporter MAY emit records for that prefix
but MUST NOT emit a record for the undelimited frame or infer any
later frame; quicProcessingStatus reports why parsing stopped. See
the assignments in the "QUIC Frame Types" IANA registry at
https://www.iana.org/assignments/quic/quic.xhtml#quic-frame-types.
See also for QUIC frame encoding.
Reference:
[this document]
Name:
quicStreamId
ElementID:
TBD10
Description:
The QUIC Stream ID carried by a frame that contains a Stream
ID field, represented as an unsigned64 value in the range 0
to 2^62-1. The two least significant bits identify the
stream initiator and whether the stream is unidirectional or
bidirectional, as defined in Section 2.1 of
.
Abstract Data Type:
unsigned64
Data Type Semantics:
identifier
Additional Information:
Derivation: parse the Stream ID field from plaintext supplied
by the sending endpoint or obtained after successful
packet-protection processing of a received packet.
Applicability: only frame
types whose format contains a Stream ID field, including
STREAM, RESET_STREAM, STOP_SENDING, MAX_STREAM_DATA,
STREAM_DATA_BLOCKED, and their registered extensions as
applicable. The base QUIC v1 frame types that contain a
Stream ID are not permitted in Initial or Handshake packets,
so passive Initial processing does not by itself make Stream
IDs available; observing them in 0-RTT or 1-RTT packets
requires endpoint state or the applicable traffic secrets.
Scope: one value per frame
observation in the Endpoint Packet Observation Profile.
Aggregation: one value per frame occurrence that contains a
Stream ID. Range: 0 to 2^62-1. In the fixed frame-observation
Template, a frame without a Stream ID uses numeric placeholder
zero with the Stream ID bit in quicFieldPresence clear; a
genuine Stream ID of zero has the bit set. A collector MUST
ignore the placeholder when the bit is clear. If packet
protection fails, the exporter MUST NOT emit a frame observation
containing this IE. If parsing stops at a later frame, preceding
completely parsed frame observations remain valid, but no Stream
ID is emitted for the undelimited frame or any inferred later
frame. See Section 2.1 of
for Stream ID semantics.
Reference:
[this document]
Name:
quicSenderDirection
ElementID:
TBD11
Description:
Indicates the sender direction of the QUIC packet relative to the
client and server roles of the connection. Assigned values are
maintained in the quicSenderDirection Values subregistry.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: determined from the packet's sender and the
exporter's connection-specific knowledge of which endpoint
initiated the connection; it is not a QUIC protocol field.
The exporter MUST retain the role association across address
changes and MUST NOT infer it solely from a particular
address-port tuple. Applicability: every QUIC-packet observation
record in the Endpoint Packet Observation Profile, whether a
top-level record in the base variant or a child record in the
sampled variant. Scope: one value per packet observation.
Aggregation: one value per observed
packet. Range: 0 to 254; value 255 is Reserved and MUST NOT be
exported. Assigned values are maintained in the
.
This IE is a Flow Key and is mandatory in that profile. If
the sender role cannot be determined, the exporter cannot
emit the packet using the Endpoint Packet Observation
Profile. The Flow-Aggregate Profile instead uses the ordered
source/destination 5-tuple and flowDirection; the
Connection-State Profile is scoped to the connection rather
than to one sender direction.
Reference:
[this document]
Name:
quicPacketNumberSpace
ElementID:
TBD12
Description:
Identifies the QUIC packet-number space of the observed packet.
Assigned values are maintained in the quicPacketNumberSpace Values
subregistry. 0-RTT and 1-RTT packets share the Application Data
packet-number space.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: determined by the exporter from the QUIC
packet type using the applicable version's packet formats.
For QUIC v1 and v2, Initial packets use value 0, Handshake
packets use value 1, and 0-RTT and 1-RTT packets use value 2.
Applicability: Initial, 0-RTT, Handshake, and 1-RTT packets.
Version Negotiation and Retry packets have no packet-number
field, and a confirmed Stateless Reset has no semantic packet
number, so none is assigned a space. Scope: one value per
QUIC-packet observation record in the Endpoint Packet Observation
Profile, whether a top-level record in the base variant or a child
record in the sampled variant.
Aggregation: one value per observed packet. Range: 0 to 254;
value 255 is Reserved and MUST NOT be exported. Assigned values
are maintained in the
. This IE is a Flow Key and
is mandatory in that profile. The Flow-Aggregate and
Connection-State profiles do not carry it. An exporter MUST
NOT apply the v1/v2 mapping to an unknown future version
without its version-specific specification. See Section 12.3
of for QUIC packet-number spaces.
Reference:
[this document]
Name:
quicFrameOffset
ElementID:
TBD13
Description:
The offset, in octets, of the first Frame Type octet of a
QUIC frame from the first octet of the plaintext payload of
the containing QUIC packet. The first frame has an offset
of zero.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from endpoint plaintext protocol state or
while parsing the plaintext packet payload after successful
packet-protection processing. For
a supported-version Initial packet, a passive observer can
do this when it has the required client Initial Destination
Connection ID, captured bytes, and packet-number context;
other encryption levels normally require the corresponding
traffic keys. Applicability and scope: one value per
completely parsed frame in the frame subTemplateList of the
Endpoint Packet Observation Profile. Aggregation: not
aggregated; frame records are ordered by this offset. Range:
0 to 2^32-1. The value MUST be less than the plaintext
payload length of the containing packet. If the start of a
frame cannot be determined, the exporter MUST NOT emit a
frame record for it; the packet's quicProcessingStatus
reports why processing stopped.
Reference:
[this document]
Name:
quicFrameLength
ElementID:
TBD14
Description:
The total encoded plaintext extent, in octets, of a QUIC
frame, from its first Frame Type octet through its final
octet in the containing packet. This is not a
frame-specific Length field; QUIC has no generic frame
length prefix.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from endpoint plaintext protocol state or
while parsing the plaintext packet payload after successful
packet-protection processing. For
a supported-version Initial packet, a passive observer can
do this when it has the required client Initial Destination
Connection ID, captured bytes, and packet-number context;
other encryption levels normally require the corresponding
traffic keys. Applicability and scope: one value per
completely parsed frame in the frame subTemplateList of the
Endpoint Packet Observation Profile. Aggregation: not
aggregated. Range: 1 to 2^32-1. The extent includes the
encoded Frame Type and every encoded field and payload octet
belonging to the frame; it is not merely the value of a
frame-specific Length field. The extent MUST fit within the
plaintext payload of the containing packet. If the complete
extent cannot be determined, the exporter MUST NOT emit a
frame record for it; the packet's quicProcessingStatus
reports why processing stopped.
Reference:
[this document]
Name:
quicPacketOffset
ElementID:
TBD15
Description:
The offset, in octets, of the first header octet of a QUIC
packet from the first octet of the enclosing UDP payload.
The first packet in the UDP payload has an offset of zero.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from the position of a packet whose
start the exporter has determined in the captured UDP
payload; no QUIC payload decryption is required.
Applicability and scope: one value per QUIC packet start that the
exporter has determined in the Network-Wire Observation Profile's
or sampled Endpoint Packet Observation Profile's packet
subTemplateList. The first candidate packet begins at
offset zero even when an unsupported version prevents determining
its end. Aggregation: not
aggregated; packet records are ordered by this offset.
Range: 0 to 2^32-1. The value MUST be less than the UDP
payload length. An exporter MUST NOT infer a later packet
offset by applying the length rules of a QUIC version it
does not support. If a packet start or the preceding packet
boundary cannot be determined, the exporter MUST NOT emit a
packet record for that undetermined occurrence;
quicDatagramParseStatus on the parent record reports the
incomplete enumeration. This IE is distinct from
quicFrameOffset, which is relative to the first plaintext
payload octet of a QUIC packet.
Reference:
[this document]
Name:
quicPacketDeltaCount
ElementID:
TBD16
Description:
The number of completely delimited QUIC packets assigned to
the observation represented by the enclosing record during
the exported observation interval. This is a QUIC-packet
counter and is distinct from packetDeltaCount, which counts
outer IP packets.
Abstract Data Type:
unsigned64
Data Type Semantics:
deltaCounter
Units:
packets
Additional Information:
Derivation: incremented once for every completely delimited QUIC
packet assigned to the observation represented by the enclosing
record. When PSAMP packet selection is active, only QUIC packets
completely delimited in the UDP payload of outer IP packets
selected under the reported Selection Sequence are eligible.
The counter is independent of whether a structured-data child
record is exported for that packet.
Applicability: the Flow-Aggregate and Connection-State
profiles. Scope: the observation interval and directionality
represented by the enclosing record; the Flow-Aggregate
Profile is unidirectional, while the Connection-State Profile
covers the connection observation identified by its Options
Scope. Aggregation: one delta value per interval; when
selection is active, it counts only those eligible inner packets
of selected outer IP packets. Range: 0 to
2^64-1. The exporter MUST set the
quicPacketDeltaCount bit in quicFieldPresence only when the
count is complete for the interval under that selection
method. Otherwise, a fixed Template carries zero as an
ignored placeholder and the presence bit is clear. A zero
value with the presence bit set is a complete count of zero.
Reference:
[this document]
Name:
quicObservationSource
ElementID:
TBD17
Description:
Identifies the source from which a QUIC packet observation
was obtained. It reports provenance independently of the
processing result in quicProcessingStatus and is not a
confidence scale.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned from the component that supplied the
exported values. Applicability and scope: one value per
packet observation in the Network-Wire and Endpoint Packet
Observation profiles. In the Flow-Aggregate and Connection-State
profiles, one value identifies the source of the first observation
that satisfied the profile's QUIC-admission rule. Aggregation: not
aggregated. Range: 0 to 254; value 255 is Reserved and MUST NOT
be exported. Assigned values are maintained in the
. Value
assignments: 0 = Unknown; 1 = Passive wire
observation; 2 = Endpoint protocol state, including a
terminating QUIC proxy acting as an endpoint for the
observed connection; 3 = Authorized cooperating device
that is not an endpoint and that was supplied the applicable
connection context or keys. Value 0 is used when the source
cannot be determined. An exporter MUST report the actual
source and MUST NOT change it merely because processing
progressed further. For example, successful passive Initial
processing remains source 1, while the success is reported
by quicProcessingStatus. See Section 3.1 of
for the limits of passive QUIC
detection.
Reference:
[this document]
Name:
quicProcessingStatus
ElementID:
TBD18
Description:
Identifies the processing result for a QUIC packet
observation independently of quicObservationSource. The
numeric values are discrete outcomes and do not form an
increasing confidence scale.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the exporter from the processing
actually performed and the condition, if any, that stopped
it. Applicability and scope: one value per packet
observation in the Network-Wire and Endpoint Packet
Observation profiles. In the Flow-Aggregate and Connection-State
profiles, one value records the processing result for the first
observation that satisfied the profile's QUIC-admission rule.
Aggregation: not aggregated. Range: 0 to 254; value 255 is
Reserved and MUST NOT be exported. Assigned values are maintained
in the
. Value
assignments: 0 = Unknown, not attempted, or
not applicable; 1 = Heuristic classification only; 2 =
Version-independent fields parsed from raw wire evidence;
3 = Supported-version packet structure parsed; 4 = Initial
packet protection successfully processed; 5 = Protected
content available from endpoint state or from the applicable
non-Initial traffic keys; 6 = Retry Integrity Tag validated;
7 = Unsupported version prevented the required
version-specific processing; 8 = Structurally malformed
packet; 9 = Capture truncated; 10 = Packet-protection or
payload-authentication failure; 11 = Retry Integrity Tag
validation failure; 12 = Unsupported frame type or frame format
prevented complete frame enumeration after plaintext became
available; 13 = A local parser or processing-resource limit
prevented complete protocol parsing; 14 = The entire received UDP
datagram was identified as a Stateless Reset by applying Section
10.3.1 of : its final 16 octets matched an
eligible token for the remote address, associated with a
Connection ID that was used and had not been retired. Status 12 applies to an
Endpoint Packet Observation for which frame enumeration was
attempted. Status 13 can apply to packet-field or frame parsing.
The exporter MUST use the status that describes the values
represented in the record and MUST NOT report fields whose
derivation depended on an operation that failed. Status 4
indicates only successful processing under publicly
derivable Initial keys and does not authenticate the peer.
Status 6 likewise has only the security properties of the
version-specific Retry Integrity Tag. When several conditions could
apply, the exporter reports the condition that terminated the
processing represented by the record: capture truncation when
required captured octets are missing; malformed input only after
a supported parser detects a structural violation; unsupported
version when sufficient invariant fields are present but no
applicable version parser exists; an authentication-failure value
only when that validation was attempted; unsupported frame parsing
only when plaintext is available but the local decoder cannot
determine an encountered frame's complete extent; Stateless Reset
confirmation only after the complete datagram-level token check
described above. A record with status 14 MUST use
quicObservationSource 2 (Endpoint protocol state) or 3 (Authorized
cooperating device); token state is not passive wire evidence.
Lack of local
support for a frame type or format, or exhaustion of a local
processing limit, does not make the packet malformed. Local policy
suppression and local export-resource or representation-size
limits are independent export outcomes
reported in quicExportFlags; they MUST NOT overwrite this
processing result.
Reference:
[this document]
Name:
quicDestinationConnectionIdLengthSource
ElementID:
TBD19
Description:
Indicates how the exporter determined the length and
context of a Destination Connection ID field for the observed
packet, or that no applicable length was available. This is
significant for Short Header
packets, whose header does not carry an explicit
Destination Connection ID length.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the exporter based on the actual
mechanism used to determine the Destination Connection ID
length; the exporter MUST report the actual source used.
Applicability: packet observations whose fixed Template includes
this IE. Values 1 through 3 apply when a Destination Connection ID
is semantically present: for Long Header packets, the explicit
length field is the source (value 1); for Short Header packets,
the length must come from learned connection context or management
configuration (values 2 and 3). Value 0 applies when the packet has
no semantic Destination Connection ID field. Value 4 applies when
a field may exist but its length cannot be determined.
Scope: one value per packet observation that includes this
IE. Aggregation: not aggregated. Range: 0 to 254; value 255 is
Reserved and MUST NOT be exported. Assigned values are maintained
in the
. Value
assignments: 0 = Not applicable because no Destination
Connection ID is semantically present; 1 = Explicit Long
Header length field; 2 = Learned connection context,
including a peer-issued Connection ID associated with the
applicable connection and direction; 3 = Management
configuration; 4 = Unknown because the length could not be
determined. When value 0 or 4 is reported, the
quicDestinationConnectionId presence bit is clear and a
fixed Template carries an empty ignored placeholder. When a
present Destination Connection ID has zero length, the
presence bit is set even though its octetArray is empty,
and this IE reports the applicable source value 1, 2, or 3.
Reference:
[this document]
Name:
quicToken
ElementID:
TBD20
Description:
The raw Token octets carried in a type-specific field of a
supported-version Long Header packet, as present on the
wire. For QUIC version 1, this is the Token following the
Token Length field of an Initial packet or the Retry Token
preceding the Retry Integrity Tag. The content is opaque
observational evidence; this IE does not assert that the
Token is valid.
Abstract Data Type:
octetArray
Data Type Semantics:
default
Additional Information:
Derivation: read directly from the wire according to the
packet format of the supported QUIC version; no QUIC
payload decryption is required. Applicability for QUIC
versions 1 and 2: Initial and Retry packets only. Version
Negotiation, 0-RTT, Handshake, and Short Header packets do
not carry this field. Scope: one value per packet
observation. Aggregation: not aggregated. Length: for an
Initial packet, the value has the length encoded by Token
Length and that length MUST NOT exceed the bytes remaining
in the delimited packet; for a Retry packet, the value
occupies the bytes after the Source Connection ID and before
the version-defined 16-octet Retry Integrity Tag. These
rules MUST NOT be applied to an unknown future version.
When the field is present, including an Initial Token whose
encoded length is zero, the quicToken presence bit is set;
a present zero-length Token is encoded as an empty
octetArray. For packet types without the field, or when its
complete extent cannot be established because the version
is unsupported, capture is truncated, the packet is
malformed, or local export limits prevent complete export,
the bit is clear and a fixed Template carries an empty
ignored placeholder. quicProcessingStatus reports protocol or
capture failure; quicExportFlags reports a local export limit.
See Sections 17.2.2 and 17.2.5 of
.
Reference:
[this document]
Name:
quicFieldPresence
ElementID:
TBD21
Description:
A bitmap that identifies which accompanying optional QUIC
fields in the same Data Record are semantically present. It
distinguishes an absent or unavailable field from a valid
zero numeric value or zero-length value encoded in a fixed
Template.
Abstract Data Type:
unsigned32
Data Type Semantics:
flags
Additional Information:
Derivation: set by the exporter for the particular Data
Record. Applicability and scope: the bits apply only to the
corresponding fields in that same Data Record, including a
frame child record when used there. Aggregation: not
aggregated. Range: the following masks are assigned in the
:
0x00000001 = quicVersion; 0x00000002 =
quicSupportedVersion; 0x00000004 =
quicDestinationConnectionId; 0x00000008 =
quicSourceConnectionId; 0x00000010 = quicToken;
0x00000020 = quicStreamId; 0x00000040 =
quicPacketDeltaCount; 0x00000080 = quicPacketLength.
Masks 0x00000100 through 0x80000000 are unassigned. An
exporter MUST set an assigned bit only when the
corresponding IE occurs in the same record and carries a
semantically present complete value. When an assigned bit
is clear and a fixed Template contains that IE, the
exporter encodes zero for a numeric IE, an empty
octetArray, or an empty list, as applicable, and the
collector MUST ignore that placeholder. When the bit is
set, zero or an empty value is the actual value. Exporters
MUST set unassigned bits to zero; collectors MUST ignore
bits they do not recognize so that future assignments
remain interoperable.
Reference:
[this document]
Name:
quicDatagramParseStatus
ElementID:
TBD22
Description:
Identifies whether a parent datagram record in the Network-Wire
Observation Profile or sampled Endpoint Packet Observation
Profile completely enumerated and delimited the QUIC packets in
the enclosing UDP payload and, if not, why packet-boundary
enumeration stopped.
Abstract Data Type:
unsigned8
Data Type Semantics:
identifier
Additional Information:
Derivation: assigned by the exporter after processing one
UDP payload. Applicability and scope: one value on the
parent datagram record of the Network-Wire Observation Profile or
sampled Endpoint Packet Observation Profile. Aggregation: not
aggregated. Range: 0 to 254; value 255
is Reserved and MUST NOT be exported. Assigned values are
maintained in the
. Value
assignments: 0 = Unknown or not reported; 1 = Complete,
meaning every octet of the UDP payload was accounted for by
completely delimited QUIC packets; 2 = Partial because an
unsupported QUIC version prevented determination of a
packet boundary; 3 = Partial because capture truncation prevented
complete packet-boundary enumeration; 4 = Partial because
malformed input prevented complete
packet-boundary enumeration; 5 =
Partial because a local parser or processing-resource limit
prevented complete packet-boundary enumeration. A child packet
record normally represents a completely delimited packet. As the
sole exception, the Network-Wire Observation Profile permits an
exporter to emit one terminal partial child record at the offset
where parsing stopped when the packet's complete invariant Long
Header prefix was captured but an unsupported version prevents
boundary determination. In that record the
quicPacketLength presence bit is clear, fields beyond the invariant
prefix are absent, and quicProcessingStatus reports the unsupported
version. No child record after that offset can be inferred. This IE
describes completeness of packet-boundary enumeration, regardless
of whether all parsed child records were exported. Export omission
is reported by quicExportFlags. This IE
does not report cryptographic validation of
individual packets, which is reported by
quicProcessingStatus.
Reference:
[this document]
Name:
quicPacketLength
ElementID:
TBD23
Description:
The total wire length, in octets, of one completely
delimited QUIC packet, from its first header octet through
its final octet. It excludes the enclosing UDP and IP
headers.
Abstract Data Type:
unsigned32
Data Type Semantics:
quantity
Units:
octets
Additional Information:
Derivation: computed from packet boundaries determined under
the applicable supported QUIC version and available
connection context. For a confirmed Stateless Reset, the
boundary is the entire UDP payload as specified in Section
10.3 of . Applicability and scope: one value per
completely delimited packet in the Network-Wire or Endpoint
Packet Observation Profile. Aggregation: not aggregated.
Range: 1 to 2^32-1. For packet formats with an explicit
Length field, the exporter applies the length rules of the
supported version. A Version Negotiation packet, a Retry
packet, or a Short Header packet occupies the applicable
remainder of its UDP payload under the version's packet
coalescing rules. An exporter MUST NOT apply these rules to
an unknown future version. When the complete boundary cannot
be determined, the quicPacketLength bit in quicFieldPresence
is clear and a fixed Template carries zero as an ignored
placeholder; the appropriate processing or datagram parse
status reports the reason. When the packet length is otherwise
available but local export policy or a resource limit prevents
its export, the presence bit is clear and quicExportFlags reports
that independent export outcome. A zero value is never a present
packet length.
Reference:
[this document]
Name:
quicExportFlags
ElementID:
TBD24
Description:
Flags reporting whether otherwise available QUIC information
in the same record or a child list directly carried by that record
was not exported because of a local resource or size limit in the
export path, configured export-policy suppression, or both.
Abstract Data Type:
unsigned8
Data Type Semantics:
flags
Additional Information:
Derivation: assigned by the exporter from conditions in its local
export path. Applicability and scope: one value per top-level
record in every profile defined by this document. Network-Wire
and sampled Endpoint inner-packet records also carry this IE for
omissions scoped to that packet. A value in a record describes omissions from fields
in that record and from child lists directly carried by it.
Aggregation: not aggregated. A zero value means that export was
complete under the applicable profile. Bit 0 (mask 0x01) means
that a local export-resource, representation-size, or record-size
limit prevented complete export. Bit 1 (mask 0x02) means that
configured export policy suppressed otherwise available
information. The bits can be set together. Bits 2 through 7 are
unassigned; exporters MUST set them to zero, and collectors MUST
ignore bits they do not recognize. Assignments are maintained in
the . If an affected field
has a quicFieldPresence bit, that bit is clear and its fixed-
Template placeholder is ignored. If a child list is affected,
this IE is set in the record containing that list. A complete
Network-Wire parse followed by export truncation or policy
suppression therefore has quicDatagramParseStatus 1 and a nonzero
quicExportFlags value. This IE reports an export outcome;
it does not replace quicObservationSource or
quicProcessingStatus.
Reference:
[this document]
In accordance with Section 4.7 of , IANA is
requested to create the following subregistries under the "IPFIX
Information Elements" registry. An enumeration registry has Value,
Name, and Reference columns. A flags registry has Bit, Mask, Name (or
Accompanying Information Element), and Reference columns. Only entries
or bit positions marked Unassigned are available for future assignment;
each such assignment requires Expert Review as defined by
and a stable public reference. An entry marked
Reserved is not available under that policy. The designated experts are
requested to verify that a new assignment has a stable, interoperable
meaning, does not duplicate an existing value, and, where it interprets
a QUIC protocol construct, is supported by an appropriate QUIC
specification. The initial assigned and Reserved entries below have
this document as their reference; two hyphens identify an Unassigned
range that has no reference.
An exporter MUST NOT emit an enumeration value marked Unassigned or
Reserved. A collector that does not yet recognize a subsequently
assigned value MUST preserve its numeric value and MUST NOT reinterpret
it as the registry's Unknown value.
A Short Header does not encode its Destination Connection ID length.
Therefore, an exporter can report a Short Header Destination Connection ID
only when it has already associated the packet with a connection and knows
the length selected by the receiving endpoint. During connection
establishment, a peer's Source Connection ID can supply a Connection ID that
the other peer subsequently uses as a Destination Connection ID, but an
exporter MUST establish the applicable connection and direction before using
that information. It MUST NOT treat an arbitrary prior Long Header
Destination Connection ID as the length context for a later Short Header.
Connection ID rotation can introduce values in protected NEW_CONNECTION_ID
frames, so following later rotations generally requires endpoint protocol
state, the applicable traffic keys, or deployment configuration. If the
exporter lacks reliable connection and length context, it MUST clear the
Destination Connection ID presence bit and MUST NOT guess the value.
Availability of QUIC fields depends on packet type and processing context.
Version Negotiation packets have neither packet protection nor header
protection. Retry packets also have neither packet protection nor header
protection and carry no packet number; their version-specific Retry
Integrity Tag is a separate integrity mechanism. Initial packets use packet
protection and header protection, but for QUIC versions 1 and 2 the keys are
derived from public version-specific constants and the Destination Connection
ID of the client's Initial packet. Consequently, a passive observer can
process a supported-version Initial packet when it has that Destination
Connection ID, direction and packet-number context, and sufficient captured
bytes. Successful Initial processing does not authenticate the peer and does
not provide confidentiality from an on-path observer. Processing Handshake,
0-RTT, and 1-RTT packets requires the corresponding traffic secrets or keys
derived from them. A Stateless Reset has no semantic packet number or frame
sequence.
quicFirstOctet is available only when the first packet octet was captured.
quicVersion and the two Connection ID length fields are invariant only in a
sufficiently complete Long Header . A Short Header
Destination Connection ID requires the connection-specific length context
described above. quicPacketType requires the applicable version-specific
mapping, except that a zero Long Header Version field identifies Version
Negotiation. An exporter MUST classify a Short Header as Unknown unless
endpoint state or successful packet-protection processing establishes 1-RTT,
and it
MUST classify a possible Stateless Reset as Unknown unless the entire UDP
datagram satisfies the token-matching procedure in Section 10.3.1 of
. A confirmed Stateless Reset consumes the entire
datagram and has no semantic Destination Connection ID, Source Connection
ID, Version, packet number, or frame sequence.
In a successfully processed supported-version Initial packet, a passive
observer can reconstruct quicPacketNumber and decode permitted Initial frame
types, offsets, and lengths. Valid Initial packets do not carry stream-related
frames, so Initial processing does not make quicStreamId available. Values
from other protected packets require endpoint protocol state or the
corresponding traffic keys. An endpoint can also export sender-side semantic
values from protocol state before wire protection is applied; such values are
not raw observations and MUST be marked with the corresponding
quicObservationSource and quicProcessingStatus.
quicObservationSource records where exported semantic values originated, and
quicProcessingStatus records the processing result. The two IEs are
independent and neither is an ordered confidence score. Exporters MUST
preserve failure outcomes such as unsupported version, malformed input,
capture truncation, packet-protection failure, and Retry Integrity Tag
failure instead of reporting them as successful lower-level processing. A
device that receives traffic secrets through a deployment-specific mechanism
MUST protect them and MUST NOT log or export them in IPFIX records, as noted
in .
IANA, "IP Flow Information Export (IPFIX) Entities"Manageability of the QUIC Transport ProtocolInformation and Data Models for Packet Discard ReportingInformation Element for Flow Discard ClassificationAcknowledgementsThe authors would like to thank Mohamed Boucadair, Benoit Claise, Chongfeng Xie, Jing Wang, Yarong Wang, Yanrong Liang,
Winnie, Saumya Dikshit, Wisdom Tan, Jiangbo Wang, Bing Liu, Xueyan Song, Xiao Min, Gao Xing, Liyan Gong, David Wright,
Yujia Gao, Qian Cao, Alex Lee, Shengnan Yue, Yimi Zhang, Guozhen Dong, Hongwei Li, Allan Michael,
JunFang Wang, Paul Aitken, Haiyang Zhang, and Liurubing for their support and detailed reviews.