IP - Telefonie / Streaming

Größe: px
Ab Seite anzeigen:

Download "IP - Telefonie / Streaming"

Transkript

1 IP - Telefonie / Streaming Sicherheit in Applikationsprotokollen Wintersemester 2011/12 Peter Knapp MatrNr: November 2011

2 Inhaltsverzeichnis 1 Session Initiation Protokoll Einleitung SIP Entities SIP Nachrichten Requests Responses Header / Body Kommunikationsbeispiele Registrierung Sitzung aufbauen und beenden Sitzung über einen Proxy Sicherheitsaspekte in SIP Gefahren und Risiken HTTP Authentifizierung S/MIME Sicherheit im Transport und Netzwerk Layer H Information Streams Protokolle und Codecs Netzwerk Komponenten Terminals Multipoint Control Units Gateways Gatekeepers Beispiel Kommunikation Inter Asterisk exchange Peer Verhalten und Nachrichten Registration Call Link Managment Call Control Call Path Optimization Mid Call Behavior Call Tear Down Network Monitoring Digit Dialing Miscellaneous Media Messages Struktur der Frames Full Frames Mini Frames Meta Frames Verschlüsselung und Authentifizierung

3 4 Real Time Transport Protokoll & RTP Control Protokoll RTP RTCP RTCP Paket Format Sicherheit Secure Real Time Transport Protokoll 21 1 Session Initiation Protokoll 1.1 Einleitung Das Session Initiation Protokoll (SIP)[10] ist ein Applikationsprotokoll, welches dazu dient Sitzungen (sessions) zwischen einen oder mehreren Teilnehmern aufzubauen. Weiters können diese verändert, sowie auch beendet werden. Mit Hilfe von SIP können sich die Teilnehmer auf Eigenschaften einer Sitzung einigen. Eine Sitzung ist in diesem Kontext der Austausch von Daten zwischen einer Gruppe von Teilnehmern. Mögliche Szenarien sind zum Beispiel Internet-Telefonanrufe, Multimedia Verbreitung und auch Multimedia Konferenzen. Das Protokoll selbst wird dabei nicht zur Datenübertragung verwendet. Diese wird von anderen Protokollen übernommen, welche Real Time Multimedia-Daten übertragen können. Das Session Initiation Protokoll bietet diesen Anwendungen die Endpunkte der Verbindung (genannt user agents). Um diese und weitere Funktionen gewährleisten zu können, wird eine Netzwerk Infrastruktur (proxy server) aufgebaut, welche dazu verwendet wird um user agents zu registrieren, Einladungen zu Sitzungen und andere Anfragen zu bearbeiten. SIP bietet dabei fünf Aspekte des Auf- und Abbaus von Multimedia-Sitzungen: User Location: Das Finden des Endpunktes der Kommunikation. User Availability: Bestimmung ob der Teilnehmer gewillt ist an der Sitzung teilzunehmen. User Capabilities: Einigung auf Medien und Multimediaparameter welche in der Sitzung verwendet werden sollen. Session Setup: Benachrichtigung des angerufenen Teilnehmers über den Anruf, sowie das Festlegen der Sitzungsparameter. Session Managment: Transfer und Beendigung von Sitzungen, die Veränderung der Sitzungsparameter und der Aufruf von weiteren Services. Zu beachten ist allerdings, dass SIP kein Kommunikationssystem ist, sondern ein Teil einer Multimediakommunikation, welche auch andere Protokolle, wie zum Beispiel RTP, beinhaltet. Auch anzumerken ist, dass SIP selbst keine zusätzliche Services bietet, allerdings werden Primitive angeboten, über die man einen Service implementieren kann. Als Beispiel kann man mit SIP ein Objekt übermitteln, welches dann verwendet werden kann um einerseits Sitzungsparameter anderer Protokolle, oder auch Bilder beziehungsweise andere Medien zu übertragen. Ein weiterer wichtiger Punkt ist, dass das Session Initiation Protokoll eine Reihe an Sicherheitsfunktionen bietet. Diese sind eine DoS Prevention, Authentifizierung zwischen den Teilnehmern und auch zwischen Teilnehmern und Proxy Servern, sowie der Schutz von Integrität und Verschlüsselung. 2

4 1.2 SIP Entities Im Session Initiation Protokoll gibt es 4 logische Entitäten, wobei eine physische Ressource durchaus in mehreren Rollen tätig sein kann. User Agent: Der User Agent ist ein Endpunkt der Verbindung. Diese starten und beenden die Sitzungen indem sie Requests (1.3.1) und Responses (1.3.2) austauschen. Dabei enthält der User Agent zwei Teile. Einerseits den User Agent Client (UAC) welcher SIP Requests startet und andererseits der User Agent Server welcher den Nutzer über eintreffende Requests informiert und im Auftrag des Nutzers Responses versendet. Proxy Server: Ein Proxy Server ist eine Entität welche als Client, wie auch als Server im Auftrag anderer Clients handelt um Requests zu versenden. Der Request kann entweder intern bearbeitet werden oder dieser wird weitergegeben (auch an andere Server). Redirect Server: Dieser akzeptiert Requests und bildet die SIP Adresse des gerufenen Teilnehmer auf null ab wenn es keine bekannte Adresse zu diesem gibt oder gibt die neuen Adressen des Teilnehmers zurück. Der Redirect Server leitet allerdings keine Requests an andere Server weiter. Registrar: Dies ist ein Server, der REGISTER Requests akzeptiert um dessen Kontakt Informationen zu speichern. 1.3 SIP Nachrichten Es wird der UTF-8 Zeichensatz in SIP verwendet, da es ein textbasiertes Protokoll ist. Es gibt zwei Arten von Nachrichten. Die erste ist der Request, welcher von einem Client zum Server gesendet wird und die zweite Art der Response vom Server zum Client. Der Aufbau beider Nachrichten ist an sich gleich und unterscheidet sich nur in der Statuszeile, wie der folgende Auszug aus [10] zeigt: generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line Requests Ein SIP Request beginnt immer mit einer Request Line, welche den Methoden Namen, die Request URI, sowie die Protokoll Version beinhaltet und diese sind durch ein Leerzeichen getrennt. Es gibt sechs verfügbare Methoden: 1. REGISTER: Registriert einen Teilnehmer am Proxy mit seinen Kontakt Informationen 2. INVITE: Baut eine Sitzung auf 3. ACK: Akzeptiert eine Sitzung 4. CANCEL: Bricht einen Sitzungsaufbau ab 3

5 5. BYE: Beendet eine Sitzung 6. OPTIONS: Erfragen der Funktionen des Servers Die Request URI ist eine SIP oder SIPS URI (Uniform Resource Indicator), welche den Teilnehmer oder Service beschreibt, der von dem Request angefordert wird. In einer URI sind ausreichend Informationen enthalten um eine Sitzung mit der Ressource aufbauen und aufrechterhalten zu können. Beispiele für eine Ressource sind ein User eines Online Services, eine Mailbox eines Nachrichtensystems, oder auch eine Abteilung einer Organisation. Der Unterschied zwischen einer SIP und einer SIPS URI besteht darin, dass bei Angabe einer SIPS URI eine sichere Verbindung über TLS zwischen dem user agent client (UAC) und der Domain der URI verwendet werden muss. Innerhalb der Domain bestimmt die Sicherheitspolitik der Domain, welche Sicherheitsmaßnahmen verwendet werden. Außerdem kann jede Ressource, die mit einer SIP URI, beschrieben ist aufgewertet werden zu einer SIPS URI, wenn sicher kommuniziert werden soll. Die obige Zeile ist der Aufbau einer SIP, bzw. SIPS URI, wobei bei der SIPS Version das "sip:" durch "sips:" ersetzt wird. Die einzelnen Teile dieser URI sind einerseits die User Information, welche "user" und "password" beinhaltet. Es ist allerdings aus sicherheitstechnischen Gründen nicht empfehlenswert "password" zu verwenden, da in diesem Fall das Passwort im Klartext übertragen wird. Insofern das Zeichen vorhanden ist, muss der "user" angegeben werden, ansonsten kann auch ein Host alleine angegeben werden (wenn dieser zb. keine User verwaltet oder selbst die Ressource ist). Der "host" enthält entweder einen Fully Qualified Domain Name oder eine IPv4/IPv6-Adresse. Die "uri parameters" können beliebig viele sein, dürfen sich allerdings nicht wiederholen und sind von der Form parameter name = parameter Wert. Hier kann man beispielsweise das Transportprotokoll angeben (TCP/UDP/SCTP). Mit den "?headers" kann man noch Header Felder in der URI angeben. Diese müssen von der Form hname = hvalue sein Responses Im Fall einer Response beginnt die Nachricht mit einer Status-Line, welche wie folgt aufgebaut ist: Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Es gibt die folgenden Status Codes aus [10]: 1xx: Provisional -- request received, continuing to process the request; 2xx: Success -- the action was successfully received, understood, and accepted; 3xx: Redirection -- further action needs to be taken in order to complete the request; 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; 6xx: Global Failure -- the request cannot be fulfilled at any server. Beispiele für Status Codes sind in Tabelle 1 gegeben. 4

