Hochschule Darmstadt - Fachbereich Informatik -

Transkript

1 Hochschule Darmstadt - Fachbereich Informatik - Spam over Internet Telephony und Privacy im Kontext des IP Multimedia Subsystem Abschlussarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) vorgelegt von Jürgen Müller Referent: Korreferent: Prof. Dr. Michael Massoth Prof. Dr. Stephan Karczewski Ausgabedatum: Abgabedatum:

2 ii

3 Erklärung Ich versichere hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die im Literaturverzeichnis angegebenen Quellen benutzt habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder noch nicht veröffentlichten Quellen entnommen sind, sind als solche kenntlich gemacht. Die Zeichnungen oder Abbildungen in dieser Arbeit sind von mir selbst erstellt worden oder mit einem entsprechenden Quellennachweis versehen. Diese Arbeit ist in gleicher oder ähnlicher Form noch bei keiner anderen Prüfungsbehörde eingereicht worden. Darmstadt, den Jürgen Müller iii

4 Erklärung iv

5 Abstrakt Die Umstellung auf die nächste Generation der Netze, die sogenannten Next Generation Networks (NGNs) schreitet immer weiter voran. Eine der essenziellen Technologien für die neuen Kernnetze ist das IMS. Parallel hierzu entwickelt sich das Aufkommen von Spam stark steigend. In den vergangenen Jahren hat sich die Quantität von -Spam auf rund 85 % gesteigert. Eine derartige Entwicklung im Voice over IP (VoIP)-Bereich könnte den gesamten Dienst gefährden. Dass es Spam over Internet Telephony (SPIT) gibt, belegt ein Versuch der Universität Duisburg- Essen. Auf einem dort testweise eingerichteten Honeypot konnte der Versand von SPIT nachgewiesen werden. Damit ist belegt, dass es sich bei SPIT um kein fiktives Problem handelt. Deshalb werden im Rahmen dieser Arbeit Abwehrmaßnahmen ermittelt, die das SPIT- Aufkommen eindämmen. Diese Mechanismen sind jedoch wirkungslos, wenn keine starken Identitäten gewährleistet sind. Aus diesem Grund werden Sicherheitsverfahren beschrieben, die den Teilnehmer authentifizieren. Das Session Initiation Protocol (SIP) gewährt jedoch die Möglichkeit, Telefonate direkt zwischen zwei Endgeräten zu führen. Da durch die direkte Übertragung des SPIT das IMS umgangen wird, kann das Endgerät nicht serverseitig geschützt werden. Deshalb wird im Rahmen dieser Arbeit ein Konzept entworfen und untersucht, um in solchen Fällen Schutz zu bieten. The change into Next Generation Networks (NGNs) is in progress. One of the keytechnologies for the new corenetworks is the IMS. At the same time the amount of -Spam is growing. The quantity of -Spam has risen to around 85 %. This development in the Voice over IP (VoIP)-Sector threatens the whole service. The existance of Spam over Internet Telephony (SPIT) was proven by an experiment of the University of Duisburg-Essen. The distribution of SPIT was demonstrated by an experimental Honeypot. This proves, that SPIT is a real problem. v

6 Abstrakt The object of this thesis is to establish methods of SPIT-prevention. However, these methods only work with strong identitys. For this reason the thesis at hand describes securityprocedures for authentication of the participants. But the Session Initiation Protocol (SIP) allows peer-to-peer-calls. Since the direct transmission of SPIT bypasses the IMS, servers are not able to check the messages for SPIT. Therefore this thesis developes a concept to provide protection against this form of SPIT. Schlüsselwörter: IP Multimedia Subsystem, Next Generation Network, Spam, Spam over Internet Telephony, Session Initiation Protocol, Voice over IP. vi

7 Vorwort Anders als bei meiner Bachelorarbeit muss ich dieses Mal dem wichtigsten Menschen in meinem Leben als erstes Danken. Janina, ohne dich wäre ich heute vermutlich kein Student. Ohne dich würde ich mich und meine Umgebung nicht reflektieren, ich würde nicht darauf achten, was ich esse, wie ich mich kleide oder wo ich in meinem Leben hin will. Kurz, du gibst mir sehr viel und ich hoffe, ich kann es dir wieder zurückgeben. Das Wichtigste was ich dir hier sagen will, ich liebe dich von ganzem Herzen. Meinen Eltern gilt ein ganz besonderer Dank. Während des Masterstudiums mussten sie mir leider deutlich öfters helfen, als während des Bachelors. Für die liebevolle Hilfe möchte ich mich daher hier nochmals bedanken. Ganz besonders muss ich Christine danken. Im Masterstudium haben wird oft zusammengearbeitet und waren immer ein gutes Team. Doch gerade beim Schreiben dieser Arbeit war sie mir eine sehr große Hilfe. Sie hat besonders oft, früh und viel für mich korrektur gelesen, danke. Aber Christine war zum Glück nicht die Einzige, die mir hilfreich zur Seite stand. Als nächstes will ich hier Klaus und Stephan danken. Wir haben zusammen angefangen zu studieren und wären alleine nicht entsprechend erfolgreich gewesen. Vielen Dank. Natürlich will ich all meinen restlichen Korrekturlesern danken. Rebecca danke für die Hilfe beim englischen Abstrakt. Andreas danke für deine weitsichtigen Kritiken an meinem Aufbau und der Hinterfragung meiner schriftlichen Aussagen. Nach meinen schlechten Erfahrungen während der Bachelorarbeit war ich sehr skeptisch, ob ich einen Betreuer brauche oder will. Trotz, dass ich in Kassel wohne und das Fraunhofer- Institut sehr weit weg ist, war mir Rachid eine sehr große Hilfe, ohne die ich es nicht geschafft hätte. Dafür möchte ich ihm sehr danken. Natürlich will ich auch meinen Referenten Prof. Dr. Michael Massoth und Prof. Dr. Stephan Karczewski danken. Darüber hinaus muss ich Prof. Dr. Elke Hergenröther danken, da sie für mich meine Mentorin war. Natürlich habe ich nicht alle genannt, die vielleicht genannt werden müssten. Vermutlich habe ich im Abgabestress vergessen, euch zu erwähnen. Daher anonymer weise, vielen Dank. vii

8 viii

9 Inhaltsverzeichnis Erklärung Abstrakt Vorwort Abbildungsverzeichnis iii v vii xiii 1 Einleitung Motivation Aufgabenstellung Wirtschaftlicher Nutzen Aufbau der Arbeit Next Generation Network Session Initiation Protocol Begriffserklärung Nachrichtenstruktur Nachrichtentypen Adressierung Prozeduren Netzelemente IP Multimedia Subsystem Begriffserklärung Adressierung Prozeduren Funktionen Zusammenfassung Spam over Internet Telephony 37 ix

10 Inhaltsverzeichnis 3.1 Definition Herkunft des Wortes Spam Bedeutung in dieser Arbeit Formen von Spam mittels Session Initiation Protcol Soziale Auswirkungen Vorgehen Informationen sammeln Sitzung etablieren Nachricht übertragen Kostenberechnung Gesetzeslage Begriffserklärung Rechtmäßiges Direktmarketing Möglichkeiten der Strafbarkeit Regelungen für Internet Service Provider Zusammenfassung Abwehrmaßnahmen Identität Blacklists Whitelists Graylists Device Fingerprinting Reputationssysteme Inhalt Interaktiv Intrusion Detection Payments at Risk Turingtests Computational Puzzles Honeypots Präventiv Adressen verbergen Adressen streuen Teilnehmerverhalten Umgang mit empfangenem Spam Zusammenfassung Sicherheitsverfahren Hypertext Transport Protocol Authentication x

11 Inhaltsverzeichnis Challenge Response Anwendungsszenarien Authentication and Key Agreement Session Initiation Protocol Security Transport Layer Security Anwendungsszenario Privacy-Service Anonymisierungsstufen Anonymisierungsverhalten Secure/Multipurpose Internet Mail Extensions Schlüsselaustausch Authentifizierung Internet Protocol Security Sicherheitsassoziationen Sicherheitsmodi Protokolle Zusammenfassung Direct-IP-SPIT-Schutz Anforderungen Konzept Analyse Entwurf Machbarkeitsstudie Existenz des Anrufers beim Betreiber überprüfen Direkte Überprüfung der Existenz des Anrufers Entwicklungsumgebung Umsetzung Bewertung Performance Akzeptanz Sicherheit Zusammenfassung Zusammenfassung Fazit Ausblick Glossary 117 xi

12 Inhaltsverzeichnis Literatur- und Quellenverzeichnis 125 Request for Comments-Verzeichnis 133 CD-ROM (im rückseitigen Einband) xii

