Zusammenfassung

  • draft-ietf-opsawg-ipfix-quic-header-00 schlägt sieben IPFIX Information Elements für QUIC-Header, Connection IDs, Packet Number, Frame Type und Stream ID vor; die drei geschützten Felder erfordern Entschlüsselung.
  • Ein befülltes Feld belegt nur, was ein bestimmter Exporter unter einer bestimmten Konfiguration gewonnen hat. Es belegt weder die vollständige Verbindungsidentität noch befugte Schlüsselnutzung, Migrationskontinuität oder Anwendungsverarbeitung.

Im Collector steht eine saubere Zeile: Fünf-Tupel, Destination Connection ID, Packet Number und Stream ID. Die Spalten tragen präzise Namen, die Übertragung meldet Erfolg. Form und Ordnung verleiten dazu, die Zeile als Verbindungsprotokoll zu behandeln.

Sie ist ein Protokoll eines Beobachtungsvorgangs.

Der am 10. September veröffentlichte OPSAWG-Arbeitsgruppenentwurf nennt quicHeaderFlag, quicVersion, quicDestinationConnectionID, quicSourceConnectionID, quicPacketNumber, quicFrameType und quicStreamID. Flags, Version und Connection IDs aus langen Headern enthalten auf der Leitung sichtbares Material. Packet Number, Frame Type und Stream ID sind geschützt und nur an Endpunkten oder auf Geräten verfügbar, die QUIC erfolgreich entschlüsseln können.

Auch Sichtbarkeit braucht Kontext. Ein kurzer QUIC-Header überträgt die Länge seiner Destination Connection ID nicht. Ein zwischengeschalteter Parser muss die ID oder ihre Länge vorher kennen. Ist die Konfiguration veraltet oder für anderen Verkehr bestimmt, kann ein formal gültiger Wert auf falsch geschnittenen Bytes beruhen. Die Annahme gehört zur Provenienz, obwohl sie nicht im Feld steht.

Eine weitere Grenze setzt der Begriff Flow. Der Entwurf betont, dass er die IPFIX-Definition und keine QUIC-eigene verwendet. RFC 7011 beschreibt einen Flow als Pakete oder Frames, die während eines Zeitraums einen Observation Point passieren und gemeinsame Eigenschaften haben. Der Metering Process darf auswählen, sampeln, klassifizieren und Eigenschaften ableiten, bevor ein Flow Record entsteht. Das Ergebnis beschreibt diesen konfigurierten Messvorgang, nicht automatisch den gesamten Verkehr zwischen zwei QUIC-Endpunkten.

QUIC trennt Verbindung und Fünf-Tupel bewusst. Nach einer Adress- oder Portänderung kann die Verbindung fortbestehen. Endpunkte vergeben mehrere Connection IDs, wechseln sie aus und ziehen sie zurück. Eine Verbindung kann daher unter verschiedenen Tupeln erscheinen. Gleichzeitig ist eine Connection ID nur im Kontext des ausgebenden Endpunkts sinnvoll, keine weltweite Kennung für Nutzer oder Gerät. Das Zusammenführen über Wechsel hinweg ist eine eigene analytische Handlung.

Auch Packet Numbers sind nicht global fortlaufend. QUIC führt getrennte Nummernräume für Initial, Handshake und Application Data; zudem zählt die Richtung. Eine Lücke kann Paketverlust bedeuten. Sie kann aber ebenso durch Sampling, einen zweiten Pfad, verspäteten Beobachtungsbeginn, fehlende Schlüssel oder verworfene Data Records beim Export entstehen. RFC 7011 erlaubt Auswahl und beschreibt Verlust im Exportpuffer. Zwei vorhandene Nachbarn beweisen keine lückenlose Mitte.

Frame Type benennt eine Grammatik, nachdem der Paketschutz entfernt wurde. Daraus folgt weder, dass alle typspezifischen Felder erfasst wurden, noch dass der Peer sie verarbeitet oder die Anwendung gehandelt hat. Eine Stream ID ist nur innerhalb ihrer Verbindung eindeutig. Ohne bestätigten Verbindungskontext und Endpunktabgleich benennt sie keine dauerhafte Anfrage oder Transaktion.

Entschlüsselungsfähigkeit ist außerdem von Entschlüsselungsbefugnis zu trennen. Korrekt entfernter Schutz authentisiert das Paket im betreffenden Schlüsselkontext. Er sagt nicht, wer die Schlüsselhaltung genehmigte, welche Felder offengelegt werden dürfen, welcher Collector sie wie lange speichern darf oder welche Automatisierung sie verwenden darf. Technische Möglichkeit ist kein Governance-Beleg.

Die Security Considerations der Revision 00 nennen gegenüber RFC 7012 keine zusätzlichen Punkte. Das hebt die IPFIX-Risiken nicht auf. RFC 7011 behandelt Authentisierung von Exporter und Collector, Integrität, Verkehrsvertraulichkeit, Privatsphäre sowie falsche Nachrichten und Templates. Diese Kontrollen umgeben den Information Element-Wert; der Wert beweist sie nicht.

Eine belastbare Beweiskette hält Observation Point und Domain, Exporter-Identität, Parser-Version, Annahme zur CID-Länge, Filter und Sampling, Entschlüsselungskontext und Befugnis, Template-Version, Packet-Number-Raum, Exportverlust, Collector und Aufbewahrung fest. Danach protokolliert sie jede Verknüpfung von Tupeln, Connection IDs und Streams und prüft sie gegen Endpunkt- und Anwendungsdaten.

Diese Abgrenzung spricht nicht gegen die Standardisierung. Gemeinsame Information Elements können proprietäre Schemata ersetzen und begrenzte Beobachtungen zwischen Werkzeugen transportieren. Der aktuelle Text bleibt aber ein Internet-Draft in Revision 00 mit Datatracker-Status I-D Exists. Daraus folgen weder RFC-Status noch Verbreitung oder Produktionsnutzen.

Für Führungskräfte lautet die Regel: Der Exporter darf für seine Beobachtung sprechen, nicht für das ungesehene Ganze. Verbindungskontinuität, Stream-Zustellung, Anwendungsverarbeitung und Geschäftsergebnis müssen in späteren Schichten jeweils neu belegt werden.

Quellen