Zusammenfassung

  • Der Reflected Test Packet Control TLV für STAMP lässt den Sender Antwortlänge, Paketanzahl und Abstand vorgeben, verpflichtet den Reflektor aber zugleich zu Grenzen für MTU, Datenrate und gesamtes reflektiertes Volumen.
  • Dasselbe C-Flag kennzeichnet sowohl eine Begrenzung durch die Ausgangs-MTU als auch eine Begrenzung durch Rate oder Volumen. Die Paketlänge trennt grobe Fälle, bewahrt jedoch weder den genauen Grenzwert noch die Policy-Generation oder die Konsequenz für die Auswertung.

Der Sender forderte eine Folge von Testpaketen an und bekam genau eines zurück. Die Authentisierung war gültig, die Sequenznummer plausibel und das C-Flag gesetzt. Damit ist belegt, dass der Reflektor die Anforderung nicht unverändert ausführte. Nicht belegt ist, ob das Paket für die Ausgangsschnittstelle zu groß gewesen wäre, die gewünschte Rate eine lokale Schwelle überschritt oder ein Volumenbudget bereits ausgeschöpft war. Diese drei Erklärungen führen zu unterschiedlichen Schlussfolgerungen.

Das ist keine Kritik an einem sparsamen Protokollbit. Ein Bit soll keinen Konfigurationsbestand transportieren. Zum Governance-Problem wird seine Kürze erst dann, wenn Monitoring, Abrechnung oder eine spätere Prüfung das Bit als vollständigen Entscheidungsnachweis behandeln. Ein protokollgemäß geschützter Reflektor und ein wie angefordert ausgeführter Test sind nicht dasselbe Ereignis.

draft-ietf-ippm-asymmetrical-pkts-14 erweitert das Simple Two-Way Active Measurement Protocol, kurz STAMP, um asymmetrische Antworten. Im Grundmodell steht einem Testpaket eine reflektierte Antwort gegenüber, deren Größe daran gebunden ist. Der neue Reflected Test Packet Control TLV kann eine andere Antwortlänge, mehrere reflektierte Pakete und einen Abstand in Nanosekunden zwischen diesen Paketen verlangen. Damit lassen sich asymmetrische Anwendungen, Raten und Multicast-Situationen näher untersuchen. Zugleich kann eine kleine Anforderung deutlich mehr Ausgangsverkehr auslösen.

Die Spezifikation nimmt diese Verstärkungswirkung ernst. Ein unterstützender Session-Reflector muss Grenzen für die reflektierte Datenrate und das gesamte STAMP-Nutzlastvolumen setzen. Die Funktion muss administrativ steuerbar und standardmäßig ausgeschaltet sein. Der Schutz der Reflektoridentität ist erforderlich; authentisiertes STAMP beziehungsweise der HMAC TLV werden empfohlen. Beim Multicast beginnt die vorgesehene Nutzung vorsichtig, weil eine Anfrage viele Reflektoren erreichen kann.

Der Schutzmechanismus ist damit deutlich. Weniger deutlich ist die Beweiskette, die nach seinem Eingriff übrig bleibt.

Ein Flag steht für zwei Schutzpfade

Übersteigt die berechnete Antwortlänge die MTU der Ausgangsschnittstelle, setzt der Reflektor C und sendet genau eine Antwort in der zulässigen Größe. Überschreitet die Anforderung dagegen eine Grenze für Datenrate oder Gesamtvolumen, setzt er ebenfalls C und sendet eine einzelne Antwort in der ansonsten berechneten Länge. Der Sender kann deshalb anhand der tatsächlichen Länge häufig erkennen, ob die grobe Ursache bei der MTU oder bei einer Ressourcenregel lag.

Für eine betriebliche Rechenschaft reicht diese grobe Trennung nicht. Im Ressourcenpfad bleibt offen, ob Rate oder Volumen ausschlaggebend waren. Unbekannt bleiben Schwellenwert, Zeitfenster, Geltungsbereich und Priorität der Regel. Die Grenze könnte pro Sitzung, Quelladresse, Mandant, Schnittstelle oder Reflektor gelten. Auch die konkrete Konfigurationsgeneration, die im Entscheidungszeitpunkt aktiv war, reist nicht mit dem Paket.

Selbst der MTU-Pfad erklärt nicht alles. Die wirksame Größe kann von der gewählten Schnittstelle, der Route, zusätzlicher Kapselung oder einer Änderung zwischen Planung und Durchführung abhängen. Das Antwortpaket zeigt, was gesendet werden konnte. Es zeigt nicht zwingend, warum gerade dieser Grenzwert galt und ob er für den nächsten Lauf noch gilt.

