Zusammenfassung

  • RFC 3487 verlangte, dass eine SIP-Prioritätsanzeige eine benannte Richtlinie aufruft, statt Warteschlange, Verdrängung, Kapazitätsanteil oder Dauer vorzuschreiben.
  • Dass ein Element das Kennzeichen verstand, bewies weder Berechtigung noch freie Ressourcen; Gateway, Leitungsnetz, Proxy und Endgerät durften verschieden handeln.

Bei einer Katastrophe werden nicht alle Teile eines Kommunikationssystems auf dieselbe Weise knapp. Ein Erdrutsch kann Leitungen zerstören, ein Ansturm kann Vermittlungsstellen füllen, ein Proxy kann an Rechenarbeit scheitern und ein Lagezentrum kann keine weitere Sitzung annehmen. RFC 3487 antwortete 2003 deshalb nicht mit einem allmächtigen Prioritätsschalter. Das Informational-Dokument legte zunächst fest, welche Entscheidungen ein künftiges Signal gerade nicht aus der Ferne treffen sollte.

Fünf Ressourcen bildeten die Karte. Ein Gateway hatte nur eine endliche Zahl von Übergängen in ein leitungsvermitteltes Netz. Das Leitungsnetz verfügte über eigene Pfade und Verfahren wie GETS oder MLPP. Im IP-Netz waren Signalisierung und Medienqualität getrennte Steuerungsfragen. Das empfangende System hatte begrenzte Sitzungskapazität. Ein SIP-Proxy konnte Rechenzeit erschöpfen, obwohl sein Zugang noch Bandbreite bot. Für diese fünf Flächen war kein gemeinsamer Mechanismus vorgeschrieben.

Entsprechend verschieden waren die Handlungen. Ein Gateway konnte einen Versuch vorziehen oder einen anderen Carrier suchen. Ein Leitungsnetz konnte nach lokalen Regeln eine bestehende Verbindung verdrängen. Ein Endsystem konnte auf einen wartenden Vorranganruf hinweisen. Ein Proxy konnte anders planen, ablehnen oder verwerfen. Dasselbe Kennzeichen konnte daher unterschiedliche Kosten und Verantwortungen auslösen.

Auch die Topologie änderte die steuerbare Oberfläche. RFC 3487 unterschied reines IP, IP zum Leitungsnetz, Leitungsnetz zu IP und CSN-IP-CSN. In einer Brücke wusste die Ursprungsseite womöglich nicht, welches Signalisierungsverfahren das entfernte Leitungsnetz nutzte. SIP-Forking konnte gleichzeitig IP- und Leitungsziele erreichen. Das Kennzeichen reiste durch einen Pfad, dessen vollständige Natur der Sender nicht kannte.

Die IP-Umgebung war ebenfalls abgestuft. Ein für Notfalldienste vorbereitetes Netz durfte Router und Reservierungen verändern. Ein transparentes Netz leitete gültige Pakete weiter. Ein SIP/RTP-transparentes Netz konnte RSVP oder DSCP blockieren. Ein eingeschränktes SIP-Netz konnte neue Header oder Methoden untersagen. Ein tragfähiger Entwurf durfte keine einzige Betreiberarchitektur voraussetzen.

Der Kern lag in der Trennung von Richtlinie und Mechanismus. Ein Aufruf per Wert hätte detailliert gefordert: höhere Warteschlange, keine Verdrängung, höchstens drei Minuten. Ein Aufruf per Referenz nannte stattdessen eine Richtlinie. Das Element, dem die Ressource gehörte, übersetzte sie in eine lokale Handlung. Selbst der Kapazitätsanteil je Stufe blieb lokal.

Damit durfte ein Kennzeichen hier verdrängen und dort nur das Verwerfen verhindern. Bei wenigen Vorranganfragen und großer Kapazität konnte kurzes Warten schonender sein als eine laufende Verbindung zu beenden. Anderswo konnte Verdrängung notwendig werden. Diese Abweichung war kein Fehler, sondern die Folge davon, Entscheidung und Ressource zusammenzuhalten.

Weitere Anforderungen machten die dünne Schnittstelle beweglich. Namensräume sollten nationale und private Systeme tragen. Die Anzeige durfte weder von einem Betreiber noch von einer Adresse abhängen. Sie musste als gültiges SIP im Band übertragen werden und mit mehreren Methoden funktionieren. Nutze auf beiden Seiten eines CSN-IP-CSN-Pfades dasselbe Schema, sollte die Übersetzung Information bewahren; bei verschiedenen Schemata räumte der RFC unvermeidlichen Verlust ein.

Unterstützung war noch keine Leistung. Ein Terminal konnte akzeptierte Namensräume abfragen oder durch einen Fehler lernen. Ohne Unterstützung sollte die Anfrage möglichst nicht schlechter als gewöhnlich behandelt werden, doch lokale Regeln durften Kennzeichnung und Authentisierung verlangen. Erkennung, Berechtigung, Kapazität und Erfolg blieben getrennt.

Auch Identität reichte nicht. Dieselbe Person tätigte normale und priorisierte Anfragen; die Stufe hing von Lage und menschlichem Urteil ab. RFC 3487 verband authentisierte Identität, Benutzerauswahl und Richtlinie. Ein From-Feld war kein dauerhaftes Privileg, ein gewähltes Kennzeichen kein Berechtigungsnachweis.

Sicherheit wurde deshalb zum tragenden Teil. Missbrauch konnte die Ressourcen verbrauchen, die legitime Helfer brauchten. Frühe Authentisierung sollte Pakete, Rechenzeit und Leitungen begrenzen, die Unbefugte besetzen. Knoten sollten Berechtigung selbst prüfen und nicht bloß transitiv vertrauen. Wiederholung, Ausschneiden und Einfügen sowie Herabstufung waren eigene Angriffe.

Datenschutz erzeugte einen zweiten Konflikt. Einsatzkräfte konnten fremde Geräte nutzen und sollten dort kein wiederverwendbares Geheimnis offenlegen. Schon die Prioritätsanzeige konnte eine sensible Lage verraten. Routingdaten brauchten daher anderen Schutz als Ende-zu-Ende-Daten. Prioritätsanzeige und Authentisierungsverfahren mussten unabhängig bleiben.

RFC 4412 setzte die Anforderungen später als Resource-Priority und Accept-Resource-Priority um. Namensraum und Wert äußerten gewünschten Vorrang; OPTIONS konnte akzeptierte Werte melden. Doch Akzeptanz bedeutete ausdrücklich weder ausreichende Ressourcen noch Erfolg. RFC 5115, 5478, 6401, 6735 und 8443 ergänzten Routing, Registrierung, Zulassung und Berechtigung, ohne die Beweiskette zu verkürzen.

Eine Rekonstruktion muss Akteur, Authentisierung, Namensraum, Wert, SIP-Methode und Topologie erhalten. Danach folgen jedes Gateway, Leitungsgebiet, jeder Proxy und Empfänger samt angewandter Richtlinienversion. Route, Warteschlange, Zulassung, Verdrängung, Medienzuteilung und menschliche Verbindung sind eigene Ereignisse.

Heng Lus Unterscheidung zwischen symbolischer und ausführbarer Macht erklärt die Eleganz. Das Kennzeichen war gemeinsam, weil es begrenzt blieb. Es transportierte eine benannte Absicht, ohne lokale Kontrolle zu beanspruchen. RFC 3487 standardisierte die Frage und machte sichtbar, weshalb legitime Antworten an jeder Grenze anders ausfallen konnten.

Quellen