13 Abbildungsverzeichnis 2.1 Server- und Client-Rollenverteilung bei einem normalen Telefonat Verteilung von Transactions und Sitzung Three-Way-Handshake mit zwei Transactions Three-Way-Handshake mit einer Transaction Veranschaulichung des Dialogs Aufbau einer SIP-Nachricht Relation zwischen permanentem und temporärem SIPURI Teilnehmerregistrierung mittels Session Initiation Protocol Der Three-Way-Handshake Beispiele für einen User Agent Veranschaulichung des SIP-Trapezoid-Begriffs Relation zwischen IMPI und IMPU Ablauf der Registrierung im IMS Sitzungsaufbau im IMS Ausschnitt aus der Referenzarchitektur des IMS Skizze einer Universal Integrated Circuit Card Drei Schritte zum SPIT Ablauf beim Double-Opt-IN Kategorisierung der Abwehrmaßnahmen Ein Beispiel für ein bildbasiertes CAPTCHA Umgehung eines CAPTCHAs Explosionsskizzenbeispiel einer Bild-Adresse aus mehreren Teilen Kategorisierung der Sicherheitsverfahren Berechnung des gemeinsamen Geheimnises mittels MD5-Algorithmus Registrierung mit HTTP Authentication Proxy-Sitzungsaufbau mit HTTP Authentication xiii

14 Abbildungsverzeichnis 5.5 Peer-to-Peer-Sitzungsaufbau mit HTTP Authentication Berechnung des Nonce-Wertes mit AKA Transport Layer Security-Schichtenmodell Domainübergreifender SIPS-Verbindungsaufbau Ende-zu-Ende-Sicherung Netz-zu-Netz-Sicherung Integration des AH-Headers in ein IP-Paket Abfolge der Responses 100 Trying und 180 Ringing Konzeptionelle Änderung im Ablauf eines Direct-IP-Calls Ablauf eines verifizierten Anrufs mit DERIVE Erfolgreicher Angriff trotz DERIVE Implementierte Änderung im Ablauf eines Direct-IP-Calls Boxplot der Messergebnisse Boxplot der Messergebnisse bis zum 90 % Perzentil Standardabweichung um das arithmetische Mittel Konfidenzintervall beider Messungen Verteilung der Spamkosten für das Jahr Reduktion von SPIT via Proxy xiv

15 Kapitel 1 Einleitung Zu Beginn wird die Motivation beschrieben, die zur Erstellung dieser Arbeit geführt hat (vgl. Abschn. 1.1, S. 1). Anschließend wird die genaue Aufgabenstellung zur Anfertigung dieser Masterarbeit dargestellt (vgl. Abschn. 1.2, S. 2). Danach wird der wirtschaftliche Nutzen dieser Arbeit beschrieben (vgl. Abschn. 1.3, S. 2). Als letztes folgt ein kurzer Überblick über den Aufbau der vorliegenden Arbeit (vgl. Abschn. 1.4, S. 3). 1.1 Motivation Seit dem Wintersemester 2007 wird an der Hochschule Darmstadt das Projekt Systementwicklung mit dem Ziel Entwicklung und Betrieb eines IMS angeboten [Mas-2009]. Seitdem wurden vier Veröffentlichungen auf Konferenzen und ein Artikel im hochschulweiten Magazin Querschnitt veröffentlicht. Außerdem wurden drei Bachelor- und vier Masterarbeiten (die hier vorliegende Arbeit inbegriffen) erstellt. Seit dem Sommer 2009 ist das Projekt Teil des Next Generation Telecommunication Factory (NextFactor)-Projekt. Dieses Projekt hat die folgenden Ziele [Mas-2008, S. 2 3]: 1. IMS/NGN-Infrastruktur mit Testing and Test Control Notation Version 3 (TTCN-3) basierter Testautomationsplattform als Service für kleinere und mittlere Unternehmen (KMU) und Unternehmenspartner. 2. Entwicklung einer umfassenden IMS/NGN-Sicherheitsinfrastrukur. 3. Entwicklung eines sicheren SIP-basierten mobilen Bezahldienstes mit Integration von Near Field Communication (NFC). Das Projekt ist in mehrere Arbeitspakete unterteilt. Diese Arbeit ist dem Arbeitspaket AP Sec4 Endgerätesicherheit (inkl. SPIT/SPAM) [Mas-2008, S ] zugeordnet. Die Aufgabenstellung für diese Masterarbeit wird im nächsten Abschnitt (vgl. Abschn. 1.2, S. 2) näher beschrieben. 1

16 Kapitel 1. Einleitung Für die Bearbeitung des Themas Spam over Internet Telephony (SPIT) ist eine Betrachtung hinsichtlich Privacy unumgänglich. Mittlerweile ist deutlich geworden [RFC-5039, S. 23], dass ohne starke Identitäten das SPIT nicht in den Griff zu bekommen ist. Eine starke Identität bezeichnet eine vertrauenswürdige Bindung zwischen Teilnehmer und Netzwerk. Doch wie können starke Identitäten im IMS gesichert werden? Ob SPIT aufkommen wird, galt lange als ungewiss. Ein Versuch der Universität Duisburg- Essen belegt die Existenz dieses Problems [Hof-2009, S. 9]. Sie betreibt einen Honeypot für SPIT, auf den bereits zugegriffen wurde. Außerdem prognostiziert das Bundesamt für Sicherheit in der Informationstechnik (BSI) für SPIT eine ähnliche quantitative Entwicklung wie bei -Spam [BSI-2009, S. 4]. Wenn jetzt etwas unternommen wird, kann diese Entwicklung aufgehalten werden. Kommt es zu einer Verbreitung von SPIT, kann dies den gesamten Einsatz von Voice over IP (VoIP) gefährden. Schließlich will niemand die selbe Masse an unerwünschten Anrufen, wie an unerwünschten s. 1.2 Aufgabenstellung Frühere Untersuchungen haben gezeigt, dass zur erfolgreichen Spambekämpfung ein gewisses Maß an Privatsphäre nötig ist [RFC-5039, S ]. Insbesondere das Vorhandensein starker Identitäten ist eine der Schlüsselrollen gegen Spam. Doch im Kontext moderner Netzarchitekturen, insbesondere des IMS, werden viele Identitäten ausgetauscht. Da sie für die Funktion der Architektur unumgänglich sind, können sie nicht entfernt werden. Folglich geht es mehr um einen effektiven Schutz. Im Kontext der Spambekämpfung bedeutet dies, dass die Identitäten mittels Authentifizierungsmaßnahmen geschützt werden müssen. Ziel dieser Arbeit ist daher die Ermittlung von Mechanismen zur Abwehr von SPIT und Gewährung von starken Identitäten. Abschließend wird eine Anti-SPIT-Maßnahme für direkte Anrufe implementiert. Da das NextFactor-Projekt noch im Anfangsstadium ist, wird zunächst eine Machbarkeitsstudie entworfen, die eine generelle Möglichkeit bestätigt. 1.3 Wirtschaftlicher Nutzen Das Aufkommen von SPIT kann dafür sorgen, dass der VoIP-Dienst vom Teilnehmer abgelehnt wird. Da die Next Generation Networks (NGNs) von diesem Problem betroffen sind [TIS-2008, S. 20], ergibt sich ein direktes Interesse der ISP, SPIT möglichst frühzeitig einzudämmen. SPIT verursacht vor allem beim Ziel des Spams hohe Kosten. Der größte Bestandteil dieser Kosten ist mit 85 % der entstehende Produktivitätsverlust [Jen-2009]. Die Kosten c s 2

