Zusammenfassung

  • RFC 5189 lässt nicht widersprüchliche Überlappungen zu, während eine neue konfliktierende Regel abgewiesen wird und die bestehende unverändert bleibt. Die Fehlerklasse braucht daher den tatsächlichen Regelvergleich.
  • Eine angenommene PER belegt die lokale Middlebox-Konfiguration. Ob Pakete die Regel trafen, die übrige Strecke passierten und von der Anwendung angenommen wurden, bleibt gesondert zu prüfen.

Die erste Anfrage wollte denselben erlaubten Flow ein zweites Mal verwalten. Die zweite wollte dieselbe interne Adresse auf ein anderes externes Paar binden. Beide landeten im selben Alarm. Damit verlor das Team die Information, welche Automatisierung idempotent war und welche Realität widersprüchlich machte.

MIDCOM modelliert Regeln als Bedingungen plus genau eine Aktion: reserve oder enable. Die Semantik beschränkt nicht nur Felder, sondern ordnet jedem Erfolg und Fehler eine Reichweite zu. Wer alle Antworten auf „offen“ und „geschlossen“ reduziert, verwirft diese Reichweite.

PRR verändert keine Paketentscheidung

Policy Reserve Rule hält Adresse oder Portbereich für eine spätere Nutzung. Je nach Gerät reserviert sie außen, innen und außen oder gar nicht. Ein reiner Paketfilter kann PRR erfolgreich bearbeiten und leere Werte zurückgeben.

Dabei entsteht kein NAT-Binding und kein Pinhole. Die Paketverarbeitung bleibt gleich. RESERVED bezeichnet einen gesicherten zukünftigen Anspruch, nicht eine erlaubte Gegenwart.

Der Receipt muss Capability, Interface, Protokoll, Portbereich, Parität, angefragte und gelieferte Tuples, Rule-ID, Group und granted Lifetime enthalten. Leere Felder dürfen nicht stillschweigend durch die Request-Werte ersetzt werden.

PER und der Konflikttest

Policy Enable Rule erstellt Bindings, Allow-Aktionen oder beides. Sie kann eine PRR ersetzen oder unmittelbar ENABLED erzeugen. Bei erfolgreicher Ersetzung darf sie dieselbe ID verwenden, obwohl die Wirkung wechselt.

Vor der Annahme prüft die Middlebox Ressourcen, Autorisierung, Interfaces, Wildcards und Konflikte. Soll dasselbe interne Adress-Port-Paar auf verschiedene externe Paare abgebildet werden, ist die neue Regel widersprüchlich. Die bestehende gewinnt, die neue wird abgelehnt.

Nicht jede Überlappung ist ein Widerspruch. Identische Regeln oder andere kompatible Mengen dürfen koexistieren. Ein Detektor, der nur Tuple-Schnittmengen prüft, erzeugt falsche Konflikte und kann zulässige Redundanz verhindern.

Im Fehlerfall bleibt eine referenzierte PRR bestehen. Das ist besonders wichtig: Abweisung der Enable-Regel bedeutet weder Öffnung noch Freigabe der reservierten Ressource. Die nächste Aktion benötigt Status und Restlaufzeit.

Lokale Zulassung ist kein Traffic-Nachweis

Eine erfolgreiche PER sagt, dass diese Middlebox eine atomare Konfigurationsanfrage angenommen hat. Sie kann die resultierenden A1/A2-Tuples und die gewährte Laufzeit melden. Sie hat damit eine lokale Wahrheit geschaffen.

Eine andere Firewall, Routing, Host-Policy, Listener oder Anwendung können weiterhin verhindern, dass der beabsichtigte Vorgang gelingt. Auch die zulässige Regel kann ungenutzt bleiben. Erst Captures vor und nach dem Gerät, Remote Receipt und Application Result zeigen den Ablauf.

Das Monitoring sollte deshalb vier Zustände nicht zusammenziehen: Ressource reserviert, Regel aktiviert, Paket beobachtet, Servicewirkung bestätigt. Jeder Zustand hat einen anderen Autor.

Requested ist nicht granted