6 Status Code Beschreibender Text Status Code Beschreibender Text 100 Trying 420 Bad Destination 180 Ringing 421 Extension Required 181 Call Is Being Forwarded 423 Interval Too Brief 182 Queued 480 Temporarily Unavailable 183 Session Progress 481 Call/Transaction Does Not Exist 200 OK 482 Loop Detected 300 Multiple Choices 483 Too Many Hops 301 Moved Permanently 484 Address Incomplete 302 Moved Temporarily 485 Ambiguous 305 Use Proxy 486 Busy Here 380 Alternative Service 487 Request Terminated 400 Bad Request 488 Not Acceptable Here 401 Unauthorized 491 Request Pending 402 Payment Required 493 Undecipherable 403 Forbidden 500 Server Internal Error 404 Not Found 501 Not Implemented 405 Method not allowed 502 Bad Gateway 406 Not Acceptable 503 Service Unavaillable 407 Proxy Authentication Required 504 Server Time Out 408 Request Timeout 505 Version Not Supported 410 Gone 513 Message Too Large 413 Request Entity Too Large 600 Busy Everywhere 414 Request URI Too Long 603 Decline 415 Unsupported Media Type 604 Does Not Exists Anywhere 416 Unsupported URI Scheme 606 Not Acceptable Tabelle 1: Status Codes in SIP Header / Body Jedes Header Feld besteht aus Paaren wie folgt: "field-name: field-value". Dabei ist es unerheblich wie viele Leerzeichen darin vorkommen und es werden auch field value Werte erlaubt, welche sich über mehrere Zeilen erstrecken, solange die darauffolgenden Zeilen mit Tabs oder Leerzeichen beginnen. Die Reihenfolge der Headerfelder ist ebenfalls unerheblich, allerdings ist es empfohlen die Proxy-relevanten Felder zuerst anzuführen. Es ist auch möglich gleiche Headerfelder mehrmals anzuführen. Dabei muss es möglich sein diese Felder in ein einziges umzuschreiben in eine durch Beistriche getrennte Liste. Die Reihenfolge der gleichen Felder ist auch entscheidend. Requests, wie auch Responses können einen Body enthalten, wobei dieser abhängig von der Request Methode ist. Im Fall einer Response wird der Inhalt des Body von der Methode und dem Rückgabe Code der Response bestimmt. Der Medientyp des Body muss von einem Content Type Header Feld bestimmt werden und insofern der Body in irgendeiner Form codiert wurde (zb. komprimiert), ist dies auch im Header als Content Encoding anzugeben. Ebenfalls können binäre Teile im Body enthalten sein, sowie "multipart" MIME Typen. Die Länge ist im Header per Content Length anzugeben. 5

7 1.4 Kommunikationsbeispiele Registrierung Zu Beginn muss sich ein Teilnehmer, in diesem Fall Bob, bei einem Registrar anmelden, sodass er auch von anderen Teilnehmern gefunden werden kann. Dies geschieht mit den Nachrichten REGISTER und der Antwort 200 OK: REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hg4bknashds7 Max-Forwards: 70 To: Bob From: Bob Call-ID: CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 SIP/ OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hg4bknashds7 ;received= To: Bob From: Bob Call-ID: CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: Sitzung aufbauen und beenden Hier wird versucht eine Sitzung zwischen zwei Teilnehmern aufzubauen, wobei auch ein Warten in einer Warteschlange angeführt ist. Die Vollständigen SIP Nachrichten werden nicht mehr aufgeführt, allerdings sind in der Grafik 1 die Abläufe und Funktionen bzw. Status Codes ersichtlich. Zwischen "7: ACK" und "1 BYE" ist die Sitzung im Gange und zb. ein IP-Telefongespräch läuft Sitzung über einen Proxy In dem Beispiel in Grafik 2 sieht man den Sitzungsaufbau über einen Proxy Server, welcher der Request weiterleitet. Weiters sieht man, dass nach dem OK beide Endpunkte ohne den Server weiter kommunizieren. 1.5 Sicherheitsaspekte in SIP Gefahren und Risiken Eine Gefahr besteht darin, dass ein Angreifer die Registrationseinträge bei einem Registrar ändert. Da es für Berechtige Personen möglich ist diese Daten für andere zu ändern, kann es einem Angreifer gelingen diese Rechte zu erhalten und somit alle Informationen 6

8 Abbildung 1: Aufbau einer SIP Sitzung und Beenden dieser, Quelle: [16] so zu verändern, dass anstelle der eigentlichen Empfänger, seine selbst angegebenen Empfänger die Nachrichten erhalten. Daher ist es sehr wichtig die Urheber eines Requests authentifizieren zu können. Eine weitere Möglichkeit wäre, dass ein Angreifer sich für einen anderen Server ausgibt und so kann er Nachrichten die über den eigentlichen Server gehen sollten abfangen und falsch bzw. gar nicht weitergeben. Somit sollten auch UA s die Möglichkeit haben Server zu authentifizieren. Proxy Server werden oft benötigt um Nachrichten weiterzuleiten. Diesen muss vertraut werden ob durch Authentifizierung oder durch guten Willen. Dennoch möchte man oft nicht, dass diese den Nachrichten Body lesen können. Wenn zum Beispiel Verschlüsselungsinformationen im Body übertragen werden, sollten diese nicht mitgelesen werden. Möglich wäre auch, dass ein solcher Server die nachfolgenden verschlüsselten Nachrichten liest, oder gar die Schlüssel ändert und auch Sicherheitsanforderungen vermindert. Wenn darin Informationen über RTP vorhanden sind, könnten auch diese so verändert werden, dass folgende Medien Ströme auf andere Devices ebenfalls übertragen werden um dort mitzuhören. Insofern ein Angreifer Nachrichten mitgelesen hat und er die Parameter der Sitzung kennt, könnte er zu einem späteren Zeitpunkt die Parameter ändern, indem er Nachrichten an beide Parteien sendet. Er kann auch BYE an beide senden, womit die Sitzung sofort beendet würde. Denial of Service Attacken sind ebenso denkbar, wenn beispielsweise Nachrichten mit falschem Absender an tausende Empfänger gesendet werden. Durch die Menge an Antworten könnte der vermeintliche Absender außer Gefecht gesetzt werden HTTP Authentifizierung Das Session Initiation Protokoll bietet einen zustandlosen Mechanismus der mit Hilfe von Aufgaben funktioniert. Dieser dient zur Authentifizierung und basiert auf dem Mechanismus in HTTP. Der grundlegende Nutzer davon ist, dass ein User Agent oder Proxy Server, 7

9 Abbildung 2: Aufbau einer SIP Sitzung über einen Proxy, Quelle: [16] der einen Request erhält, feststellen kann ob der Teilnehmer autorisiert ist, den Request zu stellen. Ein UAS sowie ein Registrar oder Redirect Server wird auf einen Request mit einem 401 Unauthorized antworten und so diesen Authentifizierungsmechanismus anfordern. Ein Proxy Server hingegen wird mit 407 Proxy Authentication Required antworten. In dem RFC 2617[9] ist der HTTP Authentifizierungsmechanismus beschrieben. Dieser wird, wie bereits erwähnt auch für SIP verwendet. Die Header Felder Proxy Authenticate, Proxy Authorization, WWW Authenticate und Authorization werden genau gleich verwendet wie bei HTTP. Wichtig anzumerken ist allerdings, dass SIP den Gebrauch des "Basic" Schemas nicht erlaubt. Es muss die "Digest Access Authentication" verwendet werden. Der Digest Mechanismus verlangt ein Shared Secret, welches nicht im Klartext übertragen wird. Standardmäßig wird für die Berechnung der Md5 Algorithmus verwendet, andere sind allerdings auch möglich. Wenn mit 401 geantwortet wird, so muss eine Aufgabe per WWW Authenticate übermittelt werden und im Fall einer 407 Antwort wird die Aufgabe mit Proxy Authenticate übertragen. Der Teilnehmer, der sich authentifizieren will, wird als Antwort in seinen Request entweder das Authorization Header Feld oder das Proxy Authorisation Feld einbauen. Im Gegensatz zu HTTP wird in SIP der "realm string" nicht als canonical-root-url verwendet, da es diese in SIP nicht gibt. Wichtig ist aber, dass der "realm string" global eindeutig sein muss und es empfohlen ist einen Hostnamen, oder Domainnamen zu verwenden. Weiters ist es nicht möglich ein ACK oder CANCEL zu authorisieren. Da auf ein ACK keine Antwort erwartet wird, kann man hier auch keine Challenge in der Antwort senden. Somit muss ein Empfänger ein ACK akzeptieren, das die gleichen Zugangsdaten wie vorangegangene Requests von dem Sender beinhaltet. Ein CANCEL wird akzeptiert, wenn es von dem gleichen Hop kommt, der auch den zu terminierenden Request gesendet 8