17 1.4. Aufbau der Arbeit für einen Anruf ergeben sich aus dem durchschnittlichen Stundenlohn l h für die entgangene Arbeitszeit t c (vgl. Formel 1.1, S. 3). Da der Mitarbeiter durch den Anruf aus seiner Tätigkeit gerissen wird, entgeht dem Arbeitgeber zusätzliche Arbeitszeit t x. Bei mehreren Spamvorfällen summiert sich dieser Betrag weiter auf. c s = (t c t x ) l h 360 (1.1) Diese Arbeit präsentiert die notwendigen Abwehrmaßnahmen und Sicherheitsverfahren. Dabei führt sie in die Probleme ein, die im Kontext von SPIT auftreten können. Insbesondere wird die Relevanz von starken Identitäten, in Form von authentisierten Teilnehmern, beschrieben. Zusätzlich wird ein Konzept zur Abwehr von Direct-IP-SPIT beschrieben. Direct-IP-SPIT ist als besonders gefährlich einzustufen, da es das IMS umgeht und somit eine Abwehr kaum möglich macht. 1.4 Aufbau der Arbeit Das Thema SPIT wird in dieser Arbeit im Kontext des IMS betrachtet. Deshalb wird in einem einleitenden Kapitel (vgl. Kap. 2, S. 5) in die für diese Arbeit wichtigsten Themen eingeführt, die unter dem Schlagwort NGNs zusammengefasst werden. Da das Session Initiation Protocol (SIP) für das IMS und die Zustellung des SPIT von zentraler Bedeutung ist, wird zunächst die Funktionsweise dieses Protokolls vorgestellt. Auf Basis dieses Wissens wird in die Thematik des IMS eingeführt werden. Anschließend wird das SPIT erklärt (vgl. Kap. 3, S. 37). Dafür wird zunächst definiert, was unter dem Ausdruck SPIT in dieser Arbeit zu verstehen ist. Bevor auf die Arbeitsweise eines Spammers eingegangen wird, werden ausgewählte soziale Auswirkungen von SPIT vorgestellt. Danach wird das Vorgehen beim Senden von SPIT erklärt. Des Weiteren wird untersucht, ob sich SPIT für den Versender finanziell lohnt. Abschließend wird in die rechtlichen Rahmenbedingungen um das Thema Spam eingeführt. Da es seit mehreren Jahren -Spam gibt, steht die Forschung dem Thema SPIT nicht unvorbereitet gegenüber. Viele Ansätze der klassischen Spambekämpfung sind auf SPIT übertragbar. Unterteilt in vier Gruppen (z. B. identitätsbasiert, präventiv) werden diese Abwehrmaßnahmen vorgestellt (vgl. Kap. 4, S. 53). Dem Thema Privacy kommt eine Schlüsselfunktion für die erfolgreiche SPIT-Bekämpfung zu. Aus diesem Grund werden im nächsten Kapitel (vgl. Kap. 5, S. 75) die Sicherheitsverfahren vorgestellt, die hierfür im IMS eingesetzt werden können. Zwar lässt sich SPIT wie -Spam nicht vollständig unterbinden, doch zeigt sich, dass eine Form des SPIT besonders kritisch ist. Das sogenannte Direct-IP-SPIT kann fast nicht abgewehrt werden. Um diesem Problem entgegenzuwirken, wurde im Rahmen dieser 3

18 Kapitel 1. Einleitung Arbeit ein Konzept zur Abwehr von Direct-IP-SPIT definiert und im Rahmen einer Machbarkeitsstudie realisiert (vgl. Kap. 6, S. 95). Abschließend werden die Erkenntnisse aus dieser Arbeit zusammengefasst und bewertet. Die Zusammenfassung wird durch einen Ausblick ergänzt. 4

19 Kapitel 2 Next Generation Network Im Kontext der digitalen Konvergenz der Netze sind die sogenannten Next Generation Networks (NGNs) [ITU-2004] als Integrationsplattform das tragende Konzept. Sie bieten zukünftig ein zentrales paketorientiertes Basisnetz z. B. für Telefonie und Internet. Zur Steigerung der Skalierbarkeit und Modularisierung sind die Kontrollfunktionen und der Transport voneinander getrennt. Um Telefonie über paketorientierte Netze zu ermöglichen, ist eine sogenannte Quality of Service (QoS) integriert. Da ohne QoS jedes Paket im Internet gleichberechtigt ist, kann es während eines Telefonats vermehrt zu Störgeräuschen kommen. Beispielsweise kann ein Sprachpaket stark verzögert eingehen, sollte ein großer Dateitransfer dazwischenkommen. Jetzt ist es möglich, Sprachpakete bevorzugt zuzustellen, um dem Echtzeitcharakter dieser Anwendung Rechnung zu tragen. Eines der tragenden Protokolle für die Internettelefonie in den NGNs ist das Session Initiation Protocol (SIP) (vgl. Abschn. 2.1, S. 5). Es stellt dem Netzwerk eine Sitzungssteuerungsfunktionalität zur Verfügung. Wenn ein Angreifer Spam versenden will, wird er nach dem heutigen Stand auf das SIP zugreifen müssen. Im Kern dieses konvergenten Netzes wird das IMS (vgl. Abschn. 2.2, S. 27) eingesetzt. Es definiert die zentralen Steuerfunktionen zur Durchführung verschiedener Services, wie z. B. Telefonie. Somit hat das IMS eine Schlüsselfunktion in der Bekämpfung von Spam over Internet Telephony (SPIT) (vgl. Kap. 3, S. 37). Da jeder der genannten Technologien für den Vertrieb sowie die Bekämpfung von SPIT relevant ist, werden diese nachfolgend genauer vorgestellt. Eine Untersuchung auf die Angriffsmöglichkeiten erfolgt später in dieser Arbeit (vgl. Kap. 4, S. 53). 2.1 Session Initiation Protocol Voice over IP (VoIP) leistet einen wichtigen Beitrag zur Konvergenz der Netze. Mit VoIP ist ein Teilnehmer in der Lage, von jedem beliebigen Endgerät (z. B. Handy) Telefonate zu führen, solange dieses internetfähig ist. 5

20 Kapitel 2. Next Generation Network Doch diese Flexibilität bedeutet zusätzlichen Aufwand. Ein Mobiltelefon ist in der Regel nicht in der Lage die Sprache in derselben Qualität zu übertragen wie ein Telefon. Das liegt an der unterschiedlichen Bandbreite. Mittels Mobilfunknetz wird beim Global System for Mobile Communications (GSM) ca. 10 kbit/s oder mittels General Packet Radio Service (GPRS) ca kbit/s zur Verfügung gestellt [3GP-2009]. Ein an das Integrated Service Digital Network (ISDN) angeschlossenes Telefon hat jedoch 64 kbit/s. Deshalb muss zur Abstimmung der Möglichkeiten eine sogenannte Sitzungssteuerung eingesetzt werden. Sie ermittelt im Rahmen der Signalisierung die Fähigkeiten der beteiligten Endgeräte. Zur Beschreibung der Fähigkeiten kommt ein Sitzungsbeschreibungsprotokoll (z. B. das Session Description Protocol (SDP) [RFC-4566]) zum Einsatz. Mit diesen Informationen kann eine Kommunikationsverbindung aufgebaut werden, die den Möglichkeiten aller Teilnehmer gerecht wird. Des Weiteren ist eine Sitzungssteuerung für den generellen Aufund Abbau einer Sitzung und für die Verwaltung dieser Sitzung zuständig. Der Begriff Sitzung bezeichnet den Austausch von Daten zwischen zwei beteiligten Teilnehmern [RFC-3261, S. 8]. Zur besseren Darstellung lässt sich dieser Begriff an folgendem Beispiel beschreiben: Alice sitzt an ihrem Computer und will Bob auf seinem Mobiltelefon erreichen. Nach der Eingabe der Mobilfunknummer findet die Sitzungssteuerung die Fähigkeiten von allen beteiligten Endgeräten heraus. Da Bob über ein Handy telefoniert, kommt ein etwas schlechterer Codec zum Einsatz. Falls Bob während des Gesprächs in ein Gebiet mit schlechterem Empfang kommt, kann der aktuelle Codec eventuell nicht mehr genutzt werden. Deshalb wird der verwendete Codec in einer solchen Situation von der Sitzungssteuerung gewechselt. Beendet Alice ihr Telefonat mit Bob, sorgt die Sitzungssteuerung dafür, dass die Verbindung getrennt wird. Der gesamte Prozess von Rufauf- bis Rufabbau wird als Sitzung bezeichnet. Das Session Initiation Protocol (SIP) [RFC-3261] ermöglicht eine solche Sitzungssteuerung. Beim Entwurf des SIP wurde besonders auf die Verständlichkeit und leichte Handhabung Wert gelegt. Aus diesem Grund ist die Syntax sehr ähnlich zur der des Hypertext Transport Protocol (HTTP) [RFC-1945][RFC-2616]. Um Nachrichten zwischen den Teilnehmern auszutauschen, kommen mehrere Transportprotokolle in Frage. Das gewählte Protokoll muss jedoch von beiden beteiligten Teilnehmern unterstützt werden, um eine Verbindung zu etablieren. Um das SIP zu transportieren, kann auf die folgenden Protokolle zurückgegriffen werden [RFC-3261, S ][RFC-4168]: Transmission Control Protocol (TCP) [RFC- 793]. User Datagram Protocol (UDP) [RFC- 768]. Session Control Transmission Protocol (SCTP) [RFC-4960]. Das SCTP und TCP bieten eine Übertragungssicherung. Eine Übertragungssicherung beinhaltet eine Nachrichtenwiederholung bei Verlust oder Beschädigung, Einhaltung der 6

