Zusammenfassung

  • Ein OPSAWG-Entwurf schlägt sieben IPFIX Information Elements für QUIC-Header, Paketnummern, Frame-Typen und Stream IDs vor. In Revision 00 sind die Elementnummern noch TBD; geschützte Werte setzen erfolgreiche Entschlüsselung voraus.
  • Der Entwurf verwendet ausdrücklich den Flow-Begriff von IPFIX, nicht den Zustand einer QUIC-Verbindung. Fünf-Tupel ändern sich, Connection IDs rotieren, und absichtliche Migration ist passiv nicht lückenlos verknüpfbar.
  • Daniel Kade schlägt feldgenaue Beobachtungsprovenienz vor: Ort, Gewinnungsmethode, Entschlüsselungsbefugnis, mögliche Lücken und zulässige Schlussfolgerung. Das ist eine redaktionelle Governance-Idee, keine IETF-Vorgabe.

Ein einheitliches Datenmodell löst ein praktisches Problem. Betreiber müssen nicht mehr für jeden Hersteller lernen, wie er eine QUIC-Version oder Connection ID nennt. Der Collector kann Typen prüfen und Datensätze gemeinsam auswerten.

Die Vereinheitlichung entfernt jedoch leicht die wichtigste Differenz: Manche Werte standen im sichtbaren Wire Image. Andere wurden mithilfe lokaler Konfiguration ausgeschnitten. Wieder andere kamen erst hinter der kryptografischen Grenze am Endpoint zum Vorschein.

Wenn die Herkunft nicht mitwandert, sieht der Datensatz vollständiger aus als die Beobachtung.

Der Vorschlag ist noch keine Registry

draft-ietf-opsawg-ipfix-quic-header-00 wurde im September 2026 zum OPSAWG Working Group Document. Datatracker nennt WG Document und I-D Exists, aber noch keinen vorgesehenen RFC-Status, Document Shepherd, verantwortlichen Area Director oder Telechat. Der Text ist ein frühes Internet-Draft.

Vorgesehen sind quicHeaderFlag, quicVersion, quicDestinationConnectionID, quicSourceConnectionID, quicPacketNumber, quicFrameType und quicStreamID. In Revision 00 tragen sie weiterhin die Kennungen TBD1 bis TBD7. Die IANA-Anforderung ist nicht mit einer abgeschlossenen Zuweisung gleichzusetzen.

Der betriebliche Anlass bleibt wichtig. QUIC schützt Transportdetails, die Zwischenstationen bei älteren Protokollen auswerteten. Gemeinsame Information Elements können unterschiedliche Messsysteme beschreiben lassen, was sie tatsächlich wissen. Dieses „tatsächlich“ muss überprüfbar bleiben.

Fünf Wege zu einer gefüllten Zelle

Long Header legen Version sowie Länge und Wert der Source und Destination Connection IDs offen. Im ersten Oktett sind manche Bits sichtbar, andere headergeschützt. Short Header enthalten die Destination Connection ID ohne Längenangabe. Ein Zwischengerät muss die Länge kennen oder vorkonfigurieren.

Damit kann quicDestinationConnectionID direkt aus einem Long Header gelesen oder mithilfe einer lokalen Längenregel ermittelt worden sein. Ohne die Konfigurationsversion lässt sich der zweite Befund später nicht sicher reproduzieren.

RFC 9001 schützt Paketnummer und Teile des ersten Oktetts; Frames befinden sich im geschützten Payload. Revision 00 ordnet Paketnummer, Frame-Typ und Stream ID daher Endpoints oder Geräten zu, die QUIC entschlüsseln können.

„Entschlüsseln“ ist keine einheitliche Befugnis. RFC 9312 beschreibt, dass ein On-Path-Beobachter Initial Secrets aus einer Versionskonstante und der ersten Destination Connection ID des Clients ableiten kann. Handshake- und 1-RTT-Schlüssel werden zwischen Endpoints aufgebaut. Wer Initial öffnet, besitzt nicht automatisch 1-RTT-Geheimnisse. Ein vom Server exportierter Stream ID ist für den Router nicht reproduzierbar.