10 hat. Dies kommt daher, dass ein CANCEL nicht mehrmals gesendet werden kann. User zu User Authentifizierung Insofern ein UAS einen Request erhält, kann er entscheiden diesen zuerst zu authentifizieren bevor er den Request bearbeitet. Wenn auch keine Nutzerdaten bereitstellt, können diese gefordert werden mit dem 401 Status Code in der Antwort. Wobei ein WWW Authenticate im Header vorhanden sein muss. Dieser hat beispielsweise diese Form: WWW-Authenticate: Digest realm="biloxi.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Möchte sich der UAC nun authentifizieren kann er den Request erneut senden mit dem folgenden Header Feld: Authorization: Digest username="bob", realm="biloxi.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", qop=auth, nc= , cnonce="0a4f113b", response="6629fae49393a c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" Proxy zu User Authentifizierung In diesem Fall geschieht die Authentifizierung gleich wie oben, nur dass hier vom Proxy mit 407 und dem Proxy Authenticate geantwortet wird. Wenn mehrere Proxy Server am Weg liegen müssen diese die 407 Antwort weiterleiten an den User und dürfen Proxy Authenticate nicht verändern. Der Teilnehmer muss wieder seine Nutzerinformationen angeben für diese Proxy und den Request erneut senden S/MIME Da SIP Nachrichten MIME Bodies haben können, ist es auch möglich S/MIME zu verwenden. Die S/MIME Zertifikate, welche für Endnutzer verwendet werden, unterscheiden sich von Server Zertifikaten. Der Unterschied liegt darin, dass sichergestellt werden muss, dass das Zertifikat einem Endnutzer gehört und daher wird eine Endnutzeradresse verwendet. Dies ist von der Form Die Zertifikate beinhalten auch die Schlüssel, welche zum signieren oder verschlüsseln der Nachrichten Bodies verwendet werden. Ein Problem hier ist, dass es keine Stelle gibt welche Zertifikate für Endnutzeranwendungen ausgibt, dennoch sollten Nutzer versuchen Zertifikate von öffentlichen Stellen zu erhalten. Der Schlüsselaustausch kann auch mit SIP vonstatten gehen. Wenn eine CMS SignedData Nachricht in S/MIME verwendet wird, so muss das Zertifikat mit dem public Key, der nötig ist um die Signatur zu prüfen, enthalten sein. Wichtig ist dass S/MIME Implementierungen zumindest SHA1 für die Signierung und 3DES als Verschlüsselungsalgorithmus unterstützen müssen. 9

11 SIP Header Geheimhaltung und Integrität mit S/MIME Um eine gewisse End-to-End Authentifikation, Integrität oder Vertraulichkeit für SIP Header sicherstellen zu können, kann man ganze SIP Nachrichten mit S/MIME als MI- ME Bodies mit den "message/sip"typ einpacken. Somit kann man darauf die Sicherheitsmöglichkeiten von S/MIME anwenden. Allerdings sind diese eingepackten SIP Requests Kopien des äußeren Header oder auch Erweiterungen dazu. Somit kann man überprüfen, ob der äußere Header verändert wurde. Insofern nun ein UAS eine solche getunnelte SIP Nachricht erhält, soll dieser auf gleiche Art und Weise antworten. Normale MIME Bodies sollten allerdings in der inneren Nachricht angehängt werden, sodass diese auch von der MIME Sicherheit profitieren Sicherheit im Transport und Netzwerk Layer In diesem Fall gibt es zwei Möglichkeiten Geheimhaltung und Integrität zu gewährleisten. Einerseits die Verwendung von IPsec, das vor allem verwendet werden kann wenn bereits bekannte Stellen miteinander kommunizieren und es kann auch auf einer Hop to Hop Basis verwendet werden. Andererseits gibt es die Möglichkeit TLS über TCP zu verwenden, indem man eine SIPS-URI verwendet. Dies ist am Besten zu verwenden, wenn sich die Parteien nicht von vornherein vertrauen. Der Nachteil ist allerdings, dass vom einen Ende zum anderen die Verbindung über Hops geht, weil auch bei den Hops (zb. Proxy Server) das Via-Feld gesetzt wird. Daher kann man sich nicht sicher sein, dass die ganze Verbindung über TLS geht, da ein Hop dazwischen kein TLS zum nächsten Hop verwendet könnte. Die minimal implementierte Verschlüsselungsumgebung muss TLS_RSA_WITH_AES_128_CBC_SHA sein. 2 H.323 Die ITU-T Recommendation H.323[15, 5] deckt die Voraussetzungen ab, welche für Multimedia Kommunikation nötig sind. Die Komponenten sind Terminals, Gateways, Gatekeeper, Multipoint Controllers, Multipoint Processors und Multipoint Control Units. Nicht alle dieser Komponente sind für eine Kommunikation von Nöten, aber zu mindestens zwei Terminale müssen vorhanden sein. Mit Hilfe von Kontrollnachrichten wird zwischen diesen Komponenten kommuniziert. Diese Kommunikation geschieht mit Information Streams. 2.1 Information Streams Diese Streams werden benötigt, damit Telefonkomponenten kommunizieren können und werden wie folgt unterteilt: Audio Signals beinhalten digitalisierte codierte Sprache. Dieses Signal wird von einem Audio Control Signal begleitet. Video Signals beinhalten digitalisierte und codierte bewegte Bilder, also Videos und wird von einem Video Control Signal begleitet. Data Signals bestehen aus Bildern, Dokumenten, Dateien und anderen Datenströmen. Communication Control Signals geben Kontrollinformationen zwischen den einzelnen funktionalen Elementen weiter und werden zb. für das Öffnen und Schließen logischer Kanäle verwendet. 10

12 Call Control Signals werden zb. für das Aufbauen und Beenden von Anrufen verwendet. Diese Information Streams sind nach der ITU-T Rec. H.225.0[14] formatiert und werden auch wie dort beschrieben versendet. 2.2 Protokolle und Codecs H.323 benötigt und definiert einige weitere Protokolle und Codecs. Die verwendeten Codecs sind für die Audio Kommunikation G.711, G.729, G.723.1, G.726, G.722, G.728, Speex. Für die Video Übertragung wird H.261, H.263, H.264 verwendet und für Texte T.140. Zumindest G.711 und H.261 sind notwendig und müssen implementiert sein. Für die Kommunikation zwischen den einzelnen Komponenten werden verschiedene Protokolle verwendet. Darunter wird H für die Registration, Administration und den Status (RAS) zwischen Terminal und Gatekeeper verwendet, sowie für die Anruf Kommunikation zwischen zwei beliebigen Komponenten. H.245 ist ein Kontrollprotokoll, welches für die Multimediakommunikation verwendet wird um die Fähigkeiten der Komponenten auszutauschen und um logische Kanäle zu öffnen und zu schließen. Für das Senden von Multimedia Information wird in der Regel RTP verwendet. Es können auch noch weitere Protokolle verwendet werden. Von diesen ist zum Beispiel H.235 zu erwähnen, welches Sicherheitsaspekte für Signalströme, wie Multimediaströme für H.323 beschreibt. In dieser Recommendation werden die Sicherheitsvorkehrungen, wie in Grafik 3 gezeigt, beschrieben. Abbildung 3: Sicherheit für H.323 laut H.235, Quelle: [13] 2.3 Netzwerk Komponenten Terminals Dies sind die grundlegenden Komponenten, die auch bei jedem Nutzer vorhanden sind. Sie sind beispielsweise in IP-Telefonen eingebaut. Ein Terminal verwaltet einen Protokollstack, der zumindest die notwendigen oben beschriebenen Protokolle und Codecs unterstützt. In Grafik 4 sieht man den Aufbau von H.323 und die Protokolle bzw. Codecs wie sie zusammenarbeiten. 11

13 Abbildung 4: Überblick über H.323, Quelle: [6] Multipoint Control Units Diese besteht aus zwei Teilen, dem Multipoint Controller und dem Multipoint Processor. Sie dienen dazu Konferenzen mit mehreren Teilnehmern zu verwalten und es ist zum Beispiel möglich, dass nicht nur die Audio Daten aller Teilnehmer gemixt werden und man so alle hört, sonder dass man auch die Video Daten aller Teilnehmer bekommt und so alle seine Gesprächsteilnehmer nicht nur hört, sondern auch sieht Gateways Diese ermöglichen die Kommunikation zwischen H.323 Netzwerken und anderen Netzwerken, wie dem Festnetz (PSTN) oder ISDN Netzwerken. Insofern ein Teilnehmer kein H.323 Terminal verwendet, müssen die Daten über ein Gateway zu dem Teilnehmer gesendet werden. Das Gateway ermöglicht somit die Kommunikation zwischen dem Festnetz und IP-Telefonen Gatekeepers Gatekeepers sind optionale Komponenten, die allerdings verschiedene Funktionen für die anderen Komponenten bereitstellen. Dazu gehört die Registrierung der Endpunkte, Auflösung von Adressen und auch Authentifizierung. Sehr wichtig ist dabei die Auflösung von Adressen, da somit auch Teilnehmer kommunizieren können, die ihre gegenseitigen IP-Adressen nicht kennen. Ein Gatekeeper kann in zwei Modi arbeiten. Einerseits "direct routed", er löst also nur die Adresse auf und die Teilnehmer kommunizieren dann direkt miteinander und andererseits "gatekeeper routed". Dies heißt dass der ganze Datenverkehr weiterhin vom einen Teilnehmer zum Anderen über den Gatekeeper läuft. Die Kommunikation zwischen Terminal und Gatekeeper, sowie zwischen Gatekeeper läuft über RAS. 12

14 2.3.5 Beispiel Kommunikation Eine mögliche Kommunikation mit H.323 zwischen zwei Terminals könnte wie in Grafik 5 aussehen. Abbildung 5: Kommunikation über H.323, Quelle: [7] 3 Inter Asterisk exchange Das Inter Asterisk exchange Protokoll (IAX)[12] ist ein Protokoll der Anwendungsschicht, das zur Kontrolle und Übertragung von Multimediainhalten dient. Es wird hauptsächlich im Bereich der Voice over IP Anruf Kontrolle verwendet, kann aber auch mit anderen Multimediainhalten verwendet werden. IAX ist ein offenes Protokoll, das ursprünglich von Asterisk, einer Software, die die Funktionalität einer Telefonanlage abdeckt, verwendet wurde. Es ist weiters ein binäres Protokoll, vor allem um Overhead in Hinblick auf VOIP Verbindungen zu reduzieren. Es verwendet auch den Ansatz, dass UDP als Transportprotokoll verwendet wird und Daten immer auch an einen einzelnen Port gesendet werden. Dies sollt helfen den Verkehr leichter zu erkennen und durch Firewalls durchzulassen. Die Grundstruktur dabei ist, dass 13