21 2.1. Session Initiation Protocol Sendereihenfolge und Eliminierung von Duplikaten. Da das SIP eine Übertragungssicherung bereitstellt, kann der Einsatz des SCTP und des TCP einen unnötigen zusätzlichen Overhead aufgrund doppelt ausgeführter Tätigkeiten bedeuten [TW-2007, S. 124]. Deshalb kommt oft das verbindungslos arbeitende UDP zum Einsatz, da es keine Übertragungssicherung einsetzt Begriffserklärung Im Kontext vom SIP wird von Wörtern und Begriffen Gebrauch gemacht, die eventuell ungeläufig sind beziehungsweise in Zusammenhang mit anderen Thematiken verwendet werden. Um Irritationen zu vermeiden, werden in diesem Abschnitt kurz die Begrifflichkeit bestimmter Ausdrücke erklärt. User Agent Client und Server Ein UA (vgl. Abschn , S. 24) besteht aus zwei Komponenten, einem UAC und einem UAS. Die Bezeichnung unterscheidet sich von der klassischen Verwendung des Client- / Server-Begriffs. Ob ein UA als Client oder als Server agiert, sagt nichts über seine eigentliche Funktion aus. Er kann eine Endeinrichtung oder ein Netzelement sein. Die Angabe, ob es sich um einen Client oder einen Server handelt, ist nur eine fallbezogene Bezeichnung. User Agent Client Alice INVITE 100 Trying 180 Ringing 200 OK ACK Bob User Agent Server User Agent Server Sitzung BYE 200 OK User Agent Client Abb. 2.1: Server- und Client-Rollenverteilung bei einem normalen Telefonat. Startet ein UA eine Kommunikation durch das Senden eines INVITE-Request, nimmt er die Rolle des UAC ein (vgl. Abb. 2.1, S. 7). Der angerufene UA übernimmt automatisch die Rolle des UAS. Seine Funktion ist die Beantwortung der Requests mit Responses. 7

22 Kapitel 2. Next Generation Network Transaction Das Anfrage-Antwort-Verfahren bei SIP wird als Transaction [RFC-3261, S ] bezeichnet. Im Rahmen einer Transaction werden eine Request und ein oder mehr Responses ausgetauscht [RFC-3261, S. 122]. Eine Transaction wird mit einer finalen Response beendet. Wenn die Request-Methode z. B. INVITE oder SUBSCRIBE (vgl. Abschn , S. 18) ist, leitet die Transaction einen Dialog (vgl. Abschn , S. 9) ein. Diese Sitzung wird wiederum durch eine weitere Transaction beendet (vgl. Abb. 2.2, S. 8). Alice INVITE 200 OK Bob Transaction 1 ACK Transaction 2 Sitzung BYE 200 OK Transaction 3 Abb. 2.2: Verteilung von Transactions und Sitzung. Um einzelne Nachrichten einer Transaction zuzuordnen, werden die folgenden Header- Felder ausgewertet: Der brach-wert im via-header-feld. Der Wert des CSeq-Header-Feld. Eine Ausnahme [RFC-3261, S ] für die Transaction ist der Three-Way-Handshake (vgl. Abschn , S. 22). Abhängig davon, wie der Verbindungsaufbau verläuft, besteht er aus mehr oder weniger Requests und Responses [RFC-3261, S ]. Erfolgreicher Verbindungsaufbau (vgl. Abb. 2.3, S. 8): Das heißt der INVITE- Request wird mit einem Response vom Typ 2xx beantwortet (vgl. Abb. 2.9, S. 23). In diesem Fall besteht der Three-Way-Handshake aus einer normalen Transaction (INVITE und 200 OK) und einer Transaction mit nur einem Request (ACK). Alice INVITE 200 OK Bob Transaction 1 ACK Transaction 2 Abb. 2.3: Three-Way-Handshake mit zwei Transactions. 8

23 2.1. Session Initiation Protocol Erfolgloser Verbindungsaufbau (vgl. Abb. 2.4, S. 9): Dies ist der Fall, wenn der INVITE-Request durch einen Response vom Typ 3xx bis 6xx beantwortet wird. Dann besteht die Transaction aus zwei Requests (INVITE und ACK) und einer Response (3xx bis 6xx). Alice INVITE 404 Not Found ACK Bob Transaktion 1 Abb. 2.4: Three-Way-Handshake mit einer Transaction. Dialog Eine zusammenhängende Folge von Transactions wird als Dialog [RFC-3261, S. 69] bezeichnet. Der Austausch der Medieninformationen, wie z. B. bei VoIP der Austausch der Sprachdaten, fällt ebenfalls unter diesen Begriff. Alice INVITE Bob 200 OK ACK Sitzung BYE 200 OK INVITE-Dialog Sitzungs-Dialog BYE-Dialog Abb. 2.5: Veranschaulichung des Dialogs. Die an einem Dialog beteiligten Transactions werden über die folgenden Header-Felder zugeordnet: Der Wert des Call-ID-Header-Feld. Der Wert des tag-parameters im From-Header-Feld. Der Wert des tag-parameters im To-Header-Feld. Ein Dialog wird von keinem Netzelement außer den Endsystemen terminiert. Ausnahmen stellen Netzelemente dar, die als Endsystem auftreten können, wie beispielsweise der B2BUA (vgl. Abschn , S. 26). 9

24 Kapitel 2. Next Generation Network Event Als Event [RFC-3265] wird bei SIP ein Ereignis bezeichnet, dass zu einem bestimmten Zustand gehört. Events werden beispielsweise für die Durchführung einer Presence-Funktion [RFC-3856] genutzt. Bei einem Presence Event wird z. B. der Abonnent informiert, wenn sich der überwachte Teilnehmer registriert. Um ein Event zu abonnieren, wird ein SUBSCRIBE-Request (vgl. Abschn , S. 19) an den gewünschten Zielteilnehmer gesendet. Sobald sich der abonnierte Zustand dieses Teilnehmers ändert, sendet sein UA einen NOTIFY-Request an den abonnierenden Teilnehmer. Diese Prozedur der Überwachung und Information wird als SIP-Specific Event Notification [RFC-3265] bezeichnet. Eine vollständige Liste aller möglichen Event Packages ist auf der Seite der Internet Assigned Numbers Authority (IANA) [IAN-2009] zu finden Nachrichtenstruktur Beim SIP besteht eine Nachricht aus zwei bis vier Elementen. Sie enthält immer die folgenden beiden Komponenten: 1. Start-Line. 2. Header. Die Nachrichten sind zustätzlich in der Lage eine Nutzlast zu transportieren. In den meisten Fällen ist dies eine Beschreibung der zu verwendenden Codecs. Enthält eine Nachricht eine Nutzlast, erweitert sich der Aufbau der Nachricht wie folgt: 1. Start-Line. 2. Header. 3. Leerzeile. 4. Body. Die Leerzeile hat die einzige Funktion, als Separator zwischen dem Header und dem Body zu dienen. Im Folgenden werden die restlichen Bestandteile einer Nachricht beschrieben. Start-Line Wie der Name bereits suggeriert, besteht die Start-Line aus nur einer einzigen Zeile. Sie enthält die wichtigsten Informationen zur Verarbeitung der Nachricht. Es gibt zwei Arten von Nachrichten. Zum einen initiierende Nachrichten, zum anderen die korrespondierende Antwort. Diese Requests und Responses (vgl. Abschn , S. 17) unterscheiden sich im Aufbau leicht voneinander. 10

25 2.1. Session Initiation Protocol Start Line Header Leerzeile Optional Body Abb. 2.6: Aufbau einer SIP-Nachricht. Zunächst wird an dieser Stelle der Request beschrieben. Abgesehen von der Methode des Requests, ist in der Start-Line der URI des Adressaten und eine Versionsnummer enthalten. Eine Methode ist die Art des Requests, z. B. REGISTER für einen Registrationsversuch. Die Versionsnummer gibt die verwendete Version des SIP an. Diese drei Bestandteile sind in der folgenden Reihenfolge angegeben (vgl. Notation 2.1, S. 11): 1. Methode 2. Request-URI 3. SIP-Version REGISTER sip : registrar. atlanta. com SIP /2.0 Notation 2.1: Beispiel einer Start-Line in einem Request. Bei einem Response ist die Start-Line ein wenig anders aufgebaut als beim Request. Sie enthält neben der SIP-Version einen sogenannten Status-Code und eine Reason Phrase. Die Reason Phrase dient der verbalen Beschreibung des Status-Codes. Sie werden in der folgenden Reihenfolge angegeben (vgl. Notation 2.2, S. 11): 1. SIP-Version 2. Status-Code 3. Reason Phrase SIP / OK Notation 2.2: Beispiel einer Start-Line in einem Response. Bei Requests sowie bei Responses werden diese drei Komponenten durch ein Leerzeichen separiert. Die Status-Line wird mit einem Wagenrücklauf-Zeichen beendet. 11

