Zusammenfassung

  • RFC 3327 erlaubte Proxys, während REGISTER einen geordneten Path hinzuzufügen; nach erfolgreicher Registrierung verknüpfte der Registrar den Vektor mit der AOR-/Contact-Bindung und gab ihn zurück.
  • Ein Home-Proxy konnte den gespeicherten Vektor später für Anfragen an diesen Contact in einen Route-Header kopieren. Der Vektor bewies nicht, welche Route das REGISTER-Paket tatsächlich genommen hatte.

Ein erlaubter Weg, der nie zurückgelegt wurde

Ein SIP-Registrar kann die Adresse speichern, unter der ein User Agent (UA) erreichbar ist. Diese Bindung beantwortet eine enge Frage: Welcher Contact soll eine Anfrage für diese Address-of-Record erhalten? Sie beantwortet nicht zwangsläufig eine zweite: Welche Zwischen-Proxys muss die Anfrage passieren, um diesen Contact zu erreichen?

Die Lücke zeigt sich, wenn REGISTER Edge-Proxys durchläuft, die ein Home-Proxy weder aus DNS noch aus seinen eigenen Routingtabellen rekonstruieren kann. Der UA kann sich aus einem besuchten Netz registrieren, der Registrar an einem anderen Ort stehen und eine spätere eingehende Anfrage muss womöglich über Knoten zurück, die im Contact-URI nicht sichtbar sind. RFC 3327 führte im Dezember 2002 eine Möglichkeit ein, einen Routenvektor im Registrierungsaustausch zu hinterlassen.

Der Name „Path“ klingt nach einer Messung. Das war nicht seine Aufgabe. Ein von REGISTER durchlaufener Proxy konnte einen Path-Wert hinzufügen. Der Registrar speicherte die geordneten Werte zusammen mit der Contact- und AOR-Bindung und spiegelte sie in einer erfolgreichen REGISTER-Antwort zurück. Später konnte ein Home-Proxy beim Abruf der Bindung den Vektor in einen vorgeladenen Route-Header übernehmen und die neue Anfrage über diese Proxys senden. Gespeichert wurde eine für die Bindung nötige Routingreferenz, kein Paketmitschnitt der REGISTER-Transaktion.

Eine Route überlebt die Transaktion

Path ähnelt Record-Route, doch die beiden haben unterschiedliche Zeithorizonte. Record-Route legt das Routing für Anfragen innerhalb des Dialogs fest, der es erzeugt hat. Path erscheint in REGISTER und der erfolgreichen Antwort, damit eine Proxyfolge für spätere Dialoge zur Verfügung steht. Das vorhandene SIP-Routing aus RFC 3261 führt Route aus; RFC 3327 transportiert die Folge über die Registrierung hinaus.

Der Geltungsbereich war begrenzt. Der Mechanismus gilt für Anfragen, die die Home-Domain des Benutzers durchlaufen oder von dort ausgehen. Werte entsprechen der Syntax eines Route-Elements und verwenden den Loose-Routing-Parameter ;lr. Ein UA kann Unterstützung mit Supported: path anzeigen; normalerweise sollten Proxys Path nur hinzufügen, wenn diese Unterstützung signalisiert wurde. Erhält ein Registrar Path ohne eine solche Angabe, empfiehlt RFC 3327 die Zurückweisung, lässt aber lokale Richtlinien zu.

Der historische Wandel bestand nicht darin, dass SIP plötzlich jeden Paketweg kannte. Die Registrierung wurde zu einem Ort, an dem Proxys Routingkontext an die Bindung heften konnten, die spätere eingehende Anfragen lenkte. Der Registrar gab Path zudem an den UA zurück. Hinzugefügte Proxys konnten also sichtbar bleiben, statt stillschweigend zu einer universellen Topologiedatenbank zu werden.

Der Vektor ist kein Zeuge

RFC 3327 erlaubt ausdrücklich, dass ein topologiekundiger Proxy einen Path-Wert zu einem anderen Knoten hinzufügt, selbst wenn er nicht der Route entspricht, die REGISTER tatsächlich genommen hat. Das legt die richtige Lesart fest: Path ist eine geordnete Routingvorgabe, die unter Proxy- und Registrar-Richtlinien entsteht, kein forensischer Nachweis des Paketwegs. Für sich allein belegt er weder, dass ein Proxy eine frühere Nachricht weitergeleitet hat, noch dass die vorgeschlagene Route weiterhin erreichbar ist oder ein künftiger Anruf zugestellt wird.

Diese Entscheidung zog auch eine Sicherheitsgrenze. Ein in den gespeicherten Vektor eingeschleuster Proxy konnte in späteren Anfragen auftauchen und Gespräche abfangen. RFC 3327 behandelt deshalb Transportintegrität und gegenseitige Authentifizierung, etwa mit TLS oder IPsec, sowie geschützte S/MIME-Kopien, mit denen ein UA Änderungen am zurückgegebenen Path erkennen kann. Ein syntaktisch gültiger URI macht einen Zwischenknoten nicht autorisiert.

Spätere Arbeit verwendete den Mechanismus für einen engeren Zweck erneut. RFC 5626 legt ein eindeutiges Flow-Token in Path, damit ein Edge-Proxy eine spätere Anfrage einer bestimmten client-initiierten Verbindung zuordnen kann. Dieses Verhalten pro Flow gehört zur späteren Erweiterung; es gilt nicht automatisch für jeden Vektor nach RFC 3327. Service-Route aus RFC 3608 weist in die entgegengesetzte Richtung: Der UA erhält eine Route für eigene ausgehende Anfragen, nicht für eingehende Anfragen an ihn.

Quellen