15 IAX Signale und mehrere Medienströme über einen UDP Strom zwischen zwei Rechnern bündelt. Es wird der UDP Port 4569 verwendet für jeden möglichen IAX Datenverkehr. Weiters gibt es die Authentifikation über Md5 oder RSA. 3.1 Peer Verhalten und Nachrichten Es gibt zwei Kategorien von Nachrichten. Einerseits verlässliche und andererseits nicht garantierte Nachrichten. Zu den ersten gehören die "Full Frames", welche den kompletten Anruf Identifier und alle Identifier der Peers beinhaltet, sowie mögliche "Information Elements"(IE). Der andere Typ sind "Mini Frames" oder "Meta Frames", die nur den Identifier des sendenden Peers beinhalten. Im Folgenden wird das Verhalten in einige funktionale Teile unterteilt: Registration Um es möglich zu machen, dass ein Peer einen anderen findet, ist es nötig dessen Netzwerkadresse zu kennen. Dies ist entweder manuell anzugeben, oder es kann in einem geteilten Verzeichnis zu finden sein. IAX bietet auch die Möglichkeit, dass sich ein Peer bei einem anderen registriert, sodass er gefunden werden kann. Dafür gibt es nun unterschiedliche Nachrichten und wird mit einem REGREQ begonnen. Insofern Authentifikation erwünscht ist wird mit REGAUTH geantwortet. Darauf wird REGREQ wieder gesendet, wobei die Authentifikationsinformationen enthalten sind. Durch ein REGACK wird die Registrierung bestätigt und es kann jederzeit mit einem REGREJ ein Fehler signalisiert werden. Die Registrierung gilt nur für bestimmte Zeit und danach muss diese mit erneuter Registrierung verlängert werden. Sollte dies nicht gewünscht sein kann auch ein REGREL zum Registrar gesendet werden, welches wieder authentifiziert werden kann, um die Registrierung zu beenden. Ein möglicher Datenfluss für eine Registrierung ist in Grafik 6 zu sehen Call Link Managment Mit IAX kann man einen Link zwischen zwei Peers aufbauen. Dies geschieht über eine NEW Nachricht, welche die Nummer des zu rufenden Teilnehmers beinhaltet. Darauf hin kann der Remote Peer mit einer Forderung nach Authentifizierung(AUTHREQ), mit RE- JECT oder ACCEPT antworten. Mit AUTHREP kann der Sender die Authentifizierung vornehmen. Daraufhin ist der Link in einem verbundenen Zustand und er kann weiter verwendet werden um Kontrollnachrichten zu senden bis der Anruf beendet wird. Das Beenden wird über die HANGUP Nachricht vollzogen Call Control Hier werden Nachrichten versendet, welche erst möglich sind nachdem ein Link mit AC- CEPT zustandegekommen ist. Als erstes nach einer NEW Nachricht wird eine RINGING sein. Allerdings ist es auch erlaubt, dass eine ANSWER zuerst kommt, ansonsten erst danach. Weiters gibt es eine BUSY Nachricht und mit HANGUP kann der Anruf auch sofort wieder beendet werden. Insofern mit DIAL begonnen wurde folgt darauf ein PRO- CEEDING und dann erst das RINGING. 14

16 Abbildung 6: Registration unter IAX, Quelle: [17] Call Path Optimization Wenn zwei Peers über einen dritten in der Mitte kommunizieren, kann sich dieser aus der Kommunikation herausnehmen, sodass die beiden anderen direkt in Kontakt stehen. Hier gibt es die Nachrichten TXREQ (beginne den Transfer Prozess für die Optimierung), TXCNT und TXACC(Prüfe die Verbindung welche die Existierende ersetzen soll), TX- READY(beende Verbindung und arbeite mit der neuen weiter) Mid Call Behavior Hier gibt es Nachrichten FLASH(bei analogen Anlagen wenn eine kurze Unterbrechung festgestellt wird), HOLD(den Anruf anhalten), UNHOLD(den Anruf weiterführen), QUELCH(der Remote Peer unterbricht den Anruf), UNQUELCH(Remote PEER setzt Anruf fort), und TRANSFER(Der Anruf soll abgebrochen werden und von empfangenden Peer wieder neu aufgenommen werden) Call Tear Down Dies wird mit den bereits erwähnten Nachrichten HANGUP, REJECT, TRANSFER und auch mit TXREADY in ihrem jeweiligen Kontext vollzogen. 15

17 3.1.7 Network Monitoring Mit der POKE und PING Nachrichten wird die Erreichbarkeit eines Peers überprüft und dieser muss mit PONG antworten und mit LAGRQ die Qualität des momentanen Links. Dabei wird ein Timestamp gesendet der mit LAGRP zurückgesendet wird Digit Dialing Diese Funktionalität dient dazu, dass auch analoge Geräte mit IAX kommunizieren können. Dabei werden eine Menge von DPREQ Nachrichten gesendet welche von DPREP beantwortet werden, indem sie anzeigen ob der Server eine Rufnummer eines Peers kennt die gleich ist oder ob weitere Zahlen eingegeben werden müssen. Wenn DPREP anzeigt dass es die Nummer gibt, kann diese mit DIAL "angerufen" werden Miscellaneous Erhaltene Nachrichten (Full Frames) werden mit ACK bestätigt, insofern sie keine andere Antwort erwarten. Wenn eine nicht gültige Nachricht erhalten wird, sendet der Peer eine INVAL Nachricht. Wenn Nachrichten nicht in der richtigen Reihenfolge eintreffen (ein Mini Frame mit Audio Inhalt bevor ein Full Frame eingelangt ist der den Beginn des Audiotransfers einleitet), so wird ein VNAK gesendet. MWI wird verwendet um einem anderen Peer zu sagen, dass man noch Nachrichten hat die warten gesendet zu werden. Wenn ein Peer eine Nachricht nicht unterstützt, wird dies mit UNSUPPORT angezeigt Media Messages Audio und Video Nachrichten werden mit Mini Frames übertragen. Sie sind einzigartig, da sie eigene Codierungen verwenden. Allerdings muss immer wenn der Timestamp ein Vielfaches von 0x8000 ist ein Full Frame gesendet werden. Wenn Mediennachrichten erhalten werden, welche keine solchen Mini Frames sind, muss darauf ein ACK gesendet werden. Mediennachrichten sind bei IAX: DTMF (Dual Tone Multi-Frequency), Voice Media, Video Media, Text Media, Image Media, HTML Media Nachrichten und Comfort Noise Nachrichten. 3.2 Struktur der Frames Full Frames Der Full Frame ist wie in Grafik 7 aufgebaut. Das F-bit zeigt an ob es sich um einen Full Frame handelt. Die 15bit Source Call Number zeigt die Nummer an welche der Sender benützt um den Anruf zu identifizieren. Das R-bit zeigt an ob der Frame noch einmal übertragen wird oder das erste Mal. Die Destination Call Number wird vom Sender verwendet um den Anruf bei dem Remote Peer zu identifizieren und stimmt mit der Source Call Number des Remote Peer überein. Der Time-Stamp ist ein 32bit Zahl welche in Millisekunden darstellt wie viel Zeit ab der ersten Nachricht des Anrufs vergangen ist. OSeqno ist eine Stream Sequenz Nummer die mit jedem gesendeten Full Frame erhöht wird. ISqeno wird hingegen mit jedem empfangenen Full Frame erhöht. Der Frametype zeigt den Typ der Nachricht an, die transportiert wird. Das C-bit deutet an wie die darauffolgenden 7 Subclass bits zu interpretieren sind. Wenn C=1, dann als Potenz von 2, sonst als vorzeichenlose Ganzzahl. 16

18 Abbildung 7: Aufbau eines Full Frame, Quelle: [1] Mini Frames Diese werden so genannt, da ihre Header minimal sind und sie keine Kontrolldaten beinhalten. Sie dienen nur dazu Medien über einen bereits aufgebauten Link zu senden. Sie haben das F-bit, welches 0 sein muss, eine Source Call Number, die wie beim Full Frame den Anruf identifiziert und einen Time-Stamp welcher die unteren 16bit des Full Frame Time-Stamp beinhaltet. In Grafik 8 ist ein solcher Frame dargestellt. Abbildung 8: Aufbau eines Mini Frame, Quelle: [2] Meta Frames Hier gibt es zwei Sorten von Frames. Das eine sind Video Frames, welche es erlauben Video Daten mit einem optimierten kürzeren Header zu übertragen und das andere sind Media Trunk Frames, welche meherere IAX Medienströme zwischen zwei Peers zusammenfassen. Die beiden Frames sind in Grafiken 9 und 10 abgebildet. 3.3 Verschlüsselung und Authentifizierung IAX unterstützt die Verschlüsselung von Anrufen mit symmetrischen Schlüsseln per AES 128bit. Die NEW Nachricht wird im Klartext übertragen und zeigt die Verschlüsselung an. Dabei gibt man das IE ENCRYPTION an. Alle nachfolgenden Nachrichten müssen verschlüsselt sein, wobei nur die Datenteile der Nachrichten codiert werden. Die Header 17