26 Kapitel 2. Next Generation Network Header Der Header beinhaltet eine Liste mit Attributen. Sie geben Aufschluss über weitere Informationen zur Nachricht. Beispielsweise wird über Attribute das Routing oder eine Identifikation durchgeführt. Die Syntax der Attribute ist dieselbe wie beim HTTP. Auf einen Attributsnamen folgt mindestens ein Attributswert. Syntax: Name: Wert(e) Beispiel: From: Alice Manche Attribute müssen in jeder Nachricht enthalten sein, andere sind optional. Je nach Nachrichtentyp (vgl. Abschn , S. 17) können weitere Attribute verpflichtend sein. Nachfolgend werden die Attribute beschrieben, die in allen Nachrichten enthalten sein müssen [RFC-3261, S ] und anhand eines Beispiels (vgl. Notation 2.3, S. 12) erklärt. From : Alice <sip : alice@atlanta.com >; tag =888 a To: Bob <sip : bob@biloxi.com >; tag =888 b Via : SIP /2.0/ UDP proxy. atlanta.de :5060; branch = z9hg4bk87asdks7 Max - Forwards : 70 Call -ID: com CSeq : 1 INVITE Notation 2.3: Minimalbeispiel eines Headers. Call-ID [RFC-3261, S. 166]: Der Call-ID ist eine eindeutige Identifikation der Sitzung. Über ihn wird die Zusammengehörigkeit der Nachrichten ermittelt. Syntax: Call-ID: Identifikation Beispiel: Call-ID: @atlanta.com CSeq [RFC-3261, S. 170]: Die CSeq ist eine fortlaufende Sequenznummer. Mit ihr wird die aktuelle Nachricht einer Transaction ermittelt. Sie besteht aus einer Zahl und dem Namen der Request-Methode. Die Zahl muss ganzzahlig und maximal 32 bit lang sein. Syntax: CSeq: Sequenznummer Request-Methode Beispiel: CSeq: 1 INVITE From [RFC-3261, S. 172]: Dieses Feld gibt an, wer die Sitzung begonnen hat. Es besteht aus einem optionalen Anzeigenamen und einem Kontakt-URI. Der Anzeigename wird genutzt, um ihn beispielsweise auf dem Display beim Klingeln anzuzeigen. Soll nichts 12

27 2.1. Session Initiation Protocol angezeigt werden, muss Anonymous als Displayname eingetragen werden. Der tag- Wert dient der Zuordnung der Nachricht zu einem Dialog. Syntax: From: Anzeigename SIP URI;tag=Wert Beispiel: From: Alice Max-Forwards [RFC-3261, S. 173]: Der Wert dieses Feldes gibt die maximale Anzahl der Weiterleitungen für diese Nachricht an. Sie wird von jedem passierten Proxy oder Gateway dekrementiert. Erreicht der Wert des Feldes die 0, wird die Nachricht nicht mehr weitergeleitet. Der Standard nennt einen Initialwert von 70 Weiterleitungen. Syntax: Max-Forwards: Anzahl Beispiel: Max-Forwards: 70 To [RFC-3261, S ]: Dieses Header-Feld beschreibt, an wen die Nachricht gesendet werden soll. Genau wie das Header-Feld From besteht es aus einem optionalen Anzeigenamen und einem Kontakt-URI. Wie beim Header-Feld From, kann der Anzeigename zur Darstellung auf dem Display genutzt werden. Entsprechend kann die Angabe des Nutzernamens durch die Angabe des Anzeigenamens Anonymous unterdrückt werden. Der unter To angegebene URI ist derselbe, wie er in der Start-Line angegeben ist. Wie beim From-Header-Feld dient der tag-wert der Zuordnung der Nachricht zu einem Dialog. Syntax: To: Anzeigename <SIP URI>;tag=Wert Beispiel: To: Bob Via [RFC-3261, S ]: Das Header-Feld Via enthält das verwendete Transportprotokoll und die Adresse des Clients. Es hat eine ähnliche Funktion wie ein Logbuch. Jeder durchlaufene Proxy trägt sich hier ein. Somit wird ermöglicht, dass ein Response durch dieselben Proxys wieder zurückfindet. Der Wert des branch-parameters dient der Zuordnung zu einer Transaction. Syntax: Via: Protokoll Adresse:Port;branch=Wert Beispiel: Via: SIP/2.0/UDP proxy.atlanta.de:5060;branch=z9hg4bk87asdks7 Zusätzlich können je nach Anwendung weitere Header-Felder in der Nachricht enthalten sein. Beispielsweise enthält ein INVITE-Request in der Regel eine Medienbeschreibung in seinem Body. Um zu beschreiben was und wie viel im Body transportiert wird, gibt es separate 13

28 Kapitel 2. Next Generation Network Header-Felder. Deshalb werden nachfolgend zusätzliche Header-Felder vorgestellt, die in einer Nachricht vorhanden sein können. Alert-Info [RFC-3261, S. 164]: Das Header-Feld Alert-Info gibt einen URI zu einer Audiodatei an. Erreicht ein INVITE-Request mit diesem Header-Feld ein Endgerät, wird die angegebene Audiodatei als Klingelton genutzt. Unterstützt das Endgerät dieses Header-Feld nicht, wird es ignoriert und mit dem normalen Ton geläutet. Bei einer 180 Ringing-Response ersetzt es das Wartezeichen. Es muss dem Teilnehmer allerdings möglich sein, die Auswertung dieses Header-Feldes zu deaktivieren. Syntax: Altert-Info: <URI> Beispiel: Altert-Info: < Authorization [RFC-3261, S ]: Ist eine Autorisation des anfragenden Teilnehmers nötig, wird dieses Header-Feld von einem UAS oder Registrar (vgl. Abschn , S. 26) eingefügt. Es beinhaltet alle für die Autorisation erforderlichen Informationen (vgl. Abschn , S. 78). Syntax: Authorization: Digest username="nutzername", realm="domain", nonce="nonce", uri="uri", response"geheimnis" Beispiel: Authorization: Digest username="alice", realm="atlanta.com", nonce="ea9c[...]", uri="sips:atlanta.com", response="dfe5[...]" Contact [RFC-3261, S. 167]: Dieses Header-Feld muss in jedem Request enthalten sein, der eine Kommunikation etabliert. Das ist z. B. bei einem INVITE-Request der Fall. Das Contact-Feld enthält einen URI für eine folgende Kontaktaufnahme. Syntax: Contact: <SIP URI> Beispiel: Contact: Event [RFC-3265, S. 7]: Benennt das zu abonnierende Event-Package. Es darf pro SUBSCRIBE-Request maximal ein Event abonniert werden. Syntax: Event: Eventtyp Beispiel: Event: presence Expires [RFC-3261, S ]: Das Expires-Feld gibt an, wie lange eine gesendete Botschaft gültig ist. Die Zeitangabe kann einen Wert von 0 bis Sekunden haben. 14

29 2.1. Session Initiation Protocol Besonders wichtig ist dieser Wert bei der Registrierung (vgl. Abschn , S. 22). Syntax: Expires: Dauer in Sekunden Beispiel: Expires: 7200 P-Asserted-Identity [RFC-3325, S. 8]: Dieses Header-Feld wird zwischen vertrauenswürdigen Netzelementen eingesetzt. Der Sender der Nachricht versichert hiermit, dass er den genannten Teilnehmer kennt und authentifiziert hat. Syntax: P-Asserted-Identity: "Teilnehmername"<SIP URI> Beispiel: P-Asserted-Identity: Privacy [RFC-3323, S ]: Dient der Nutzung eines Privacy-Services (vgl. Abschn. 5.3, S. 86). Je nach Feldwert werden diverse Bereiche der Nachricht anonymisiert. Syntax: Privacy: Privacylevel Beispiel: Privacy: user Proxy-Authenticate [RFC-3261, S ]: Dient der Authentifikation eines Teilnehmers durch einen Proxy (vgl. Abschn , S. 78). Er beinhaltet alle zur Berechnung eines gemeinsamen Geheimnis benötigten Informationen. Syntax: Proxy-Authenticate: Digest realm="domain", nonce="nonce" Beispiel: Proxy-Authenticate: Digest realm="atlanta.com", nonce="ea9c[...]" Proxy-Authorization [RFC-3261, S. 175]: Dieses Header-Feld wird von einem Proxy beigefügt, wenn eine Autorisation (vgl. Abschn , S. 78) gefordert ist. Es beinhaltet alle für die Autorisation erforderlichen Informationen. Syntax: Proxy-Authorization: Digest username="nutzername", realm="domain", nonce="nonce", uri="uri", response"geheimnis" Beispiel: Proxy-Authorization: Digest username="alice", realm="atlanta.com", nonce="ea9c[...]", uri="sips:atlanta.com", response="dfe5[...]" Subscription-State [RFC-3265, S. 15]: Gibt den Status des abonnierten Events an. Der Status kann active (akzeptiert), pending (in Bearbeitung) und terminated (beendet) sein. Ist das Abonnement akzeptiert oder in Bearbeitung, sollte eine Gültigkeits- 15