Auch quicHeaderFlag braucht einen Herkunftshinweis. Enthält das Feld rohe sichtbare Bits, das Oktett nach Entfernung des Header-Schutzes, eine Maske oder eine normalisierte Klassifikation? Der acht Bit breite Datentyp entscheidet das nicht.

Sinnvoll sind deshalb mindestens fünf Klassen: wire-visible, configured-match, initial-secret-derived, endpoint-decrypted und inferred. Alle können einen Wert liefern; ihre Beweiskraft ist verschieden.

Ein IPFIX-Flow hat einen Beobachtungsort

RFC 7011 definiert einen Flow als Pakete oder Frames, die während eines Zeitraums einen Observation Point passieren und Eigenschaften teilen. Ein Flow Record beschreibt diese beobachtete Menge. Der QUIC-Entwurf stellt ausdrücklich klar, dass „flow“ dem IPFIX-Begriff folgt, nicht QUIC.

Der Observation Point kann Port, Sonde, logische Schnittstelle oder eine Schnittstellenmenge sein. Eine Observation Domain ID ist nur lokal je Exporting Process eindeutig. Der Metering Process bildet Records, der Exporter versendet sie, der Collector wendet Templates und Interpretation an. Ort und Verarbeitungskette gehören zur Aussage.

Eine QUIC-Verbindung ist Endpoint-Zustand. Sie kann mehrere Fünf-Tupel durchlaufen, viele Streams und mehrere Packet-Number-Spaces enthalten. Ein Sensor auf dem alten Pfad sieht den neuen nicht zwingend. Ein Endpoint kennt Schlüssel und Stream-Zustand, aber nicht jede Verwerfung im Netz. Die Perspektiven ergänzen sich, ohne identisch zu werden.

Connection IDs sind kontextuelle Routing-Griffe

RFC 9000 erlaubt mehrere aktive Connection IDs für eine Verbindung. Jeder Endpoint stellt dem Peer IDs für die Richtung zu sich bereit. Sie können ersetzt, stillgelegt und gewechselt werden. Unter bestimmten Bedingungen ist auch die Länge null zulässig.

So übersteht eine Verbindung NAT Rebinding oder Migration, ohne am Fünf-Tupel zu hängen. Zugleich wird Linkability begrenzt. RFC 9312 warnt: Eine neue ID beweist keine neue Verbindung; dieselbe ID auf einem anderen Fünf-Tupel beweist nicht immer Kontinuität. Absichtliche Migration geht mit einem ID-Wechsel einher, den ein passiver Beobachter gerade nicht allein verknüpfen soll.

Gruppierung nur nach Fünf-Tupel kann eine Verbindung teilen und mehrere zusammenwerfen. Gruppierung nur nach ID teilt bei Rotation. Jede Wiederholung pfadübergreifend als Migration zu deuten kann Fremdverkehr verbinden. Die Korrelation braucht eine begründete Methode und sichtbare Unsicherheit, keinen erfundenen globalen Schlüssel.

Endpoint-Telemetrie verschiebt die Offenlegungsgrenze

Ein Endpoint-Exporter kann geschützte Details gezielt liefern, ohne Traffic Secrets an Zwischenstationen zu verteilen. Das kann die sauberere Architektur sein. Sobald Paketnummern, Frame-Typen oder Stream IDs IPFIX verlassen, erhält der Collector aber Struktur, die passiv nicht sichtbar war.

RFC 7011 verlangt Mechanismen für Vertraulichkeit, Integrität und Authentisierung und bezeichnet Flow-Daten als potenziell personenbezogen und privacy-sensitiv. Ein geschützter Exportweg legt noch nicht fest, welcher Mandant, Analyst oder Automat die Endpoint-Daten lesen darf, wie lange sie bleiben und ob sie pfadübergreifend verknüpft werden.

