Zusammenfassung

  • RFC 3319 definierte zwei DHCPv6-Optionen zur Ermittlung lokaler SIP-Ausgangsproxys: eine geordnete Domänennamenliste und eine geordnete IPv6-Adressliste.
  • Werden beide geliefert, sollte der Client die Namen bevorzugen und die SIP-Serverermittlung anwenden. Die Optionen nennen Kandidaten, belegen aber weder einen vertrauenswürdigen Proxy noch einen zustande gekommenen Anruf.

Eine DHCP-Antwort beantwortete eine engere Frage als ein Anruf

Das Problem von RFC 3319 wird leicht ungenau beschrieben. Ein SIP-Client kann die im SIP-URI angegebene Adresse kennen und trotzdem einen lokalen Ausgangsproxy benötigen. Eine Firewall, ein lokaler Wählplan, Notfalldienste oder andere lokale Vorgaben können einen solchen Vermittler sinnvoll machen. Manuelle Konfiguration war möglich; RFC 3319 bot eine weitere Variante: DHCPv6 sollte Kandidaten für die Ermittlung bereitstellen.

Entscheidend ist die Rolle des Servers. RFC 3261 unterscheidet User Agents, Proxys, Redirect-Server und Registrare. Mit „SIP-Server“ meint RFC 3319 ausdrücklich den Host, der einen ausgehenden SIP-Proxy betreibt. Dass ein DHCP-Paket diesen Host nennt, belegt weder die Registrierung eines Nutzers noch die Berechtigung des Ziels, den Abschluss eines SIP-Dialogs, ausgehandelte Medien oder einen erfolgreichen Anruf.

Zwei Formate, eine Rangfolge

Option 21, OPTION_SIP_SERVER_D, enthält eine Liste von Domänennamen; Option 22, OPTION_SIP_SERVER_A, eine Liste von IPv6-Adressen. Beide sind nach Präferenz geordnet, und eine konforme Implementierung muss beide unterstützen. Der Client kann eine oder beide Optionen über die DHCPv6 Option Request Option (ORO) anfordern. Was der Server zurückgibt, hängt von seiner Konfiguration und der Anfrage ab. Selbst bei einer Anforderung beider Optionen darf er nur eine liefern und sollte die Namensoption bevorzugen.

Erhält der Client beide Listen, sollte er zunächst die Domänennamen verwenden. Die numerischen Adressen sind ein bedingter Rückfall: Er darf sie erst versuchen, wenn sich kein Name der ersten Liste auflösen oder erreichen lässt. Das ist nicht gleichbedeutend mit dem wahllosen Testen jeder Adresse. Auch die Namen werden der Reihenfolge nach geprüft; zum nächsten geht es erst, wenn der vorherige Versuch scheitert, kein gemeinsamer Transport verfügbar ist oder eine lokale Richtlinie die Domäne ausschließt.

Ein Name speiste die SIP-Ermittlung, ersetzte sie aber nicht

Die Domänennamen führen in das Verfahren zur Ermittlung von SIP-Servern aus RFC 3263. RFC 3319 empfiehlt, dass sie auf unterschiedliche NAPTR-Einträge statt lediglich auf verschiedene A-Einträge verweisen. So kann ein DHCP-Server Proxys verschiedener Anbieter benennen. NAPTR und SRV werden dadurch nicht ersetzt: Die Option liefert einen Einstiegspunkt, anschließend gelten weiterhin die SIP-Ermittlung und die Regeln für den Transport.

„Rückfall“ bezeichnet damit einen konkreten Übergang. Ein später gelisteter Name ist nicht automatisch ein Ersatzserver, nur weil er im Paket steht. Der Client versucht ihn erst nach einer definierten Fehlersituation. Bei gleichzeitig gelieferten Namen und Adressen folgt die IPv6-Liste noch später. Das Netz verteilt Kandidaten und Reihenfolge; Auflösung, Transport und Zulässigkeit bleiben Entscheidungen des Clients.

Diese Aufteilung der Kontrollebene war nützlich: Das Netz konnte lokale Dienstoptionen verteilen, ohne auf jedem Client denselben Proxy fest einzutragen. Die Antwort bewies jedoch nicht, dass ein Host reagiert, einen gemeinsamen Transport unterstützt, die Anfrage dieses Nutzers akzeptiert oder den Rest der Sitzung tragen kann. „Als bevorzugt konfiguriert“ und „erfolgreich verwendet“ sind verschiedene Beobachtungen.

Der Konfigurationsweg kann Vertrauen auch umlenken

Der Sicherheitsabschnitt benennt das Risiko: Verändert oder ergänzt ein Angreifer eine DHCP-Antwort, kann ein User Agent zu einem bösartigen SIP-Server gelenkt werden. Dieser könnte Anfragen abfangen oder den Dienst verweigern. Eine manipulierte Antwort könnte außerdem Namen entfernen, die zu TLS-fähigen Servern geführt hätten, und so das Abfangen erleichtern.

Das ist das Bedrohungsmodell des RFC, kein Bericht über einen konkreten Vorfall. Es behauptet weder, dass jede empfangene Adresse authentisch sei, noch dass jeder Name zu TLS führt. Die DHCP-Antwort ist Teil der Vertrauenskette, weil sie beeinflusst, wohin eine Anwendung ihre Signalisierung als Nächstes sendet. Identitätsprüfung, Richtlinien und Schutzmaßnahmen im übrigen System bleiben eigenständige Anforderungen. Einen Server zu finden heißt nicht, ihn zu authentifizieren.

Die alte Option bleibt in neueren DHCPv6-Unterlagen sichtbar

Die allgemeine DHCPv6-Spezifikation wurde weiterentwickelt: RFC 9915 löste RFC 8415 ab. Im IANA-Register für DHCPv6-Optionscodes sind die Codes 21 und 22 weiterhin RFC 3319 zugeordnet; RFC 9243 enthält später YANG-Konfigurationsgruppen für beide SIP-Serverformen. Das zeigt fortbestehende Referenzen in Registern und Datenmodellen, aber weder tatsächliche Nutzung durch Betreiber noch Client-Unterstützung, erfolgreiche Rückfälle oder abgeschlossene Anrufe.

Der Beitrag von RFC 3319 war enger und interessanter als „DHCP findet einen Telefonserver“. Es standardisierte die priorisierte Ermittlung eines lokalen Ausgangsproxys: zuerst Namen, Adressen nur unter bestimmten Bedingungen. Der Anruf liegt außerhalb der Option. Die Ermittlung kann einen Zielort für Signalisierung nennen, aber nicht beglaubigen, was danach geschieht.

Quellen