30 Kapitel 2. Next Generation Network dauer angegeben werden. Wird es abgelehnt, sollte eine Begründung angegeben werden. Syntax: Subscription-State: Status;expires=Dauer;reason=Begründung Beispiel: Subscription-State: active;expires=0 WWW-Authenticate [RFC-3261, S. 182]: Dient der Authentifikation eines Teilnehmers durch einen UAS oder Registrar (vgl. Abschn , S. 78). Dieses Header-Feld beinhaltet einen Nonce-Wert, der in der angegebenen Domain gültig ist. Er dient der Berechnung eines gemeinsamen Geheimnis, das zur Autorisation verwendet wird. Syntax: WWW-Authenticate: Digest realm="domain", nonce="nonce" Beispiel: WWW-Authenticate: Digest realm="atlanta.com", nonce="ea9c[...]" Die oben genannten Header-Felder können für manche Nachrichten verpflichtend sein. Im Umkehrfall ist es in vielen Situationen nicht erlaubt, diese Header-Felder in bestimmten Nachrichten einzusetzen. Um Klarheit zu schaffen, werden diese Eigenschaften hier zusammengefasst (vgl. Tab. 2.1, S. 16). Header-Feld Wo ACK BYE CAN INV MES NOT OPT REG SUB Alert-Info o Authorization R o o o o o o o Contact R o m m o o m Contact 1xx o o o Contact 2xx m m o o o Event R? m m Expires o o o o Expires 2xx o o o m P-Asserted-Identity o o? o o o Privacy o o o o o o o o o Proxy-Authenticate 401 o o o o? o o? Proxy-Authenticate 407 m m m m m m m Proxy-Authorization o o o o o o o o Subscription-State Req? m WWW-Authenticate 401 m m m m m m m WWW-Authenticate 407 o o o? o o? Tab. 2.1: Zusammenfassung der relevanten optionalen Header-Felder. 16

31 2.1. Session Initiation Protocol Die in der Tabelle genannten Abkürzungen in der Spalte Wo geben die betroffenen Nachrichtentypen an. Steht in einer Zeile nichts in dieser Spalte, gelten die Informationen für alle Nachrichten. Wird ein dreistelliger Statuscode angegeben, betrifft die Angabe die entsprechenden Responses oder Response-Gruppen. Sind nur Requests betroffen, wird das Kürzel R angezeigt. Um zu beschreiben, inwiefern ein Header-Feld in einer der Nachrichten vorhanden sein kann, werden folgende Kürzel verwendet: : Das Header-Feld darf in dieser Nachricht nicht verwendet werden. o: Das Header-Feld kann in dieser Nachricht verwendet werden, muss aber nicht. m: Das Header-Feld muss immer in dieser Nachricht vorhanden sein.?: Im Standard wird auf diese Konstellation nicht eingegangen, daher ist kein Zusammenhang bekannt. Body Sofern ein Body vorhanden ist, enthält er zusätzliche Informationen, die für die reine Nachrichtenübermittlung irrelevant sind. Theoretisch kann fast jede Information mit dem SIP tranportiert werden. In der Praxis beläuft sich die Art des Inhaltes auf wenig Verschiedene. Beispielsweise beinhaltet eine MESSAGE-Request (vgl. Abschn , S. 18) die gesendete Nachricht im Klartext. Am wichtigsten ist der Body beim Sitzungsaufbau. Zu dieser Phase wird die Beschreibung der Medieninformationen im Body transportiert. Dafür kommt vor allem das Session Description Protocol (SDP) [RFC-4566] zum Einsatz. Da der Nutzdatenaustausch für diese Arbeit irrelevant ist, wird an dieser Stelle nicht weiter darauf eingegangen Nachrichtentypen Bevor näher auf die Funktionsweise von SIP eingegangen wird, ist es für das Verständnis wichtig, die Nachrichtentypen zu kennen. Bei Prozeduren, wie beispielsweise dem Verbindungsaufbau, werden nur die Namen der Nachrichten zur Beschreibung verwendet. Wie bereits erwähnt, werden die Nachrichten in zwei Nachrichtentypen unterteilt: Requests. Response. Requests initiieren in der Regel eine Kommunikation. Ein Request wird mit dem Senden einer Response vom UAS beantwortet. Im Folgenden werden beide Arten sowie einige wichtige Vertreter beschrieben. 17

32 Kapitel 2. Next Generation Network Requests Um eine Transaction zu starten, sendet der UAC einen Request an den UAS. Requests können von bestätigender Form sein (z. B. ACK). Selbst wenn sie als Bestätigung fungieren sind sie kein Response. Die Methode eines Request wird durch ihren Namen gegeben. Im Folgenden werden die für diese Arbeit relevanten Requests kurz vorgestellt. ACK [RFC-3261, S ]: Der ACK-Request (ACKnowledge) besagt, dass der Response auf den zuvor gesendeten INVITE-Request erfolgreich empfangen wurde. Da diese Nachricht nur bestätigend fungiert, wird sie niemals selbst bestätigt. BYE [RFC-3261, S ]: Wenn Bob das Telefonat beendet, sendet er ein BYE an Alice. Daraufhin kann die Verbindung getrennt werden. CANCEL [RFC-3261, S. 115]: Wenn Alice z. B. während des Klingelns den Hörer auflegt, sendet sie ein CANCEL an Bob. Dadurch wird der Verbindungsaufbau abgebrochen und es kommt keine Verbindung zustande. Bobs Telefon hört auf zu klingeln und Bob weiß, dass er nicht mehr abnehmen muss. INVITE [RFC-3261, S ]: Will Alice mit Bob telefonieren, sendet sie einen INVITE-Request an ihn. Dieser Request kann bereits Informationen über von Alices Endgerät unterstützten Codecs enthalten. Bobs Endgerät gleicht diese angebotenen Codecs mit seinen unterstützten Codecs ab und bestätigt die Übereinstimmungen. Der Verbindungsaufbau wird weiter unten (vgl. Abschn , S. 22) ausführlicher behandelt, daher wird an dieser Stelle nicht weiter darauf eingegangen. Wenn während einer laufenden Sitzung ein INVITE-Request gesendet wird, dient dies in der Regel der Änderung des verwendeten Codecs und wird als re-invite bezeichnet [RFC-3261, S. 16]. MESSAGE [RFC-3428]: Mittels eines MESSAGE-Request kann Alice eine Kurznachricht an Bob senden. Dieser, als Instant Messaging bekannte Service, wurde durch ICQ [ICQ-2009] populär. Ursprünglich wurden nur sehr kurze Nachrichten ausgetauscht. Mit SIP ist diese Beschränkung jedoch nicht mehr gegeben. In der Regel werden diese Nachrichten nicht in Form einer bidirectionalen Kommunikation genutzt. Vielmehr werden sie wie Pager unidirektional verwendet. NOTIFY [RFC-3265, S. 34]: Über ein NOTIFY-Request wird ein Zustandswechsel bekannt gegeben. Der NOTIFY-Request bildet zusammen mit dem SUBSCRIBE-Request die Basis für einen Präsenz-Dienst. Somit kann eine Feundesliste mit dem Onlinestatus aller Freunde realisiert werden. Das Interesse an einem Zustand wird über das Senden des SUBSCRIBE-Requests ausgedrückt. 18