Die Paketnummer wirkt an der kryptografischen Nonce mit. Der Frame-Typ offenbart Transportverhalten. Die Stream ID identifiziert einen Stream innerhalb der Verbindung und codiert Initiator und Richtung. Es ist kein Application Payload, aber zusammen entsteht ein neues Strukturwissen.

Endpoint-decrypted muss daher Rolle und genehmigten Zweck nennen. Initial-derived bleibt getrennt. Configured-match trägt die Konfigurationsversion. Inferred darf nicht wie gemessen aussehen. Geheimschlüssel gehören nie in die Provenienz.

Lücken entstehen vor und nach dem Export

Die IPFIX Sequence Number zählt gesendete Data Records je Exportstrom und Observation Domain. Ein Collector kann Sprünge, Duplikate oder Umordnung erkennen. Sie sagt nicht, welche QUIC-Pakete vor dem Observation Point verloren gingen, durch Sampling ausgeschlossen, vom Metering nicht erfasst oder nicht entschlüsselbar waren.

Templates sind ebenfalls Teil der Evidenz. Ein Data Record bekommt Bedeutung durch das passende Template Record. Geht das Template verloren oder ändert es sich, können empfangene Bytes uninterpretierbar werden. Export Time ist nicht Capture Time. Eine Collector-Normalisierung ist nicht der Rohwert.

Vollständigkeit braucht einen Genitiv: vollständig für von E in D während S gesendete Data Records; vollständig für von P unter Policy M beobachtete Pakete; vollständig für von Endpoint R empfangene und erfolgreich geöffnete Felder. Keine dieser Grenzen ist automatisch die gesamte Verbindung.

Feldgenaue Beobachtungsprovenienz

Ich schlage einen feldgenauen Beobachtungsprovenienz-Nachweis vor. Er ergänzt die sieben Elemente, statt ein universelles QUIC-Verbindungsobjekt zu erfinden.

Jeder Wert wird mit Exporter, Observation Domain und genauem Observation Point verbunden; mit Capture und Export Time; Richtung, Fünf-Tupel, Header Form und Version; Information Element, Template-Version, Rohwert oder expliziter Abwesenheit; sowie der Erwerbsklasse.

Geschützte Felder tragen Endpoint-Rolle und Entschlüsselungsbefugnis, nicht den Schlüssel. Connection IDs tragen Länge und deren Quelle, Aussteller, Richtung und sichtbare Grenzen von Rotation oder Retirement. Paketnummern erhalten den Space; Frames und Streams die konkrete Paketinstanz statt einer entordneten Liste.

Hinzu kommen Sampling- und Metering-Policy, Capture Loss, Export Suppression, Sequence-Number-Lücken, Template-Wechsel und Collector-Transformationen. Am Ende stehen zulässige Verbraucher, Retention, Aggregation, geeignete Entscheidung, Widerspruch, Owner und Ablauf.

Das ist Daniel Kades redaktioneller Vorschlag, keine Forderung von Revision 00, OPSAWG oder IANA. Er verhindert, dass ein korrektes Feld durch die Nachbarschaft anderer korrekter Felder eine ganze Verbindung beglaubigt.

Aussagen auf der richtigen Stufe

„Long-Header-Version an P gesehen“ ist eine Wire-Aussage. „Short-Header-ID mit Konfiguration C getrennt“ ist konfigurationsabhängig. „Initial-Frame durch ableitbares Secret geöffnet“ ist eine begrenzte kryptografische Aussage. „Stream ID von Server E exportiert“ ist Endpoint-Wissen. „Diese Flows gehören zu einer Verbindung“ bleibt eine Korrelation.

IPFIX macht Tatsachen vergleichbar. Gute Governance verhindert, dass Vergleichbarkeit mit Allwissen verwechselt wird.

Quellen