19 Abbildung 9: Aufbau eines Meta Video Frame, Quelle: [12] Abbildung 10: Aufbau eines Meta Trunk Frame, Quelle: [12] Call Numbers werden im Klartext übertragen und der Rest des Frame wird mit 16 bis 32Byte zufälliger Daten aufgefüllt und anschließend verschlüsselt. Die zufälligen Daten werden dabei aber vor den eigentlichen Daten eingefügt. Authentifizierung erfolgt in IAX mittles Md5 oder RSA. Mit dem Information Element CHALLENGE wird die Aufgabe für Md5 oder RSA, welches zuerst vereinbart wird (mit dem IE AUTHMETHODS), übertragen. Die beiden IE s MD5 RESULT bzw. RSA RESULT liefern dann die Antwort auf die Aufgabe. 4 Real Time Transport Protokoll & RTP Control Protokoll Das Real Time Transport Protokoll[11] bietet die Möglichkeit Echtzeitdaten, wie interaktive Audio- und Videokonferenzen, von einem Ende zum Anderen zu übertragen. Normalerweise wird RTP mit UDP verwendet, es ist aber auch möglich andere Transportprotokolle zu verwenden. Ebenso wird Multicast unterstützt. Das RTP Control Protokoll[11] wird verwendet um die Qualität des Service festzustellen und um Informationen über die Teilnehmer weiterzuleiten. 18

20 4.1 RTP Abbildung 11: RTP Header, Quelle: [3] In der Grafik 11 sind die fixen Header Felder von RTP angeführt. Das V-bit steht für die Version und das P-bit deutet an ob am Ende ein oder mehrere Padding Bytes folgen. Wenn das X-bit gesetzt ist, muss nach dem Header eine Header Erweiterung folgen. CC bestimmt die Anzahl an CSRC Identifier, die nach dem Header folgen. M steht für das Markerbit, das zb das Ende eines Streams anzeigen kann. PT definiert den Datantyp des Payload, wobei ein Empfänger Pakete ignorieren muss, wenn er den Payload Typ nicht kennt. SSRC ist eine zufälliger Identifier der die syncronization source bezeichnet. Die CSRC list beinhaltet 0 bis 15 Einträge, welche die contributing sources identifizieren. Dies ist wichtig wenn der Datenstrom aus mehreren Quellen gemixt wird. RTP sollte einen geraden Ziel Port wählen und RTCP den nächsten ungeraden Port. Der Port darf nicht der gleiche sein, da die Ports verwendet werden um die Ströme wieder zu trennen. Da RTP für viele Anwendungen verwendet werden kann, kann man für gewisse Anwendungen Profile beschreiben. Hier wählt oder definiert man die benötigten Erweiterungen, welche für die Anwendungen benötigt werden. Ein zweiter Teil ist die Spezifikation des Formates der Payload. Hier wird angegeben, wie zb Videodaten codiert und in RTP transportiert werden sollen. 4.2 RTCP RTCP basiert auf dem periodischen Senden von Paketen zu allen Teilnehmern einer Sitzung und es hat folgende vier Funktionen: Das Protokoll soll Informationen über die Qualität der Datenverteilung liefern. Somit können auch Fehler in der Übertragung festgestellt werden und Netzwerk Probleme diagnostiziert werden. RTCP hat einen persistenten Identifier für die RTP source, der auch canonical Name genannt wird (CNAME). Da ein SSRC sich im Konfliktfall ändern kann, oder wenn ein Programm neu gestartet wird, brauchen Teilnehmer den CNAME um alle Teilnehmer weiterhin finden zu können. Der CNAME ist auch wichtig um zb Audio und Videostreams, die in zwei RTP Sitzungen übertragen werden, zu synchronisieren. Da alle Teilnehmer RTCP Pakete senden, wissen sie immer wie viele Teilnehmer zugegen sind und können die Rate kontrollieren und anpassen, mit welcher die Pakete gesendet werden. 19

100 Trying Ein Anruf wird zu vermitteln versucht. Anruf wird weitergeleitet

100 Trying Ein Anruf wird zu vermitteln versucht. Anruf wird weitergeleitet Code Text Phrase Bedeutung 100 Trying Ein Anruf wird zu vermitteln versucht 180 Ringing Es klingelt beim Gegenüber 181 Call Is Being Forwarded Anruf wird weitergeleitet 182 Queued Anruf ist in Warteschleife

Mehr

Digitale Sprache und Video im Internet

Digitale Sprache und Video im Internet Digitale Sprache und Video im Internet Kapitel 6.4 SIP 1 SIP (1) SIP (Session Initiation Protocol), dient als reines Steuerungsprotokoll (RFC 3261-3265) für MM-Kommunikation Weiterentwicklung des MBONE-SIP.

Mehr

180 Ringing Diese Antwort zeigt an, dass das aufgerufene Programm lokalisiert worden ist und der Anruf signalisiert wird.

180 Ringing Diese Antwort zeigt an, dass das aufgerufene Programm lokalisiert worden ist und der Anruf signalisiert wird. 1xx Informative Rückmeldungen 100 Trying Diese Antwort zeigt an, dass Maßnahmen im Namen des Anrufers ergriffen wurden, aber dass das aufgerufene Programm nicht lokalisiert wurde. 180 Ringing Diese Antwort

Mehr

Proseminar IP-Telefonie. Timo Uhlmann. Einleitung 1 2 3 4 5

Proseminar IP-Telefonie. Timo Uhlmann. Einleitung 1 2 3 4 5 Proseminar IP-Telefonie Timo Uhlmann Einleitung 1 2 3 4 5 Inhalt 1. Motivation 2. Protokolle H.323 3. Kosten/Angebote 4. Fazit Einleitung 1 2 3 4 5 2/24 Motivation Telefonieren kostet Geld (noch) zeitabhängig

Mehr

VOIP Basics 14.11.2005

VOIP Basics 14.11.2005 VOIP Basics 14.11.2005 VoIP! Voice over IP! VOIP V o i c e Skypen! Voipen! DSL-Telefonie! Internettelefonie! IP-Telefonie! Billig! Was ist VOIP -Voice over Internet Protokoll = Stimmenübertragung über

Mehr

im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein

im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein VoIP-Verschlüsselung Verschlüsselung im DFN Berlin 18.10.2011 Renate Schroeder, DFN-Verein Einordnung VoIP in DFNFernsprechen VoIP seit 5 Jahren im DFN verfügbar VoIP ist Teil des Fernsprechdienstes DFNFernsprechen

Mehr

VoIP. Gliederung. 1. Einführung. 3.2Anforderungen 3.3Stand Dinge. 3.3Wie geht es Dinge weiter?

VoIP. Gliederung. 1. Einführung. 3.2Anforderungen 3.3Stand Dinge. 3.3Wie geht es Dinge weiter? Sicherheit Ruhr-Universität Voice over IP Thomas WS Seminar (VoIP 2004/2005 VoIP) Eisenbarth ITS Bochum 1. Einführung 1.1 1.2 1.3 Was Bisherige Die Zukunft ist VoIP? Telefonie Gliederung 10.02.2005 - Folie

Mehr

VoIP - Protokolle. Somala Mang Christian Signer Jonas Baer