33 2.1. Session Initiation Protocol OPTIONS [RFC-3261, S ]: Nicht alle UAs unterstützen dieselben Codecs, Methoden, Erweiterungen usw. Um einen anderen Teilnehmer nach seinen Fähigkeiten zu fragen, wurde dieser Request definiert. REGISTER [RFC-3261, S ]: Um Telefonate führen zu können, muss sich ein Endgerät im Netz anmelden. Dafür sendet es ein REGISTER-Request an den Location- Service (vgl. Abschn , S. 26). Ein registriertes Endgerät muss sich innerhalb eines bestimmten Intervalls erneut mit einem REGISTER-Request beim Location-Service melden. Somit wird dafür gesorgt, dass nur aktive Teilnehmer registriert bleiben. Will sich ein Teilnehmer vom Netzwerk abmelden, sendet er ein REGISTER-Request mit einem Time-out mit dem Wert 0 an den Location-Service. SUBSCRIBE [RFC-3265, S. 34]: Wenn Alice eine Information bekommen will, wenn Bob sein Telefonat beendet hat und wieder erreichbar ist, sendet sie ein SUBSCRIBE- Request für das Presence-Event Package (vgl. Abschn , S. 99). Sobald Bob fertig telefonieren ist, erhält Alice einen NOTIFY-Request, dass Bob wieder verfügbar ist. Responses Eine Antwort seitens des UAS wird als Response bezeichnet. Diese Nachrichten werden über ein Nummerierungssystem identifiziert, das sich an HTTP [RFC-1945, S ] anlehnt. Eine Nachricht vom Typ 404 bezeichnet beispielsweise analog zum HTTP [RFC-1945, S. 36] einen nicht auffindbaren Teilnehmer. Die Responses haben einen dreistelligen Code als Bezeichner. Zusätzlich zum Code enthält jede Response eine sogenannte Reason Phrase. Maßgeblich für die Verarbeitung ist jedoch nicht die Reason Phrase sondern der dreistellige Code. Zusätzlich werden sie in sechs Gruppen unterteilt, wobei die erste Ziffer des Codes die Gruppenzugehörigkeit angibt. 1xx Provisional: Teilt dem Teilnehmer mit, dass sein Request in Bearbeitung, aber noch nicht abgeschlossen ist. In der Regel ist das Senden und Verarbeiten dieser Nachrichten optional. Deshalb werden in allen Abbildungen in dieser Arbeit die Nachrichten vom Typ 1xx entweder ausgelassen oder mit gestrichelten Linien dargestellt. 2xx Success: Der Request wurde erfolgreich empfangen, verstanden und akzeptiert. 3xx Redirection: Der Teilnehmer ist unter dem angegebenen URI nicht erreichbar. Dieser Response teilt dem UAC mit, wie er den gewünschten Gesprächspartner erreichen kann. 4xx Client Error: Der Request enthält eine fehlerhafte Syntax oder kann bei diesem Server nicht verarbeitet werden. 5xx Server Error: Der Server ist nicht in der Lage, den Request zu bearbeiten. 19

34 Kapitel 2. Next Generation Network 6xx Global Failure: Der Request kann überhaupt nicht verarbeitet werden. Der Standard definiert eine Vielzahl von Responses. Für diese Arbeit sind jedoch nicht alle relevant. Daher werden hier nur die wichtigen Nachrichten näher vorgestellt. 100 Trying [RFC-3261, S. 183]: Der Request ist vom nächsten Kommunikationspunkt erfolgreich empfangen worden. Der Kommunikationspunkt führt jedoch momentan nicht näher spezifizierte Bearbeitungen durch. Beispielsweise kann dies eine Datenbankabfrage sein. 180 Ringing [RFC-3261, S. 183]: Ein INVITE-Request wurde vom UAS empfangen und dieser versucht, den Benutzer ans Telefon zu rufen. 200 OK [RFC-3261, S. 183]: Der Request ist angenommen. 401 Unauthorized [RFC-3261, S. 185]: Der gesendete Request bedarf einer Authentifizierung (vgl. Abschn , S. 78). Die für die Authentifizierung benötigten Informationen werden im Header übertragen. Diese Nachricht wird von einem UAS oder einem Registrar-Server gesendet. 404 Not Found [RFC-3261, S. 186]: Es gibt keinen Teilnehmer unter dem angefragten URI oder unter der besagten Domain. 407 Proxy Authentication Required [RFC-3261, S. 186]: Der gesendet Request bedarf einer Authentifizierung. Die für die Authentifizierung benötigten Informationen werden im Header übertragen. Diese Nachricht wird von einem Proxy-Server gesendet. 433 Anonymity Disallowed [RFC-5079]: Die Annahme des Request wird verweigert, da der anfragende Teilnehmer anonym ist. 434 Suspicious Call [Kut-2008, S. 6]: Der Request wird abgelehnt, weil der anfragende Teilnehmer nicht verifiziert werden konnte. 480 Temporarily Unavailable [RFC-3261, S. 188]: Die angefragte Ressource ist momentan nicht verfügbar. Dies ist der Fall, wenn versucht wurde einen Teilnehmer anzurufen, der momentan offline ist. 481 Call/Transaction Does Not Exist [RFC-3261, S. 188]: Der empfangene Request, kann keiner laufenden Transaction oder keinem laufenden Dialog zugeordnet werden. 486 Busy Here [RFC-3261, S ]: Das Zielsystem wurde erfolgreich kontaktiert, aber der Teilnehmer ist zurzeit Beschäftigt. 489 Bad Event [RFC-3265, S. 35]: Das mittels SUBSCRIBE-Request angefragte Event-Package wird nicht unterstützt. 20

35 2.1. Session Initiation Protocol Adressierung Bei der Internettelefonie gibt es, wie bei der klassischen Telefonie, zu viele Endgeräte, um sie manuell zu vermitteln. Beim Festnetz wird die Zuordnung über Nummern im sogenannten E.164-Format [ITU-2005] durchgeführt. Für SIP wurde ein anderer eindeutiger Identifikationsmechanismus entworfen. Das Schema des sogenannten Session Initiation Protocol Uniform Ressource Identifier (SIP URI) folgt den Richtlinien für Internet-URI [RFC-3986]. Der Aufbau ist stark an den einer -Adresse angelehnt. Genauer hat ein SIP URI die gleiche Syntax wie eine - Adresse, angeführt vom doppelpunktseparierten Präfix sip. Syntax: Beispiel: Der Standard [RFC-3261, S ] sieht vor, dass ein Teilnehmer auf mehreren Endgeräten unter einer Nummer erreichbar ist. Dies lässt sich mit nur einem SIP URI nicht verwalten. Daher sind zwei SIP URI-Typen definiert [RFC-3261, S ], die sich in ihrer Funktion folgendermaßen unterscheiden (vgl. Abb. 2.7, S. 22): Permanenter SIP URI: Der permanente SIP URI wird benutzt, um mit einem Teilnehmer in Kontakt zu treten. Es sind keinerlei Kenntnisse über den Aufenthaltsort des Teilnehmers notwendig. Er besteht aus einem Anschlussnamen, der in der Regel vom Betreiber festgelegt wird. Der Host-Teil hat die gleiche Struktur wie bei einer -Adresse und ist von Betreiber zu Betreiber verschieden. Temporärer SIP URI: Der temporäre SIP URI dient der Zuordnung auf die angemeldeten Endgeräte. Der Anschlussname wird auf die gleiche Weise gebildet, wie bei einem permanenten SIP URI. Anstelle eines Domainnamens wird nach die tatsächliche IP-Adresse des Endgerätes eingesetzt. Somit hat jedes Gerät eine eindeutige Adresse, mit der es lokalisiert werden kann. Um sich die Funktionsweise der beiden SIP URI zu verdeutlichen, kann sich folgendes Szenario vorgestellt werden (vgl. Abb. 2.7, S. 22). Bob bekommt von seinem Telefonanbieter den permanenten SIP URI zugewiesen. In unserem Fall hat Bob einen Computer und ein Handy, die beide VoIP-fähig sind. Wenn sich Bob mit diesen Geräten beim Registrar anmeldet, werden beide Geräte unter einem separaten temporären SIP URI abgelegt. Außerdem erstellt er eine Relation von Bobs permanenten SIP URI zu diesen Einträgen. Wird Bob angerufen, können beide Geräte gleichzeitig angesprochen werden. Das Telefonat wird an das Gerät vermittelt, an dem Bob sich zuerst meldet. 21

