Summary

  • An OPSAWG draft proposes seven IPFIX Information Elements for QUIC headers, packet numbers, frame types and stream IDs. The identifiers remain TBD in revision 00, and protected values require successful decryption.
  • The draft expressly uses the IPFIX meaning of a flow, not a QUIC connection. Five-tuples can change, connection IDs can rotate or disappear, and passive observers cannot follow every intentional migration.
  • Daniel Kade proposes field-level observation provenance: record where and how each value was obtained, what decryption authority existed, what was missed and which conclusion the field may support. This is an editorial control, not an IETF requirement.

The first row arrived from a border router. It carried a five-tuple, a QUIC version, two connection IDs and a header flag. The second arrived from a service endpoint. It carried a packet number, a frame type and a stream ID. The collector rendered both rows with the same typeface, the same timestamp precision and the same green status.

That visual equality was false.

The router had observed selected features of a wire image. The endpoint had opened cryptographically protected material as a participant in the connection. One record described packets grouped at an Observation Point. The other disclosed facts from inside an endpoint's transport state. Joining them may be useful, but the join is a hypothesis until its provenance and identity rules are preserved.

A young draft with seven proposed fields

draft-ietf-opsawg-ipfix-quic-header-00 became an OPSAWG working-group document in September 2026. It has no intended RFC status, document shepherd, responsible Area Director or telechat recorded. It remains an Internet-Draft at the earliest working-group state, not an approved standard or an IANA allocation.

Revision 00 proposes seven Information Elements: quicHeaderFlag, quicVersion, quicDestinationConnectionID, quicSourceConnectionID, quicPacketNumber, quicFrameType and quicStreamID. Their proposed Element IDs are still TBD1 through TBD7. That procedural boundary matters. A prototype can test names and semantics; an operator cannot honestly report that the global registry already guarantees them.

The proposal addresses a real manageability gap. QUIC carries packets in UDP and protects almost all transport detail that traditional network devices learned to inspect in TCP. Common Information Elements could let exporters describe the part of QUIC they actually know without each vendor inventing an incompatible vocabulary.

The phrase “actually know” carries the burden.

One list contains several observation powers

The draft divides the fields even when their rows later look alike. The version and the source and destination connection IDs in a long header are visible on the path. Portions of the first header byte are visible too, while other bits are protected. A short header carries a destination connection ID without its length; an intermediate device must already know or be configured with the length before it can parse that field reliably.

Packet number, frame type and stream ID are protected. RFC 9001 explains that packet numbers and parts of the first byte receive header protection, while frame content sits inside the protected payload. Revision 00 therefore places these values at endpoints or at devices able to decrypt QUIC packets.

Even “decrypted” is not one category. RFC 9312 notes that an on-path observer can derive the Initial secrets for a known QUIC version from the client's initial destination connection ID. That makes Initial payloads observable to a suitably equipped monitor. Handshake and 1-RTT packets use keys established by the endpoints. A record derived from public Initial-secret mechanics does not prove access to endpoint traffic secrets, and an endpoint-derived stream ID does not prove that a border sensor could reproduce it.

The first byte needs the same care. Exporting an eight-bit quicHeaderFlag value can tempt a collector to treat every bit as a direct wire observation. Yet some bits are protected. The row needs to say whether it contains raw visible bits, a value after header-protection removal, a mask, or a vendor-normalised interpretation. A standard name cannot answer that question after the acquisition history has been discarded.

IPFIX already names the first boundary

RFC 7011 defines a flow as a set of packets or frames passing an Observation Point during an interval and sharing properties. A Flow Record contains measured and characteristic properties of that observed flow. The QUIC draft expressly says that its use of “flow” follows IPFIX, not QUIC.

This is not legalistic wording. It prevents an ontology error.

An Observation Point may be a router port, a probe, a logical interface or a broader set of interfaces. Its Observation Domain identifier is locally unique to an Exporting Process. The Metering Process decides how packets become records; the Exporting Process sends them; the Collecting Process interprets them. Each stage can change the evidence surface without changing the familiar column name.

A QUIC connection, by contrast, is endpoint state. It can use several paths and packet-number spaces, contain many streams and survive address changes. A record of packets sharing a five-tuple at one Observation Point is not automatically that object. Nor does a collector create the missing object merely by adding a destination connection ID.

Connection IDs are routing handles, not durable identities

RFC 9000 lets each endpoint issue connection IDs for packets sent toward it. Several can be active at once. An endpoint can ask its peer to retire old IDs and supply replacements; a peer can change which active ID it uses. Zero-length IDs are also possible when the deployment does not need them for routing.

This design allows a connection to survive NAT rebinding or migration without binding its identity to one five-tuple. It also deliberately resists unwanted linkability. RFC 9312 gives both warnings an operator needs: a new connection ID does not necessarily mean a new connection, and the same connection ID on a different five-tuple does not necessarily establish continuity. Intentional migration is accompanied by a connection-ID change that a passive observer cannot link from the wire image alone.