VoIP - Protokolle. Somala Mang Christian Signer Jonas Baer VoIP - Protokolle Somala Mang Christian Signer Jonas Baer Inhalt Motivation Protokolle SIP IAX2 Skype Vergleich Diskussion Seite 2 Motivation Schweizer CRM integriert Skype und Twixtel (http://www.inside-it.ch)

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Internet Protokolle für Multimedia - Anwendungen

Internet Protokolle für Multimedia - Anwendungen Internet Protokolle für Multimedia - Anwendungen Kapitel 5.7 Streaming im Web (RTSP) 1 Streaming Media (1) Streaming Media Strom ist kontinuierlich wird unmittelbar während des Empfangs wiedergegeben wird

Mehr

Begriffe. Proxy: Ein SIP Knoten, der sowohl als Client als auch als Server arbeitet. Hauptaufgabe ist das Routing von SIP Nachrichten.

Begriffe. Proxy: Ein SIP Knoten, der sowohl als Client als auch als Server arbeitet. Hauptaufgabe ist das Routing von SIP Nachrichten. Begriffe Client: Ein SIP Knoten, der SIP Requests verschickt und SIP Responses empfängt. Server: Ein SIP Knoten, der SIP Requests empfängt und SIP Responses sendet. User Agent (UA): Ein SIP Knoten, der

Mehr

SDP ABNF (RFC4234) Session Initiation Protocol. Einleitung SDP Body. Anwendung

SDP ABNF (RFC4234) Session Initiation Protocol. Einleitung SDP Body. Anwendung SDP Body Anwendung SDP (vgl. 4566) bietet eine Beschreibung einer Session (z.b. Multimedia Konferenz) mit allen Informationen, die von Clients benötigt werden, um an der Session teilzunehmen: Name und

Mehr

Seminar Mobile Systems. The Session Initiation Protocol in Mobile Environment

Seminar Mobile Systems. The Session Initiation Protocol in Mobile Environment Seminar Mobile Systems The Session Initiation Protocol in Mobile Environment 1 Lorenz Fischer, Ruben Meier Mobile Systems Seminar 13. Juni 2005 Übersicht Einführung Protokolle (SIP, SDP, RTP) Komponenten

Mehr

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Übersicht Internetsicherheit Protokoll Sitzungen Schlüssel und Algorithmen vereinbaren Exportversionen Public Keys Protokollnachrichten 29.10.2003 Prof.

Mehr

Auswirkungen von Sicherungsmechanismen auf Entwicklung und Anwendung von Testverfahren am Beispiel von Voice over IP

Auswirkungen von Sicherungsmechanismen auf Entwicklung und Anwendung von Testverfahren am Beispiel von Voice over IP Auswirkungen von Sicherungsmechanismen auf Entwicklung und Anwendung von Testverfahren am Beispiel von Voice over IP 15. ITG-Fachtagung Mobilkommunikation Annika Renz Daniel Hartmann Diederich Wermser

Mehr

... relevante Ports für Streaming bzw. Remote Control!

... relevante Ports für Streaming bzw. Remote Control! ... relevante Ports für Streaming bzw. Remote Control! Wenn Sie mit der Installation des IO [io] 8000 / 8001 beginnen, ist es am sinnvollsten mit einem minilan zu beginnen, da dies mögliche Fehlrequellen

Mehr

Streaming Protokolle Jonas Hartmann

Streaming Protokolle Jonas Hartmann Streaming Protokolle Jonas Hartmann 1 Streaming Protokolle Inhaltsverzeichnis 1. Definition / Anwendungsfälle 2. Offizielle RFC Streaming Protokolle 3. Ein wichtiges proprietäres Protokoll 4. Konkreter

Mehr

Voice over IP. Sprache und Daten in einem gemeinsamen Netz. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Voice over IP. Sprache und Daten in einem gemeinsamen Netz. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Voice over IP Sprache und Daten in einem gemeinsamen Netz Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Normen Ablauf und Einzelheiten Verbindungsaufbau und Verbindungsverwaltung

Mehr

Buchner Roland, Günther Markus, Fischer Oliver

Buchner Roland, Günther Markus, Fischer Oliver Buchner Roland, Günther Markus, Fischer Oliver Telefonieren über das Datennetz Erster Hype schon in den 90ern seit CeBIT 2004 wieder im Gespräch Erobert Telekommunikationsmarkt Alle großen Telekom Anbieter

Mehr

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis

Security Associations Schlüsseltausch IKE Internet Key Exchange Automatischer Schlüsseltausch und Identitätsnachweis Wie Interoperabel ist IPsec? Ein Erfahrungsbericht Arturo Lopez Senior Consultant März 2003 Agenda Internet Protokoll Security (IPsec) implementiert Sicherheit auf Layer 3 in OSI Modell Application Presentation

Mehr

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet.

VPN unterstützt 3 verschiedene Szenarien: Host to Host: Dies kennzeichnet eine sichere 1:1 Verbindung zweier Computer, z.b. über das Internet. 1. VPN Virtual Private Network Ein VPN wird eingesetzt, um eine teure dedizierte WAN Leitung (z.b. T1, E1) zu ersetzen. Die WAN Leitungen sind nicht nur teuer, sondern auch unflexibel, da eine Leitung

Mehr

Multicast Security Group Key Management Architecture (MSEC GKMArch)

Multicast Security Group Key Management Architecture (MSEC GKMArch) Multicast Security Group Key Management Architecture (MSEC GKMArch) draft-ietf-msec-gkmarch-07.txt Internet Security Tobias Engelbrecht Einführung Bei diversen Internetanwendungen, wie zum Beispiel Telefonkonferenzen

Mehr

Bemerkung: Jede Ressource sollte über einen. Ressource A. Ressource. eindeutigen Namen verfügen. Ressource F. Ressource. Ressource E.

Bemerkung: Jede Ressource sollte über einen. Ressource A. Ressource. eindeutigen Namen verfügen. Ressource F. Ressource. Ressource E. 10 Hypertext Transfer Protocol 10.1 Hypermedia 10.2 Universal Resource Identifier 10.3 Nachrichten 10.4 Proxy 10.5 Cache 10.6 Authentifizierung 10.7 S Hypermedia: A D C B E F Bemerkung: Jede sollte über

Mehr

Peer-to-Peer Internet Telephony using the Session Initiation Protocol (SIP)

Peer-to-Peer Internet Telephony using the Session Initiation Protocol (SIP) Seite - 1 - HAW Hamburg Anwendungen I Nico Manske Peer-to-Peer Internet Telephony using the Session Initiation Protocol (SIP) Seite - 2 - Seite - 3 - reines P2P System für IP Telefonie bei SIP Client Server

Mehr

SIRTCP/IP und Telekommunikations netze

SIRTCP/IP und Telekommunikations netze SIRTCP/IP und Telekommunikations netze Next Generation Networks und VolP - konkret von Ulrich Trick und Frank Weber 2., erweiterte und aktualisierte Auflage Oldenbourg Verlag München Wien Inhalt Inhalt

Mehr

14. Fachtagung Mobilkommunikation Osnabrück

14. Fachtagung Mobilkommunikation Osnabrück SOA-basierte Peer-to-Peer-Mehrwertdienstebereitstellung 14. Fachtagung Mobilkommunikation Osnabrück 13. - 14. Mai 2009 Dipl.-Ing. Armin Lehmann, Prof. Dr.-Ing. Ulrich Trick Fachhochschule Frankfurt am

Mehr

Was ist VoIP Grundlagen RTP, SIP und H3.23 Schwachstellen und Angriffsszenarien

Was ist VoIP Grundlagen RTP, SIP und H3.23 Schwachstellen und Angriffsszenarien VoIP und Sicherheit Wie sicher kann VoIP sein? Welche Schwachstellen gibt es? Netzwerksicherheit CNB 4 SS 2008 Patrick.Schuetzeberg@hs-furtwangen.de Philipp.Wielatt@hs-furtwangen.de Patrick Schützeberg,

Mehr

UDP-, MTU- und IP- Fragmentierung

UDP-, MTU- und IP- Fragmentierung UDP-, MTU- und IP- Fragmentierung Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung

Mehr

DaLUG, 28.5.2004. Voice over IP

DaLUG, 28.5.2004. Voice over IP DaLUG, 28.5.2004 Voice over IP Zwei Netze 64Kbit/s Intelligent Network aka ISDN 33.6-3000 Kbit/s 10-1000 Mbit/s Stupid Network aka Das Internet Zwei GUIs Kaum verändert seit 1888 Kommandozeile, Scriptfähig

Mehr

VIRTUAL PRIVATE NETWORKS

VIRTUAL PRIVATE NETWORKS VIRTUAL PRIVATE NETWORKS Seminar: Internet-Technologie Dozent: Prof. Dr. Lutz Wegner Virtual Private Networks - Agenda 1. VPN Was ist das? Definition Anforderungen Funktionsweise Anwendungsbereiche Pro

Mehr

Um IPSec zu konfigurieren, müssen Sie im Folgenden Menü Einstellungen vornehmen:

Um IPSec zu konfigurieren, müssen Sie im Folgenden Menü Einstellungen vornehmen: 1. IPSec Verbindung zwischen IPSec Client und Gateway 1.1 Einleitung Im Folgenden wird die Konfiguration einer IPSec Verbindung vom Bintec IPSec Client zum Gateway gezeigt. Dabei spielt es keine Rolle,

Mehr

Voice over IP. Sicherheitsbetrachtung

Voice over IP. Sicherheitsbetrachtung Voice over IP Sicherheitsbetrachtung Agenda Motivation VoIP Sicherheitsanforderungen von VoIP Technische Grundlagen VoIP H.323 Motivation VoIP Integration von Sprach und Datennetzen ermöglicht neue Services

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

Mehr

Vortrag Netz- und Service-Infrastrukturen

Vortrag Netz- und Service-Infrastrukturen VoIP mit IAX Vortrag Netz- und Service-Infrastrukturen Holger Schildt holger.schildt@informatik.tu-chemnitz.de TU-Chemnitz holger.schildt@informatik.tu-chemnitz.de - VoIP mit IAX p.1/21 Übersicht Einführung

Mehr

Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg. Modul 5: IPSEC

Prof. Dr. Martin Leischner Netzwerksysteme und TK. Hochschule Bonn-Rhein-Sieg. Modul 5: IPSEC Modul 5: IPSEC Teil 1: Transport- und Tunnelmode / Authentication Header / Encapsulating Security Payload Security Association (SAD, SPD), IPsec-Assoziationsmanagements Teil 2: Das IKE-Protokoll Folie

Mehr

VoIP Security. Konzepte und Lösungen für sichere VoIP-Kommunikation. von Evren Eren, Kai-Oliver Detken. 1. Auflage. Hanser München 2007

VoIP Security. Konzepte und Lösungen für sichere VoIP-Kommunikation. von Evren Eren, Kai-Oliver Detken. 1. Auflage. Hanser München 2007 VoIP Security Konzepte und Lösungen für sichere VoIP-Kommunikation von Evren Eren, Kai-Oliver Detken 1. Auflage Hanser München 2007 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 446 41086 2 Zu Leseprobe

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

Protokollanalyse bei VoIP

Protokollanalyse bei VoIP Protokollanalyse bei VoIP 1. Einführung 2. Protokoll Stack H.323 3. Protokollanalyse in VoIP-Umgebung Funktionelle Analyse Paketanalyse 4. Dimensionierungsaspekte bei VoIP Jitter-Theorie Bandbreite bei

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Video over IP / Videostreaming

Video over IP / Videostreaming Video over IP / Videostreaming - einige wenige Aspekte - Prof. Dr. Robert Strzebkowski Beuth Hochschule für Technik Berlin Unterscheidung: 'Echter Streaming' mit Streaming-Server HTTP-Download als 'Pseudostreaming'

Mehr

Grundlagen der. Videokommunikation

Grundlagen der. Videokommunikation Grundlagen der Videokommunikation Netzwerke: Qualitäts- und Leistungserwartungen Netzwerke: Qualitäts- und Leistungserwartungen Netzwerke: über DFN X-WiN-Anbindung X-WiN ist im DFN-Verein technische Basis

Mehr

VoIP Grundlagen und Risiken

VoIP Grundlagen und Risiken VoIP Grundlagen und Risiken Hochschule Bremen Fakultät Elektrotechnik und Informatik 1 Zu meiner Person Informatik-Professor an der Hochschule Bremen Aktuelle Lehrgebiete: Rechnernetze Informationssicherheit

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

IT-Sicherheit WS 2013/14. Übung 11. zum 30. Januar 2014

IT-Sicherheit WS 2013/14. Übung 11. zum 30. Januar 2014 Prof. Dr. C. Eckert Thomas Kittel IT-Sicherheit WS 2013/14 Übung 11 zum 30. Januar 2014 Institut für Informatik Lehrstuhl für Sicherheit in der Informatik 1 SSL/TLS in VoIP In Voice-over-IP (VoIP) Kommunikation

Mehr

Modul 12: 12.1 Vertiefung Paket- u. Leitungsvermittlung 12.2 Voice over IP, Next Generation Networks

Modul 12: 12.1 Vertiefung Paket- u. Leitungsvermittlung 12.2 Voice over IP, Next Generation Networks Modul 12: 12.1 Vertiefung Paket- u. Leitungsvermittlung 12.2 Voice over IP, Next Generation Networks 17.06.2014 16:57:15 Folie 1 12.1 Vertiefung Paketund Leitungsvermittlung 17.06.2014 16:57:16 Folie 2

Mehr

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien

IPsec. Vortrag im Rahmen des Seminars Neue Internet Technologien IPsec Vortrag im Rahmen des Seminars Neue Internet Technologien Friedrich Schiller Universität Jena Wintersemester 2003/2004 Thomas Heinze, Matrikel xxxxx Gliederung IPsec? - Motivation, Grundbegriffe,

Mehr

Chapter 8 ICMP. CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von

Chapter 8 ICMP. CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von Chapter 8 ICMP CCNA 2 version 3.0 Wolfgang Riggert, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

RADIUS Protokoll + Erweiterungen

RADIUS Protokoll + Erweiterungen RADIUS Protokoll + Erweiterungen Universität Hamburg Seminar: Internet-Sicherheit Claas Altschaffel Sommersemester 2005 Inhalt Einleitung Paketaufbau Ablauf Protokoll-Support RADIUS Proxy Erweiterungen

Mehr

How to install freesshd

How to install freesshd Enthaltene Funktionen - Installation - Benutzer anlegen - Verbindung testen How to install freesshd 1. Installation von freesshd - Falls noch nicht vorhanden, können Sie das Freeware Programm unter folgendem

Mehr

SIRTCP/IP und Telekommunikations netze

SIRTCP/IP und Telekommunikations netze SIRTCP/IP und Telekommunikations netze Anforderungen - Protokolle -Architekturen Von Ulrich Trick und Frank Weber Oldenbourg Verlag München Wien Inhalt Vorwort IX 1 Anforderungen an die Telekommunikationsinfrastruktur

Mehr

Konfigurationsanleitung Standortkopplung mit T444 (ISDN) und RT1202 (SIP) Graphical User Interface (GUI) Seite - 1 -

Konfigurationsanleitung Standortkopplung mit T444 (ISDN) und RT1202 (SIP) Graphical User Interface (GUI) Seite - 1 - Konfigurationsanleitung Standortkopplung mit T444 (ISDN) und RT1202 (SIP) Graphical User Interface (GUI) Copyright Stefan Dahler 22. Oktober 2013 Version 1.0 www.neo-one.de Seite - 1 - 7. Standortkopplung

Mehr

Authentication Header: Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen

Authentication Header: Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen IP Security Zwei Mechanismen: Authentication : Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen Encapsulating Security Payloads (ESP): Verschl., Datenauth. Internet Key Exchange Protokoll:

Mehr

Nutzerauthentifizierung mit 802.1X. Torsten Kersting kersting@dfn.de

Nutzerauthentifizierung mit 802.1X. Torsten Kersting kersting@dfn.de Nutzerauthentifizierung mit 802.1X Torsten Kersting kersting@dfn.de Inhalt EAP Protokoll EAP Methoden 802.1X Netzwerk Port Auth. 802.1X in WLAN s 802.11i (TKIP, CCMP, RSN) Einführung Design Fehler in statischem

Mehr

SIP Konfiguration in ALERT

SIP Konfiguration in ALERT Micromedia International Technisches Dokument SIP Konfiguration in Alert Autor: Pierre Chevrier Seitenanzahl: 13 Firma: Micromedia International Datum: 16/10/2012 Update: Jens Eberle am 11.10.2012 Ref.

Mehr

Mehr als Voice over IP Integrierte Sprach- und SIP. =====!" ==Systems= Wolfgang Mandok T-Systems Nova, Technologiezentrum

Mehr als Voice over IP Integrierte Sprach- und SIP. =====! ==Systems= Wolfgang Mandok T-Systems Nova, Technologiezentrum Mehr als Voice over IP Integrierte Sprach- und IP-Kommunikationslösungen basierend auf SIP Wolfgang Mandok T-Systems Nova, Technologiezentrum Mehr als Voice over IP Übersicht 1. Einleitung 2. SIP Architektur

Mehr

Sichere Netzwerke mit IPSec. Christian Bockermann

Sichere Netzwerke mit IPSec. Christian Bockermann <christian@ping.de> Sichere Netzwerke mit IPSec Christian Bockermann Überblick Gefahren, Ziele - Verschlüsselung im OSI-Modell IPSec - Architektur - Schlüssel-Management - Beispiele Unsichere Kommunikation

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells.

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. Übung 7 1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. 2.) Charakterisieren Sie kurz das User Datagram Protokoll (UDP) aus der Internetprotokollfamilie