Der Agent schlägt eine Lifetime vor. Die Middlebox gewährt höchstens den kleineren Wert aus Request und beim Session-Start angekündigtem Maximum. Der operative Ablauf richtet sich nach dem gewährten Wert.

RLC kann verlängern, verkürzen oder mit null terminieren. Die Verlängerung kann abgelehnt werden, ohne den bestehenden Timer zu ändern. Ein asynchrones Ereignis kann den Zustand durch die Middlebox oder einen anderen autorisierten Agenten verändern.

Darum gehören requested, maximum, granted, remaining, Beobachtungszeit und Event-Ursprung in getrennte Felder. Ein einzelnes expires_at, das aus dem Request berechnet wird, ist keine verlässliche Tatsache.

Session und Rule sterben nicht gemeinsam

Normale, asynchrone oder verbindungsbedingte Session-Terminierung beendet den Kontrollkanal. Etablierte Regeln bleiben bis zum eigenen Ablauf oder einem weiteren Terminierungsereignis erhalten.

Die Entkopplung schützt Flows bei Controller-Ausfall. Sie kann aber Pinholes ohne lebende Erklärung hinterlassen. Owner, ursprünglicher Request, gewährte Lifetime und folgende Events müssen außerhalb der Session verfügbar bleiben.

Der authentifizierte Ersteller ist Owner über die gesamte Rule-Lifetime. Andere Agenten dürfen nur aufgrund expliziter lokaler Autorisierung handeln. Wer gerade verbunden ist, ist nicht automatisch der Urheber des Zustands.

Gruppen sind aus Mitgliedern abgeleitet

Jede Rule gehört genau einer Gruppe, alle Mitglieder haben denselben Owner. Die Gruppe entsteht mit dem ersten Mitglied und endet mit dem letzten. Ihre Lifetime ist zunächst das Maximum der Member-Lifetimes.

GLC kann allen Mitgliedern eine gemeinsame Zeit geben oder sie mit null beenden. Ein einheitlicher Gruppenakt hat ungleiche Folgen: RESERVED-Freigabe gibt Kapazität zurück, ENABLED-Terminierung verändert Paketbehandlung.

Deshalb muss die Gruppenansicht Member-State und Historie zeigen. Ein grüner Gruppenstatus beweist weder, dass alle Regeln ENABLED sind, noch dass irgendein Paket sie genutzt hat.

Atomarität und Unterbrechung

Request Transactions sind untereinander atomar. Kein stabiler Zwischenzustand wird dem Agenten berichtet. Asynchrone Transactions dürfen die Bearbeitung jedoch unterbrechen oder beenden. Teilt eine konkrete Implementierung den semantischen Vorgang, muss sie die veränderte Atomarität offenlegen.

Der Evidence Record beginnt mit Change-, Session-, Agent-, Request- und Middlebox-ID, Authentication, Owner, Capability, Interfaces, Operation, Rule, Group und Prior State. Danach folgen PRR- oder PER-Parameter, Konfliktvergleich und Failure Reason.

Er hält die drei Lifetime-Werte, das Überleben einer Reservation, Status Reads und REN/GEN/STN in Reihenfolge. Session End und Rule End sind verschiedene Ereignisse. Captures, Remote Receipt, Application Result, Expiry und Rollback schließen die Kette.

Ohne diese Kette ist „angenommen“ eine präzise Aussage über die Middlebox. „Kommunikation erfolgreich“ wäre eine Erfindung.

Quellen

  1. RFC 5189 HTML
  2. RFC 5189 Text
  3. RFC-5189-Information
  4. Datatracker RFC 5189
  5. RFC-5189-Historie
  6. RFC-5189-Referenzen
  7. RFC-5189-Errata
  8. RFC 3989
  9. RFC-3989-Information
  10. RFC 3303
  11. RFC-3303-Information
  12. RFC 3304
  13. RFC-3304-Information
  14. RFC 3198
  15. RFC 3234
  16. RFC 3022
  17. RFC 6887
  18. Heng Lu — Realitätsebenen
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — laufender Code zuerst