The inverse problem exists too. Multiple QUIC connections can share an address and port pair when non-zero connection IDs distinguish them. A collector that groups only by five-tuple can merge separate connections. A collector that groups rigidly by connection ID can split one connection at rotation. A collector that assumes every cross-tuple repeat proves migration can join unrelated traffic.

These are not failures of connection IDs. They are failures to respect what the identifiers were designed to control. A routing handle can be excellent at steering a packet and still be unsuitable as a permanent audit key.

Protected fields move the institutional boundary

An endpoint exporter has knowledge an intermediate router was intentionally denied. That may be the right design: the endpoint can provide operational visibility without distributing traffic keys to the network. But once protected frame or stream information leaves the endpoint in IPFIX, the disclosure boundary has moved.

The relevant question is not only whether the IPFIX transport was encrypted. RFC 7011 requires confidentiality, integrity and authentication mechanisms and warns that collected flow data can be personally identifiable and privacy-sensitive. Transport protection is necessary, but it does not decide which collector, tenant, analyst or automated system should receive endpoint-derived stream metadata, how long it should persist, or whether it may be joined across paths.

A packet number is used in the cryptographic nonce construction. A frame type exposes transport behaviour. A stream ID identifies a stream only within a connection and encodes initiator and directionality in its low bits. None is application payload, yet their combination can reveal timing and structure unavailable to a passive path observer. Calling the fields “telemetry” does not return them to the public wire image.

The acquisition authority therefore belongs in the record. “Endpoint decrypted” should identify the exporting endpoint role and approved purpose. “Initial derived” should remain distinct. “Configured match” for a short-header connection ID should name the configuration version. “Inferred” should never be rendered as if it were measured.

A populated cell is not completeness evidence

The draft's use cases ask whether all QUIC packets were fully received and which frame or stream was observed. IPFIX can help answer bounded versions of those questions, but the collector must retain what the exporter was capable of seeing.

RFC 7011's Sequence Number counts Data Records sent within an export stream and Observation Domain. A discontinuity can tell the collector that IPFIX records were missed. It cannot name QUIC packets that the Observation Point never saw, packets excluded by sampling, records suppressed by metering policy, or protected fields the exporter could not derive. Absence has several layers.

Templates add another. A Data Record is interpreted through a Template Record. If the template changed, expired or was missed, identical bytes can be undecodable or misread. Export time is not packet capture time. Observation Domain is not a global site ID. A collector transformation is not the original measurement. Flattening these facts into one warehouse row produces a cleaner schema and a weaker claim.

Completeness should be stated relative to a named scope: all Data Records received from exporter E for domain D and sequence interval S; all packets observed at point P under metering profile M; all protected fields successfully opened by endpoint role R. “Complete connection” requires more evidence and may remain unknowable to that system.

Attach provenance to every proposed element

A field-level observation provenance record can preserve these limits without changing the seven proposed Information Elements. It belongs beside the measurement, not inside an invented universal connection object.

For each value, record the exporter identity, Observation Domain and exact Observation Point; packet capture and export times; direction, five-tuple, packet form and version; Information Element and template identity; raw value or explicit absence; and one acquisition class: wire-visible, configured match, Initial-secret derived, endpoint decrypted or inferred.

Protected observations need the endpoint role and authorisation that allowed decryption, but never exported secret keys. Connection-ID observations need the parsed length and how that length was known, which endpoint issued the ID, the direction in which it appeared and whether rotation or retirement state was visible. Packet numbers need their number space. Frame and stream fields need the packet occurrence that carried them, because a list of types is not an ordered transcript.

Then preserve metering and sampling policy, packet and export-record loss indicators, Sequence Number discontinuities, template revision and collector transformations. Finally, name permitted consumers, retention, aggregation, the decision for which the value is fit, residual uncertainty and the owner who can close or expire the inference.

This record is Daniel Kade's editorial proposal. Revision 00 does not require it. Its purpose is modest: keep a correct field from acquiring authority it never had merely because several correct fields share a row.

Use a ladder of public claims

Operational language should rise only as high as the evidence.

“Long-header version observed at point P” is a wire claim. “Short-header destination ID parsed using configuration C” is a configured claim. “Initial frame type recovered using version-derived Initial secrets” is a cryptographic acquisition claim. “Stream ID exported by server endpoint E” is an endpoint claim. “These flows belong to one connection” is a correlation conclusion. “The connection was complete” is a stronger coverage conclusion.

No phrase needs to be weakened. It needs to be placed on the right rung.

Standard Information Elements are valuable precisely because they let different exporters speak about comparable properties. Their success should not be measured by how quickly a dashboard erases the difference between observation and reconstruction. It should be measured by whether an operator can compare fields without losing who was capable of seeing each one.

Sources