36 Kapitel 2. Next Generation Network SIP-Teilnehmer Permanenter SIP-URI Temporärer SIP-URI 1 Temporärer SIP-URI 2 Temporärer SIP-URI n Abb. 2.7: Relation zwischen permanentem und temporärem SIPURI Prozeduren Der Ablauf der Standardprozeduren wird im Standard vom SIP beschrieben [RFC-3261]. Für unsere Betrachtungen sind die Registrierung und der Sitzungsaufbau besonders wichtig. Zum einen entscheiden sie über die Zugangsmöglichkeiten ins Netz, zum anderen wird über den Verbindungsaufbau die Spamübertragung eingeleitet. Damit ein Netzelement die Adresse eines anzusprechenden Netzelementes kennt, fordert es diese beim Domain Name Service (DNS) [RFC-3263] an. Da dieser Schritt für die Darstellung der Prozeduren nicht essenziell ist, wird er hier der Übersichtlichkeit halber nicht aufgeführt. Registrierung Um ein Telefonat initiieren zu können, muss sich ein Teilnehmer zunächst dem Netz bekannt machen. Dies geschieht über die Registrierung. Die Aufenthaltsinformationen über den Teilnehmer werden über den Registrar beim Location Service (vgl. Abschn , S. 24) hinterlegt. Alice Registrar REGISTER 401 Unauthorized REGISTER 200 OK Abb. 2.8: Teilnehmerregistrierung mittels Session Initiation Protocol. Um dem Registrar seine aktuelle Kontaktadresse mitzuteilen [RFC-3261, S ], sendet der UA dem Registrar einen REGISTER-Request. Mit dieser Nachricht übermittelt er alle für die Registrierung wichtigen Informationen (vgl. Notation 2.4, S. 23). Mit der Angabe seines permanenten SIP URI identifiziert sich der Teilnehmer gegenüber dem Registrar. Im Contact-Header-Feld nennt der UA den temporären SIP URI, unter der er momentan erreichbar ist. 22

37 2.1. Session Initiation Protocol REGISTER sip : atlanta. com SIP /2.0 From : Alice <sip : alice@atlanta.com > To: Alice <sip : alice@atlanta.com > CSeq : 1 REGISTER Contact : <sip : alice@ > Expires : 7200 [...] Notation 2.4: REGISTER-Request während der Registrierung. Die Registrierung gilt nur für die Dauer in Sekunden, die das Expires-Header-Feld angibt. Meldet sich der UA bis zum Ablauf der angegebenen Anzahl an Sekunden nicht erneut beim Registrar, wird die Registrierung aufgehoben. Mit dieser Regelung wird verhindert, dass ein UA im Falle eines UA-Absturzes registriert bleibt. Will sich der Teilnehmer gezielt Deregistrieren, sendet er einen erneuten REGISTER- Request an den Registrar. Um zu signalisieren, dass er sich abmeldet, trägt der UA eine Gültigkeitsdauer von null Sekunden ein. Die Registrierung läuft dadurch direkt wieder ab und der Registrar hebt diese wieder auf. Aus Gründen der Sicherheit schreibt der Standard [RFC-3261, S. 64] vor, die Registrierung zu authentifizieren. Inwieweit sich der Registrierungsprozess dadurch verändert, wird in dieser Arbeit detailliert dargestellt (vgl. Abschn , S. 78). Sitzungsaufbau Zum Sitzungsaufbau gehört nicht nur der reine Aufbau einer Punkt-zu-Punkt-Verbindung, sondern ebenso das Auffinden des Zielteilnehmers. Wie anfangs erwähnt, ist es mit SIP möglich, auf mehreren Geräten erreichbar zu sein. Um eine Kommunikationsverbindung zwischen zwei Teilnehmern aufzubauen, verwendet SIP analog zum TCP den Three-Way-Handshake (vgl. Abb. 2.9, S. 23). Alice sendet in der Rolle des UAC einen INVITE-Request an Bob. Sobald Bob das Telefonat annimmt, sendet sein UA einen 200 OK-Response als Bestätigung an Alice zurück. Falls Alice nach wie vor an der Kommunikation interessiert ist, sendet sie ein ACK an Bob. Alice INVITE 200 OK ACK Bob Abb. 2.9: Der Three-Way-Handshake. 23

38 Kapitel 2. Next Generation Network Warum sind für eine Kommunikationsverbindung drei Schritte notwendig? Bei einem normalen Nachrichtenaustausch reichen normalerweise zwei Nachrichten aus! Der Grund liegt in der unterschiedlichen Antwortzeit. Bei einem normalen Request antwortet eine Maschine, wodurch sehr schnell ein Response zustande kommt. Im Falle eines INVITE muss der angerufene Teilnehmer auf das Klingeln des Telefons reagieren. Bis er das getan hat, kann es sein, dass der Anrufende längst aufgelegt hat. Der Three-Way-Handshake dient demnach der Sicherung, dass nach wie vor beide Teilnehmer an einer Verbindung interessiert sind Netzelemente SIP benötigt für seine Funktionsfähigkeit die Unterstützung einiger Netzelemente. Eine Ausnahme bildet der B2BUA, er wird nicht zwangsweise benötigt. In der Praxis hat sich jedoch gezeigt, dass er aus Sicherheitsgründen oft eingesetzt wird. Im Folgenden werden diese Netzelemente vorgestellt. User Agent Wenn ein Teilnehmer einen anderen Teilnehmer anrufen will, benötigt er dafür eine Schnittstelle. Diese Schnittstelle bietet sich in Form eines UA. Der Standard [RFC-3261] nennt keine Vorgaben, wie die Gestalt eines UA zu sein hat. Diese Entscheidung wurde aus Gründen der Flexibilität getroffen, um zukünftigen Entwicklungen nicht im Wege zu stehen. Heute können UAs anhand ihres Aufbaus grob in zwei Gruppen unterteilt werden: 1. Hard-Phone. 2. Soft-Phone. Bei einem Hard-Phone (vgl. Abb. 2.10(a), S. 25) handelt es sich um eine komplette Einheit. Sie sind in der Regel konstruiert wie ein herkömmlicher Telefonapparat mit einigen Zusatztasten für die erweiterte Funktionalität (z. B. eine Taste, um die ausgehende Identität zu wählen). Technisch eher unversierte Nutzer haben es mit dieser Version eines UAs deutlich leichter, da die Handhabung sehr nah am gewohnten Festnetztelefon ist. Ein Soft-Phone (vgl. Abb. 2.10(b), S. 25) ist ein UA der nur in Form einer Software existiert. Es benötigt eine laufende Trägerplattform wie einen Computer, um einsatzfähig zu sein. Der Vorteil dieser Variante ist, dass er sehr leicht ausgetauscht und erweitert werden kann. Unabhängig von der Art des UAs ist seine eigentliche Funktion immer gleich. Er ist dazu da Telefonate zu erzeugen, zu terminieren und zu verwalten. Zusätzlich kann der UA Zusatzfunktionen unterstützen. Viele UAs bieten die Möglichkeit, Videotelefonate oder Konferenzen zu führen. Da der Fokus dieser Arbeit auf SPIT liegt, wird auf derartige Zusatzfunktionen nicht weiter eingegangen. 24

39 2.1. Session Initiation Protocol (a) Hard-Phone [sno-2009]. (b) Soft-Phone [HSC-2009]. Abb. 2.10: Beispiele für einen User Agent. Proxy Wenn ein Telefonat aufgegeben wird, ist der Proxy [RFC-3261, S ] die erste Anlaufstelle. Er nimmt den Telefonwunsch entgegen, wertet ihn aus und leitet ihn in Richtung des Zielteilnehmers weiter. Bevor der Proxy die Nachricht verarbeitet, überprüft er zunächst die Berechtigung des Teilnehmers. Ist der Teilnehmer berechtigt, wird die Nachricht auf syntaktische Fehler und Korrektheit des Inhalts überprüft. Beispielsweise werden die angegebenen Codecs auf ihre Unterstützbarkeit untersucht. Sind die Nachricht und der Teilnehmer verifiziert, schreibt oder entfernt der Proxy gegebenenfalls Informationen innerhalb der Nachricht. Ein Statefull-Proxy muss seine Adresse über das Via-Header-Feld eintragen, um an der Kommunikation beteiligt zu bleiben. Zur Weiterleitung der Nachricht überprüft der Proxy, ob sich der Zielteilnehmer im Heimatoder in einem Fremdnetz befindet. Ist er selbst für diesen Teilnehmer zuständig, fragt er beim Location-Server den temporäre SIP URI des Teilnehmers an. Anschließend leitet er die Nachricht an einen anderen Proxy weiter. Der Aufbau dieses Verfahrens der Weiterleitung ist bekannt als SIP-Trapezoid [RFC-3261, S. 118], da sich die Kommunikation hier in einem Trapezoid darstellen lässt (vgl. Abb. 2.11, S. 26). Proxys werden zwischen Statefull und Stateless unterschieden. Diese beiden Proxys verhalten sich im Wesentlichen in der Verarbeitung der Nachrichten anders. Wie der Name bereits andeutet, ist der Stateless-Proxy [RFC-3261, S ] nicht in der Lage Informationen länger zu speichern. Geht bei ihm eine Nachricht ein, wird sie verarbeitet und weitergeleitet. Anschließend hat der Stateless-Proxy keinerlei Informationen mehr über diese Nachricht. Ein Statefull-Proxy [RFC-3261, S ] ist dagegen in der Lage, sich eine Kommunikation zu merken. Dadurch kann nur der Statefull-Proxy einen Anruf an mehrere UAs splitten 25