Zusammenfassung

  • RFC 5393 beschreibt, wie weniger als zehn gültige SIP-Nachrichten einen potenziellen Baum von 2^71 Nachrichten anlegen konnten; mit mehreren AORs bleibt der Verkehr vor der ersten Wiederholung größer als N!, selbst bei durchgängiger Loop-Erkennung.
  • Max-Breadth deckelt offene parallele Zweige und gibt den Kredit nach einer endgültigen Antwort wieder frei. Der Spitzenwert sinkt, der aggregierte Verkehr laut RFC nicht.
  • Registrierungsgraph, Via-Historie, Loop-oder-Spirale-Entscheidung, aktive Breite, kumulierte Zweige und über B2BUAs erhaltene Historie benötigen eigene Nachweise.

Die Grenze galt für Bestand, nicht für Durchsatz

Für jeden Response Context unterscheidet RFC 5393 Incoming Max-Breadth vom Outgoing Max-Breadth. Letzteres ist die Summe der Werte aller weitergeleiteten Anfragen ohne endgültige Antwort und darf das eingehende Budget nicht überschreiten.

Bei acht Zielen und einem Budget von vier starten vier Zweige. Scheitert einer, sinkt die ausgehende Summe auf drei. Der frei gewordene Kredit kann das fünfte Ziel öffnen. So lassen sich alle acht Ziele besuchen, ohne je fünf gleichzeitige Zweige zu erzeugen.

Ein Entwurf ohne Rückgabe des Kredits wurde verworfen. Er hätte die lebenslange Transaktionszahl auf einen konstanten Faktor begrenzt, aber die legitime Reichweite stark verändert und womöglich bestehende Installationen gebrochen. Das Protokoll erhielt serielle Erreichbarkeit und begrenzte den Spitzenverbrauch.

Darum ist „Limit vier“ keine vollständige Aussage. Vier offene Zweige, vier Ziele insgesamt und vier Hops sind verschiedene Kontrollflächen. Nur die erste wird zugesichert.

Der gültige Verzeichniszustand war der Verstärker

Zwei Proxy/Registrar-Dienste hielten vier AORs. Jede Adresse bei P1 verwies auf beide Adressen bei P2; P2 spiegelte diese Bindungen zurück. Ein INVITE teilte sich in zwei, vier und acht Anfragen.

Die Nachrichten konnten gültig und authentisiert sein. Das Risiko entstand aus der Komposition der Kontakte. Bis Max-Forwards null erreichte, wuchs der Baum weiter. Beim empfohlenen Startwert 70 enthält er 2^71 - 1 Anfragen; Timer-C-Abläufe können 408- und CANCEL-Verkehr ergänzen.

RFC 5393 berichtet von einer SIPit-Ausführung mit mehr als zwei Proxys und Max-Forwards 20. Das Bombardement dauerte Stunden; die Fertigstellung des einen INVITE wurde auf knapp zehn Tage hochgerechnet. Neustarts halfen nicht dauerhaft, wenn der Registrierungszustand erhalten blieb.

Ein neuer Prozess besitzt nicht automatisch eine neue Ursache. Bleibt der ausführbare Graph bestehen, kehrt die Arbeit nach dem Neustart zurück.

Loop-Erkennung stoppt Wiederholung, nicht Vielfalt

Im binären Fall ist Loop-Erkennung wirksam. Bei Umsetzung auf allen Proxys nennt der RFC 14 stimulierte Nachrichten im ersten Szenario und 10 in der Ein-Server-Variante. Deshalb müssen Proxys beim Fork zu mehreren Orten prüfen, ob sie denselben Verarbeitungszustand wiedersehen.

Der zweite Teil des Via-branch-Werts hängt von Request-URI, verwendeten Route-Feldern und weiteren Eingaben der Location-Logik ab. Ergibt die erneute Berechnung denselben Wert, folgt 482. Ändert sich der Wert, handelt es sich um eine Spirale mit verändertem Routingkontext.

Die Entscheidung verlangt unveränderte Historie. Entfernt oder verändert ein Element die Via-Parameter, verliert der ursprüngliche Knoten seine Vergleichsmöglichkeit. Zwei verschleiernde Elemente können einen Kreislauf erzeugen, den keiner von beiden sieht.

Bei N AORs, die jeweils auf die ganze Menge forken, können vor jeder Wiederholung alle Permutationen der übrigen N-1 Adressen durchlaufen werden. Die letzte Verzweigung erzeugt allein N! Anfragen. Die RFC-Tabelle nennt 64 für vier AORs, 1.956 für sechs, 109.600 für acht und 9.864.100 für zehn.

Das ist keine Prognose für normalen SIP-Verkehr. Es beweist, dass ein Duplikatfilter die Zahl erstmalig auftretender Pfade nicht begrenzt. Lokale Neuheit ist kein globales Kostenurteil.

Tiefe, Breite und Lebenszeitarbeit

Max-Forwards begrenzt Hops. Max-Breadth begrenzt gleichzeitige Zweige. Der RFC untersagt, die Breite hopweise zu reduzieren und damit als Tiefenzähler zu verwenden. Die kumulierte Zweigzahl bleibt eine dritte Größe.

440 Max-Breadth Exceeded sagt, dass der gewünschte Parallelplan nicht passt und der Proxy weder serialisiert noch umleitet. Es sagt nicht, dass keine weitere Arbeit entsteht. Mit dem Wert eins bleibt serielles Forking möglich.

Der Sicherheitsteil ist unmissverständlich: Max-Breadth senkt den aggregierten Angriffsverkehr nicht, sondern verteilt ihn über längere Zeit. Mehrere Wurzelanfragen können den Bestand offener Transaktionen allmählich aufbauen.

Die gewonnene Zeit ist wertvoll, wenn Betreiber AOR-bezogene und systemweite Anstiege sehen und Ressourcen vorübergehend sperren. Ohne diese Intervention wird aus einer Flut nur eine langsamere Flut.

Der B2BUA entscheidet über eine gemeinsame Vergangenheit

Ein B2BUA beendet die UAS-Seite und erzeugt eine neue UAC-Anfrage. Topologieverbergung kann legitim sein, entfernt aber womöglich die Historie, auf der Via, Max-Forwards und Max-Breadth beruhen. RFC 5393 warnt, dass zwei solche Grenzen die Schleife füreinander unsichtbar machen können.

RFC 7332 verlangte später, Max-Forwards zu kopieren und zu dekrementieren sowie Max-Breadth zu übertragen und durchzusetzen; die Loop-Erkennung aus RFC 5393 wird empfohlen. Die Wahl zwischen Obfuskation und Erkennbarkeit wird damit sichtbar.

Veröffentlichung beweist keine Ausführung. Running-Code-Primat verlangt einen Test über den realen B2BUA, einen Vergleich der Werte beider Seiten und den Nachweis, dass parallele UAC-Anfragen dasselbe eingehende Budget teilen.

Evidenzgrenze

Die Quellen tragen RFC-Text, SIPit-Bericht, Berechnungen und Normen. Sie belegen weder heutige Produktunterstützung noch Angriffshäufigkeit oder konkrete Ausfälle. 2^71, N! und 9.864.100 bleiben an ihre Konstruktionen gebunden.

Die belastbare Aussage lautet: Gleichzeitigkeit ist eine Bestandsaufnahme; Gesamtarbeit ist ein Hauptbuch. Wer Sicherheit behauptet, muss beide und die Entscheidung über jeden zurückgekehrten Kredit erhalten.