Mehr

Application Layer Gateway

Application Layer Gateway Gesicherte Videokonferenzen mit einem Application Layer Gateway Karl-Hermann Fischer Sales Consultant fischer@gsmue.pandacom.de 1 Das Unternehmen Systemintegrator und Dienstleister im Bereich der Netzwerke

Mehr

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015

ÖSTERREICH RECHNET MIT UNS. Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 ÖSTERREICH RECHNET MIT UNS Standard e-rechnungs-webservice (SERWS) - Ideen DI Philip Helger, BRZ 17.02.2015 www.brz.gv.at BRZ GmbH 2015 AGENDA Ausgangsbasis Webservice bei E-RECHNUNG.GV.AT SERWS Ziele

Mehr

Sicherheit bei VoIP - Ein Überblick

Sicherheit bei VoIP - Ein Überblick - Ein Überblick Christian Louis christian@kuechenserver.org 29. Dezember 2004 Überblick Grundlagen von IP-Telefonie Gefahren bei IP-Telefonie Standards VoIP-Sicherheit Status Quo Ausblick 29. Dezember

Mehr

Themen. Anwendungsschicht DNS HTTP. Stefan Szalowski Rechnernetze Anwendungsschicht

Themen. Anwendungsschicht DNS HTTP. Stefan Szalowski Rechnernetze Anwendungsschicht Themen Anwendungsschicht DNS HTTP Anwendungsschicht OSI-Schicht 7, TCP/IP-Schicht 4 Dienste für den Nutzer/Anwender Unabhängig von den niederen Schichten Verschiedene Dienste bzw. Services DNS HTTP FTP,

Mehr

Diplomanden- und Doktorandenseminar. Implementierung eines Gnutella-Clients für IPv6

Diplomanden- und Doktorandenseminar. Implementierung eines Gnutella-Clients für IPv6 Diplomanden- und Doktorandenseminar Implementierung eines Gnutella-Clients für IPv6 1. Motivation 2. IPv6 3. Gnutella 4. Portierung Frank Sowinski 17.12.2002 Motivation Gute Gründe für IPv6 Das Anwachsen

Mehr

Datenfluss bei Voice-over-IP. Einflüsse auf Sprachqualität. Ende-zu-Ende-Verzögerungszeit (Delay) Schwankungen der Verzögerungszeit (Jitter) Sender

Datenfluss bei Voice-over-IP. Einflüsse auf Sprachqualität. Ende-zu-Ende-Verzögerungszeit (Delay) Schwankungen der Verzögerungszeit (Jitter) Sender Sender Quelle Datenfluss bei Voice-over-IP Kodieren Paketieren Verzögerungen verlorene Pakete begrenzte Datenrate Sende- Puffer Einflüsse auf Sprachqualität Verzögerungszeit Delay Schwankungen der Verzögerungszeit

Mehr

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST 2. Interaktive Web Seiten GET und POST Die Übertragungsmethoden GET und POST sind im http Protokoll definiert: POST: gibt an, dass sich weitere Daten im Körper der übertragenen Nachricht befinden: z.b.

Mehr

Kolloquium der. Sicherheitslösungen für VoIP Netzwerke

Kolloquium der. Sicherheitslösungen für VoIP Netzwerke Kolloquium der Sicherheitslösungen für VoIP Netzwerke 28.06.2006 Paul-Silberbach-Saal der FH Köln Dipl.- Ing. 2006 Überblick des heutigen Abends Gefahren für VoIP-fähige Netzwerke Ansätze zur Netzwerksicherheit

Mehr

ICMP Internet Control Message Protocol. Michael Ziegler