Zwei Auswerter können C=1 sehen und trotzdem gegensätzliche Geschichten erzählen. Für den einen beweist die Antwort, dass der Ressourcenschutz ordnungsgemäß reagierte. Für den anderen ist sie ein gewöhnlicher Messpunkt für die Leistung des entfernten Pfads. Die erste Aussage kann richtig sein, während die zweite auf einem Versuch beruht, der in seiner vorgesehenen Form nie stattfand.

Eine begrenzte Antwort ist nicht der angeforderte Versuch

Wer zehn Pakete in kurzem Abstand anfordert und eines empfängt, hat möglicherweise Erreichbarkeit und eine funktionsfähige Reaktion unter Begrenzung beobachtet. Nicht beobachtet wurden zwangsläufig die Gleichmäßigkeit der Folge, Verluste zwischen ihren Elementen, das Verhalten einer Warteschlange unter der gewünschten Last oder die angestrebte Reflexionsrate. Der einzelne Laufzeitwert darf nicht stillschweigend als Stichprobe der geplanten Serie behandelt werden.

Dasselbe gilt für die Länge. Wird eine Antwort auf die MTU gekürzt, beweist das erfolgreiche kleinere Paket nicht, dass die ursprünglich verlangte Größe den Pfad passiert hätte. Bleibt die Länge gleich, fällt aber die Anzahl wegen einer Raten- oder Volumengrenze auf eins, belegt die Antwort nicht die Tragfähigkeit des gewünschten zeitlichen Musters. Der Schutz hat eine unabhängige Variable des Experiments verändert; also muss sich auch die Beschreibung des Ergebnisses ändern.

Ein brauchbares Messarchiv sollte mindestens zwischen „wie angefordert ausgeführt“, „unter Begrenzung ausgeführt“ und „keine Antwort“ unterscheiden. Für einen begrenzten Lauf gehört festgehalten, welche Dimension abwich: Länge, Anzahl, Intervall oder mehrere davon. So wird der spätere Nutzer nicht gezwungen, den Versuchsplan allein aus einem verbliebenen Paket zu rekonstruieren.

Auch der Sonderfall einer angeforderten Paketanzahl von null macht die Lücke sichtbar. Dafür ist keine Antwort vorgesehen; die Anfrage soll verworfen werden, wobei eine lokale Regel das Verhalten überschreiben kann. Soll ausdrücklich keine Rückantwort entstehen, ist Return Path No Reply die klarere Methode. Schweigen kann damit beabsichtigt, policybedingt oder durch Netzverlust entstanden sein. Ein nicht vorhandenes Paket kann seine Ursache nicht selbst erläutern.

Multicast vergrößert den unsichtbaren Nenner

Bei Unicast lässt sich die mögliche Verstärkung als Verhältnis zwischen einer Anfrage und einem Reflektor betrachten. Im Multicast kann dieselbe Anfrage mehrere Reflektoren mit unterschiedlichen Ausgangspfaden, Ressourcenständen und lokalen Grenzwerten erreichen. Einige liefern die ganze Folge, andere nur eine begrenzte Antwort, wieder andere schweigen. Das Ergebnis ist deshalb nicht nur eine Sammlung von Messwerten, sondern auch die Spur mehrerer unabhängiger Schutzentscheidungen.

Die vorsichtige Multicast-Aktivierung, die Trennung von Auswahl auf Layer 2 und Layer 3 sowie der Identitätsschutz sind in diesem Zusammenhang mehr als Sicherheitsdetails. Wenn der Sender nicht weiß, wie viele Reflektoren tatsächlich teilnahmeberechtigt waren und welche lokalen Regeln ihre Antworten beeinflussten, bleibt der Nenner einer Erfolgsquote ungesichert. Die Quote vermischt Erreichbarkeit, Gruppenmitgliedschaft, Policy und Schutzreaktion.

Drei Antworten bedeuten nicht zwingend, dass nur drei Reflektoren den Test empfangen haben. Vielleicht erreichte er zehn, von denen sieben ihn wegen lokaler Regeln verwarfen oder verkürzten. Unterschiedliche Paketgrößen müssen ebenso wenig nur auf verschiedene Pfade hinweisen; sie können aus abweichenden Konfigurationsgenerationen stammen. Mit jeder zusätzlichen Reflexionsstelle wächst der Wert eines lokalen, nachvollziehbaren Policy-Nachweises.

Dieser Nachweis gehört nicht vollständig ins öffentliche Paket. Genaue Schwellen und Ressourcenstände könnten selbst für Missbrauch wertvoll sein. Sinnvoller ist eine Trennung: Auf dem Draht bleibt das kompakte Signal, im geschützten Betriebsbereich entsteht eine Quittung, die Signal, Regel und Entscheidung miteinander verbindet.

