Zusammenfassung

  • Die am 28. September aktualisierte Revision 01 ist ein aktiver OPSAWG-Internet-Draft mit IESG-Status I-D Exists, kein RFC mit bereits vergebenen neuen IPFIX-Kennungen.
  • Vier getrennte Zustände beschreiben künftig, ob die Datagrammgrenzen bekannt sind, wie ein Paket verarbeitet wurde, ob ein Feld tatsächlich präsent ist und ob lokal verfügbare Angaben beim Export fehlten.

In Betriebsprotokollen führt eine leere Spalte leicht zu einer eindeutigen Aussage: Das Merkmal war nicht da. Doch der Weg vom Paket zur Tabelle hat mehrere Stellen, an denen Information verloren gehen kann. Ein Sensor kennt die Grenze eines späteren QUIC-Pakets möglicherweise nicht, eine Aufnahme kann abgeschnitten sein, ein Parser an fehlerhaften Bytes scheitern oder eine lokale Richtlinie einen bereits ermittelten Wert nicht ausgeben. Wer nur das Endfeld betrachtet, verwechselt die Messgrenze mit einer Eigenschaft des Verkehrs.

draft-ietf-opsawg-ipfix-quic-header-01 erweitert die frühere Vorlage erheblich. Revision 00 schlug sieben QUIC-spezifische Information Elements vor. Revision 01 beschreibt 24 vorgeschlagene Elemente und vier Exportprofile: passive Beobachtung am Netz, Paketbeobachtung am Endpunkt, Flow-Aggregat und optionaler Verbindungszustand. Das Netzprofil legt seine Zähleinheit genau fest. Ein nicht fragmentiertes IP-Paket mit einem vollständigen UDP-Datagramm erzeugt einen übergeordneten Datensatz. Mehrere darin zusammengefasste QUIC-Pakete, deren Grenzen erkennbar sind, erscheinen als geordnete Kindeinträge mit Offset. Ihre Herkunft aus demselben Datagramm darf beim Export nicht verschwinden.

Neu ist vor allem die Unterscheidung der Ursachen. quicDatagramParseStatus betrifft die Frage, ob alle inneren Paketgrenzen bestimmt werden konnten. quicProcessingStatus beschreibt die Verarbeitung eines konkreten QUIC-Pakets. quicExportFlags steht für eine andere Art von Lücke: lokal unterdrückte oder aufgrund von Größen- und Ressourcenlimits abgeschnittene, sonst verfügbare Angaben. Die Zustände sind keine aufsteigende Vertrauensskala. Eine vollständige Grenzbestimmung kann mit einem problematischen Kindpaket zusammentreffen. Ebenso kann die Analyse fertig sein, während eine lokale Exportregel Werte entfernt.

Bei festen IPFIX-Templates muss ein codierter Platz auch dann vorhanden sein, wenn ein Feld in der Beobachtung keinen sinnvollen Wert hat. quicFieldPresence entscheidet, ob eine Null oder leere Bytefolge als tatsächlicher Wert gilt oder nur als Platzhalter, den der Empfänger ignorieren muss. Eine Null-Länge kann also real sein; derselbe sichtbare Eintrag kann auch „nicht verfügbar“ bedeuten. Das Präsenzbit löst eine Auslegungsfrage, nicht die Authentizität der Paketquelle.

Besonders heikel ist eine nicht unterstützte QUIC-Version. Aus invarianten Feldern lässt sich die nächste Paketgrenze nicht immer ableiten. Frühere sauber abgegrenzte Pakete dürfen erhalten bleiben; an der Stoppstelle kann eine partielle Beobachtung stehen. Spätere koaleszierte Pakete deshalb für abwesend zu erklären, verbietet der Entwurf. Paketnummern, Frame-Typen und Stream-IDs gehören ohnehin nicht zum Netzprofil. Dass sie dort fehlen, ist kein Urteil über ihren Inhalt auf dem Draht.

Die vorgeschlagenen Nummern sind noch nicht von IANA endgültig zugeteilt. Der Text belegt weder Implementierungen noch eine neue Sicherheitsvorfallserie. Er beschreibt, welche unterschiedlichen Grenzen ein künftiger Export präzise sichtbar machen könnte.

Quellen