ICMP Internet Control Message Protocol. Michael Ziegler ICMP Situation: Komplexe Rechnernetze (Internet, Firmennetze) Netze sind fehlerbehaftet Viele verschiedene Fehlerursachen Administrator müsste zu viele Fehlerquellen prüfen Lösung: (ICMP) Teil des Internet

Mehr

Chapter 11 TCP. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von

Chapter 11 TCP. CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Chapter 11 TCP CCNA 1 version 3.0 Wolfgang Riggert,, FH Flensburg auf der Grundlage von Rick Graziani Cabrillo College Vorbemerkung Die englische Originalversion finden Sie unter : http://www.cabrillo.cc.ca.us/~rgraziani/

Mehr

BeamYourScreen Sicherheit

BeamYourScreen Sicherheit BeamYourScreen Sicherheit Inhalt BeamYourScreen Sicherheit... 1 Das Wichtigste im Überblick... 3 Sicherheit der Inhalte... 3 Sicherheit der Benutzeroberfläche... 3 Sicherheit der Infrastruktur... 3 Im

Mehr

TCP/IP-Protokollfamilie

TCP/IP-Protokollfamilie TCP/IP-Protokollfamilie Internet-Protokolle Mit den Internet-Protokollen kann man via LAN- oder WAN kommunizieren. Die bekanntesten Internet-Protokolle sind das Transmission Control Protokoll (TCP) und

Mehr

Konzept eines IP-basierten Telefonnetzes unter der Verwendung von ENUM

Konzept eines IP-basierten Telefonnetzes unter der Verwendung von ENUM Konzept eines IP-basierten Telefonnetzes unter der Verwendung von 28. September 2004 Betreuer: Diplomarbeit Dr. Günther Schreiner, toplink GmbH John-Erik Horn Dipl.-Ing. Sebastian Kiesel, IKR Dipl.-Ing.

Mehr

Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur.

Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur. MIKOGO SICHERHEIT Inhaltsverzeichnis Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur Seite 2. Im Einzelnen 4 Komponenten der Applikation

Mehr

IT-Sicherheit Kapitel 11 SSL/TLS

IT-Sicherheit Kapitel 11 SSL/TLS IT-Sicherheit Kapitel 11 SSL/TLS Dr. Christian Rathgeb Sommersemester 2014 1 Einführung SSL/TLS im TCP/IP-Stack: SSL/TLS bietet (1) Server-Authentifizierung oder Server und Client- Authentifizierung (2)

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner

NAT & VPN. Adressübersetzung und Tunnelbildung. Bastian Görstner Adressübersetzung und Tunnelbildung Bastian Görstner Gliederung 1. NAT 1. Was ist ein NAT 2. Kategorisierung 2. VPN 1. Was heißt VPN 2. Varianten 3. Tunneling 4. Security Bastian Görstner 2 NAT = Network

Mehr

IPSec. Motivation Architektur Paketsicherheit Sicherheitsrichtlinien Schlüsselaustausch

IPSec. Motivation Architektur Paketsicherheit Sicherheitsrichtlinien Schlüsselaustausch IPSec Motivation Architektur Paketsicherheit Sicherheitsrichtlinien Schlüsselaustausch Motivation Anwendung auf Anwendungsebene Anwendung Netzwerk- Stack Netzwerk- Stack Anwendung Netzwerk- Stack Netz

Mehr

VoIP Security Konzepte und Lösungen für sichere VoIP-Kommunikation

VoIP Security Konzepte und Lösungen für sichere VoIP-Kommunikation Evren Eren, Kai-Oliver Detken VoIP Security Konzepte und Lösungen für sichere VoIP-Kommunikation ISBN-10: 3-446-41086-4 ISBN-13: 978-3-446-41086-2 Leseprobe Weitere Informationen oder Bestellungen unter

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

Seminar Neue Techologien in Internet und WWW

Seminar Neue Techologien in Internet und WWW Seminar Neue Techologien in Internet und WWW Sicherheit auf der Anwendungsschicht: HTTP mit SSL, TLS und dabei verwendete Verfahren Christian Raschka chrisra@informatik.uni-jena.de Seminar Neue Internettechnologien

Mehr

Mobilität in IP (IPv4 und IPv6)

Mobilität in IP (IPv4 und IPv6) Mobilität in IP (IPv4 und IPv6) Prof. B. Plattner ETH Zürich IP Next Generation - Mobilität (1) Uebersicht Formen der Mobilitätsunterstützung 1 Echt mobile Benutzer (drahtlos erschlossene Laptops)» Handover

Mehr

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden:

Prinzipiell wird bei IP-basierenden VPNs zwischen zwei unterschiedlichen Ansätzen unterschieden: Abkürzung für "Virtual Private Network" ein VPN ist ein Netzwerk bestehend aus virtuellen Verbindungen (z.b. Internet), über die nicht öffentliche bzw. firmeninterne Daten sicher übertragen werden. Die

Mehr

2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-D-VoD.fm, 2006-11-22 08.08] http://www-vs.informatik.uni-ulm.

2006-2007, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-D-VoD.fm, 2006-11-22 08.08] http://www-vs.informatik.uni-ulm. D Video on Demand D.1 1 RTSP Real-Time Streaming Protocol (RTSP) IETF Standard definiert in RFC 2326 (1998) Zielsetzung Signalisierung und Kontrolle von multimedialen Datenströmen Aufbau, Abbruch von Sitzungen

Mehr

Diameter. KM-/VS-Seminar. Wintersemester 2002/2003. schulze_diameter.ppt Christian Schulze_03-Februar-07

Diameter. KM-/VS-Seminar. Wintersemester 2002/2003. schulze_diameter.ppt Christian Schulze_03-Februar-07 Diameter KM-/VS-Seminar Wintersemester 2002/2003 Betreuer: Martin Gutbrod 1 Übersicht Einleitung AAA Szenarien Remote dial-in Mobile dial-in Mobile telephony Design von Diameter Ausblick Features Protokoll

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

Mehr

DynDNS für Strato Domains im Eigenbau

DynDNS für Strato Domains im Eigenbau home.meinedomain.de DynDNS für Strato Domains im Eigenbau Hubert Feyrer Hubert Feyrer 1 Intro homerouter$ ifconfig pppoe0 pppoe0: flags=8851...

Mehr

Remote Access. Virtual Private Networks. 2000, Cisco Systems, Inc.

Remote Access. Virtual Private Networks. 2000, Cisco Systems, Inc. Remote Access Virtual Private Networks 2000, Cisco Systems, Inc. 1 Remote Access Telefon/Fax WWW Banking E-mail Analog (?) ISDN xdsl... 2 VPNs... Strong encryption, authentication Router, Firewalls, Endsysteme

Mehr

Site2Site VPN S T E F A N K U S I E K B F W L E I P Z I G

Site2Site VPN S T E F A N K U S I E K B F W L E I P Z I G Site2Site VPN S T E F A N K U S I E K B F W L E I P Z I G Übersicht Einleitung IPSec SSL RED Gegenüberstellung Site-to-Site VPN Internet LAN LAN VPN Gateway VPN Gateway Encrypted VPN - Technologien Remote

Mehr

Sichere Identitäten in Smart Grids

Sichere Identitäten in Smart Grids Informationstag "IT-Sicherheit im Smart Grid" Berlin, 23.05.2012 Sichere Identitäten in Smart Grids Dr. Thomas Störtkuhl, Agenda 1 2 Beispiele für Kommunikationen Digitale Zertifikate: Basis für Authentifizierung

Mehr

Asterisk. The Open Source PBX

Asterisk. The Open Source PBX Asterisk. The Open Source PBX In association with: www.bb-k.ch www.asterisk.org Was ist Asterisk? Bei Asterisk handelt es sich nicht um eine reine VoIP-Lösung, sondern um eine echte Software-PBX, die jeden

Mehr

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1

Breitband ISDN Lokale Netze Internet WS 2009/10. Martin Werner, November 09 1 Telekommunikationsnetze 2 Breitband ISDN Lokale Netze Internet Martin Werner WS 2009/10 Martin Werner, November 09 1 Breitband-ISDN Ziele Flexibler Netzzugang Dynamische Bitratenzuteilung Effiziente Vermittlung

Mehr

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät

NAT und Firewalls. Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de. Universität Bielefeld Technische Fakultät NAT und Firewalls Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung 27. April 2005

Mehr

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein: - Grundkonfiguration des Routers. - Ein Bootimage ab Version 7.4.x.

Folgende Voraussetzungen für die Konfiguration müssen erfüllt sein: - Grundkonfiguration des Routers. - Ein Bootimage ab Version 7.4.x. 7. PPPoE Server 7.1 Einleitung Im Folgenden wird die Konfiguration einer Dialin Verbindung über PPPoE zum Router beschrieben, um eine zusätzliche Authentifizierung durchzuführen. Bei der Einwahl eines

Mehr

IP Telefonie Sicherheit mit Cisco Unified Communications Manager

IP Telefonie Sicherheit mit Cisco Unified Communications Manager IP Telefonie Sicherheit mit Cisco Unified Communications Manager Dipl. Ing. (FH) Thomas Ströhm Friday, November 09, 2007 Überblick Security Herausforderungen der IP-Telefonie Einsatz von Secure RTP mit

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 20.06.2003 Internet Security:

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

1REMOTE KONFIGURATION

1REMOTE KONFIGURATION 1REMOTE KONFIGURATION Copyright 24. Juni 2005 Funkwerk Enterprise Communications GmbH Bintec Workshop Version 0.9 Ziel und Zweck Haftung Marken Copyright Richtlinien und Normen Wie Sie Funkwerk Enterprise

Mehr