Eine Herkunftsquittung für die Begrenzung

Eine nützliche Quittung ist kein vollständiger Konfigurationsexport. Sie enthält eine stabile Test- und Sitzungskennung, die geschützte Identität des Reflektors, Empfangs- und Sendezeit, die angeforderten Werte für Länge, Anzahl und Intervall sowie die tatsächlich gesendeten Werte. Dazu kommt eine Ursachenklasse: MTU, Rate, Volumen oder administrativer Verwerfungsentscheid.

Die Quittung sollte den Geltungsbereich der Regel und eine nicht offenbarende Kennung ihrer Generation nennen. Wenn möglich, hält sie außerdem fest, welcher Anteil eines Raten- oder Volumenbudgets vor und nach der Anfrage belegt war. Exakte interne Kapazitäten müssen dafür nicht gegenüber dem Sender offengelegt werden; sie können im Betreiberprotokoll bleiben und über eine Prüfkennung referenziert werden.

Konfigurierte und beobachtete Werte dürfen nicht in einem Feld verschwimmen. MTU und Ratengrenze beschreiben die Entscheidungslage, tatsächlich gesendete Länge und Paketanzahl beschreiben ihre Ausführung. Erst beide Seiten zusammen erlauben die Frage, ob eine neue Policy den Messverlauf änderte oder ob dieselbe Policy auf eine andere Last traf.

Ein wiederverwendeter Name wie „Standard-Schutzprofil“ ist keine ausreichende Herkunft. Nach mehreren Änderungen bezeichnet er verschiedene Regeln. Eine Versionsnummer, ein Hash oder eine monotone Generation bindet den Messzeitpunkt an einen aufbewahrten Stand. Ist dieser Stand später nicht mehr verfügbar, kann die Auswertung ehrlich festhalten, dass nur die grobe Ursache, nicht aber der genaue Schwellenwert rekonstruierbar ist.

Zum Nachweis gehört schließlich eine Aussage über die Verwendbarkeit. Die Antwort kann für Erreichbarkeit gültig, für Serienverlust oder Durchsatz bei der angeforderten Rate aber ungeeignet sein. Diese Einordnung hängt vom Zweck des Tests ab und muss daher nicht vom Reflektor stammen. Sie sollte jedoch untrennbar mit dessen Quittung verbunden werden, damit ein Messpunkt seine Interpretationsgrenzen nicht verliert.

Andere Flags ersetzen keine Erklärung

Die Erweiterung berührt weitere Zustände, darunter ECN, das U-Flag und vertrauenswürdige Veränderungen im Pfad. Jeder Zustand besitzt eine eigene Bedeutung. Er darf nicht als Behelfsursache für C oder als Ersatz für fehlende Policy-Herkunft gelesen werden. Eine Anzeige mit vielen Bits sieht informationsreich aus, kann aber weiterhin nur unverbundene Signale statt einer kausalen Entscheidungskette enthalten.

Auch die Sequenznummer erfüllt eine andere Aufgabe. Monotone Werte und Schutz gegen Wiederholung helfen, Pakete zu ordnen und Replay-Angriffe zu erkennen. Sie nennen nicht die aktive Ressourcengrenze. Authentisierung beweist die Herkunft beziehungsweise den Besitz eines Schlüssels, nicht die Angemessenheit der Konfiguration oder die Gültigkeit einer aus der begrenzten Antwort gezogenen Leistungsaussage.

Das wird besonders bei einer späteren Störungsanalyse wichtig. Sämtliche Pakete können kryptografisch einwandfrei sein und der betriebliche Bericht trotzdem falsch, weil die Plattform einen eingeschränkten Lauf als vollständigen Erfolg verbuchte. Transportintegrität ist keine Garantie für Interpretationsintegrität.

Quellen

https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/ https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/history/ https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-14.html https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-14.txt https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-14.xml https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-13.txt https://author-tools.ietf.org/iddiff?url1=draft-ietf-ippm-asymmetrical-pkts-13&url2=draft-ietf-ippm-asymmetrical-pkts-14 https://datatracker.ietf.org/wg/ippm/about/ https://datatracker.ietf.org/wg/ippm/documents/ https://www.rfc-editor.org/rfc/rfc8762.html https://www.rfc-editor.org/rfc/rfc8972.html https://www.rfc-editor.org/rfc/rfc9097.html https://www.rfc-editor.org/rfc/rfc7497.html https://www.rfc-editor.org/rfc/rfc9503.html https://www.rfc-editor.org/rfc/rfc8085.html https://www.rfc-editor.org/rfc/rfc1982.html https://www.rfc-editor.org/rfc/rfc7799.html https://www.rfc-editor.org/rfc/rfc7942.html https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/ https://heng.lu/the-policy-mirror/