Lesezeit
3 Minuten
Session Border Controller
Ein Session Border Controller stellt vielfältige Möglichkeiten des VoIP-Routings inklusive Sicherheitsfunktionen zur Verfügung. Er lässt sich je nach Hersteller sowohl als physische Appliance als auch in virtueller Form für unterschiedliche Virtualisierungsplattformen bereitstellen. Wir beleuchten die Möglichkeiten, die ein Session Border Controller bietet.
Als Kernfunktion
stellt ein Session Border Controller (SBC) zunächst einen Back-to-
Back-User-Agent zur Verfügung.
Ein Back-to-Back-User-Agent terminiert
auf einer Seite der Kommunikationsbeziehung
ankommend die Verbindung als
Server und baut auf der anderen Seite
eine Verbindung als Client auf. Er kann
je nach Kommunikationsrichtung die genannten
Funktionen wechselseitig nutzen.
Die Einbindung dieses User-Agenten in das jeweilige Netzwerkdesign ist je nach
Schutzbedarf unterschiedlich realisierbar.
Bei der einfachen Variante für kleinere Netzwerke ist der SBC im Internet-Edge- Router integriert. Hierdurch besteht die Möglichkeit, einen NAT-Übergang zu vermeiden. Der SBC spricht zur internen IP-PBX (Private Branch Exchange) mit privaten IP-Adressen und zum Internet Telephony Service Provider (ITSP) mit öffentlich gültigen IP-Adressen. NAT ist deshalb bei VoIP ein Problem, da wie beschrieben zwei unterschiedliche Netzwerkstreams für Signalisierung und Sprachdaten nötig sind und eine Ende-zu-Ende-Kommunikationsbeziehung zum Einsatz kommt.
Benjamin Pfister/dr
Bei der einfachen Variante für kleinere Netzwerke ist der SBC im Internet-Edge- Router integriert. Hierdurch besteht die Möglichkeit, einen NAT-Übergang zu vermeiden. Der SBC spricht zur internen IP-PBX (Private Branch Exchange) mit privaten IP-Adressen und zum Internet Telephony Service Provider (ITSP) mit öffentlich gültigen IP-Adressen. NAT ist deshalb bei VoIP ein Problem, da wie beschrieben zwei unterschiedliche Netzwerkstreams für Signalisierung und Sprachdaten nötig sind und eine Ende-zu-Ende-Kommunikationsbeziehung zum Einsatz kommt.
Die
Port-Informationen für die Medien- und
Sprachdaten werden innerhalb der Signalisierung
im sogenannten Session Description
Protocol (SDP) ausgetauscht.
Sollten also die privaten IP-Adressinformationen
der IP-PBX transparent innerhalb
der Signalisierungspakete für die
Mediendaten ins öffentliche Netz weitergeleitet
werden, könnten die Daten vom
öffentlichen Netz zur IP-PBX nicht ankommen,
da der ITSP diese privaten IPAdressinformationen
im öffentlichen
Netz nicht für das Routing der Sprachdaten
nutzen kann.
Dies führt zum sogenannten "Dead Air"-
Effekt, also dass keine Sprache übertragen
wird.
NAT-Hürden überwinden
Sollte der SBC in einem privaten IP-Adressraum positioniert sein, gibt es bei vielen SBC-Anbietern das Leistungsmerkmal "NAT-Traversal". Dieses lässt sich über unterschiedliche Techniken wie zum Beispiel Session Traversal Utilities for NAT (STUN) oder Traversal using Relay around NAT (TURN) umsetzen. Bei STUN fragt der Client im privaten Netz bei einem STUN-Server die IPAdress- und Port-Information im Zielnetz ab, um diese korrekt in die Signalisierung hineinzuschreiben.
Das Zielnetz ist hierbei meist das öffentliche Internet. Hierdurch besitzen beide Kommunikationspartner die benötigten Informationen, um eine bidirektionale Verbindung herstellen zu können. Bei TURN kommt ein Relay-Server sozusagen als Man-in-the-Middle zum Einsatz, der von beiden Kommunikationspartnern bidirektional erreichbar ist. Es gibt also hierbei keine direkte Kommunikationsbeziehung zwischen beiden Kommunikationspartnern.
Einbindung in DMZ
Bei höheren Schutzbedarfen ist eine einbeinige oder zweibeinige Einbindung in eine DMZ oder Voice-DMZ denkbar. Die zweibeinige Integration erlaubt ein noch feineres Filtern der Datenpakete. Auf die Frage, welches Design das richtige für die jeweilige Organisation darstellt, gibt es jedoch keine allgemeingültige Antwort. Zunächst sollten Sie eine Schutzbedarfsfeststellung durchführen und im Nachgang noch eine Betrachtung des internen Netzdesigns und der Möglichkeiten des jeweiligen SBCs.
Zusätzlich bieten SBCs verschiedene sogenannte Interworking-Technologien. Hierunter ist eine Anpassung an die jeweiligen ansonsten inkompatiblen Kommunikationspartner zu verstehen. Dies könnten zum Beispiel zwei IP-Telefonanlagen verschiedener Hersteller sein, die nur unterschiedliche SIP-RFCs unterstützen oder nicht kompatible Codecs, also anders digitalisierte und komprimierte Sprache verwenden.
Hierbei kann ein SBC mit einem sogenannten Audio-Transcoding eine Anpassung an die jeweilige Gegenstelle sicherstellen. Gleiches ist auch bei der Signalisierung möglich. Einige SBCs bieten die Möglichkeit, H.323 auf SIP und umgekehrt umzuwandeln. Aber auch SIP ist nicht gleich SIP. Häufig sind Manipulationen im SIPHeader erforderlich, um die spezifischen Vorgaben verschiedener Provider und Hersteller erfüllen zu können. Dies kommt in vielen Fällen bei der Signalisierung von Anrufumleitungen (Diversion oder History- Info-Header) oder bei der Übergabe der Anruferinformationen (Request-, From-, P-Asserted-Identity oder P-Preferred- Identity-Header) zum Einsatz.
Topologie verstecken
Damit keine Weiterleitung interner Informationen wie zum Beispiel private IPAdressinformationen oder Modell- und Versionsnummern der internen TK-Anlage erfolgt, kann ein sogenanntes Topology Hiding zum Einsatz kommen. Dies ist aus Sicherheitsgründen empfehlenswert, damit bei eventuellen Verwundbarkeiten und veröffentlichten Security Advisories diese nicht einfach ausgenutzt werden. Zusätzlich kann ein SBC auch die Registrierung beim Provider übernehmen, um bei mehreren IP-Telefonanlagen mit nur einer Registrierung eines Rufnummernblocks zu arbeiten oder wenn die interne TK-Anlage keine Registrierung beim Provider unterstützt.
Das Signalisierungsprotokoll SIP wartet mit unterschiedlichen Transportprotokollen auf. Sowohl UDP als auch TCP können zum Einsatz kommen. Da UDP anfällig für IP-Spoofing ist, bietet sich insbesondere im öffentlichen Netz der Einsatz von TCP an – am besten in Kombination mit TLS. TCP bildet auch die Grundlage für SIPTLS, also die Verschlüsselung der SIP-Signalisierung über eine TLS-verschlüsselte Verbindung. Ein SBC kann auch hierbei für ein Interworking, in diesem Fall ein Transport-Protokoll-Interworking durchführen. Darunter ist die Umwandlung von UDP nach TCP – beziehungsweise TCP in Kombination mit TLS – und umgekehrt zu verstehen.
Wähltöne übermitteln
In vielen Fällen kommt bei Einwahlen von Telefonkonferenzen oder Abstimmungen per Telefon auch das Dual-Tone-Multi- Frequency-(DTMF)-Verfahren zum Einsatz. Auch hierbei gibt es bei IP-basierter Telefonie unterschiedliche Wege, um die DTMF-Töne zu übermitteln. Zuerst ist hier die Inband-Methode zu nennen. Dabei wird der Ton innerhalb des VoIPSprachbands übertragen, was bei starker Komprimierung problematisch sein kann. Die zweite Methode besteht darin, die gewählte Ziffer als digitale Information im RTP-Stream zu transportieren. Dieses Verfahren ist im RFC 2833 sowie dessen Nachfolger RFC 4733 beschrieben.
Als dritte Möglichkeit bietet sich die sogenannte Out-of-Band-Variante an. Hierbei erfolgt die Übertragung innerhalb von SIP-Signalisierungspaketen und nicht im RTP-Stream. Zwischen all diesen Varianten sollte der SBC umwandeln können, wenn die Gegenstellen unterschiedliche Verfahren unterstützen und anwenden. Zentrale Bestandteile eines SBC stellen natürlich aber auch die Administration und das Monitoring dar. Für die Administration stehen je nach Hersteller unterschiedliche Schnittstellen zur Verfügung. Dies reicht von der klassischen CLI über SNMP bis hin zur webbasierten GUI und APIs.
Aufbauend auf diesen Schnittstellen gilt es, die gewünschte Qualität sicherzustellen. Hierbei unterscheiden sich die Produkte: Während einige Systeme ein Qualitätsmonitoring direkt über eine Kommandozeile oder das webbasierte GUI anbieten, ist dies bei anderen Systemen nur über zusätzliche Managementsysteme und APIs möglich.
NAT-Hürden überwinden
Sollte der SBC in einem privaten IP-Adressraum positioniert sein, gibt es bei vielen SBC-Anbietern das Leistungsmerkmal "NAT-Traversal". Dieses lässt sich über unterschiedliche Techniken wie zum Beispiel Session Traversal Utilities for NAT (STUN) oder Traversal using Relay around NAT (TURN) umsetzen. Bei STUN fragt der Client im privaten Netz bei einem STUN-Server die IPAdress- und Port-Information im Zielnetz ab, um diese korrekt in die Signalisierung hineinzuschreiben.
Das Zielnetz ist hierbei meist das öffentliche Internet. Hierdurch besitzen beide Kommunikationspartner die benötigten Informationen, um eine bidirektionale Verbindung herstellen zu können. Bei TURN kommt ein Relay-Server sozusagen als Man-in-the-Middle zum Einsatz, der von beiden Kommunikationspartnern bidirektional erreichbar ist. Es gibt also hierbei keine direkte Kommunikationsbeziehung zwischen beiden Kommunikationspartnern.
Einbindung in DMZ
Bei höheren Schutzbedarfen ist eine einbeinige oder zweibeinige Einbindung in eine DMZ oder Voice-DMZ denkbar. Die zweibeinige Integration erlaubt ein noch feineres Filtern der Datenpakete. Auf die Frage, welches Design das richtige für die jeweilige Organisation darstellt, gibt es jedoch keine allgemeingültige Antwort. Zunächst sollten Sie eine Schutzbedarfsfeststellung durchführen und im Nachgang noch eine Betrachtung des internen Netzdesigns und der Möglichkeiten des jeweiligen SBCs.
Zusätzlich bieten SBCs verschiedene sogenannte Interworking-Technologien. Hierunter ist eine Anpassung an die jeweiligen ansonsten inkompatiblen Kommunikationspartner zu verstehen. Dies könnten zum Beispiel zwei IP-Telefonanlagen verschiedener Hersteller sein, die nur unterschiedliche SIP-RFCs unterstützen oder nicht kompatible Codecs, also anders digitalisierte und komprimierte Sprache verwenden.
Hierbei kann ein SBC mit einem sogenannten Audio-Transcoding eine Anpassung an die jeweilige Gegenstelle sicherstellen. Gleiches ist auch bei der Signalisierung möglich. Einige SBCs bieten die Möglichkeit, H.323 auf SIP und umgekehrt umzuwandeln. Aber auch SIP ist nicht gleich SIP. Häufig sind Manipulationen im SIPHeader erforderlich, um die spezifischen Vorgaben verschiedener Provider und Hersteller erfüllen zu können. Dies kommt in vielen Fällen bei der Signalisierung von Anrufumleitungen (Diversion oder History- Info-Header) oder bei der Übergabe der Anruferinformationen (Request-, From-, P-Asserted-Identity oder P-Preferred- Identity-Header) zum Einsatz.
Topologie verstecken
Damit keine Weiterleitung interner Informationen wie zum Beispiel private IPAdressinformationen oder Modell- und Versionsnummern der internen TK-Anlage erfolgt, kann ein sogenanntes Topology Hiding zum Einsatz kommen. Dies ist aus Sicherheitsgründen empfehlenswert, damit bei eventuellen Verwundbarkeiten und veröffentlichten Security Advisories diese nicht einfach ausgenutzt werden. Zusätzlich kann ein SBC auch die Registrierung beim Provider übernehmen, um bei mehreren IP-Telefonanlagen mit nur einer Registrierung eines Rufnummernblocks zu arbeiten oder wenn die interne TK-Anlage keine Registrierung beim Provider unterstützt.
Das Signalisierungsprotokoll SIP wartet mit unterschiedlichen Transportprotokollen auf. Sowohl UDP als auch TCP können zum Einsatz kommen. Da UDP anfällig für IP-Spoofing ist, bietet sich insbesondere im öffentlichen Netz der Einsatz von TCP an – am besten in Kombination mit TLS. TCP bildet auch die Grundlage für SIPTLS, also die Verschlüsselung der SIP-Signalisierung über eine TLS-verschlüsselte Verbindung. Ein SBC kann auch hierbei für ein Interworking, in diesem Fall ein Transport-Protokoll-Interworking durchführen. Darunter ist die Umwandlung von UDP nach TCP – beziehungsweise TCP in Kombination mit TLS – und umgekehrt zu verstehen.
Wähltöne übermitteln
In vielen Fällen kommt bei Einwahlen von Telefonkonferenzen oder Abstimmungen per Telefon auch das Dual-Tone-Multi- Frequency-(DTMF)-Verfahren zum Einsatz. Auch hierbei gibt es bei IP-basierter Telefonie unterschiedliche Wege, um die DTMF-Töne zu übermitteln. Zuerst ist hier die Inband-Methode zu nennen. Dabei wird der Ton innerhalb des VoIPSprachbands übertragen, was bei starker Komprimierung problematisch sein kann. Die zweite Methode besteht darin, die gewählte Ziffer als digitale Information im RTP-Stream zu transportieren. Dieses Verfahren ist im RFC 2833 sowie dessen Nachfolger RFC 4733 beschrieben.
Als dritte Möglichkeit bietet sich die sogenannte Out-of-Band-Variante an. Hierbei erfolgt die Übertragung innerhalb von SIP-Signalisierungspaketen und nicht im RTP-Stream. Zwischen all diesen Varianten sollte der SBC umwandeln können, wenn die Gegenstellen unterschiedliche Verfahren unterstützen und anwenden. Zentrale Bestandteile eines SBC stellen natürlich aber auch die Administration und das Monitoring dar. Für die Administration stehen je nach Hersteller unterschiedliche Schnittstellen zur Verfügung. Dies reicht von der klassischen CLI über SNMP bis hin zur webbasierten GUI und APIs.
Aufbauend auf diesen Schnittstellen gilt es, die gewünschte Qualität sicherzustellen. Hierbei unterscheiden sich die Produkte: Während einige Systeme ein Qualitätsmonitoring direkt über eine Kommandozeile oder das webbasierte GUI anbieten, ist dies bei anderen Systemen nur über zusätzliche Managementsysteme und APIs möglich.
Benjamin Pfister/dr