Sichere Multimediakonferenzen - Institute for Computing and

Sichere Multimediakonferenzen
Diplomarbeit
Markus Pscheidt
April 2000
Begutachter: Reinhard Posch
Betreuer: Herbert Leitold
Institut für angewandte Informationsverarbeitung
Technische Universität Graz
Sichere Multimediakonferenzen
Inhaltsverzeichnis
Inhaltsverzeichnis
1.
Einleitung .................................................................................................................................... 1
2.
Computer Netzwerke.................................................................................................................. 3
2.1. Grundlagen ................................................................................................................................... 3
2.1.1. Anforderungen .................................................................................................................... 4
Verbindungen..................................................................................................................... 4
Kosteneffiziente Ressourcen-Aufteilung ........................................................................... 5
Funktionalität ..................................................................................................................... 6
Performance ....................................................................................................................... 7
2.1.2. Netzwerkarchitektur............................................................................................................8
Schichten und Protokolle ................................................................................................... 9
OSI Architektur................................................................................................................ 10
Internet Architektur.......................................................................................................... 11
2.2. Direct Link Netzwerke ............................................................................................................... 12
2.2.1. Ethernet (CSMA/CD)........................................................................................................ 13
Physikalische Eigenschaften ............................................................................................ 13
Frame Format ................................................................................................................... 14
Adressen........................................................................................................................... 14
Sende-Algorithmus .......................................................................................................... 14
2.3. Packet Switching ........................................................................................................................ 15
2.3.1. Forwarding ........................................................................................................................ 16
Virtuelle Verbindung ....................................................................................................... 16
Datagramme ..................................................................................................................... 16
2.3.2. Routing.............................................................................................................................. 17
2.4. Internetworking .......................................................................................................................... 18
2.4.1. Internet Protocol (IP)......................................................................................................... 18
Service Modell ................................................................................................................. 18
Datagramm-Dienst ........................................................................................................... 19
IP-Header ......................................................................................................................... 19
Fragmentierung ................................................................................................................ 20
Globale Adressen ............................................................................................................. 20
Datagram Forwarding ...................................................................................................... 21
Adress-Auflösung (ARP) ................................................................................................. 21
Fehlerbenachrichtigung (ICMP) ...................................................................................... 21
2.4.2. Host Namen (DNS) ........................................................................................................... 22
2.5. Transport-Protokolle................................................................................................................... 23
i
Inhaltsverzeichnis
Sichere Multimediakonferenzen
2.5.1. Demultiplexing: UDP........................................................................................................ 23
2.5.2. Byte-Stream: TCP ............................................................................................................. 24
Allgemeine Betrachtungen............................................................................................... 24
Segmente.......................................................................................................................... 24
TCP Header...................................................................................................................... 25
Verbindungsaufbau und Terminierung ............................................................................ 25
Sliding Window ............................................................................................................... 26
Flusskontrolle................................................................................................................... 28
Slow Start......................................................................................................................... 28
Congestion Avoidance ..................................................................................................... 28
Fast Retransmit ................................................................................................................ 29
Fast Recovery................................................................................................................... 29
3.
Sicherheit in Datennetzen ........................................................................................................ 31
3.1. Einleitung.................................................................................................................................... 31
3.1.1. Gefahren und Maßnahmen................................................................................................ 31
3.2. Kryptographische Grundlagen.................................................................................................... 32
3.2.1. Symmetrische Verschlüsselung ........................................................................................ 33
Electronic Code Book Mode (ECB) ................................................................................ 33
Cipher Block Chaining (CBC) ......................................................................................... 34
DES .................................................................................................................................. 34
3.2.2. Asymmetrische Verschlüsselung ...................................................................................... 35
Diffie Hellman ................................................................................................................. 36
RSA.................................................................................................................................. 36
Hashing ............................................................................................................................ 37
Digitale Signaturen........................................................................................................... 37
Zertifikate......................................................................................................................... 37
3.3. Firewalls ..................................................................................................................................... 38
Paketfilter ......................................................................................................................... 38
Circuit Level Gateway ..................................................................................................... 39
Application Level Gateway.............................................................................................. 39
3.4. IPSec........................................................................................................................................... 40
Authentication Header (AH) ............................................................................................ 40
Encapsulating Security Payload (ESP) ............................................................................ 41
Schlüsselmanagement ...................................................................................................... 41
3.5. SSL ............................................................................................................................................. 42
3.6. SOCKS ....................................................................................................................................... 43
4.
Multimediakonferenzen ........................................................................................................... 45
4.1. Real-Time Applikationen ........................................................................................................... 45
4.1.1. Service-Modell.................................................................................................................. 45
Service-Klassen................................................................................................................ 46
4.2. Protokoll-Stack ........................................................................................................................... 47
4.3. H.323 .......................................................................................................................................... 48
4.3.1. H.323 Endknoten............................................................................................................... 48
ii
Sichere Multimediakonferenzen
Inhaltsverzeichnis
4.3.2. Kanäle ............................................................................................................................... 49
4.4. SIP .............................................................................................................................................. 50
4.5. RTP/RTCP.................................................................................................................................. 51
4.5.1. RTP ................................................................................................................................... 52
4.5.2. RTCP................................................................................................................................. 53
4.6. RSVP .......................................................................................................................................... 53
4.6.1. Reservierung ..................................................................................................................... 54
5.
Windows Sockets ...................................................................................................................... 55
5.1. Das WinSock-Modell ................................................................................................................. 55
5.2. Programm-Schema ..................................................................................................................... 56
5.2.1. Client/Server Modell......................................................................................................... 56
Client-Server Assoziation ................................................................................................ 56
5.2.2. Programm-Skizze.............................................................................................................. 57
5.2.3. Socket öffnen .................................................................................................................... 57
5.2.4. Socket benennen................................................................................................................ 57
5.2.5. Socket-Assoziation............................................................................................................ 58
Szenario UDP................................................................................................................... 58
Szenario TCP ................................................................................................................... 59
5.2.6. Senden und Empfangen..................................................................................................... 59
Socket Demultiplexing..................................................................................................... 60
5.2.7. Socket schließen................................................................................................................ 60
5.2.8. Skizzen für TCP und UDP ................................................................................................ 62
5.3. Operationsmodi .......................................................................................................................... 63
5.3.1. Blocking I/O...................................................................................................................... 63
5.3.2. Nonblocking I/O................................................................................................................ 63
5.3.3. Overlapped I/O.................................................................................................................. 63
5.4. Service Provider Interface .......................................................................................................... 64
5.4.1. WinSock 2 als WOSA....................................................................................................... 64
5.4.2. Interface Modell ................................................................................................................ 65
5.4.3. Layered Service Provider.................................................................................................. 66
5.4.4. Aufgabenteilung................................................................................................................ 66
5.4.5. Mapping zwischen API- und SPI-Funktionen .................................................................. 67
5.4.6. Installation......................................................................................................................... 67
6.
Benutzung des RLSP ................................................................................................................ 69
6.1. Aufgabenstellung........................................................................................................................ 69
6.2. Funktionsweise ........................................................................................................................... 70
6.2.1. Szenario TCP .................................................................................................................... 71
6.2.2. Szenario UDP.................................................................................................................... 72
6.3. Komponenten.............................................................................................................................. 73
6.3.1. RLSP ................................................................................................................................. 73
6.3.2. RLSP.INI........................................................................................................................... 74
[Configuration]................................................................................................................. 74
[Proxytunnel] ................................................................................................................... 75
iii
Inhaltsverzeichnis
Sichere Multimediakonferenzen
[TCP Outgoing], [UDP Outgoing] ................................................................................... 75
[TCP Incoming], [UDP Incoming] .................................................................................. 75
6.3.3. Proxytunnel ....................................................................................................................... 76
client.ini, server.ini........................................................................................................... 76
6.3.4. Installer.............................................................................................................................. 76
6.3.5. Monitor.............................................................................................................................. 78
7.
Zusammenfassung .................................................................................................................... 81
A.
Abkürzungen............................................................................................................................. 83
B.
Bibliographie............................................................................................................................. 89
B.1.Networking ................................................................................................................................. 89
B.2.Security....................................................................................................................................... 90
B.3.Internet Telefonie........................................................................................................................ 91
B.4.Windows Sockets........................................................................................................................ 92
B.5.Weiterführende Literatur ............................................................................................................ 92
iv
Sichere Multimediakonferenzen
Abbildungsverzeichnis
Abbildungsverzeichnis
Bild 2-1:
Direktverbundenes Netzwerk: (a) Point-to-Point, (b) Multiple Access ........................... 4
Bild 2-2:
Netzwerk mit Switches..................................................................................................... 4
Bild 2-4:
Kommunikationskanal zwischen Prozessen ..................................................................... 7
Bild 2-6:
Service- und Peer-Interfaces............................................................................................. 9
Bild 2-8:
OSI Netzwerkarchitektur................................................................................................ 10
Bild 2-9:
Internet Protokollgraph................................................................................................... 11
Bild 2-10:
Alternative Darstellung des Protokollgraphen................................................................ 11
Bild 2-11:
CSMA/CD Verfahren..................................................................................................... 12
Bild 2-12:
Ethernet Frame Format................................................................................................... 13
Bild 2-13:
Durch Switch entsteht Stern-Topologie.......................................................................... 14
Bild 2-14:
Netzwerk dargestellt als Graph....................................................................................... 17
Bild 2-15:
Ein Netzwerk aus physikalischen Netzen („internet“) ................................................... 18
Bild 2-16:
IPv4 Packet Header ........................................................................................................ 19
Bild 2-17:
IP Adressen: (a) Klasse A; (b) Klasse B; (c) Klasse C................................................... 20
Bild 2-18:
Beispiel einer DNS Hierarchie ....................................................................................... 22
Bild 2-19:
Format des UDP Headers ............................................................................................... 23
Bild 2-20:
Format des TCP Headers................................................................................................ 25
Bild 2-21:
Zeitachse für den Three-Way Handshake....................................................................... 26
Bild 2-22:
Vereinfachte Darstellung für eine Richtung des TCP Datenaustausches: Daten fließen in
eine Richtung, ACKs in die andere ................................................................................ 26
Bild 2-23:
Beziehung zwischen TCP Sende- und Empfangsbuffer................................................. 27
Bild 3-1:
Sicherheitslösungen in den TCP/IP Ebenen ................................................................... 32
Bild 3-2:
Symmetrischer (Private Key) Algorithmus .................................................................... 33
Bild 3-3:
Electronic Code Book Mode (ECB)............................................................................... 34
Bild 3-4:
Cipher Block Chaining (CBC) ....................................................................................... 34
Bild 3-5:
Eine Runde des DES-Algorithmus ................................................................................. 34
Bild 3-6:
Unsymmetrischer (Public Key) Algorithmus ................................................................. 35
Bild 3-9:
AH in Transport Mode: (a) Original IP Paket; (b) Paket mit AH Header ...................... 40
Bild 3-10:
AH in Tunnel Mode: (a) Original IP Paket; (b) Tunneled Packet; (c) Paket mit AH
Header............................................................................................................................. 40
Bild 3-11:
VPN mit IPSec: Hosts verschlüsseln, Gateways authentifizieren die Daten.................. 41
Bild 3-12:
Zustandekommen einer SSL Verbindung....................................................................... 43
Bild 4-1:
Layered Protocol Archtitektur ........................................................................................ 46
v
Abbildungsverzeichnis
Sichere Multimediakonferenzen
Bild 4-2:
Multimediakonferenz-Architektur laut IETF ................................................................. 47
Bild 4-3:
H.323 Komponenten....................................................................................................... 49
Bild 4-4:
SIP-Verbindungsaufbau mit Hilfe eines Proxy-Servers ................................................. 50
Bild 4-5:
RTP Header .................................................................................................................... 52
Bild 4-6:
RSVP Multicast-Baum ................................................................................................... 54
Bild 5-2:
Verbindungsorientierte Netzwerk-Programme (TCP).................................................... 61
Bild 5-3:
Verbindungslose Netzwerk-Programme (UDP) – Setze den Namen des Empängers
explizit ............................................................................................................................ 62
Bild 5-4:
Verbindungslose Netzwerk-Programme (UDP) – Setze den Namen des Empfänger bei
jedem Datagramm .......................................................................................................... 62
Bild 5-5:
Windows Sockets 2 Struktur als WOSA-Komponente in Windows.............................. 64
Bild 5-6:
Layered Protocol Archtitektur ........................................................................................ 65
Bild 6-1:
Funktionsweise des RLSP .............................................................................................. 70
Bild 6-2:
Szenario TCP: Informationsfluss.................................................................................... 71
Bild 6-3:
Szenario UDP mit Mapping zwischen Udp und Tcp...................................................... 72
Bild 6-4:
Die graphische Version des Installers ............................................................................ 77
Bild 6-5:
Der Monitor .................................................................................................................... 78
vi
Sichere Multimediakonferenzen
Einleitung
1. Einleitung
Die Verschmelzung des traditionellen leitungsvermittelten Telefonnetzwerks mit paketvermittelten IPNetzen bringt zum einen Kosteneinsparungspotenziale, zum anderen entstehen neue Services. Der
professionelle Einsatz von Internet-Telephonie und Multimediakonferenzen verlangt eine
Sicherheitsinfrastruktur, die die Integrität und Vertraulichkeit der Daten sowie die Authentizität der
Teilnehmer sicherstellt.
Für den praktischen Teil der Diplomarbeit wurde ein Ansatz gewählt, der diese Aufgaben in einer für
Netzwerk- Applikationen transparenten Weise erfüllt. Außerdem ist das Ergebnis der Arbeit nicht auf
bestimmte Anwendungen beschränkt. Vielmehr werden beliebige IP Adressen und Ports spezifiziert,
die über einen SSL-gesicherten Kanal kommunizieren sollen. Damit ist die Realisierung von Virtual
Private Networks (VPN), also die Kommunikation zwischen vertrauenswürdigen Netzen über das
unsichere Internet hinweg, möglich.
Das Ergebnis ist eine dynamische Bibliothek (DLL), die die Service Provider Schnittstelle von
Windows Sockets 2 nutzt und als Layered Service Provider in das Windows System eingebunden
wird. Die DLL befindet sich logisch zwischen Applikation und TCP/IP-Stack. Nach der Registrierung
gehen Datenströme von Applikationen an die DLL und werden über den sicheren SSL-Kanal
gesendet.
Der vorliegende Text beschreibt den theoretischen Hintergrund, in dem die Aufgabenstellung
angesiedelt ist und leitet dann in die Erläuterung der praktischen Lösung über. Zunächst folgt eine
Darstellung der Konzepte moderner Netzwerke mit Bezug auf das Internet. Kapitel 2 beschreibt
ausgehend von den Anforderungen an Netzwerke jene Technologien, die Computer auf
unterschiedlichen Ebenen miteinander verbinden. Es werden sowohl lokale Netzwerke betrachtet als
auch die Strukturen des Internets.
Kapitel 3 ist eine Einführung in Sicherheitskonzepte, die zur Sicherung von Netzwerkdaten eingesetzt
werden. Zuerst werden die kryptographischen Grundlagen wie symmetrische und asymmetrische
Verschlüsselung erläutert, die dann in Konzepten und Protokollen Anwendung finden, um Daten
zwischen Computern im Netzwerk zu sichern. Zu diesen zählen unter anderem Firewalls und Secure
Socket Layer (SSL).
Im anschließenden Kapitel werden Multimediakonferenzen behandelt. Diese gehören zur Klasse der
Real-Time-Applikationen und haben besondere Ansprüche an die Verzögerungscharakteristik des
Netzwerks. Eine Reihe von Protokollen bildet die Basis für Multimediakonferenzen. Im Bereich des
Verbindungsaufbaus gibt es zwei konkurrierende Ansätze, die jeweils beschrieben werden. Zusätzlich
kommen Protokolle zur Übertragung von Bild und Ton in Echtzeit zum Einsatz.
1
Einleitung
Sichere Multimediakonferenzen
Die Beschreibung des praktischen Teils leitet das Kapitel über Windows Sockets ein. Dieses erläutert
wesentliche Grundlagen, die der Erstellung des Security Providers zugrunde liegen. Dazu gehört
einerseits die Struktur von Netzwerkapplikationen und deren Operationsmodi, andererseits das Service
Provider Interface von Windows Sockets 2, das erst die Erstellung eines flexiblen Security Providers
ermöglicht, der nicht an einzelne Applikationen gebunden ist. Das Ergebnis der praktischen Arbeit
selbst wird im abschließenden Kapitel vorgestellt.
Mein Dank gilt Prof. Reinhard Posch und DI Herbert Leitold für die Ermöglichung und die Betreuung
der Arbeit während der vergangenen Monate.
Graz, im April 2000
2
Sichere Multimediakonferenzen
Computer Netzwerke
2. Computer Netzwerke
Netzwerke zählen zu den zentralen Gebieten der Computerwissenschaften. Sie werden von vielen
Menschen genutzt, unter anderem für populäre Dienste wie Emails zu versenden, durchs World Wide
Web zu „surfen“ sowie mit zunehmender Bandbreite die Möglichkeit Videokonferenzen zu führen. In
diesem Kapitel sollen die Konzepte vorgestellt und erläutert werden, mit Hilfe derer Netzwerke
gebildet werden. Es beginnt damit, die Anforderungen zu definieren und mögliche Architekturen
vorzustellen, in deren Mittelpunkt Protokolle stehen. Von diesen Architekturen ausgehend werden
physische Verbindungen zwischen zwei bzw. mehreren Computern erstellt. Die Technologien dazu
heißen etwa Ethernet oder Token Ring und bilden lokale Netzwerke.
Diese stoßen an ihre Grenzen wenn es darum geht, geographisch weit entfernte sowie eine größere
Anzahl an Hosts miteinander zu verbinden. Packet switching heißt das Konzept, um die
Kommunikation zwischen nicht direkt verbundenen Hosts zu ermöglichen. Die Datenpakete
durchlaufen Switches und Router, um ans Ziel zu gelangen. Dazu müssen Router die nötige Kenntnis
über die Topologie des Netzwerks erlangen, sodass die Daten den Empfänger erreichen. Viele Pakete
unterschiedlicher Sender passieren zur selben Zeit den Router, sie streiten sich sozusagen um die
Aufmerksamkeit des Routers. Dieser Vorgang heißt Contention. Wenn die Buffer des Routers
erschöpft sind, müssen weitere Pakete verworfen werden (Congestion).
Der Aufbau dieses Kapitels erstreckt sich von der Analyse der Anforderungen und der Architekturen
von Netzwerken über physikalische Netze – das sind Netze, deren Hosts ein gemeinsames
Übertragungsmedium teilen – bis zu Transport-Protokollen, die für den geordneten Datentransfer aus
der Sicht von Applikationen verantwortlich sind. Der anfänglichen Anforderungsanalyse wird viel
Platz eingeräumt, da sie für das Verstehen des Funktionierens von Netzwerken eine wichtige Basis
bildet. Auf das Konzept des Packet Switching wird in einem eigenen Abschnitt dieses Kapitels
eingegangen, da sich dieses grundlegend von der traditionellen Methode der Vermittlung im
Telefonnetz unterscheidet. Von diesen Konzepten ausgehend folgt eine Erläuterung des zentralen
Internet Protokolls (IP). Zusätzlich wird noch das Namenssystem des Internet vorgestellt, das Domain
Name System. Auf das IP Protokoll setzen schließlich die Transport-Protokolle auf, deren Analyse
den Abschluss dieses Kapitels bildet.
2.1. Grundlagen
Den Aufbau und die Technologien von Netzwerken ergeben sich aus einer Reihe von Anforderungen,
die die Basis bilden für Applikationen wie etwa FTP, WWW und Videokonferenzen [PD96]. In
diesem Abschnitt sollen zunächst diese Anforderungen analysiert werden, um danach auf
Netzwerkarchitekturen überleiten zu können, die sich eignen, diese Anforderungen zu erfüllen. Wie
3
Computer Netzwerke
Sichere Multimediakonferenzen
(a)
(b)
Bild 2-1:
Direktverbundenes Netzwerk:
(a) Point-to-Point, (b) Multiple Access
Bild 2-2:
Netzwerk mit Switches
im folgenden gezeigt wird, gibt es zunächst die Anforderung, dass Netzwerke ermöglichen sollen,
Verbindungen zwischen Computern herzustellen, um damit einen Datenaustausch zu erreichen. Dabei
sollen die stets beschränkten Ressourcen möglichst effizient ausgenutzt werden. Dazu ist es nötig,
Kriterien für Effizienz zu analysieren. Schließlich wird noch gezeigt, welche Funktionen ein Netzwerk
den Applikationen zur Verfügung stellen soll und welche Parameter der Messung von
Netzwerkperformance dienen.
Der nächste Schritt ist die Ableitung einer allgemeinen Architektur als Vorlage für
Implementierungen. Dazu werden die Konzepte von Protokollen und Schichten, auf denen Protokolle
implementiert werden, vorgestellt. Als Referenzarchitektur gilt die OSI-Architektur mit sieben
Schichten. Schließlich wird die Internet-Architektur vorgestellt.
2.1.1.
Anforderungen
Dieser Abschnitt gliedert sich in vier Teile, die wesentliche Anforderungen an Netzwerke darstellen.
Als erstes wird gezeigt, dass Verbindungen nötig sind, um einen Datenaustausch zwischen Computern
zu ermöglichen. Daran schließen die Themen von effizienter Ressourcennutzung sowie Funktionalität
bezüglich Applikationen und Performance-Parametern an.
Verbindungen
Zu allererst wird von einem Netzwerk verlangt, Verbindungen zwischen Computern bereitzustellen.
Das passiert auf verschiedenen Ebenen. Auf unterster Ebene kann ein Netzwerk aus zwei oder
mehreren Computern (Knoten, Nodes) bestehen, die über ein physikalisches Medium verbunden sind
(Links). Im Falle eines einzelnen Paares spricht man von point-to-point, für den Fall mehrerer Knoten,
die sich ein Medium teilen, verwendet man den Begriff multiple access, wie in Bild 2-1 zu sehen.
Nicht alle Computer benötigen eine physikalische Verbindung zwischen einander. Kooperierende
Knoten schaffen indirekte Verbindungen, wie im Beispiel eines switched networks. Dieser Typ von
Netzwerken besteht aus Computern, die jeweils über point-to-point links verbunden sind. Computer,
die mit mindestens zwei Links verknüpft sind, verwenden eine Logik, die in Software implementiert
ist, um Daten weiterzuleiten (forwarding). Diese Computer stellen sogenannte Switches dar. Zwei
Typen eines switched networks sind circuit switched (leitungsvermittelte) Netzwerke und packet
switched (paketvermittelte) Netzwerke.
4
Sichere Multimediakonferenzen
Computer Netzwerke
Leitungsvermittelte Netze finden Anwendung im Telefonsystem. Es besteht eine Verbindung mit
reservierter Bandbreite zwischen den Teilnehmern, die im Verbindungsaufbau zustande kommt.
Paketvermittelte Netze werden oft für Computer-Netze eingesetzt. Es gibt keinen expliziten
Verbindungsaufbau, sondern es werden diskrete Datenblöcke gesendet, die sich ihren Weg durchs
Netzwerk bahnen, jedoch weder garantiert ankommen noch jedesmal mit der selben Zeitverzögerung.
Paketvermittelte Netze verwenden die Strategie store and forward, d. h. die Pakete (genannt Packets
oder Messages – je nach Transport Protokoll) werden zur Gänze in den Switches zwischengespeichert
bevor sie den weiteren Weg durchs Netz antreten.
Die Wolke in Bild 2-2 trennt die Knoten, die das Netzwerk implementieren (die Netzelemente) von
den Knoten, die die Dienste des Netzwerks benutzen (die Hosts). Das Symbol der Wolke ist im
allgemeinen Platzhalter für eine beliebige Art eines Netzes und findet oft Verwendung in Skizzen.
Die nächste Ebene, in der Computer indirekt verbunden werden, ist das Zusammenführen
unabhängiger Netzwerke zu einem sogenannten internetwork oder kurz internet. Dabei steht internet
mit kleinem i ganz allgemein für ein Netz aus mehreren einzelnen Netzwerken, und das Internet für
das konkrete operierende TCP/IP Internet. Die Funktion, die Switches zwischen Endknoten hat,
nämlich Daten weiterzuleiten, erledigen Router (auch Gateways genannt) zwischen zwei oder
mehreren Netzen.
Damit ein Host die Möglichkeit hat, einen anderen Host als Empfänger zu definieren, erhalten alle
Hosts eindeutige Adressen in numerischer Form zugewiesen, die sie von allen anderen Hosts im
Netzwerk unterscheiden. Wenn Sender und Empfänger nicht direkt verbunden sind, ist es die Aufgabe
der Switches und Router, die Daten auf geeignetem Weg durchs Netzwerk zu schleusen. Der Prozeß
der systematischen Entscheidung, wohin Datenpakete weitergeleitet werden sollen, nennt sich
Routing.
Während bis dato davon ausgegangen wurde, dass der Source Node seine Daten an einen einzelnen
Destination Node sendet – diese Adressierung nennt sich Unicast – kommt es gelegentlich auch vor,
dass der Sender die Daten an alle Knoten im Netzwerk senden möchte (Broadcast) oder an einen Teil,
jedoch nicht an alle Knoten (Multicast). Spezielle Adressen müssen also als Broadcast- bzw.
Multicast-Adressen reserviert werden.
Kosteneffiziente Ressourcen-Aufteilung
Wie erwähnt herrscht das Modell des packet switched Netzwerks vor, wenn es sich um Computernetze
handelt. Der Grund dafür liegt in der höheren Effizienz gegenüber den circuit switched Netzen, wie im
folgenden gezeigt wird.
Wenn jedes beliebige Paar von Hosts in einem indirekt verbundenen Netzwerk miteinander
kommunizieren möchte, dann müssen die Ressourcen des Netzwerks aufgeteilt werden. Dabei kommt
erschwerend hinzu, dass die Hosts jeden beliebigen Link potenziell zur selben Zeit in Anspruch
nehmen. Das fundamentale Konzept dazu heißt Multiplexing, d. h. Aufteilen von Systemressourcen
auf mehrere Benutzer. Die Daten mehrere Hosts werden also multiplexed auf den physikalischen Link
und, nachdem die Daten den Link passiert haben, wieder demultiplexed, also wieder zum
ursprünglichen Datenstrom zusammengesetzt.
Es gibt verschiedene Arten des Multiplexing; Synchronous time division multiplexing (STDM) teilt
den Teilnehmern eine feste Zeiteinheit zu. Frequency division multiplexing (FDM) vergibt einen Teil
des gesamten zur Verfügung stehenden Frequenzspektrums, den der Teilnehmer für sich nutzen kann.
5
Computer Netzwerke
Sichere Multimediakonferenzen
...
Bild 2-3:
Multiplexing von Paketen auf gemeinsam genutzten Link
Daneben gibt es noch Statistical multiplexing. Dieses hat den großen Vorteil, daß hier keine
Leerlaufzeiten entstehen, wenn ein Sender zeitweilig keine Daten versendet. Der Link wird zwar auch
auf Zeitintervalle aufgeteilt, allerdings erfolgt die Zuteilung zu einem Sender auf Anfrage, also nur
dann, wenn auch Daten anstehen.
Da einige Sender eventuell sehr große Datenmengen versenden möchten, müssen sich alle auf eine
Größe einigen, auf die des sogenannten Packet. Jeder Sender muß die Datenblöcke also im
allgemeinen auf diese Größe fragmentieren, und der Empfänger muß darauf vorbereitet sein, die
Packets wieder zu größeren Blöcken zusammenzusetzen.
Die Entscheidung, welches Packet als nächstes gesendet wird, liegt bei den Netzwerkelementen. Jeder
Router bzw. Switch entscheidet unabhängig; Sein Ziel sollte es sein, möglichst fair zu entscheiden.
Beispiele für mögliche Strategien sind Round-Robin bzw. FIFO (First in – first out). Es kann
vorkommen, dass der Router bzw. Switch mehr Pakete erhält als er über den Link weitersenden kann.
In diesem Fall versucht er, Daten in internen Buffern temporär abzulegen. Sind die Buffer überlastet,
müssen Pakete zwangsläufig verworfen werden. Diese Situation nennt man Congestion.
Funktionalität
Die Anforderungen an ein Netzwerk aus Applikations-Perspektive sind größer als lediglich das
effiziente Transportieren von Datenpaketen in einer Ansammlung von Computern. Die vielfältigen
Aufgaben, die bei der Kommunikation zwischen Applikationen auf verschiedenen Hosts entstehen,
könnten in jeder einzelnen Applikation neu entwickelt werden, das ist aber sicher nicht besonders
effizient. Daher ist es ein guter Kompromiss, gemeinsame Funktionalität einmal zu implementieren
und den Anwendungen dann zur Verfügung zu stellen, die die Dienste dann nutzen können.
Intuitiv werden Netzwerke als Provider von logischen Kanälen (Channels) gesehen, über die
Applikationsprozesse Daten austauschen. Dies ist in Bild 2-4 veranschaulicht. Jeder Kanal stellt die
Services dar, die die Applikation benötigt und stellt damit eine abstrakte Verbindung zwischen zwei
Prozessen dar – so wie die Wolke Konnektivität zwischen Knoten symbolisiert.
Die Herausforderung besteht darin, zu erkennen, welche Funktionalität von seiten der Anwendungen
gefragt ist. Mögliche Bespiele sind
garantierte Zustellung,
Eintreffen der Datenpakete in der selben Reihenfolge, in der sie gesendet wurden,
abhörsichere Kanäle mit Hilfe von Verschlüsselung.
6
Sichere Multimediakonferenzen
Host
Computer Netzwerke
Host
Applikation
Host
Host
Applikation
Bild 2-4:
Kommunikationskanal zwischen Prozessen
FTP sowie digitale Bibliotheken etwa laufen nach dem Schema eines Request/Reply Kanals ab. Eine
Partei macht eine Anfrage (der Client), die vom Befragten, dem Server, beantwortet wird, in dem
Dateien oder andere Informationen transferiert werden (so der Client die nötigen Zugriffsrechte
besitzt.
Während eine FTP Anfrage noch immer als erfolgreich gilt, auch wenn sie mehrere Sekunden in
Anspruch nimmt, hat die Klasse von Applikationen für Videoübertragung und Videokonferenzen
andere Anforderungen. Wird die Verzögerung der Übertragung kurzzeitig zu groß, sind die zu spät
angekommenen Daten wertlos, da kein kontinuierliches Abspielen der Bild- oder Tondaten mehr
möglich ist.
Aus diesen Beispielen geht hervor, dass es mindestens zwei unterschiedliche Typen von Kanälen
geben sollte: einen Request/Reply-Kanal und einen Message Stream-Kanal. Während Request/ReplyKanäle Daten verlässlich übertragen sollen, ist für Message Stream-Kanäle rasche Übertragung
wichtiger. Für beide ist Übertragung in der korrekten Reihenfolge wichtig und auch Abhörsicherheit
kann für beide interessant sein.
Die Eigenschaften der Kanäle richten sich also nach den Anforderungen der übergeordneten
Applikationen. Von der darunter liegenden Technologie aus betrachtet gibt es dagegen Limitationen,
was diese Technologie bieten kann. Man hat mehrere Fehlerquellen zu beachten, die sich negativ auf
die Verlässlichkeit des Netzwerks auswirken: Bit Fehler, Packet Fehler und Fehler auf Node und Link
Level. Diese Fehlerquellen werden an dieser Stelle nicht weiter vertieft.
Performance
Wenn es um Netzwerke geht, ist es notwendig, von Anfang an den Aspekt der Effizient
einzubeziehen. Es reicht nicht aus, etwas zuerst korrekt zu implementieren und danach zu optimieren.
Netzwerkperformance wird in Bandbreite als auch in Verzögerung (Latency, Delay) gemessen. Die
Bandbreite gibt die Anzahl der Bits an, die pro Zeiteinheit durch das Netzwerk bzw. über den Link
transportiert werden können, z. B. 10 MBit/s. Umgekehrt kann man sich vorstellen, dass jedes
einzelne Bit in einem 10 MBit/s Netzwerk 0,1 µs (10-7 s) benötigt, um in das Netzwerk zu gelangen.
7
Computer Netzwerke
Sichere Multimediakonferenzen
Delay
Bandwidth
Bild 2-5:
Netzwerk abstrahiert als Leitung mit Länge und Durchmesser
Latency ist die Zeit, die ein Bit benötigt, um von einem Ende des Netzwerks zum anderen zu gelangen,
etwa 25 ms für einen transkontinentalen Link. Die sogenannte Round Trip Time (RTT) ist die Summe
der Verzögerungen in beide Richtungen, also von einem Ende zum anderen und wieder zurück.
Die wahrgenommene Verzögerung wird von drei Parametern beeinflusst: durch die endliche
Ausbreitungsgeschwindigkeit des Lichts, die Zeit um einen Datenblock zu transportieren und durch
Bufferzeiten innerhalb der Switches und Router:
Verzögerung = Ausbreitung + Übertragung + Bufferzeiten
Ausbreitung = Distanz / Lichtgeschwindigkeit
Übertragung = Datengröße / Bandbreite
Man erkennt, dass die gesamte Verzögerung potenziell durch die Lichtgeschwindigkeit begrenzt wird.
Je nach Anwendung stehen unterschiedliche Aspekte der Verzögerung im Vordergrund. Beim
Versenden eines einzelnes Byte wird Verzögerung wesentlich von der Distanz bestimmt, bei mehreren
MByte dagegen maßgeblich von der Bandbreite.
Das Delay × Bandwidth Produkt schließlich misst die Anzahl der Bits, die in einem Kanal Platz
finden. Es gibt somit auch an, wie viele Bits der Sender absenden muss, bevor der Empfänger das erste
Bit davon erhält.
Viele Anwendungen fordern vom Netzwerk einfach soviel Bandbreite wie sie erhalten können.
Andere, etwa Videoapplikationen, haben aufgrund der Bilddaten genau bekannte Anforderungen.
Auch in Bezug auf Latency gibt es Anforderungen. Manche möchten einfach nur eine möglichst kurze
Verzögerung, anderen ist es wichtig, dass die Verzögerung nicht zu stark variiert. Diese Variation der
Verzögerung wird Jitter genannt.
2.1.2.
Netzwerkarchitektur
Zu den genannten Anforderungen an Netzwerke kommt hinzu, dass Netzwerke niemals eine konstante
Struktur beibehalten, sondern ständig weiterentwickelt werden, um sich an neue Situationen und
Anforderungen von Anwendungen und Technologie anzupassen [PD96]. Um diese komplexe
Situation überschaubar zu machen, wurden Architekturen entwickelt, von denen die OSI- und die
Internet-Architektur die am weitesten verbreiteten sind [Tan92]. Beiden gemeinsam ist die
Organisation in Schichten, die unterschiedliche Teile der gesamten Funktionalität implementieren.
Nach einer Erläuterung des Schichtenmodells folgt das OSI-Modell, da es ein wichtiges
Referenzmodell ist, bevor die Internet-Architektur vorgestellt wird.
8
Sichere Multimediakonferenzen
Host
Übergeordnetes
Objekt
Protokoll
Bild 2-6:
Computer Netzwerke
Host
Service
Interface
Peer-zu-Peer
Interface
Übergeordnetes
Objekt
Protokoll
Service- und Peer-Interfaces
Schichten und Protokolle
Zusätzliche Abstrahierung führt zum Design mit Hilfe von Schichten (Layer). Die Idee ist, die Dienste
einer darunterliegenden Hardware zu nutzen und eine Anzahl an Schichten darüber zu legen. Jede
Schicht baut auf die untere auf und implementiert ein höheres Service Level. Das Schichtenmodell
bringt zwei Vorteile: Erstens zerlegt es die komplexe Aufgabe in kleinere, besser überschaubare Teile.
Zweitens entsteht ein modulares Design, in der neue Funktionalität gezielt in eine Schicht eingebaut
werden kann.
Die Objekte, die die einzelnen Schichten darstellen, sind die Protokolle. Jedes Protokoll besitzt zwei
Interfaces: ein Service Interface für lokale Objekte und ein Peer Interface zum Gegenstück auf einer
anderen Maschine, das die Art und Weise festlegt, wie die beiden Peers Nachrichten austauschen, wie
in Bild 2-6 dargestellt. Um die Daten mit dem Peer auszutauschen, gibt jede Schicht die Daten an das
Protokoll unterhalb weiter, bis es schließlich auf den physikalischen Link gesendet wird. Die
Protokolle, die das Netzwerk gemeinsam darstellen, werden im Protokollgraph zusammengefasst. Die
Knoten stellen die Protokolle dar, die Kanten Abhängigkeitsbeziehungen. Die Protokolle, die sich eine
Anwendung zu Nutze macht, um ein gewisses Service zu verwenden, nennt man Protokoll-Stack (z. B.
TCP/IP Stack).
Standards für Protokolle und Protokollgraphen werden von ISO (International Standards Organization)
und IETF (Internet Engineering Task Force) festgelegt. Die Regeln, die Form und Inhalt der
Protokollgraphen festlegen, werden als Netzwerkarchitektur bezeichnet.
Kapselung
Layer i+1
Ein Protokoll, das Daten von einer übergeordneten Schicht erhält,
interpretiert diese Daten nicht, da es nichts darüber weiß, ob es sich
z. B. um eine Email Nachricht, ein Videoframe oder sonst etwas
handelt. Andererseits muss ein Protokoll mit seinem Peer einige
Informationen austauschen, sodass dieser die empfangenen Daten in
der richtigen Weise überarbeiten kann. Diese Kontrollinformationen
werden in der Regel als Header vor die eigentliche Nachricht gestellt
oder als Trailer an die Nachricht angehängt, bevor sie gesendet, d. h.
an die nächste niedrigere Schicht weitergegeben wird. Das Format
des Headers ist im Protokoll definiert. Die eigentliche Nachricht wird
Datenblock
Layer i
Header
Datenblock
Layer i-1
Bild 2-7:
Kapselung
9
Computer Netzwerke
Sichere Multimediakonferenzen
End Host
End Host
Application
Application
Presentation
Presentation
Session
Session
Knoten im Netzwerk
(Switches, etc.)
Transport
Transport
Network
Network
Network
Network
Data link
Data link
Data link
Data link
Physical
Physical
Physical
Physical
Bild 2-8:
OSI Netzwerkarchitektur
Body genannt und ist in der neu entstandenen, vergrößerten Nachricht gekapselt (encapsulated).
Der Peer, der die Nachricht inklusive Header (bzw. Trailer) empfängt, macht die umgekehrten
Operationen: der Header wird entfernt, die Aktionen, die der Header impliziert, werden auf den
Message Body angewendet, und das Resultat an das höhere Objekt weitergegeben.
Multiplexing und Demultiplexing
Multiplexing gibt es nicht nur als Technik für Packet Switching, sondern auch, um die Beziehung
zwischen zwei übereinander gelegenen Protokollen herzustellen. Damit das untere Protokoll
feststellen kann, an welches von den vielen möglichen Protokollen die Daten weitergegeben werden
sollen, besitzt der Header einen Demultiplexing Schlüssel (demux key), der senderseitig – so wie alle
anderen Header-Felder – eingetragen wird und das übergeordnete Protokoll identifiziert.
OSI Architektur
ISO war eine der ersten Organisationen, die eine Spezifikation aufstellte, um Netzwerke zu
implementieren. Diese Architektur heißt Open Systems Interconnection (OSI) [TAN92] und teilt die
Netzwerkfunktionalität auf sieben Schichten auf, die ein Referenzmodell für Protokollgraphen
darstellen. Die ITU (International Telecommunications Union) veröffentlicht Protokollspezifikationen
auf Grundlage der ISO Architektur, z. B. X.25 als Standard für packet-switching Protokolle oder
X.400 für Emails. Die sieben Schichten sind in Bild 2-8 dargestellt. Die untersten drei Schichten sind
in allen Netzwerkknoten vorhanden und kommen zum Einsatz, wenn Daten einen Host passieren,
während nur Endknoten die oberen Schichten implementieren, die dann benutzt werden, wenn Daten
vom Benutzer gesendet oder empfangen werden.
10
o
Die physische Schicht hat die Aufgabe, Bits über ein Kommunikationsmedium zu
transportieren und bezieht sich auf die Hardware, die diese Aufgabe erfüllt.
o
Die Data Link Schicht aggregiert eine Anzahl von Bits zu einem sogenannten Frame. Sie ist
für Fehlerkontrolle und Synchronisation der physischen Schicht verantwortlich. Diese Schicht
wird meist von Netzwerkadaptern (Ethernet etc.) implementiert.
Sichere Multimediakonferenzen
FTP
HTTP
Computer Netzwerke
NV
TCP
UDP
Applikation
TCP
UDP
IP
IP
Netzwerk
Ethernet
FDDI
...
Token Ring
Bild 2-10: Alternative Darstellung des Protokollgraphen
Bild 2-9:
Internet Protokollgraph
o
Die Network Schicht kümmert sich um das Routing und Forwarding von Paketen in
paketvermittelten Netzen.
o
Der Transport Layer implementiert Kanäle zwischen Prozessen, die Nachrichten austauschen.
Diese Schicht kontrolliert, dass die Pakete vollständig und in korrekter Reihenfolge übertragen
werden.
o
Session soll die verschiedenen Datenströme einer Applikation organisieren. Diese Schicht
koordiniert die Kommunikation und den dazu nötigen Verbindungsaufbau und die
Terminierung.
o
Presentation ist dafür zuständig, Datenformate von eingehenden und ausgehenden Daten zu
konvertieren. Dies kann z. B. die Darstellung eines Textes in Form eines Dialogfensters sein.
Diese Schicht ist meist im Betriebssystem implementiert.
o
In der Application Schicht werden die Kommunikationspartner identifiziert sowie
applikationsspezifische Parameter verhandelt. In dieser Schicht ist etwa das FTP Protokoll
zum Dateiaustausch angesiedelt.
Internet Architektur
Die Internet-Architektur wird auch TCP/IP Architektur [PD96, Sta97] genannt und baut auf
Erfahrungen auf, die im Zuge des ARPANET Projekts des U.S. Verteidigungsministeriums gesammelt
wurden. Die OSI Architektur wiederum kam erst später und wurde von ARPANET und Internet
Architektur mitbeeinflusst. Die Architektur besteht aus vier Schichten, die in Bild 2-9 dargestellt sind:
Die unterste Schicht bilden die Data Link-Protokolle. Sie bestehen meist aus einer Kombination aus
Hardware (Adapter) und Software (Device Driver). Hier finden sich die bekannten Ethernet und FDDI
Protokolle.
Das Internet Protocol (IP) steht auf der zweiten Ebene, der Network-Schicht. Es ermöglicht den
Zusammenschluss unterschiedlicher Netzwerktechnologien in ein einziges logisches Netzwerk. Neben
dem IP Protokoll finden sich auf dieser Ebene noch ICMP (Internet Control Message Protocol) und
ARP (Address Resolution Protocol). IP stellt jedoch ein zentrales Element im Protokoll-Stack dar.
Die Transport-Schicht enthält zwei wesentliche Protokolle: das Transmission Control Protocol (TCP)
und das User Datagram Protocol (UDP). Sie stellen zwei alternative logische Kanäle bereit. TCP
bietet einen verlässlichen Byte-Stream Kanal und UDP einen unverlässlichen Datagram- (entspricht
einer Message) Kanal. TCP und UDP werden Transport-Protokolle sowie auch End-zu-End-Protokolle
11
Computer Netzwerke
Sichere Multimediakonferenzen
Carrier Sense
Multiple Access
Collision Detection
Bild 2-11:
CSMA/CD Verfahren
genannt. Eine Eigenschaft des Internet Protokollstack ist, dass das Schichtenmodell nicht allzu streng
verstanden werden will. Applikationen können direkt IP verwenden, also ohne TCP und UDP.
Über der Transport-Schicht laufen Applikationsprotokolle, wie etwa FTP, SMTP (Simple Mail
Transfer Protocol) oder HTTP (HyperText Transport Protocol). Sie sind nicht zu verwechseln mit
Applikationen an sich. Applikationsprotokolle ermöglichen z. B. verschiedenen Email-Applikationen,
miteinander zu kommunizieren, indem sich alle an das standardisierte Applikationsprotokoll SMTP
halten.
Eine bemerkenswerte Tatsache soll noch angebracht werden. Innerhalb der IETF gibt es die Kultur,
nur bereits lauffähige Protokolle als Standard zuzulassen. Damit will man sicher gehen, dass nur
effizient implementierbare Protokolle eingesetzt werden. Eine gute Charakterisierung der Arbeit der
IETF stellt folgende Aussage dar:
„We reject kings, presidents, and voting. We believe in rough consensus and running code“
(Dave Clark).
2.2. Direct Link Netzwerke
Das einfachste vorstellbare Netzwerk ist eines, in dem alle Stationen über ein physikalisches Medium
direkt verbunden sind. Mit dem Zusammenschließen mit Hilfe von Kupferleitungen ist es natürlich
nicht getan, es gibt einige Probleme, um die sich jede Netzwerktechnologie kümmern muss, egal ob es
sich um Point-to-Point Links, Carrier Sense Multiple Access Netzwerke oder Token Rings handelt
[Sta97, PD96]:
Kodierung: Bits müssen auf dem gemeinsamen Medium so übermittelt werden, dass sie der
Empfänger verstehen kann. Dazu wird die logische 1 in ein High-, die 0 in ein Low-Signal
verwandelt. Es entsteht die Problematik, dass die Clocks von Sender und Empfänger
miteinander ständig synchronisiert sein müssen, damit die Daten korrekt dekodiert werden
können. Dafür gibt es einige Kodierungs-Strategien wie z. B. NRZ (Non Return To Zero) und
Manchester encoding .
12
Sichere Multimediakonferenzen
Computer Netzwerke
64
48
48
16
Präambel
Dest addr
Src addr
Type
32
Body
8
CRC Postambel
Bild 2-12: Ethernet Frame Format
Framing: Die Interpretation der Bit-Sequenzen als zusammengehörende Nachrichtenblöcke.
Netzwerkadapter leisten diese Aufgabe, d. h. die Hosts senden und erhalten Frames.
Fehlererkennung: Frames können während der Übertragung unbeabsichtigt modifiziert
werden. Solche Fehler müssen erkannt und entsprechende Maßnahmen eingeleitet werden.
Dazu wird redundante Information in den Frames mit übertragen, wie etwa mit Hilfe von CRC
(Cyclic Redundancy Check) oder Checksummen.
Medienzugriffskontrolle: Weil alle Hosts denselben Leiter teilen, muss der Zugriff darauf in
einer fairen Weise gestaltet werden.
In weiterer Folge soll beispielhaft die Technologie des Ethernet vorgestellt werden, wo ein
gemeinsamer Bus zur Datenübertragung verwendet wird. Andere Technologien verwenden z. B. eine
ringförmige Struktur der Datenleitungen wie etwa Token Ring und FDDI, auf die nicht näher
eingegangen wird.
2.2.1.
Ethernet (CSMA/CD)
Ethernet [Bor96] ist eine erfolgreiche Netzwerktechnologie und ein Beispiel für Carrier Sense
Multiple Access/Collision Detection (CSMA/CD). Das klassische Ethernet unterstützt eine
Übertragungsrate von 10 MBit/s. Wie in Bild 2-11 zu sehen, senden und empfangen mehrere Stationen
Frames über einen gemeinsamen Bus (Multiple Access). Alle Knoten haben die Fähigkeit zu
unterscheiden, ob der Bus im Augenblick von einem anderen Teilnehmer benutzt wird oder nicht
(Carrier Sense). Weiters kann jeder Knoten zugleich Bits auf den Bus plazieren und den Bus abhören,
ob ein Frame eines anderen Knotens mit dem eigenen kollidiert (Collision Detection). Diese Situation
kann entstehen, wenn beide Knoten quasi gleichzeitig mit dem Senden beginnen.
Physikalische Eigenschaften
Ein Ethernet Bus besteht aus einem Koaxial-, Twisted Pair- oder Glasfaserkabel und ist in der Länge
beschränkt. Hosts, die sich einklinken, tun das mit Hilfe eines Transceivers, der für Übertragen und
Abhören zuständig ist und der wiederum mit dem Ethernet Adapter verbunden ist. Der Adapter
implementiert die gesamte Logik und ist selbst an den Host angeschlossen. Bis zu fünf EthernetBussegmente können per Repeater in Serie geschaltet werden. Alle Signale, die ein Host aussendet,
werden durch das gesamte Netz geschickt. An den Enden werden die Signale absorbiert, so dass sie
nicht reflektiert werden und andere Signale überlagern. Ethernet benutzt das Manchester Verfahren zur
Bitkodierung.
13
Computer Netzwerke
Sichere Multimediakonferenzen
Bild 2-13: Durch Switch entsteht Stern-Topologie
Frame Format
Das Format eines Ethernet-Frames ist in Bild 2-12 dargestellt. Er beginnt mit einer 64 Bit-Präambel
aus alternierenden Nullen und Einsen. Diese dient dazu, den Empfänger zu synchronisieren. Source
und Destination Host werden durch 48 Bit-Adressen identifiziert. Das Packet Type Feld dient als
Demultiplexing Schlüssel, der das übergeordnete Protokoll definiert. Ein Frame kann maximal
1500 Byte Daten enthalten, jedoch mindestens 46 Byte, um Kollisionen feststellen zu können. 32 Bit
Checksumme und Postambel bezeichnen das Ende des Frames.
Adressen
Die Adresse ist fest ins ROM des Adapters eingebrannt. Sie ist weltweit eindeutig und die 6 Bytes
werden meist in folgender Form, mit Doppelpunkten getrennt und ohne führende Nullen, dargestellt:
z. B. 8:0:2b:e4:b1:2. Um die Eindeutigkeit zu erreichen, erhält jeder Hersteller einen Präfix, z. B.
0x08002 für AMD.
Jedes Frame, das durch das Ethernet läuft, wird von jedem Adapter empfangen. Der leitet es jedoch
nur dann weiter an den Host, wenn
−= es die eigene Adresse wiedererkennt,
−= es sich um eine Broadcast-Adresse handelt,
−= es sich um eine Multicast-Adresse handelt und der Adapter vom Host angewiesen wurde, auf diese
Adresse zu hören,
−= der Adapter in den promiscous mode gesetzt wurde, d. h. alle Pakete akzeptiert werden sollen.
Sende-Algorithmus
Frames werden von jedem Adapter sofort gesendet, wenn der Bus nicht bereits verwendet wird
[PD96]. Zwischen zwei Frames muss allerdings 9,6 µs gewartet werden, um den Bus nicht zu
blockieren. Sollten zwei oder mehr Adapter zugleich beginnen, Daten zu senden, kommt es zur
Kollision, die die Adapter jedoch bemerken. Die Transceiver senden eine Störsequenz und brechen
den Sendevorgang ab. Um sicher zu gehen, dass keine Kollision zwischen dem eigenen und anderen
14
Sichere Multimediakonferenzen
Computer Netzwerke
Input
Port
Incoming
Identifier
Output
Port
Outgoing
Identifier
2
1
2
4
2
4
0
3
2
5
1
11
2
6
0
4
Tabelle 2-1: Switch-Tabelle für Virtuelle Verbindung
Ziel
Switch Port
A
3
B
0
C
2
D
3
E
1
Tabelle 2-2: Switch-Tabelle für Datagrammdienst
Frames passiert, müssen mindestens 512 Bits gesendet werden – 14 Byte Header, 46 Byte Daten und
4 Byte CRC ergibt 64 Byte oder 512 Bit. Und zwar deshalb, da das Verzögerung × Bandbreite Produkt
für ein Ethernet maximaler Ausdehnung von z. B. 2500 m 512 Bit ergibt (Delay 51,2 µs, Bandbreite
10 MBit/s). Nach einer Kollision wartet der Adapter entweder 0 oder 51,2 µs, je nach Ergebnis eines
Zufallsgenerators. Bei neuerlicher Kollision kommt eine dritte Option dazu, und in jeder weiteren
Runde eine neue, nämlich die doppelte Zeit. Nach 16 Versuchen wird ein Sendefehler zum Host
gemeldet.
2.3. Packet Switching
Die Netzwerke, die mit Ethernet und Token Ring Technologie gebildet werden können, sind in ihrer
geographischen Ausdehnung sowie in der Anzahl der angeschlossenen Stationen eingeschränkt. Um
globalere Netzwerke zu bauen, können Netzwerkelemente eingesetzt werden. Mit ihrer Hilfe können
Hosts miteinander kommunizieren, die nicht direkt verbunden sind, d. h. die nicht das gleiche
physikalische Ausbreitungsmedium (das selbe Kabel) teilen. In Bild 2-13 ist ein Switch dargestellt,
der mehrere Hosts verbindet und dabei eine Stern-Topologie erzeugt. Trotzdem sind die über Switches
verbundenen Stationen noch immer Teilnehmer des selben Netzwerks. Im Unterschied zum
Telefonnetz, das eine Leitung zwischen Anrufer und Angerufenem vermittelt (circuit switching),
werden hier die einzelnen Datenpakete vermittelt, die auf dem Weg von Sender zu Empfänger
Switches durchlaufen und von diesen weitergeschickt werden (packet switching, Paketvermittlung)
[Tan92].
Packet Switches [PD96] bestehen aus mehreren Inputs und Outputs, die mit Hosts und eventuell
anderen Switches verbunden sind. Die Hauptaufgabe ist das Forwarding, das Empfangen von Paketen
am Input und die Weiterleitung zum richtigen Output. Um feststellen zu können, welcher Output
gewählt werden soll, benötigt der Switch einiges Wissen über die Topologie des Netzwerks. Der
Prozess der Akkumulierung dieses Wissens in einem Switch ist eine einfache Form des Routing. Die
dritte Herausforderung für einen Switch hat mit dem Buffer der Pakete zu tun. Wenn mehr Pakete an
den Inputs ankommen, als an die Outputs – die auch nur eine begrenzte Bandbreite haben – abgegeben
werden können, entsteht ein Stau am Eingang. Die Eigenschaft, dass alle einkommenden Pakete um
die Gunst des Switches streiten, heißt Contention. Ein damit verwandtes Phänomen ist das von
Congestion; das ist das Verwerfen von einkommenden Paketen, weil die Buffer der Switches nicht
mehr ausreichen, um die Daten aufzunehmen.
15
Computer Netzwerke
2.3.1.
Sichere Multimediakonferenzen
Forwarding
Die Verwendung eines Switches erzeugt eine Stern-Topologie (siehe Bild 2-13), deren Ausläufer aus
Punkt-zu-Punkt Verbindungen, Bus- oder Ring-Strukturen gebildet werden. Einzelne Switches haben
zwar selbst nur eine begrenzte Anzahl an Input und Output Ports, aber durch das Verbinden mehrerer
Switches können sehr große Netzwerke entstehen. Diese Netzwerke haben eine gute Skalierbarkeit, da
sich das Hinzufügen neuer Hosts an einen Switch nicht unbedingt negativ auf die Gesamtperformance
des Netzwerks auswirkt. Das ist ein Unterschied zu den direkt verbundenen Netzwerken, wo niemals
zwei Hosts gleichzeitig senden können.
Das Forwarding [PD96] zwischen Input und Output Link ist laut OSI-Architektur Aufgabe des
Network-Layer. Der Switch muss dabei jeweils das an diesem Link verwendete Data Link Protokoll
unterstützen, z. B. jenes für E1 (2,048 MBit/s), E3 (34,368 MBit/s) oder STM-1 (Glasfaser mit
155,52 MBit/s). Die amerikanischen Äquivalente sind T1, T3 sowie STS-1, die jedoch
unterschiedliche Bandbreiten unterstützen. Die Ein- und Ausgänge eines Switches werden als Ports
bezeichnet.
Die Tätigkeit des Forwardens arbeitet allgemein mit Hilfe von Informationen im Header des Packets,
die der Switch als Grundlage für die Entscheidung nimmt, welcher Output Port gewählt werden soll.
Wie diese Informationen aussehen, hängt von der verwendeten Methode ab. Die zwei gängigen
Ansätze sind der verbindungslose Datagramm-Ansatz und der verbindungsorientierte Ansatz des
Virtual Circuit (Virtuelle Verbindung).
Virtuelle Verbindung
Diese besonders für WAN-Verbindungen häufig eingesetzte Technik benötigt zuerst das
Zustandekommen einer virtuellen Verbindung zwischen Source und Destination. Mit dem Transport
der Connection Request Nachricht werden in allen Switches sogenannte Virtual Circuit Identifier
(VCI) generiert, die später Pakete mit dem Sender assoziieren werden und – mit Hilfe des Wissens der
Netzwerktopologie – den Output Port determinieren. Die Tabelle eines Beispiel-Switches in Tabelle 21 zeigt, dass aus der Kombination <Input Port, Incoming VCI> der Output Port und der VCI, der
zwischen diesem Switch und dem folgenden Knoten ausgehandelt wurde, ermittelt wird. Jeder VCI
gilt nur zwischen zwei Knoten und muss zwischen diesen beiden Knoten eindeutig sein.
Datagramme
Ohne zuerst eine Verbindung zum Empfänger herzustellen, werden die Datenpakete (Datagramme)
losgeschickt. Jedes einzelne Paket hat genug Informationen in seinem Header, um das Ziel erreichen
zu können; dabei handelt es sich um die gesamte Zieladresse – im Gegensatz zur kurzen VCI der
virtuellen Verbindung. Ein Switch, der ein Paket empfängt, konsultiert die sogenannte Forwarding
Tabelle (auch Routing Tabelle genannt), die das Mapping zwischen Empfängeradresse und Output
Port enthält (Tabelle 2-2). Das Forwarding ist also ein simples Table-Lookup. Das eigentliche
Problem ist (so wie im Fall der virtuellen Verbindung für das Connection Request Packet) das
Beschaffen der Tabelleninhalte, also das Routing.
16
Sichere Multimediakonferenzen
B
1
Computer Netzwerke
1
C
A
1
D
E
1
1
1
Kosten
NextHop
A
1
A
C
1
C
D
2
C
E
2
A
F
2
A
G
3
A
1
1
F
Ziel
G
Tabelle 2-3: Routing-Tabelle für Knoten B
Bild 2-14: Netzwerk dargestellt als Graph
2.3.2.
Routing
Damit Forwarding überhaupt erst möglich ist, müssen Router wie auch Switches eine gewisse
Kenntnis über das Netzwerk besitzen, das sie mit Hilfe von verteilten Routing-Protokollen erhalten.
Routing [PD96, Bor96] ist ein graphentheoretisches Problem. Dabei sind die Switches die Knoten und
die Links die Kanten, denen Kosten zugeordnet werden. Router speichern ihre Informationen in
sogenannten Routing-Tabellen. In Bild 2-14 ist ein Beispiel-Netzwerk dargestellt, dessen Kanten alle
gleich hohe Kosten haben und Tabelle 2-3 zeigt die Routing-Tabelle eines Knotens. Das Problem des
Routing ist es, den kostengünstigsten Weg zwischen zwei Knoten des Netzwerks zu berechnen. Für
einfache Netzwerke kann das statisch berechnet werden. Die Nachteile sind dabei jedoch, dass es nicht
möglich ist, auf Link- oder Knotenausfälle zu reagieren und sich an neue Knoten oder geänderte
Kosten zu adaptieren. Deshalb erfolgt das Routing in der Regel dynamisch. Um gute Skalierbarkeit zu
erreichen, erfolgt es außerdem in einem über alle Router verteilten Verfahren. Es gibt zwei
wesentliche Klassen von Routing-Protokollen: Distance Vector und Link State Vector.
Beim Distance Vector Routing-Protokoll informiert jeder Router seine Nachbarn über seine eigene
Routing-Tabelle. Wenn ein Router solche Informationen erhält, vergleicht er sie mit seiner eigenen
Tabelle. Er erneuert die Einträge, wenn sich zu anderen Knoten geringere Kosten ergeben als bisher
bekannt und informiert wiederum seine Nachbarn darüber.
Wenn das Link State Routing-Protokoll verwendet wird, macht sich jeder Router ein Bild des
gesamten Netzwerks. Wenn ein Link ausfällt oder wieder aktiv wird, wird eine Nachricht, das
sogenannte Link State Advertisement, über das ganze Netzwerk gesendet. Damit können alle Router
ihre Tabellen neu berechnen. Im Unterschied zu Distance Vector ist die ganze Route zum Empfänger
bekannt.
17
Computer Netzwerke
Sichere Multimediakonferenzen
Netzwerk 1 (Ethernet)
H1
H2
H3
H7
R3
H8
Netzwerk 2 (Ethernet)
R1
R2
Netzwerk 4
(point to point)
H4
Netzwerk 3 (Token Ring)
H5
H6
Bild 2-15: Ein Netzwerk aus physikalischen Netzen („internet“)
2.4. Internetworking
Ein internetwork oder kurz internet entsteht durch das Zusammenschließen einzelner physikalischer
Netzwerke, die unterschiedlicher Art sein können, z. B. Ethernets und Token Rings. Es kommt zu
zwei wichtigen Problemen, die gelöst werden müssen: die Heterogenität der Netzwerktechnologien
und die Skalierbarkeit des internets. Bezüglich Heterogenität geht es darum, ein funktionierendes
Host-zu-Host Service über diesen Mix an Technologien hinweg zu schaffen. Bezüglich Skalierbarkeit
muss eine geeignete Routing-Methode sowie ein Adressmodell gewählt werden.
2.4.1.
Internet Protocol (IP)
Bild 2-15 zeigt ein Beispiel für ein internet, also ein logisches Netzwerk, das sich aus mehreren
physikalischen Netzwerken zusammensetzt [PD96]. Diese Einzelnetzwerke basieren jeweils nur auf
einer Technologie: Ethernet, Token Ring oder Point-to-Point. Die Knoten, die die physikalischen
Netze verknüpfen, sind die sogenannten Router, mitunter auch Gateways genannt. Das Protokoll, das
es ermöglicht, Daten zwischen zwei beliebigen Hosts im internet auszutauschen, ist das Internet
Protocol (IP), auch bekannt nach den Erfindern als Kahn-Cerf Protokoll. IP läuft auf allen Knoten und
macht aus den Einzelnetzen ein logisches internet. TCP und UDP laufen typischerweise in der Ebene
über IP und verwenden dessen Infrastruktur. Das IP Protokoll wird in [Rob96] zusammengefasst.
Service Modell
Das Service, das IP bietet, ist die Host-to-Host Paketzustellung. Dabei wurde im Entwurf versucht, es
so generell wie möglich zu halten, sodass jede beliebige existierende oder erst entstehende
Netzwerktechnologie in der Lage sein soll, IP zu unterstützen. Das IP Service Modell besteht aus zwei
Teilen: Ein Adress-Schema, das alle Hosts eindeutig identifiziert, und ein verbindungsloser
18
Sichere Multimediakonferenzen
0
4
8
Version HLen
16
19
TOS
Ident
TTL
Computer Netzwerke
31
Length
Flags
Protocol
Offset
Checksum
SourceAddr
DestAddr
Options (falls erwünscht)
Pad
Bild 2-16: IPv4 Packet Header
Datagramm-Dienst zur Datenübertragung. Dieses Service Modell wird auch Best Effort genannt, weil
IP alles versucht, um eine erfolgreiche Übertragung zustande zu bringen, aber keine Garantien abgibt.
Datagramm-Dienst
Die Datenübertragung erfolgt ohne explizite Reservierung einer End-zu-End-Verbindung. Als
Übertragungsrahmen dient das Datagramm, das unter anderem mit der Ziel-Adresse versehen wird.
Jedes Datagramm enthält genug Header-Informationen, um durch das Netzwerk gesendet zu werden.
Sollte ein Datagramm verloren gehen, wird vom Netzwerk – in Übereinstimmung mit Best Effort –
keine wiederholte Übertragung des Datagramms veranlasst. Aufgrund dieser Charakteristik des
Datagrammdienstes ist IP ein unzuverlässiges (unreliable) Service. Dies gilt als eine der größten
Stärken von IP, denn diese Flexibilität ermöglicht es IP, auf jeder Technologie zu laufen. Viele der
Technologien existierten nicht, als IP erfunden wurde, und keine Netzwerktechnologie hat sich bisher
als zu bizarr für IP erwiesen. Es wurde sogar behauptet, IP laufe über zwei Blechdosen und ein Stück
Draht.
IP-Header
Das Format des IP-Headers ist in Bild 2-16 zu sehen. Eine detaillierte Beschreibung der Felder ist in
[RFC0791] zu finden. An dieser Stelle sollen einige wesentliche Felder erläutert werden.
Version wird für das derzeitige IP auf den Wert 4 gesetzt. Die nächste Version wird IPv6 bzw. IPng
(IP Next Generation) [Sta97, PD96] sein. Die wichtigste Änderung in IPv6 ist die Erweiterung der
Adressen (SourceAddr, DestAddr) von 32 Bit auf 128 Bit. Damit sollen Engpässe bei der Vergabe
von IP-Adresse vermieden werden. Version 5 wurde für ein experimentelles Protokoll namens ST-II
verwendet.
TOS (Type of Service) sollte Applikationen die Möglichkeit geben, diverse Anforderungen an die
Übertragung zu spezifizieren, z. B. bezüglich Netzwerkverzögerung, Verlässlichkeit der Übertragung
oder Datendurchsatz. Diese Möglichkeiten wurden nie intensiv genutzt, stellen aber einen Weg dar,
um QoS (Quality of Service) zu implementieren.
Das zweite Wort enthält Informationen bezüglich Fragmentierung, die im folgenden Abschnitt
behandelt wird. Das TTL (Time to Live) Feld wird in jedem Router dekrementiert und soll verhindern,
dass Pakete ohne Ende ziellos durchs Internet zirkulieren. Es wird zu Beginn auf einen Wert größer 0,
z. B. 64, gesetzt. Wenn 0 erreicht wird, wird das Datagramm verworfen. Der Wert dieses Feldes sollte
19
Computer Netzwerke
Sichere Multimediakonferenzen
7
(a)
0
24
Network
Host
16
14
(b)
(c)
1 0
Network
1 1 0
Host
21
8
Network
Host
Bild 2-17: IP Adressen: (a) Klasse A; (b) Klasse B; (c) Klasse C
laut Definition in Sekunden gemessen werden. Allerdings muss jeder Router den Wert um
mindestens 1 vermindern, sodass meist die Anzahl der Hops gemessen wird.
Als Demultiplexing Schlüssel für das übergelagerte Protokoll dient Protocol. TCP hat hier
beispielsweise den Wert 6, UDP hat 17. Dieser Wert gibt damit an, welcher Header am Beginn der
Payload des IP-Datagramms steht.
Fragmentierung
Da jedes physikalische Netzwerk seine eigene Maximalgröße für Datenpakete hat (z. B. Ethernet:
1500 Bytes, FDDI: 4500 Bytes), ist unmöglich, eine Größe für IP-Pakete zu finden, die in jedem Paket
eines darunterliegenden Netzwerks Platz findet, ohne unnötig Ressourcen zu verschwenden. Die
Alternative ist ein Mechanismus zur Fragmentierung und Wiederherstellung von IP-Paketen, falls sie
zu groß sind.
Fragmentierte Datagramme können mit Hilfe des Ident Feldes identifiziert und wiederhergestellt
werden. Jedes Fragment ist selbst ein vollständiges Datagramm, das erst am Empfänger wieder mit
den übrigen Fragmenten vereinigt wird. Der Fragmentierungsprozess kann beliebig wiederholt
werden, sollte ein Fragment auf ein Netzwerk mit kleinerer Paketgröße stoßen. Die Fragmente können
in jedem Fall sofort zum ursprünglichen Datagramm wiederhergestellt werden. Der Wert des IdentFeldes ist derselbe für alle Fragmente eines Datagramms und sollte am Empfänger eindeutig sein,
damit die Fragmente zugeordnet werden können. Die Position des Fragments im ursprünglichen
Datagramm ist durch den Wert des Offset gegeben.
Globale Adressen
Adressen müssen im gesamten Internet eindeutig sein, damit jeder mit jedem Host in jedem
physikalischen Netzwerk kommunizieren kann. IP Adressen haben aber noch eine weitere
Eigenschaft. Sie sind hierarchisch, im Unterschied zu den flachen (strukturlosen) Ethernet Adressen.
IP Adressen setzen sich aus einem Netzwerkteil und einem Hostteil, der einen bestimmten Host in
diesem Netzwerk bezeichnet, zusammen.
IP Adressen werden in drei Klassen (A, B und C) unterteilt, die in Bild 2-17 dargestellt sind.
Zusätzlich gibt es eine Klasse D für Multicast-Adressen. Sie haben eine Länge von 32 Bit. Adressen
der Klasse A haben als erstes Bis eine 0. Wie man in der Abbildung sieht, sind von den circa vier
Milliarden Adressen Hälfte aus der Klasse A, ein Viertel gehören zur Klasse B und ein Achtel zur
20
Sichere Multimediakonferenzen
Computer Netzwerke
Klasse C. Der Netzwerkteil von Klasse A Adressen besteht aus nur 7 Bits, d. h. es gibt lediglich 128
Klasse A Netzwerke, dagegen gibt es 221 ≈ zwei Millionen Klasse C Netze.
Das Schema ist flexibel genug, Netzwerke von sehr unterschiedlicher Größenordnung zu organisieren.
Es unterstützt wenige sehr große Netze (WANs) und sehr viel kleine Netze (LANs). IP Adressen
werden üblicherweise mit vier durch Punkte getrennte Dezimalwerte niedergeschrieben, z. B.
129.27.142.140.
Datagram Forwarding
Forwarding ist der Prozess des Empfangens und Weiterleitens eines Paketes am korrekten Output Port.
Datagramme, die von Sender zu Empfänger unterwegs sind, können mehrere Router passieren. Jeder
Knoten, ob Router oder Host, versucht zuerst festzustellen, ob die Zieladresse im selben Netzwerk
liegt. Dazu vergleicht der Knoten den Netzwerkteil der Zieladresse mit den Netzwerkteilen seiner
Interfaces. Bei Übereinstimmung liegt das Ziel am selben physikalischen Netzwerk und das Paket
wird direkt unter Benutzung der Übertragungsmechanismen dieses Netzwerks übermittelt.
Im anderen Fall muss das Datagramm zum nächsten Router geschickt werden. Im allgemeinen hat
jeder Knoten die Wahl zwischen mehreren Routern. Um den optimalen Router zu ermitteln, sieht der
Knoten in der Forwarding Tabelle nach. Sollte das Ziel dort nicht aufscheinen, gibt es einen Default
Router, an den das Datagramm gesendet werden kann.
Adress-Auflösung (ARP)
Hat das Datagramm das Netzwerk erreicht, in dem sich der Empfänger befindet, muss es noch zum
entsprechenden Empfänger-Host transportiert werden. Dazu ist eine Übersetzung der IP Adresse des
Empfängers in das Adressschema des jeweiligen Netzwerks nötig, also z. B. eine Übersetzung von IP
in Ethernet Adressen. Dabei ist zu bemerken, dass diese beiden Adressen keine Beziehung zueinander
haben und also nicht direkt voneinander ableitbar sind; es muss also eine Tabelle vorhanden sein,
deren Inhalt eine Zuordnung ermöglicht und dynamisch generiert werden sollte, damit auf
Änderungen der Netzwerktopologie automatisch reagiert werden kann. Das ist die Aufgabe des
Address Resolution Protocol (ARP). Es macht sich die Tatsache zunutze, dass die meisten LANTechnologien wie Ethernet und FDDI Broadcast unterstützen.
Wenn ein Host ein IP Datagramm an einen Host des eigenen Netzwerks schickt, konsultiert er die
ARP Tabelle. Ist kein Eintrag vorhanden, schickt er eine Broadcast-Anfrage an das Netzwerk mit der
gesuchten IP Adresse sowie der eigenen IP- und Link Layer Adresse. Der Host, der die gesuchte IPAdresse erkennt, antwortet mit seiner Link Layer Adresse, und der Sender fügt das Mapping in seine
ARP Tabelle ein bzw. erneuert den Eintrag. Eine Erneuerung bedeutet das Rücksetzen des Timeouts.
Da auch des Senders IP- und Link Level Adresse in der Broadcast-Anfrage vorhanden sind, können
die Hosts, die das Broadcast empfangen, ihren entsprechenden Tabelleneintrag setzen. Weitere
Informationen zu ARP sind unter [Rob96] und [PD96] zu finden.
Fehlerbenachrichtigung (ICMP)
Obwohl IP jederzeit zulässt, dass Pakete verworfen werden, geschieht dies nicht ohne Fehlermeldung.
IP wird zusammen mit seinem Pendant ICMP (Internet Control Message Protocol) [Rob96, Sta97]
eingesetzt. ICMP definiert eine Anzahl an Fehlermeldungen, die zum Source Host zurück geschickt
werden, wenn es Probleme in einem Host oder Router gibt. Es existieren etwa Meldungen, dass ein
21
Computer Netzwerke
at
se
co
cc
Sichere Multimediakonferenzen
edu
com
ac
gov
nasa
mil
org
net
nsf
tu-graz kfunigraz
iaik
iicm
Bild 2-18: Beispiel einer DNS Hierarchie
Host nicht erreichbar ist, dass die Wiederherstellung fragmentierter Pakete nicht gelingt, dass TTL den
Wert 0 erreicht hat, dass die IP Checksumme nicht stimmt, etc.
Außerdem definiert ICMP einige Kontrollnachrichten, mit denen ein Router den Sender informieren
kann. Eine davon ist ICMP-Redirect, das den Sender instruiert, einen anderen Router zu verwenden,
um zum gegebenen Empfänger zu gelangen, da dieser Weg kürzer bzw. kostengünstiger ist.
2.4.2.
Host Namen (DNS)
Dasselbe Problem, das ein Internet lösen muss, nämlich jenes der Skalierbarkeit, muss auch ein
Benennungssystem lösen. Namen werden den Hosts in der Regel zusätzlich zu den Adressen
vergeben, da die numerischen Adressen schwer zu merken sind. Namen haben die Eigenschaften, eine
variable Länge zu haben und keinerlei Routing-Informationen für das Netzwerk bereitzuhalten.
Ein Name Server hat die Aufgabe, mit einem Namen konfrontiert die dazu gebundene Adresse zu
liefern. Das Benennungssystem des Internet ist das Domain Name System (DNS) [Rob96, PD96].
Bevor DNS eingeführt wurde, hatte eine zentrale Stelle namens Network Information Center (NIC) die
Verantwortung, eine Datei namens hosts.txt zu verwalten, und sie regelmäßig an sämtliche
Systemadminstratoren zu verteilen, die sie dann wiederum auf ihren Rechnern updaten mussten. Seit
Mitte der 80er Jahre ist das DNS in Verwendung, das eine hierarchische Struktur hat (siehe Bild 2-18).
Die gesamte Tabelle der <Name, Adresse> Bindungen ist in einer Anzahl an kleineren Tabellen über
das Internet verteilt, und zwar in den Name Servern.
Die DNS Hierarchie kann als Baum dargestellt. Das Wort „Domäne“ hat dabei nicht mehr Bedeutung
als der Kontext, in dem neue Namen definiert werden können. Es existieren Domänen für jedes Land
sowie die sechs U.S. Domänen edu, com, gov, mil, org und net. Die Hierarchie ist eine reine
Abstraktion und wird in Zonen unterteilt. Jede Zone korrespondiert mit zwei oder mehreren Name
Servern, die die selbe Information redundant speichern, sodass beim Ausfall eines Servers der Betrieb
aufrecht erhalten werden kann. Anfragen an Name Server können auch mit dem Hinweis beantwortet
werden, sich an den Name Server einer anderen Hierarchieebene zu wenden.
22
Sichere Multimediakonferenzen
Computer Netzwerke
SrcPort
DstPort
CheckSum
Length
Data
Bild 2-19: Format des UDP Headers
2.5. Transport-Protokolle
Wenn internets und die darunterliegenden Technologien erst einmal definiert sind, ist die nächste
Aufgabe, Kanäle zwischen Prozessen zu schaffen. Die Protokolle, die die Kommunikation zwischen
Prozessen anbieten, sind die Transport-Protokolle. Die Herausforderung für diese Protokolle besteht
darin, die für Applikationen unerwünschten Eigenschaften wie Paketverluste, Größenbeschränkungen
der Pakete, falsche Ankunftsreihenfolge der Pakete, etc. zu vermeiden und stattdessen Services
anzubieten, die von Anwendungen benötigt werden [PD96]:
o
garantierte Übertragung
o
korrekte Reihenfolge der Pakete am Empfänger
o
nicht mehr als eine Kopie pro Paket
o
beliebig große Nachrichten
o
Flusskontrolle
o
Unterstützung mehrerer Applikationsprozesse pro Host
UDP und TCP sind zwei solche Transport-Protokolle im Internet. Während UDP ein einfaches
Demultiplexing-Service anbietet, steht TCP für ein zuverlässiges Byte-Stream Service. Applikationen
haben über Application Programming Interfaces (APIs) Zugang zu den Diensten der TransportProtokolle.
2.5.1.
Demultiplexing: UDP
Das User Datagram Protocol (UDP) [Rob96, PD96] implementiert die einfachste Möglichkeit, das
Host-zu-Host Service zu einem Prozess-zu-Prozess Service zu erweitern. Die einzige Anforderung
dafür ist, ein Demultiplexing einzuführen, damit mehrere Prozesse am selben Host die
Netzwerkdienste in Anspruch nehmen können. Zu diesem Zweck muss eine eindeutige Identifizierung
der Ziel-Prozesse gegeben sein. Dies geschieht indirekt, indem ein abstrakter Identifikator, ein
sogenannter Port eingesetzt wird. Source Hosts senden Daten an einen Port, und Destination Hosts
erwarten Daten auf einem Port.
Diese Demultiplexing Funktionalität wird mit Hilfe des UDP Headers implementiert, der in Bild 2-19
zu sehen ist. Die 16 Bit ergeben mehr als 65000 verschiedene Ports pro Host. Das ist genug, um einen
Prozess auf einem Host zu identifizieren. Der Demultiplexing Schlüssel für UDP entspricht also dem
<Host, Port> Tupel.
23
Computer Netzwerke
Sichere Multimediakonferenzen
Bevor der erste Kontakt zwischen einem Client und einem Server stattgefunden hat, konnten natürlich
noch keine Ports vereinbart werden. Deswegen bietet der Server den Zugang über einen well-known
Port an, also ein Port, den der Client kennt. Ein well-known Port ist vergleichbar mit einer
Notrufnummer, die allgemein bekannt ist. DNS Server sind etwa auf Port 53 erreichbar, HTTP Server
meist unter Port 80.
2.5.2.
Byte-Stream: TCP
Das Transmission Control Protocol (TCP) ist ein Protokoll, das ein verbindungsorientiertes,
verlässliches Byte-Stream Service anbietet. Byte-Stream bedeutet, dass Daten nicht als unteilbare
Messages betrachtet werden, sondern Byte für Byte übertragen werden, und damit einen Datenstrom
aus vielen kleinen Elementen darstellen. Dabei können beide Seiten senden und empfangen, TCP
Verbindungen sind also full-duplex. Neben einer zuverlässigen, geordneten Übertragung führt es
selbständig Flusskontrolle und Congestion-Kontrolle aus. Congestion bezieht sich auf den
Netzwerkzustand, während Flusskontrolle bedeutet, dass des Empfängers Buffer nicht überlastet
werden sollen. Das TCP Protokoll wird in [Rob96] und [Sta97] zusammengefasst bzw. erläutert.
Allgemeine Betrachtungen
Das Herzstück von TCP bildet der sogenannte Sliding Window Algorithmus, der in weiterer Folge
erklärt wird. Es soll noch auf einige konzeptuelle Merkmale des Protokolls eingegangen werden.
Zwischen den beiden Hosts muss ein expliziter Verbindungsaufbau dafür sorgen, dass sich die beiden
Prozesse auf einen gegenseitigen Datenaustausch einigen. Dabei werden Statusinformationen
ausgetauscht, um den Sliding Window Algorithmus beginnen zu können.
Zweitens muss beachtet werden, dass die RTT zwischen zwei beliebigen Hosts im Internet sehr
variabel ist. Das bedeutet, dass der Timeout-Mechanismus für Retransmissions adaptiv sein soll, d. h.
der Zeitpunkt, wann Daten wiederholt gesendet werden, hängt start vom Netzwerk zwischen den
beiden Peers ab.
Drittens können manche Pakete außergewöhnlich lange durch das Netzwerk benötigen, also muss der
Empfänger darauf vorbereitet sein, dass Pakete in falscher Reihenfolge eintreffen.
Viertens können die Hosts über sehr unterschiedliche Ressourcen verfügen, d. h. nicht jede TCPVerbindung kann mit derselben Buffergröße rechnen. Stattdessen sollen sich die beiden Peers
gegenseitig informieren, wie groß ihre Ressource jeweils zum gegenwärtigen Zeitpunkt sind.
Und fünftens hat ein Sender keine Kenntnis darüber, welchen Weg die Pakete durchs Netzwerk
nehmen werden und welche Kapazitäten die Links zwischen Sender und Empfänger haben. Daher ist
eine Vermeidung von Congestion wünschenswert.
Segmente
Obwohl TCP Byte-orientiert ist und somit von der Applikation Byte für Byte entgegennimmt,
überträgt TCP nicht jedes Byte einzeln, sondern sammelt eine relevante Anzahl an Bytes von der
Applikation und sendet diese in einem IP Paket zusammen mit dem TCP Header. Die Pakete, die
24
Sichere Multimediakonferenzen
0
4
10
Computer Netzwerke
16
31
DstPort
SrcPort
SequenceNum
Acknowledgement
HdrLen
AdvertisedWindow
0
UrgPtr
CheckSum
Options (falls erwünscht)
Data
Bild 2-20: Format des TCP Headers
zwischen den Peers ausgetauscht werden, nennt man Segmente, da sie jeweils einen Ausschnitt des
Byte-Stromes beinhalten.
TCP Header
Der TCP-Header ist in Bild 2-20 dargestellt. So wie bei UDP finden sich ebenfalls Ports für Sender
und Empfänger im Header. SequenceNum, Acknowledgment und AdvertisedWindow sind Teil
des Sliding Window Algorithmus. Die sechs möglichen Flags sind:
-
SYN, FIN: für Verbindungsaufbau bzw. –abbau,
-
ACK:
True, falls das Acknowledgment-Feld gültig ist,
-
URG:
True, falls das Segment Urgent- (Out of Band-) Daten beinhaltet,
-
PUSH:
die Push Operation wird ausgeführt,
-
RESET:
Der Receiver wünscht einen Abbruch der Verbindung
Die Checksum wird über den TCP Header, die TCP Daten und einen Pseudoheader über einige
Felder des IP-Headers berechnet. HdrLen gibt die Länge des Headers in 32-Bit-Worten an und legt
damit fest, ob Optionen definiert sind.
Verbindungsaufbau und Terminierung
Eine TCP Verbindung wird initiiert, indem ein Client ein active open zu einem Server ausführt, d. h.
der Client gibt ein explizites Kommando zum Verbindungsaufbau. Der Server hat zuvor bereits ein
passive open erledigt und wartet auf die Kontaktaufnahme durch Clients. Somit ist der Aufbau eine
asymmetrische Aktivität, denn die beiden Seiten unternehmen unterschiedliche Aktivitäten zur
Herstellung einer Verbindung.
Der Algorithmus zur Verbindungsherstellung heißt Three-Way Handshake und ist in Bild 2-21
skizziert. Ziel ist es, die Sequenznummern auszutauschen, mit denen Sender und Empfänger ihre
Daten durchnummerieren werden:
25
Computer Netzwerke
Client
Sichere Multimediakonferenzen
Server
1 . SYN
, Seque
nceNum
= x
= y,
ceNum
Seq uen
,
K
C
1
A
+
nt = x+
2 . SYN
dgeme
le
w
o
n
Ack
3 . ACK
, Ackno
w ledge
ment =
y+ 1
Bild 2-21: Zeitachse für den Three-Way Handshake
Data (SequenceNum)
Sender
Empfänger
Acknowledgement +
AdvertisedWindow
Bild 2-22: Vereinfachte Darstellung für eine Richtung des TCP Datenaustausches:
Daten fließen in eine Richtung, ACKs in die andere
1. Zuerst gibt der Client seine Sequenznummer bekannt. Diese sendet er in einem SYN-Paket.
2. Die Sequenznummer des Clients beantwortet der Server mit einem Acknowledgment und der
Sequenznummer für seine Daten. In diesem Paket sind sowohl SYN- als auch ACK-Flag
gesetzt.
3. Da in TCP jede Nachricht bestätigt werden muss, schickt der Client schließlich noch ein
Acknowledgment zum Server. Damit sind die Sequenznummern vereinbart.
Es gibt einen Grund dafür, dass Sequenznummern ausgetauscht werden. Es soll nämlich vermieden
werden, immer bei der selben Nummer zu beginnen (z. B. 0), weil nach dem Abbruch einer
Verbindung eine neue Verbindung aufgebaut werden kann, für die dann die gleichen
Sequenznummern verwendet werden könnten. Diese Situation könnte zu Fehlern in der Übertragung
führen.
Sliding Window
Der Sliding Window Algorithmus hat historische Bedeutung und wird heute durch einige Konzepte
ergänzt, die in weiterer Folge diskutiert werden. Zunächst soll der Sliding Window Algorithmus
erklärt werden. Er dient folgenden Funktionen:
26
Sichere Multimediakonferenzen
Computer Netzwerke
Sendeapplikation
Epfängerapplikation
TCP
TCP
LastByteWritten
LastByteAcked
LastByteSent
LastByteRead
NextByteExptected
LastByteRcvd
Bild 2-23: Beziehung zwischen TCP Sende- und Empfangsbuffer
•= der zuverlässigen Übertragung von Daten,
•= der Übertragung in korrekter Reihenfolge und
•= der Flusskontrolle.
Ein wesentliches Merkmal, das der Implementierung der Flusskontrolle entspricht, ist das Ankündigen
einer Fenstergröße des Empfängers gegenüber dem Sender. Dies geschieht mit Hilfe des
AdvertisedWindow-Feldes im TCP Header. Der Sender darf niemals mehr als AdvertisedWindow
Daten im Umlauf haben.
Wie Bild 2-23 zeigt, haben Sender und Empfänger jeweils einen dynamischen Buffer, dessen Größe
durch die Werte einiger Variablen bestimmt wird, die den Zustand der Verbindung repräsentieren. Im
Buffer des Senders befinden sich Daten, die gesendet, aber nicht bestätigt wurden, sowie Daten, die
von der Applikation geschrieben wurden, aber noch nicht gesendet wurden. Der Buffer des Senders
enthält Daten, die in der falschen Reihenfolge angekommen sind sowie Daten, die korrekter
Reihenfolge vorliegen, aber von der Applikation noch nicht gelesen wurden.
Jederzeit gilt im Sender:
LastByteAcked ≤ LastByteSent
da der Empfänger kein Byte bestätigen kann, das noch nicht gesendet wurde, sowie:
LastByteSent ≤ LastByteWritten
da TCP kein Byte senden kann, das die Applikation noch nicht geschrieben hat. Bytes zur Linken von
LastByteAcked wurden bereits bestätigt und müssen nicht mehr im Buffer gespeichert werden.
Rechts von LastByteWritten wurden noch keine Bytes generiert und es wird hier ebenso kein
Bufferplatz benötigt.
Die Ungleichungen am Empfänger lauten:
LastByteRead < NextByteExpected
27
Computer Netzwerke
Sichere Multimediakonferenzen
da die Applikation ein Byte nicht lesen kann, bevor dieses und alle vorangehenden Bytes empfangen
wurden. NextByteExpected zeigt auf das erste Byte, das entsprechend der Reihenfolge als nächstes
erwartet wird, also auf den Beginn der (ersten) Lücke. Weiters gilt:
NextByteExpected ≤ LastByteRcvd + 1
da NextByteExpected auf das Byte nach LastByteRcvd zeigt, falls alle Daten in korrekter
Reihenfolge eintrafen. LastByteRcvd referenziert das Byte mit der höchsten Sequenznummer aller
empfangenen Bytes und markiert somit das Ende des Buffers.
Flusskontrolle
Die Größe des Sliding Window bestimmte historisch die Menge an Daten, die gesendet werden kann,
ohne auf Bestätigungen des Empfängers zu warten. Mit folgendem Konzept drosselt der Empfänger
den Sender, indem er eine Fenstergröße ankündigt, die nicht größer als der freie Buffer des
Empfängers ist:
AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd – LastByteRead)
Um die Forderung des Empfängers einhalten zu können, berechnet der Sender die sogenannte
effektive Fenstergröße. Nur wenn diese größer 0 ist, werden Daten gesendet:
EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked)
Moderne Konzepte modifizieren dieses Verhalten. Diese Quasi-Standards haben sich in vielen
Implementierungen bewährt. Es handelt sich dabei um Slow Start, Congestion Avoidance, Fast
Retransmit und Fast Recovery.
Slow Start
Das Konzept des Slow Start soll verhindern, dass TCP zu Beginn die gesamte Menge an Daten ins
Netzwerk sendet, die vom Receiver mittels AdvertisedWindow erlaubt werden. Dies kann
insbesondere dann zu Problemen führen, wenn die beiden Hosts nicht im selben LAN sind und die
Daten von Routern gebuffert werden müssen. Slow Start verwendet ein weiteres Fenster, das
Congestion Window (cwnd). Beim Aufbau einer neuen Verbindung wird das Congestion Window auf
die Größe eines Segments gesetzt. Bei jedem Empfang eines ACKs wird das Congestion Window um
eine Segmentgröße erhöht. Beim Senden gilt jeweils das Minimum der beiden Fenster (Congestion
und Advertised Window) als Obergrenze der erlaubten Datenmenge.
Wird an einem bestimmten Punkt die Kapazität des Internets erreicht, beginnt ein Router, Pakete zu
verwerfen. Damit wird der Sender in Kenntnis gesetzt, dass Congestion eingetreten ist. In der Praxis
wird Slow Start meist gemeinsam mit Congestion Avoidance implementiert. Dieses Konzept wird als
nächstes beschrieben.
Congestion Avoidance
Congestion Avoidance ist ein Verfahren, um mit verlorenen Paketen aufgrund von Congestion
umzugehen. Der Algorithmus geht davon aus, dass die meisten Pakete nicht durch physische Schäden
des Netzes, sondern durch Congestion verloren gehen. Zusätzlich zum Congestion Window wird noch
eine zweite Variable benötigt, nämlich die Slow Start Threshold Size (ssthresh).
28
Sichere Multimediakonferenzen
Computer Netzwerke
Je nach der Größe des aktuellen Fensters (Minimum aus Congestion Window und Advertised
Window) im Verhältnis zu ssthresh wird die Fesnstergröße bei Empfang eines ACK entweder nach
dem Konzept von Slow Start erhöht oder um folgenden Betrag: segsize*segsize/sshtresh. Dabei ist zu
bemerken, dass es sich im ersten Fall um eine exponentielle Steigerung handelt, im zweiten Fall aber
um eine lineare Steigerung. Solange die aktuelle Fenstergröße kleiner oder gleich sshtresh ist, wird
nach dem Slow-Start Konzept gesendet, sonst nach dem linearen Konzept.
Zu Beginn wird sshtresh auf 65535 gesetzt [RFC2001]. Um auf eine Situation mit Congestion zu
reagieren, wird sshtresh auf die Hälfte der aktuellen Fenstergröße gesetzt. Zusätzlich wird im Fall
eines Timeouts das Congestion Window auf die Größe eines Segments zurückgesetzt. Damit beginnt
die Übertragung wieder im Slow Start Verfahren, bis der nun verminderte sshtresh erreicht wird.
Fast Retransmit
TCP hat die Charakteristik, sogenannte duplicate ACKs zu senden, wenn Pakete in nicht korrekter
Reihenfolge ankommen. Zunächst kann der Sender nicht entscheiden, ob ein Paket verloren wurde
oder zeitlich später ankommt als Pakete mit höherer Sequenznummer. Wenn mehr als drei duplicate
ACKs ankommen, wird ein Paketverlust angenommen und bei Anwendung des Fast Retransmit
Algorithmus macht TCP eine erneute Übertragung dieses Pakets, ohne auf ein Timeout zu warten. Das
Congestion Window wird auf Segmentgröße herabgesetzt.
Fast Recovery
Dies ist eine weitere Verfahren zur Verbesserung der Übertragungseigenschaften von TCP. Es besteht
darin, nach dem erneuten Senden eines verlorenen Pakets durch Fast Retransmit nicht den Slow Start
Algorithmus zu verwenden, sondern Congestion Avoidance. Das bedeutet, das Congestion Window
wird nicht auf eine Segmentgröße zurückgesetzt, sondern auf den Wert von sstresh. Das verbessert den
Throughput bei mäßiger Congestion – besonders für große Fenster.
Der Grund, nicht in den Slow Start zu wechseln, liegt im Empfang von duplicate ACKs, denn diese
können nur dann gesendet werden, wenn der Empfänger andere Segmente erhält. Das bedeutet, dass
noch immer Daten zwischen Sender und Empfänger übertragen werden und der Datenfluss muss nicht
notwendigerweise abrupt stark gebremst werden.
29
Computer Netzwerke
30
Sichere Multimediakonferenzen
Sichere Multimediakonferenzen
Sicherheit in Datennetzen
3. Sicherheit in Datennetzen
In diesem Kapitel werden Sicherheitsaspekte vorgestellt, die sich auf den Schutz von Informationen in
Netzwerken beziehen. Einleitend folgt eine Darstellung von Sicherheitsrisiken sowie von Strategien,
möglichen Attacken entgegenzuwirken. Die meisten Methoden beruhen auf kryptographischen
Algorithmen, die zum besseren Verständnis der später erläuterten Sicherheitskonzepte präsentiert
werden.
3.1. Einleitung
Kryptographie ist die Wissenschaft mathematischer Methoden, die sich mit verschiedenen Aspekten
von Informationssicherheit beschäftigen wie etwa Geheimhaltung, Integrität und Authentizität
[MOV97]. Dazu zählen grundsätzlich alle Verfahren, die Daten transformieren und die schwer
umkehrbar sind. In diesem Zusammenhang spricht man von starker Kryptographie, wenn es praktisch
unmöglich ist, diese Umkehroperation ohne das Wissen über die geeigneten Schritte durchzuführen.
Unmöglich hat hier die Bedeutung, dass auch ein sehr großer Ressourceneinsatz dazu nicht ausreicht.
Für ein relevantes Level an Datensicherheit ist starke Kryptographie das Maß der Dinge.
3.1.1.
Gefahren und Maßnahmen
Mögliche Gefahren für den Datentransport in Netzwerken entstehen durch die gemeinsame Nutzung
der Infrastruktur großer Netze wie das Internet. Ein User, für den die Daten nicht bestimmt sind, kann
seine Attacke anonym durchführen und hat dabei viele verschiedene Möglichkeiten [MAB99, Pfl97]:
Abhören der ausgetauschten Informationen
Manipulation der Informationen
Vortäuschen einer falschen Identität
Verhindern von Informationsaustausch (Denial of Service)
Attacken auf Passwörter und Schlüssel
Zerstörung von Daten (etwa durch einen Virus)
Auf diese Bedrohungen gibt es nicht ein einziges Gegenmittel, das in der Lage ist, sie zu entschärfen.
Dagegen schafft in vielen Fällen die Kombination der folgenden Konzepte das erwartete Maß an
Sicherheit:
31
Sicherheit in Datennetzen
Application
Transport: TCP
Network: IP
Data Link: Interface
Bild 3-1:
Sichere Multimediakonferenzen
- S-MIME
- Kerberos
- Proxies
- SET
- IPSec (ISAKMP)
- SOCKS
- SSL, TLS
- IPSec (AH, ESP)
- Paketfilter
- Tunneling Protokolle
- CHAP, PAP, MS-CHAP
Sicherheitslösungen in den TCP/IP Ebenen
Vertraulichkeit: durch Verschlüsselung werden die Daten für Dritte unzugänglich gemacht.
Authentifizierung und Autorisierung der Kommunikationsteilnehmer identifiziert das jeweilige
Gegenüber.
Integrität bedeutet die Unverfälschtheit der Daten, dass also Übertragungsfehler und Veränderung
durch Dritte erkannt werden.
Verbindlichkeit oder Nichtabstreitbarkeit ist der sichere Nachweis einer Transaktion. Käufer und
Händler können sich etwa gegenseitig Zusagen machen.
Diese Sicherheitskonzepte werden von unterschiedlichen Diensten in unterschiedlichen Ebenen
implementiert, wie in Bild 3-1 dargestellt.
−= Der Internet Layer ist gut geeignet, Sicherheitsdienste im Bereich Host-zu-Host zu unterstützen.
Aus den aufgezählten Konzepten soll S/Mime (Secure Multi-Purpose Internet Mail Extensions)
hervorgehoben werden. Es erweitert den MIME Standard [RFC1521], der den Austausch
beliebiger Daten per Email definiert, um Sicherheitsinstrumente. Die Daten können verschlüsselt
bzw. signiert werden. S/Mime verwendet den RSA Algorithmus, der in Kapitel 3.2.2 erläutert
wird. RSA Security hat S/Mime als IETF-Standard vorgeschlagen.
−= Der Transport Layer ist geeignet für Sicherheit auf Prozess-zu-Prozess Basis. Sowohl SOCKS als
auch SSL/TLS werden später in diesem Kapitel behandelt.
−= Der Application Layer ist gut geeignet, um Sicherheitsvorkehrungen für individuelle Dokumente,
die übertragen werden, zu treffen.
−= Die Data Link-Ebene und einige zugehörige Beispiele sind in Bild 3-1 aus Gründen der
Vollständigkeit ebenfalls eingezeichnet. Diese sollen aber nicht näher erläutert werden.
3.2. Kryptographische Grundlagen
Im folgenden sollen die wesentlichen Konzepte zur Kryptographie vorgestellt werden. Die Ansätze
können in symmetrische und asymmetrische Algorithmen unterteilt werden. Zunächst sollen die
möglichen Operationsmodi für symmetrische Algorithmen vorgestellt werden. Daran schließt die
Beschreibung des DES-Standards für symmetrische Verschlüsselung an.
32
Sichere Multimediakonferenzen
Secret
Key
Verschlüsselung
Bild 3-2:
Sicherheit in Datennetzen
Secret
Key
Entschlüsselung
Symmetrischer (Private Key) Algorithmus
Unsymmetrische Verschlüsselung ging aus den Arbeiten von Diffie und Hellman hervor. RSA zählt zu
den wichtigsten Algorithmen in diesem Bereich. Mit Hilfe von unsymmetrischer Verschlüsselung
können Signaturen und Zertifikate erzeugt werden, die ebenfalls dargestellt werden. [Sch96] ist eine
umfassende Referenz zu Sicherheitsaspekten. [MOV97] ist theoretisch orientiert. Eine leicht
verständliche, allgemeine Einführung bieten [Beu96] und [Wob98].
3.2.1.
Symmetrische Verschlüsselung
Bei der symmetrischen oder Private Key-Verschlüsselung wird derselbe Schlüssel zum Ver- und
Entschlüsseln benutzt. In Bild 3-2 wird dies durch das Schlüsselsymbol veranschaulicht. Sender und
Empfänger müssen sich also auf einen gemeinsamen Schlüssel einigen, bevor irgendein
Datenaustausch erfolgt. Dies ist ein Nachteil, da bei mehreren Teilnehmern die Anzahl an Schlüsseln
sehr groß wird. Bei n Teilnehmern werden bereits n(n-1)/2 Schlüssel benötigt, damit jedes
Teilnehmerpaar einen eigenen besitzt, der außerdem über einen sicheren Weg ausgetauscht werden
will.
Der Vorteil von symmetrischer Verschlüsselung ist die relativ hohe Geschwindigkeit, mit der ver- und
entschlüsselt wird, und die effiziente Implementierbarkeit in Hardware. Ein simples Beispiel für ein
symmetrisches Verfahren ist bitweises XOR. Zweimalige Anwendung des XOR Operators ergibt
wieder das Original.
Es gibt zwei Arten symmetrischer Algorithmen: Block-Algorithmen, die auf einem Datenblock pro
Runde operieren, und Stream-Algorithmen, die Bit für Bit verarbeiten. Block-Algorithmen arbeiten in
verschiedenen Modi, von denen im folgenden zwei elementare Modi herausgegriffen und näher
erläutert werden sollen.
Electronic Code Book Mode (ECB)
Electronic Codebook Mode (ECB) bearbeitet jeden Block unabhängig von den anderen. Wie in Bild
3-3 zu sehen ist, werden die Klartextblöcke mi jeweils verschlüsselt, ohne dass das Ergebnis einer
Verschlüsselung in die Verschlüsselung eines anderen Blocks eingeht. Das bedeutet, dass identische
Datenblöcke auch in identische chiffrierte Blöcke umgewandelt werden. Dies ist ein Nachteil dieses
Verfahrens, da dadurch Attacken möglich sind. Die unabhängige Verarbeitung erlaubt andererseits
eine Parallelisierung der Verschlüsselung der Datenblöcke und damit eine hohe
Verarbeitungsgeschwindigkeit.
33
Sicherheit in Datennetzen
mi
mi-1
Sichere Multimediakonferenzen
mi+1
m1
m2
m3
Ek
Ek
Ek
c1
c2
c3
c0
Ek
Ek
Ek
ci-1
ci
ci+1
Bild 3-3:
Electronic Code Book Mode (ECB)
Bild 3-4:
Li-1
Ri-1
Cipher Block Chaining (CBC)
Schlüssel
shift
Permutation
shift
Permutation
S-Box Substitution
P-Box Permutation
Li
Bild 3-5:
Ri
Schlüssel
Eine Runde des DES-Algorithmus
Cipher Block Chaining (CBC)
CBC (Cipher Block Chaining) lässt das Ergebnis der Verschlüsselung des vorigen Blocks in die
Verschlüsselung einfließen, sodass die Attacke erschwert wird. Jeder Datenblock wird, bevor der
Verschlüsselungsalgorithmus angewendet wird, mit dem Output des vorigen Blocks XOR-verknüpft
(Bild 3-4). Ein Initialisierungsvektor c0 wird als Input für die Verarbeitung des ersten Blocks
verwendet. Dieser sollte zufällig gewählt werden.
Neben diesen beiden Modi gibt es unter anderem noch CFB- (Cipher Feedback) und OFB- (Output
Feedback) Modus. Bei diesen beiden fließt die vorangegangene Chiffrierung derart ein, dass Blöcke
kleiner als die Blockgröße abgefertigt werden können.
DES
Ein verbreiteter Block-Algorithmus ist DES (Data Encryption Standard) [Sch96, Wob98]. DES wurde
von IBM entwickelt und schon 1977 zum U.S. Standard erklärt. DES ist gut erforscht und arbeitet mit
56-Bit Schlüsseln auf 64-Bit Blöcken, entweder in ECB, in CBC oder für Blöcke kleiner 64 Bit in
34
Sichere Multimediakonferenzen
Bob’s
Public Key
Verschlüsselung
Sicherheit in Datennetzen
Bob’s
Private Key
Entschlüsselung
Alice
Bild 3-6:
Bob
Unsymmetrischer (Public Key) Algorithmus
CFB Modus. In jeder der 16 Runden wird ein neuer Schlüssel abgeleitet. Jede Runde stellt eine
Kombination von Substitution und Permutation dar.
Der DES-Schlüssel wird als 64-Bit Wert dargestellt. Davon sind allerdings 8 Bit zur Paritätskontrolle
vorgesehen und haben für den Schlüssel keine weitere Bedeutung. Die Operationen, die in einer
Runde ausgeführt werden, sind in Bild 3-5 zu sehen. Zu Beginn jeder Runde werden die Bits des
Schlüssels verschoben. Aus den 56 Bits werden danach 48 Bits ausgewählt. Die rechte Hälfte des 64Bit Datenblocks wird durch Permutation auf 48 Bits erweitert und dient zusammen mit den 48 Bits des
Schlüssels als Input zu einer XOR-Operation. Durch die anschließende Substitution in der
sogenannten „S-Box“ ergibt sich eine Reduktion auf 32 Bits, die noch einer Permutation durch die
„P-Box“ unterzogen werden. Schließlich folgt noch eine XOR-Operation dieser 32 Bits und der linken
Hälfte des Datenblocks. Das daraus resultierende Ergebnis stellt die neue rechte Seite des Datenblocks
dar. Die rechte Seite des Datenblocks wird die neue linke Seite.
Inzwischen gibt es eine neue Variante von DES, um eine Brute-Force-Attacke auf den mittlerweile
etwas kurzen 56-Bit Schlüssel zu erschweren: Triple DES (3DES) wendet den DES-Algorithmus in
drei Runden mit zwei verschiedenen 56-Bit Schlüsseln an.
Ein anderes Verfahren, das angetreten ist, DES zu ersetzen, ist AES (Advanced Encryption Standard).
1997 wurde eine Initiative seitens des NIST (National Institute of Standards and Technology) gestartet
und die Öffentlichkeit wurde aufgerufen, Blockalgorithmen als Kandidaten vorzuschlagen. Von diesen
Vorschlägen wurden 15 akzeptiert und evaluiert. Aus diesen wurden fünf Algorithmen für die nächste
Runde zugelassen: Mars, RC6, Rijndael, Serpent und Twofish. Sie sollen aber nicht näher erläutert
werden. Der Entscheidungsprozess ist derzeit noch nicht abgeschlossen.
3.2.2.
Unsymmetrische Verschlüsselung
Diese ist die zweite Kategorie von Chiffriermethoden. Sie wird auch Public Key Verschlüsselung
genannt. Jeder Teilnehmer hat ein Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen
Schlüssel. Der private Schlüssel wird vom Teilnehmer geheimgehalten, während der öffentliche
Schlüssel an alle weitergegeben werden kann bzw. soll. Die beiden Schlüssel ergänzen sich in dem
Sinn, dass Daten mit einem Schlüssel chiffriert werden und mit dem anderen dechiffriert.
Andere Benutzer können dem Besitzer des öffentlichen Schlüssels auf sicherem Weg Daten
zukommen lassen, indem sie sie mit dem öffentlichen Schlüssel des Empfängers chiffrieren. Das
dazupassende Gegenstück, der private Schlüssel, ist einzig im Besitz des Empfängers und nur dieser
kann folglich die Daten lesen.
35
Sicherheit in Datennetzen
Sichere Multimediakonferenzen
Außerdem eignen sich die unsymmetrischen Algorithmen ausgezeichnet, um Nachrichten zu
authentifizieren: Wird die Nachricht mit dem privaten Schlüssel chiffriert, weiß der Empfänger, der
die Nachricht mit dem öffentlichen Schlüssel des Senders lesen kann, von wem sie kommt, da nur der
Besitzer des privaten Schlüssels in der Lage ist, diesen anzuwenden. Dieses Prinzip wird in digitalen
Signaturen angewendet. Außerdem gewährleistet dieses Verfahren Nichtabstreitbarkeit. Fügt man
noch Datum und Zeit in die Signatur ein, so hat man einen guten Nachweis über die Kommunikation.
Diffie Hellman
Diffie und Hellman sind die Begründer der unsymmetrischen Verschlüsselungstechnik und
publizierten den ersten Algorithmus, den Diffie Hellman-Algorithmus [Sch96]. Es handelt sich um ein
Verfahren zum Austausch von Schlüsseln, die für symmetrische Verschlüsselung verwendet werden
können. Dabei tauschen die beiden Teilnehmer lediglich öffentliche Informationen aus, also solche,
die von jedermann lesbar sein können. Diese verwenden die beiden dann dazu, einen Schlüssel
abzuleiten. Kein Dritter ist in der Lage, den Schlüssel zu rekonstruieren, auch wenn er den Datenfluss
der beiden Partner abgehört hat. Diffie Hellman bietet keine Authentifizierung. Dazu kann z. B. RSA
verwendet werden.
Wollen Alice und Bob einen gemeinsamen geheimen Schlüssel erzeugen, gehen sie wie folgt vor:
Zunächst einigen sich die beiden auf eine große Primzahl n und die Zahl g, die meist als Generator
bezeichnet wird. Die Zahl g ist meist kleiner als n und hat die Eigenschaft, dass sie jede Zahl zwischen
1 und n-1 erzeugen kann, indem sie mit sich selbst eine bestimmte Anzahl mal multipliziert wird und
anschließend die (mod n)-Funktion angewendet wird. Als nächstes berechnen Alice und Bob ihre
privaten Werte:
1. Alice wählt einen privaten Wert x und sendet Bob den Wert der Berechnung X = gx mod n
2. Bob wählt den Wert y und sendet folgenden Wert an Alice: Y = gy mod n
3. Alice berechnet k = Yx mod n
4. Bob berechnet k’ = Xy mod n
Sowohl k als auch k’ sind äquivalent zu gxy mod n. Kein Zuhörer kann diesen Wert berechnen, denn er
kennt nur n, g, X und Y. Der Wert k ist der geheime Schlüssel, der von Alice und Bob getrennt
berechnet wurde.
RSA
RSA [Sch96, Wob98], benannt nach seinen Erfindern Rivest, Shamir und Adelman, ist ein De facto
Standard für unsymmetrische Verschlüsselung. Die Schlüssellänge ist nicht wie bei DES fix
festgelegt, sondern kann je nach Bedarf mitwachsen; Beispiele sind 512, 768, 1024 oder 2048-Bit
Schlüssel, die mit zunehmender Rechnerleistung immer größer werden.
Der RSA Algorithmus funktioniert folgendermaßen: Zunächst werden zwei große Primzahlen p und q
gewählt und daraus das Produkt n = pq berechnet. Diese Zahl n wird als Modulus bezeichnet. Danach
wählt man eine Zahl e, die kleiner als n ist und die Bedingung erfüllt, dass sie keinen gemeinsamen
Teiler mit (p-1)(q-1) besitzt außer die Zahl 1. Man wählt eine weitere Zahl d, für die gilt, dass (ed - 1)
36
Sichere Multimediakonferenzen
Sicherheit in Datennetzen
durch (p-1)(q-1) teilbar ist. Die Werte e und d sind Teil des öffentlichen und privaten Schlüssels. Die
Werte p und q werden nicht länger benötigt und sollten vernichtet werden.
Öffentlicher Schlüssel: (n, e)
Privater Schlüssel: (n, d)
Um eine Message m zu verschlüsseln, wird sie zuerst in Blöcke geteilt, deren numerischer Wert
kleiner als n ist. Die Verschlüsselung erfolgt durch diese Berechnung:
ci = mie mod n
Die Entschlüsselung erfolgt mit dem anderen Schlüssel:
mi = cid mod n
Dabei ist es auch möglich, die beiden Schlüssel in umgekehrter Reihenfolge anzuwenden.
Hashing
Eine Hash-Funktion erzeugt eine Art Fingerabdruck eines Dokuments [Sch96, MAB98]. Sie erzeugt
aus einem Input variabler Länge einen Hashwert von konstanter Länge, der keine Rückschlüsse auf
das originale Dokument zulässt. Hashing soll möglichst vermeiden, dass verschiedene Dokumente
denselben Hashwert produzieren.
Diese Anforderung kann natürlich nie ganz erfüllt werden, da es mehrere Dokumente geben muss, die
denselben Hashwert liefern, aber es soll nur mit unverhältnismäßig hohem Aufwand möglich sein.
Hashfunktionen heißen auch Message Digests. Nimmt man neben dem Dokument als zweiten InputParameter einen Schlüssel, erhält man den sogenannten Message Authentication Code (MAC). In
anderen Worten: Verschlüsselt man einen Hashwert, erhält man einen MAC.
Hashfunktionen können die Integrität einer Nachricht beweisen. Mit der Verschlüsselung im Fall des
MAC wird der Sender authentifiziert. Hashfunktionen sind vor allem dann sinnvoll, wenn man auf die
Verschlüsselung der gesamten Nachricht (aus Effizienzgründen) verzichten möchte und lediglich
Integrität und Authentizität zum Ziel hat.
Digitale Signaturen
Die digitale Signatur ist ein spezieller MAC, dessen Schlüssel der private Schlüssel des Absenders ist
[MAB98]. Die Signatur wird an die Nachricht, die selbst verschlüsselt oder unverschlüsselt sein kann,
angehängt. Der Empfänger, der den Hash-Algorithmus kennt, kann dann die erhaltene Signatur mit
seiner selbst ermittelten vergleichen und somit Integrität und Authentizität der Nachricht sicherstellen.
Übertragungsfehler und böswillige Veränderung werden erkannt, da der Fingerabdruck sich
unterscheidet.
Als Authentifizierungs-Standard gilt der Digital Signature Standard (DSS). Er setzt sich aus dem
Digital Signature Algorithm (DSA) und dem Hash-Verfahren SHA-1 (Secure Hash Algorithm)
zusammen. SHA-1 produziert einen 160-Bit Hashwert.
37
Sicherheit in Datennetzen
Sichere Multimediakonferenzen
privater
Schlüssel
Hashfunktion
Nachricht
Bild 3-7:
Verschlüsselung
Digitale
Signatur
Hashing einer Nachricht mit dem privaten Schlüssel ergibt Signatur
Zertifikate
Ein Problem mit der unsymmetrischen Verschlüsselung ist der Austausch von öffentlichen Schlüsseln.
Dabei geht es um Unsicherheit, ob ein öffentlicher Schlüssel wirklich zu dieser Person gehört. Ein
Man-In-The-Middle-Attack [Sch96, Wob98] macht davon Gebrauch, indem er den beiden
Teilnehmern seinen öffentlichen Schlüssel als den des Kommunikationspartners ausgibt. Er kann
damit alle Nachrichten abfangen, entschlüsseln, eventuell verändern, wieder verschlüsseln und
weitersenden.
Um diese Gefahr auszuschalten, gibt es Zertifizierungsstellen, die den öffentlichen Schlüssel an eine
Person binden. Ein Zertifikat entsteht durch das Hashing des öffentlichen Schlüssels und des Namens
des Besitzers. Dieser Fingerabdruck wird mit dem privaten Schlüssel der Certification Authority (CA)
verschlüsselt. Damit dieses System funktioniert, müssen die Teilnehmer der Zertifizierungsstelle
trauen. Das können öffentliche Einrichtungen wie etwa Universitäten sein oder es kann sich auch ein
Netzwerk aus Bekannten ergeben, die sich gegenseitig vertrauen. Die Anordnung von
Zertifizierungsstellen in einer Hierarchie kann zusätzliche Übersichtlichkeit bieten. Diese Hierarchie
bildet eine sogenannte Trust chain. Der CA an der Wurzel traut jeder und ihr Private Key ist „top
secret“.
3.3. Firewalls
Firewalls [MAB98, CZ95] trennen das globale Netz in zwei Teile: in das vertrauenswürdige interne
Netz und den Rest. Der Informationsfluss zwischen den beiden Seiten wird reguliert, damit die Gefahr
von Attacken von außen so gering wie möglich wird. Die Firewall implementiert die Security Policy
des Unternehmens. Firewalls stehen in Zusammenarbeit mit Routern, die das Verbindungsglied
zwischen internen und externen Netzwerken darstellen.
Die Firewall fällt ihre Entscheidungen, ob Daten passieren dürfen, aufgrund der Informationen der
Paket-Header. Dabei unterscheiden sich drei Typen von Firewalls; Der sogenannte Paketfilter
betrachtet jedes IP-Paket einzeln, während Circuit-Level Gateways Verbindungen behandeln.
Application Level Gateways schließlich kennen Sessions, die zwischen Applikationen bestehen.
38
Sichere Multimediakonferenzen
Sicherheit in Datennetzen
Firewall
Sicheres
internes Netz
(Organisation A)
Bild 3-8:
Firewall
Unsicheres
Netz
(Internet)
Sicheres
internes Netz
(Organisation B)
Firewalls trennen interne Netze vom globalen Netz
Paketfilter
Der Paketfilter macht einen Binärvergleich der Header-Informationen des IP Paketes mit seiner
Security Policy und lässt es passieren oder verwirft es. Die Policy kann den Verkehr über diese beiden
Felder regulieren:
Adress-Informationen: Es können einzelne Hosts oder ganze Netzwerke vom Zugang zum
schützenswerten Netz ausgeschlossen werden. Dabei gibt es die beiden gegenläufigen Ansätze:
entweder alle Adressen zuzulassen außer einigen, oder alle abzulehnen, außer den auserwählten,
z. B. Netzwerke, die zur selben Organisation gehören.
Service: Je nach Art des Services werden unterschiedliche Ports verwendet. Das kann dazu
benutzt werden, einige Services zu verbieten. Telnet auf Port 23 könnte deaktiviert werden, um
Hackern diese Angriffsfront zu verwehren, während Email auf Port 25 im allgemeinen ein
wichtiger Dienst für die Angehörigen einer Organisation ist und freigeschaltet wird.
Kombiniert man die beiden Varianten, könnte etwa Telnet von vertrauenswürdigen Netzen gewährt
werden. Packet Filtering läuft meist in der Netzwerkadapterkarte des Routers ab, oder, in der
langsameren Variante, im Betriebssystem des Routers. Zu den eingeschränkten Möglichkeiten der
Paketfilter zählt unter anderem, dass das interne Netz nach wie vor sichtbar bleibt.
Circuit Level Gateway
Während Paketfilter sich keinen Status über die Verbindungen und die Messages merken, die sie
passieren, ist die beim Circuit Level Gateway anders. Dies hat den Vorteil, dass der Datenfluss in
beide Richtungen ermöglicht wird, wenn die Daten zur selben Verbindung gehören. Es sind also
beispielsweise nicht zwei Einträge in die Policy für ein- und ausgehende Telnet-Nachrichten
notwendig. Im Unterschied zum Application Level Gateway, der als nächstes beschrieben wird,
werden die Datenpakete nicht zusätzlich bearbeitet.
Application Level Gateway
Dieser Typ Firewall tut mehr als Pakete auszufiltern. Jene Pakete, die die Filterkriterien erfüllen und
durchgelassen werden, werden im Gateway neu formatiert, und die Adressfelder des Headers von
ausgehenden Paketen zeigen von nun an auf den Gateway, als hätte dieser die Pakete erzeugt. Damit
ist die Firewall der einzige Computer, der außerhalb des Netzwerks gesehen werden kann; ein Hacker
39
Sicherheit in Datennetzen
(a)
IP Hdr
(b)
IP Hdr
Sichere Multimediakonferenzen
Payload
AH Hdr
Payload
Authentifiziert
(außer variable Felder)
Bild 3-9:
AH in Transport Mode: (a) Original IP Paket; (b) Paket mit AH Header
kann also nichts über die Topologie des internen Netzes ausforschen, ohne zuerst die Firewall zu
knacken.
Gateways erfordern sogenannte Proxy-Applikationen für jedes erlaubte Service. Die Proxies
überprüfen die Inhalte der Pakete dieses Dienstes. Sie haben detailliertes Wissen zu den
entsprechenden Services (z. B. Email, HTTP).
Gateway Firewalls sind nicht in Hardware oder im Betriebssystem implementiert, sondern als
eigenständige Software, das auf einem Server-OS läuft. Zu ihren Vorteilen zählt das Loggen des
Netzwerkverkehrs. Damit werden alle Einbruchsversuche aufgezeichnet. Wegen der umfangreichen
Aktionen (Re-Adressierung etc.) läuft ein Gateway langsamer als ein Paketfilter und kann die NetzPerformance für die Benutzer des internen Netzes wesentlich reduzieren. Außerdem besteht einiger
Aufwand zur Administration: ein neues Service verlangt auch einen neuen Proxy.
3.4. IPSec
Die IP Security Architecture schafft eine Möglichkeit für Benutzer, kryptographische Mechanismen
zur Sicherheit zu nutzen [MAB98]. IP Pakete werden Integritäts-, Authentizitäts- und
Verschlüsselungsverfahren unterworfen. Es ist sowohl für Hosts als auch für Gateways einsetzbar. Die
kryptographischen Algorithmen sind dabei änderbar, ohne dass das Auswirkungen auf die restliche
Implementierung von IPSec hat. Für Verschlüsselung kann z. B. DES, für Authentifizierung RSA zum
Einsatz kommen.
IPSec arbeitet auf Host-zu-Host Basis. Dafür bietet sich die Netzwerkschicht an, denn damit ist es
möglich, den Datenaustausch applikationsunabhängig durchzuführen. Dies ist gut dafür geeignet,
VPNs (Virtual Private Networks) zu implementieren. Auf der anderen Seite bringt die
Verschlüsselung des gesamten Datenverkehrs auch einen Nachteil: Es ist nicht möglich, eine
Einschränkung auf bestimmte Dienste vorzunehmen.
Die zwei wesentlichen Verfahren sind der Authentication Header (AH), der eine SenderAuthentifizierung durchführt, und Encapsulating Security Payload (ESP), das Authentifizierung und
auch Datenverschlüsselung bietet.
40
Sichere Multimediakonferenzen
(a)
IP Hdr
(b)
New IP Hdr
(c)
New IP Hdr AH Hdr
Sicherheit in Datennetzen
Payload
IP Hdr
Payload
IP Hdr
Payload
Authentifiziert
(außer variable Felder)
Bild 3-10: AH in Tunnel Mode: (a) Original IP Paket; (b) Tunneled Packet; (c) Paket mit AH Header
Host A
Gateway
Internet
Gateway
Host B
AH in Tunnel Mode
ESP in Transport Mode
Bild 3-11: VPN mit IPSec: Hosts verschlüsseln, Gateways authentifizieren die Daten
Authentication Header (AH)
AH bietet Integrität und Authentifizierung für IP Pakete. Der AH kann in zwei unterschiedlichen
Varianten angewendet werden: Die beiden Modi werden in Bild 3-9 und Bild 3-10 dargestellt.
Transport Mode: Es werden die gesamten Payload Daten sowie jene IP Header-Informationen
authentifiziert, die sich en route nicht ändern. Felder, die sich ändern, sind TOS, Flags, Fragment
Offset, TTL und Header Checksum. Diese Felder sind nicht Teil des Inputs für den MACAlgorithmus.
Tunnel Mode: Hier wird ein neues IP Paket erzeugt, dessen Payload das ursprüngliche Paket
inklusive Header ist. Auf das neue Paket wird der Transport Mode angewendet. Der Vorteil ist, dass
alle Felder authentifiziert werden. Die IP Adressen des ursprünglichen Headers und des neuen Headers
müssen nicht übereinstimmen; dies ist besonders für Gateways interessant.
Encapsulating Security Payload (ESP)
Mit ESP ist auch Verschlüsselung des IP Paketes möglich. Auch hier gibt es Transport und Tunnel
Mode. Während Transport Mode den Header des IP Pakets weder authentifiziert noch verschlüsselt,
41
Sicherheit in Datennetzen
Sichere Multimediakonferenzen
ist das im Tunnel Modus der Fall, da hier der Header zur Payload wird. Der Tunnel Mode wird
typischerweise zwischen Gateways (Firewalls) verwendet.
Obwohl ESP eigentlich alle Aufgaben erfüllt, die AH implementiert, ist AH sinnvoll, solange keine
Verschlüsselung gefordert wird, da es effizienter in Bezug auf Geschwindigkeit implementiert ist.
Eine beliebte Variante ist AH in Tunnel Mode, das mit ESP verschlüsselte Daten schützt, z. B. um ein
Virtual Private Network (VPN, siehe Bild 3-11) oder Dial up Remote Access zu implementieren.
Damit ist während der Übertragung größtmögliche Sicherheit gegeben, da durch den Tunnel-Modus
von ESP der neuerzeugte Paket-Header die Adresse des Senders nicht offen legt.
Schlüsselmanagement
IPSec funktioniert auch einfach mit manuell erzeugten Schlüsseln. Aber eine Umgebung, die sich um
Schlüsselerzeugung und deren Austausch kümmert, ist ab ein paar Benutzern unabkömmlich. Dieses
Framework stellt IKE (Internet Key Exchange) zur Verfügung. In der ersten Phase wird zwischen den
Kommunikationspartnern ein sicherer Kanal etabliert, auf dem dann die Schlüssel sowie einige andere
Parameter für die sogenannte SA (Security Association) ausgetauscht werden; SAs identifizieren eine
unidirektionale Kommunikation über IPSec zwischen zwei Hosts und definieren die Algorithmen für
Authentifizierung und Verschlüsselung. Die wichtigen Bausteine der Schlüsselverwaltung sind:
Internet Security Association and Key Management Protocol (ISAKMP): Eine Umgebung für das
Management von SAs und Schlüsseln, jedoch nicht für den Schlüsselaustausch.
Oakley: Ein Schlüsselaustauschprotokoll, das ISAKMP ergänzt. Es erledigt den Austausch und
das Update von Schlüsselmaterial für Security Associations.
IKE: Ein Protokoll, das Teile von ISAKMP und Teile des Oakley und des SKEME Protokolls für
IPSec AH und ESP sowie für ISAKMP selbst implementiert.
3.5. SSL
SSL steht für Secure Socket Layer [MAB98] und wurde von Netscape und RSA Data Security
entwickelt mit dem Ziel, Verbindungen sicher zu machen. Dazu wird eine Schicht zwischen
Transport- und Application-Layer eingefügt, also etwa zwischen TCP und HTTP. SSL bietet
Verschlüsselung, Authentifizierung des Servers und optional (ab Version 3.0) auch des Clients und
Datenintegrität. Im Gegensatz zu IPSec ist die Orientierung darauf ausgerichtet, Sicherheit für Dienste
zu implementieren, nicht auf Host-zu-Host Basis.
Die SSL-Schicht verhält sich zur TCP Applikation hin unsichtbar, indem es ein API anbietet, das dem
von TCP gleicht. Theoretisch kann SSL daher von allen auf TCP/IP basierenden Protokollen genutzt
werden, ohne die Applikation zu ändern.
SSL setzt sich selbst aus zwei Schichten zusammen. Die obere implementiert das Handshake
Protokoll für die einleitende Authentifizierung und den Transfer der symmetrischen Schlüssel, die
dann in der unteren Schicht, dem SSL Record Protocol zum Datentransfer genutzt werden.
Der Verbindungsaufbau läuft in mehreren Schritten ab (siehe dazu Bild 3-12):
1. Hello Phase: Der Client etabliert eine Verbindung zum Server und teilt diesem seine verfügbaren
Krypto-Algorithmen mit.
42
Sichere Multimediakonferenzen
Sicherheit in Datennetzen
Client
Server
1
SSL
Record
Change
Cipher Spec
SSL Handshake
Client Hello
2
(Certifcate)
(Client Key Exchange)
(Certificate Verify)
Finished
Server Hello
(Certificate)
(Server Key Exchange)
(Certificate Request)
Server Hello Done
3
Change Cipher Specs
4
Finished
Change Cipher Specs
5
Send Data
Send Data
Bild 3-12: Zustandekommen einer SSL Verbindung
2. Der Server wählt daraus ein Public Key-, ein Private Key- und ein Hash-Verfahren aus und teilt
seine Wahl dem Client mit. Außerdem sendet der Server ein Zertifikat, falls der Client ihn dazu
aufgefordert hat, und eine Server Key exchange message, um den symmetrischen Schlüssel zu
generieren.
3. Der Client schickt eventuell ein Certificate, danach seine Key exchange message. Nun besitzen
Client und Server genug Informationen, um über symmetrische Verschlüsselung einen
vertraulichen Datenaustausch zu gewährleisten, sowie den MAC für die Integrität der Daten zu
erzeugen.
4. Client und Server beenden die Verhandlungen mit je einer Finish Meldung. Der Client
authentifiziert den Server, indem er einige chiffrierte zufällige Testnachrichten schickt, die nur der
richtige Server lesen kann. Der Server kann auf vergleichbare Weise den Client authentifizieren,
falls der Client über ein registriertes Zertifikat verfügt.
5. Alle weiteren Daten werden mit dem Sitzungsschlüssel chiffriert, etwa mit Hilfe des DES oder
RC4 Verfahrens. MACs werden nach MD5, SHA oder DSS erzeugt und an den Datenblock
angehängt.
43
Sicherheit in Datennetzen
Sichere Multimediakonferenzen
SOCKS
Rules
SOCKS
Server
IP Filter
Rules
Port 1080
Server
Port
Client
Server
SOCKS Authentifizierung
Client-Server Authentifizierung
Bild 3-13: SOCKS Server spaltet Client-Server Verbindung in zwei Teilverbindungen
3.6. SOCKS
SOCKS ist ein Standard für Gateways [MAB98]. Anders als bei herkömmlichen Gateways erspart
sich der Benutzer, sich zuerst am Proxy anzumelden und sich erst im zweiten Schritt zum
gewünschten Ziel zu verbinden. Diese Aufgabe übernimmt die SOCKS-Software, die sowohl im
SOCKS Server als auch im Client implementiert sein muss (SOCKSified Clients). Der Ziel-Server hat
jedoch keine Kenntnis davon, dass die Verbindung von einem SOCKS Server erfolgt.
SOCKSv5 erlaubt eingehende und ausgehende Verbindungen, sowohl TCP als auch UDP. Für
SOCKS ist es nicht nötig, für jede neue Applikation einen Proxy Code zu entwerfen. SOCKSv5
unterstützt
verschiedene
Authentifizierungs-,
Verschlüsselungs-,
Tunnelingund
Schlüsselmanagement-Methoden, unter anderem IPSec für Authentifizierung und Verschlüsselung.
Der SOCKS Server nimmt auf Port 1080 Verbindungsanfragen entgegen und öffnet, wenn die
notwendigen Berechtigungen existieren, je nach Anfrage einen TCP oder UDP Kanal. Danach folgt
die Authentifizierung des Clients am Ziel-Server und schließlich der Datenaustausch. Im Falle einer
UDP Anfrage führt jedes Datagramm einen Request-Header, der das Ziel identifiziert.
44
Sichere Multimediakonferenzen
Multimediakonferenzen
4. Multimediakonferenzen
Mit der gesteigerten Geschwindigkeit moderner Netzwerke sind neue Anwendungen entstanden, die
aus dieser Tatsache ihren Nutzen ziehen. Es handelt sich dabei z. B. um Video- und
Sprachübermittlung. Diese Applikationen stehen im Mittelpunkt dieses Kapitels. Zuerst wird das
Service Modell diskutiert, das ihnen zugrunde liegt. Wie dieses Modell in der Praxis umgesetzt wird,
sollen die Ausführungen zur Protokoll-Hierarchie erläutern, die im Rahmen von Internet Telephonie
und Multimediakonferenzen zu finden ist. Schließlich folgt eine Einführung in die wichtigsten
Protokolle, die sich derzeit im Einsatz befinden.
4.1. Real-Time Applikationen
Unter Real-Time Applikationen versteht man jene Klasse von Anwendungen, die spezifische
Anforderungen an die Verzögerungscharakteristik des Übertragungssystems stellen. Diese
Anforderungen müssen somit von den Knoten im Netzwerk erfüllt werden; das derzeit etablierte BestEffort Modell des Internet reicht dafür nicht aus. Das angestrebte Service-Modell [PD96] für Real
Time Applikationen geht über diesen Best-Effort Mechanismus hinaus und erweitert es. Applikationen
sollen die Möglichkeit haben, gewisse Bandbreiten mit maximalem Delay vom Netzwerk anzufordern.
Das Netzwerk kann dann versuchen eine Verbindung mit geforderter Qualität aufzubauen. Ein Zugang
dazu ist, dass alle Router, die an dieser Verbindung teilhaben, versuchen, eine vereinbarte Anzahl an
Bits pro Sekunde zu reservieren. Eine andere Möglichkeit ist die Verwendung von Service-Klassen,
die Services unterschiedlicher Qualität anbieten.
4.1.1.
Service-Modell
Wir haben es grundsätzlich mit zwei Arten von Applikationen zu tun. Einerseits gibt es die
traditionellen Datenapplikationen wie Telnet, FTP, Email, Web Browsing etc., für die ein kleiner
Delay durchaus angenehm ist, die aber auch bei größerem Delay funktionieren.
Daneben entstehen eine Reihe von Real-Time Applikationen wie etwa IP Telephonie: Daten werden
erzeugt, indem Samples des Mikrofons digitalisiert werden. Die Daten werden in Pakete aufgeteilt und
durch das Netzwerk transportiert. Am Empfänger werden die Daten entgegengenommen und in
Audiosignale umgewandelt. Wichtig ist dabei der Zeitpunkt der Wiedergabe. Jedes Sample soll genau
dann wiedergegeben werden, wenn das vorige die Wiedergabe abgeschlossen hat, also in sequenzieller
Reihenfolge.
45
Sequenznummer
Multimediakonferenzen
Sichere Multimediakonferenzen
Paketankunft
Paketerzeugung
Playback
Buffer
Verzögerung
des Netzes
Zeit
Bild 4-1:
Layered Protocol Archtitektur
Ein Sample, das erst nach seinem geplanten Wiedergabezeitpunkt ankommt, ist damit ohne jeden
Wert, denn der Redefluss kann aus Verständigungsgründen nicht verzögert werden. In einem solchen
Fall wird das Sample ausgelassen und die Wiedergabe geht mit dem darauffolgenden Sample weiter.
Könnte man garantieren, dass alle Pakete gleich lang durchs Netz benötigen, könnten alle Samples
sofort nach Eintreffen abgespielt werden. Aber aufgrund von Queues in Switches und Routern
variieren die Übertragungszeiten. Um mit dieser Situation umzugehen, implementiert der Empfänger
einen Buffer für die Samples, die vor ihrem geplanten Abspieltermin eintreffen, um dann zum
korrekten Zeitpunkt wiedergegeben zu werden. Damit werden kurze Verzögerungen der Pakete
ausgeglichen. Durch diesen Mechanismus wird effektiv ein konstanter Offset zwischen dem Zeitpunkt
des Sprechens und des Abspielens erzeugt.
Bild 4-1 veranschaulicht die Situation: Die beiden Diagonalen zeigen Sample-Erzeugung bzw.
Playback. Die geschwungene Linie entspricht der Ankunft der Pakete am Empfänger. Solange das
Playback nicht zu früh erfolgt, werden die Variationen in der Übertragungszeit nicht bemerkt, da der
Buffer vorhanden ist. Die Differenz zwischen Zeitpunkt des Sprechens und der Wiedergabe sollte
jedoch nicht größer als 300 ms [PD96] betragen, da es sonst für die Gesprächspartner als unangenehm
empfunden wird.
Service-Klassen
Aufgrund unterschiedlicher Typen von Applikationen ergeben sich unterschiedliche Anforderungen
ans Netzwerk, die sich in den Service-Klassen niederschlagen. Diese bieten Services an, die über BestEffort hinausgehen. Real-Time Applikationen können einerseits in tolerante und intolerante
Applikationen bezüglich Paketverlusten eingeteilt werden, andererseits nach ihrer
Anpassungsfähigkeit bezüglich Delay und Datenrate.
Man kann sich dabei viele Kombinationen vorstellen, mit Ausnahme von intoleranten und zugleich
Delay-adaptiven Real-Time Applikationen. Ein Beispiel einer Anwendung mit adaptiver Datenrate ist
ein Video-Kodieralgorithmus, dessen Datenrate die erzielte Qualität wiederspiegelt. Für die Palette an
46
Sichere Multimediakonferenzen
Multimediakonferenzen
Signaling
H.323
SIP
Quality of Service
RTSP
RSVP
RTCP
Transport
media encaps.
(H.261, MPEG)
RTP
TCP
UDP
IPv4, IPv6
Link layer
Bild 4-2:
Multimediakonferenz-Architektur laut IETF
Applikationen ergeben sich verschiedene Service-Klassen. Intolerante Applikationen verlangen ein
garantiertes Service, wo ein bestimmter Delay nicht überschritten werden darf. Eine weitere Kategorie
ist ein Service mit vorhersagbarem Delay (predictive service), der zwar meist eingehalten wird, aber
gelegentliche Paketverluste verzeichnet. Dieser Dienst kann zu einer effizienteren Netzwerkauslastung
als das garantierte Service führen.
Daneben kann es nützlich sein, vom Netzwerk eine Übertragung mit kontrolliertem Delay
anzufordern. Dabei steht nicht so sehr die Quantität des Delays im Vordergrund als die Tatsache, dass
die Pakete innerhalb eines gewissen Zeitintervalls ankommen, d. h. alle etwa gleich schnell.
4.2. Protokoll-Stack
Internet Telephonie sowie Konferenzen mit anderen Medien wie z. B. Video basieren auf einer Reihe
von Protokollen, die verschiedene Aufgaben übernehmen. IETF hat einen Protokoll-Stack entwickelt,
der die Bereiche Verbindungsaufbau, Datentransport und Service-Qualität (QoS, Quality of Service)
umfasst (Bild 4-2) [SR98]. Es werden sowohl Echtzeit-Applikationen als auch Stored Media Streams
(z. B. Video abspielen) unterstützt.
Die Verwendung mehrerer verschiedener Protokolle, die jeweils ein bestimmtes Service
implementieren, schafft Modularität, Flexibilität, Übersichtlichkeit und einfache Erweiterbarkeit.
Teilnehmer bzw. Netzwerk-Server, die nur ein bestimmtes Service unterstützen, brauchen nur das
entsprechende Protokoll zu implementieren, ohne dadurch Interoperabilitätsprobleme zu erzeugen.
Außerdem können Protokoll-Komponenten in Applikationen wiederverwendet werden.
Die verwendeten Protokolle sind nicht auf bestimmte Medien oder auf Unicast eingeschränkt. Das
Hinzufügen neuer Medien verlangt keine Änderungen in der Netzwerk-Infrastruktur, was einen großen
Vorteil gegenüber dem traditionellen Telefonnetz darstellt. Außerdem ist das Erweitern von
Gesprächen zwischen zwei Personen zu Multi-Party Konferenzen leicht möglich.
Um das Zustandekommen einer Verbindung kümmern sich entweder das H.323 Protokoll der ITU-T
oder das von der IETF entwickelte SIP (Session Initiation Protocol) [deC99]. RTP ist das zentrale
Protokoll zum Transport von Sprach- und Videodaten für die Übertragung in Echtzeit. Die
47
Multimediakonferenzen
Sichere Multimediakonferenzen
H.323
Spezifikation des Systems
H.225.0
Call control (RAS), call setup
H.235
Sicherheitsprotokoll: Authentifikation, Integrität, Vertraulichkeit
H.245
Capability exchange
H.450
Zusatzdienste
H.246
Interoperabilität mit verbindungsorientierten Netzwerk-Services
H.332
Für Konferenzen mit vielen Teilnehmern
H.26x
Video codecs: z. B. H.261, H.263
G.7xx
Audio codecs: G.711, G.723, G.729, G.728, etc.
Tabelle 4-1: ITU-T Spezifikationen, die Teil von H.323 sind
unidirektionale Übertragung von Streaming-Daten kontrolliert eventuell auch das RTSP (Real Time
Streaming Protocol).
Um die nötigen qualitativen Rahmenbedingungen, die für Real-Time-Applikationen notwendig sind
und im vergangenen Kapitel erläutert wurden, zu gewährleisten, wird ein Ressourcen-AllokationsProtokoll eingesetzt, in diesem Stack ist es RSVP (Resource Reservation Protocol).
4.3. H.323
Es handelt sich hier um eine Familie von Standards, die in Tabelle 4-1 aufgelistet sind. H.323
spezifiziert das System und referenziert eine Reihe weiterer Standards. Das System, das von der
ITU-T stammt, definiert Protokolle für die Implementierung von Multimedia-Kommunikation in
paketvermittelten Netzen wie dem Internet. Es übernimmt die Aufgaben von Kodierung,
Paketaufteilung von Audio- und Videosignalen, Verbindungsaufbau und –kontrolle, sowie Austausch
der Fähigkeiten der Teilnehmer (capability exchange). Die meisten Implementationen entsprechen
derzeit der Version 2 [ITU323]; Seit Semptember 1999 existiert Version 3.
4.3.1.
H.323 Endknoten
H.323 definiert vier wesentliche Komponenten: Terminals, Gateways, Gatekeeper und Multipoint
Control Units (MCU).
Terminals sind Client-Endknoten im IP-Netzwerk, die die folgenden Funktionen erfüllen sollen:
Verbindungsmanagement: Zum Aufbauen und Überwachen von Verbindungen muss jeder
Terminal drei Standards unterstützen: RAS (Registration/Admission/Status) zum An- und
Abmelden am Gatekeeper, der die Zone verwaltet, H.225 um Calls zu erzeugen und H.245, das
einen komplexen Standard darstellt um die Kanäle zu verwalten. Sämtliche Protokolle basieren
auf ASN.1 (Abstract Syntax Notation One) für ihre Nachrichten.
48
Sichere Multimediakonferenzen
Terminal
Multimediakonferenzen
Terminal
Router
Gatekeeper
Terminal
H.323 Zone
Gateway
Telephone
Terminal
IP Netzwerk
SCN
Telephone
Terminal
Bild 4-3:
H.323 Komponenten
Echtzeit-Kommunikation: Terminals verwenden RTP/RTCP für Audio- und VideoPaketübertragung.
Codecs: Diese komprimieren und dekomprimieren die Audio- und Videodaten vor bzw. nach der
Übertragung. Aus Interoperabilitätsgründen ist der G.711 Audio-Codec vorgeschrieben, andere
sind optional.
Gateways ermöglichen Verbindungen zwischen paketvermittelten und leitungsvermittelten Netzen.
Sie sind nur im Fall solcher Verbindungen zwischen den Netzen erforderlich. Sie erledigen Call setup
und Call control in beiden Netzen und übersetzen die Übertragungsformate und Codecs.
Gatekeeper haben vier wesentliche Aufgaben: Adressübersetzung von Alias-Adressen zu TransportAdressen (IP Adresse und Port), Kontrolle über Zulassung von Calls, Regulierung der Bandbreite und
das Zonen-Management. Gatekeeper sind zwar optional, aber wenn sie vorhanden sind, müssen sich
alle anderen Endknoten, die in der administrativen Zone des Gatekeepers liegen, bei diesem
registrieren und ihre Calls dort anmelden.
MCUs ermöglichen Konferenzen zwischen drei oder mehr Endknoten. Eine MCU besteht
typischerweise aus einem Multipoint Controller (MC) und einer variablen Anzahl an Multipoint
Prozessoren (MP). Der MC hat Kontrollaufgaben wie Capability exchange, während die MPs die
Medienströme verarbeiten und mischen.
4.3.2.
Kanäle
H.323 definiert folgende Transport-Layer-Verbindungen als Kanäle:
RAS channel: Dieser Kanal dient der Kommunikation zwischen Endknoten und Gatekeeper und ist
in H.225.0 definiert. Der Endknoten registriert sich über diesen Kanal und fragt um die
Berechtigung, einen Call tätigen zu dürfen.
49
Multimediakonferenzen
Sichere Multimediakonferenzen
example.com
fiction.com
[email protected]
(3) Alice@klingon
(2) Alice
registrar server
(1) INVITE [email protected]
(4) INVITE Alice@klingon
(7) 200 OK
user agent client
(6) 200 OK
(8) ACK [email protected]
(8)
AC
proxy
server
(9) ACK Alice@klingon
User
agent
server
(5)
Alice@klingon
Bild 4-4: SIP-Verbindungsaufbau mit Hilfe eines Proxy-Servers
Call signaling channel: Der Kanal dient der Medienkontrolle. Nach Eröffnen des Kanals werden
die logischen Medienkanäle mit Hilfe dieses Kanals initiiert.
Logische Medienkanäle: Sie transportieren Audio und Video mit Hilfe von RTP/RTCP. Die
Übertragung erfolgt in Paaren von unidirektionalen Kanälen.
RAS und logische Kanäle laufen über ein unverlässliches Transport-Protokoll wie UDP, H.245 und
der Call signaling channel über ein verlässliches Service wie TCP.
4.4. SIP
So wie im Fall von H.323 wird auch bei Verwendung von SIP als Medientransport-Protokoll RTP
verwendet. SIP (Session Initiation Protocol) ist ein Application-Layer-Protokoll, das MultimediaSessions erzeugen, ändern und beenden kann [RFC2543]. Es gibt zwei wesentliche Elemente: den
User Agent (UA) und den Network Server. Der User Agent residiert in den Endknoten und besteht aus
zwei Komponenten: aus dem User Agent Client (UAC), der für das Versenden von SIP-Requests
verantwortlich ist, und dem User Agent Server (UAS), der diese Requests beantwortet. Es gibt drei
Arten von Netzwerk-Servern: den Redirect Server, den Proxy Server und den Registrar. Ein einfacher
SIP Call kommt sogar ohne Server aus, aber viele Services benötigen sie. Im Vergleich zu H.323 ist
der SIP UA äquivalent zu einem H.323 Terminal während die SIP Server dem H.323 Gatekeeper
entsprechen.
Eine typische Prozedur stellt ein SIP UAC dar, der einen Request sendet, wie in Bild 4-4 abgebildet.
Ein SIP Proxy Server kümmert sich um die Lokalisierung des gewünschten Partners und ein SIP UAS
akzeptiert den Call. Der gesamte Verbindungsaufbau nimmt in diesem Beispiel neun Schritte in
Anspruch – eine erfolgreiche SIP-Invitation besteht im allgemeinen lediglich aus einem INVITE- und
einem ACK-Request. Der INVITE-Request beinhaltet eine Session-Beschreibung mit Informationen
50
Sichere Multimediakonferenzen
Multimediakonferenzen
zu den unterstützten Medientypen und der Transport-Adresse, wohin die Mediendaten gesendet
werden sollen. SIP Adressen werden SIP-URLs genannt und haben die Form sip:[email protected].
Das SIP Message-Format basiert auf dem leicht lesbaren HTTP Message-Format.
In Bild 4-4 ist auch ein sogenannter Registrar-Server zu sehen, bei dem sich Empfänger – im
konkreten Fall Alice – mit ihrer SIP-URL und IP-Adressen registrieren, sodass später eine
Lokalisierung des Teilnehmers über die SIP-URL möglich ist.
Redirect-Server behandeln eine INVITE Message, indem sie die SIP-URL des Empfängers
zrücksenden, sodass der Client selbst die Verbindung zum Empfänger aufbauen kann Statt die
Nachrichten indirekt über einen Proxy Server zu senden, werden diese also direkt zwischen den
Teilnehmern ausgetauscht. SIP-Server können auch eine Kombination aus den verschiedenen ServerTypen sein; so wäre etwa ein kombinierter Server vorstellbar, der sowohl die Aufgaben eines Proxyals auch eines Registrar-Servers übernimmt.
Die Beschreibung von SIP Sessions in Requests wird nicht von SIP selbst gemacht. Dazu steht ein
eigenes Protokoll zur Verfügung, dessen sich SIP bedient: das Session Description Protocol (SDP). Es
dient neben der Beschreibung auch für das Annoncieren von Sessions [RFC2327].
4.5. RTP/RTCP
Das Real Time Protocol (RTP) ist ein Transport Protokoll zum Übertragen von Datenblöcken in
Echtzeit über Multicast oder Unicast Netzwerk-Dienste [RFC1889]. Das Datentransport-Protokoll
RTP arbeitet stets zusammen mit dem Kontrollprotokoll RTCP (RTP Control Protocol). Letzteres
erlaubt das Monitoring des Datentransfers in einer Art und Weise, dass es sich an eine große Anzahl
an Multicast-Teilnehmer anpassen kann, ohne das Netzwerk zu überlasten (scaling). RTP und RTCP
sind unabhängig von den darunter liegenden Transport und Network Schichten, werden in der Regel
aber mit UDP/IP verwendet.
Zu den wichtigsten Anforderungen, die die Übertragung von Real-Time-Datenströmen an ein
Transport-Protokoll stellt, zählen
Sequencing: Die Pakete müssen am Empfänger in Echtzeit geordnet werden. Verlorene Pakete
müssen erkannt und ohne nochmalige Übertragung kompensiert werden.
Medien-Synchronisation: Da keine Pakete während der Sprechpausen generiert werden, muss die
Zeitdifferenz zwischen aufeinander folgenden Paketen übermittelt und eingehalten werden.
Zusätzlich sollen die Medien untereinander, z. B. Audio und Video, synchronisiert werden, damit
das Bild zum Ton passt.
RTP/RTCP ist medienunabhängig. Das Kodierungsschema für ein bestimmtes Paket kann aus dem
Header entnommen werden und entspricht einem bei IANA (Internet Assigned Numbers Authority)
registrierten Schema. Obwohl QoS nicht im Bereich von RTCP liegt, wird ein Feedback generiert, das
den Sendern Aufschluss über den Zustand der Übertragung gibt.
Mixer und Translatoren sind zwei Komponenten, die in RTP-Systemen eingesetzt werden können. Sie
konvertieren Mediendaten und dienen somit der effizienten Datenübertragung. Mixer kombinieren die
Mediendaten verschiedener User zu einem Datenstrom und senden diesen. Translatoren hingegen
betrachten nur einen einzelnen Datenstrom und konvertieren diesen in ein anderes Format, bevor sie
51
Multimediakonferenzen
0
4
V
Sichere Multimediakonferenzen
8
16
CSRC
payload
P X count M type
31
sequence number
timestamp
synchronization source identifier (SSRC)
contributing source identifiers (CSRC)
opt.
header extension
opt.
payload (audio, video, ...)
Pad
Bild 4-5:
opt.
RTP Header
diesen senden. Translatoren können die Übertragung an die verfügbare Bandbreite anpassen und die
Sender von dieser Aufgabe entlasten.
Die Verschlüsselung der Mediendaten erfolgt über eine Methode, die durch das Signaling Protokoll
vereinbart wird. Das bedeutet, dass durch H.323 oder SIP die Authentifizierung der Teilnehmer sowie
auch der Austausch von Schlüsseln erfolgt, die dann zur Chiffrierung der Mediendaten herangezogen
werden.
4.5.1.
RTP
Wenn ein Host Mediendaten senden möchte, übergibt er sie an RTP. RTP formatiert die Daten in
Paketgröße, hängt diese an den RTP Header an und übergibt sie dem Transport Layer. Dadurch erfolgt
die Übertragung zu einer Multicast-Gruppe oder unicast zu einem anderen Teilnehmer.
Der RTP-Header besteht aus 12 Byte und einigen zusätzlichen optionalen Feldern und ist in Bild 4-5
dargestellt. V indiziert die Protokoll-Version, X signalisiert die Existenz einer Header extension. Wenn
P gesetzt ist, besteht ein Padding am Ende der Payload, das nicht von RTP selbst benötigt wird,
sondern den verwendeten Verschlüsselungsalgorithmus unterstützt, um eine einheitliche Blockgröße
zu erreichen.
Die Teilnehmer einer Multicast-Gruppe werden durch 32-Bit IDs (SSRC) identifiziert. Wenn ein
Mixer im Einsatz ist, werden alle Teilnehmer, die zum Inhalt dieses Pakets beitragen – z. B. alle
Sprecher einer Telefonkonferenz – in der CSRC-Liste aufgeführt, deren Länge durch den CSRC
count bestimmt wird.
Das M-Bit dient der Unterstützung des Framing und indiziert je nach Medium den Beginn oder das
Ende eines zusammengehörigen Datenblocks. Payload type identifiziert das Kodierverfahren für
dieses Paket. Sequence Number wird mit jedem Paket inkrementiert und zeigt den Zeitpunkt der
Erzeugung des Pakets. Die Payload kann selbst einen medienspezifischen Header beinhalten.
52
Sichere Multimediakonferenzen
4.5.2.
Multimediakonferenzen
RTCP
Der Datentransport von RTP wird durch ein Kontrollprotokoll erweitert, um die Übertragung zu
überwachen und Informationen über die Sender und Empfänger der Datenströme auszutauschen.
Durch das Senden von Feedback können Sender ihre Datenströme an die mögliche Übertragungsrate
des Netzwerks anpassen.
Jedes RTCP Paket besteht im allgemeinen aus einem sender report (SR) oder einem receiver report
(RR), gefolgt von source descriptors (SDES). Sender reports werden von RTP-Sources generiert und
beschreiben die Anzahl der gesendeten Bytes sowie Synchronisationsinformationen. Ein receiver
report beschreibt für jeden Sender der Gruppe die Verlustrate und den Jitter.
SDES-Pakete beinhalten einige Informationen über die Session wie den kanonischen Namen
(CName), der die Form einer Email-Adresse hat, sowie Name, Email, Telefonnummer, etc. Diese
Informationen können im User Interface dargestellt werden, um andere Teilnehmer kennenzulernen.
Die RTCP-Pakete werden periodisch gesendet. Allerdings nimmt die Frequenz mit zunehmender
Teilnehmeranzahl ab, damit große Gruppen das Netz nicht überlasten.
4.6. RSVP
Während verbindungsorientierte Netze immer ein Setup-Protokoll benötigen, um in den Switches die
nötigen Ressourcen zu reservieren, entstehen solche Protokolle erst mit dem Aufkommen neuer
Dienste wie Echtzeit-Applikationen. Das meistbeachtetste derartige Protokoll ist das Resource
Reservation Protocol (RSVP) [PD96, RFC2205]. RSVP ermöglicht es, Ressourcen im Internet zu
reservieren. Damit können Benutzer, die einen Datenstrom empfangen möchten, die nötige Bandbreite
vom Netzwerk anfordern. Die Reservierung findet vor dem eigentlichen Datentransfer statt.
Paketvermittelte Netze erreichen Robustheit vor allem folgender Charakteristik: Router können
abstürzen und Links ausfallen, ohne die Übertragung abzubrechen – die Daten können im allgemeinen
auch einen anderen Weg durchs Netz nehmen. Um diese Situation zu erhalten, verwendet RSVP das
Konzept des Soft State in den Routern, der nicht explizit gelöscht werden muss, sondern mittels
Timeout terminiert wird, sobald das regelmäßige Refresh durch den Endknoten ausbleibt. Allerdings
ist noch anzumerken, dass paketvermittelte Netzwerke nicht jenen Grad an Robustheit erreichen, der
in leitungsvermittelten Netzen herrscht.
Eine weitere Idee hinter RSVP ist der empfänger-orientierte Zugang. D. h., Empfänger sind für die
Reservierung zuständig. Dies ist deshalb sinnvoll, da bei vielen Multicast Applikationen wesentlich
mehr Empfänger als Sender existieren (z. B. Videoausstrahlung) und außerdem nicht jeder Empfänger
die selben Medien empfangen möchte.
Aufgrund von Soft State und Empfänger-Orientierung ist es einfach, Änderungen in der Reservierung
vorzunehmen: Dafür ist lediglich ein Refresh mit geänderten Anforderungen nötig.
53
Multimediakonferenzen
Sender 1
Sichere Multimediakonferenzen
PATH
R
Sender 2
R
PATH
RESV
(merged)
R
R
RESV
Empfänger 1
R
RESV
Bild 4-6:
4.6.1.
Empfänger 2
RSVP Multicast-Baum
Reservierung
Für den einfachen Fall einer Unicast-Übertragung sind zwei Schritte notwendig. Zuerst benötigt der
Empfänger die Charakteristik des Datenstroms des Senders, die sogenannte Flow Spec, um dann die
Reservierung entsprechend zu beantragen. Diese Reservierung muss in jedem Router entlang des
Übertragungspfades erfolgen. Dazu sendet der Sender eine PATH-Nachricht mit der Flow Spec zum
Empfänger. Jeder Router, der diese Nachricht erhält, merkt sich den reverse path, den die
Reservierungsanforderung später gehen wird. Nach dem Empfang der PATH-Message sendet der
Empfänger eine RESV-Message zurück mit den benötigten Anforderungen. Jeder Router entlang des
Pfades versucht die Reservierung durchzuführen und sendet die RESV-Nachricht weiter. Wenn alles
gut geht, bestehen ab nun die reservierten Ressourcen zwischen Sender und Empfänger. Solange diese
aufrecht erhalten werden sollen, sendet der Empfänger alle 30 Sekunden wieder eine RESV-Nachricht.
Auch die PATH-Messages werden periodisch ausgesendet. Wenn ein Router oder Link ausfällt, geht
die PATH-Nachricht automatisch einen anderen Weg, und ein neuer Pfad wird erzeugt, auf dem die
RESV-Nachrichten und die Daten gesendet werden. Router, die nicht mehr am Pfad liegen, erhalten
keine RESV-Nachrichten mehr und geben ihre Ressourcen frei.
Im Fall von Multicast kann es mehrere Sender und mehrere Empfänger geben (Bild 4-6). Gibt es
mehrere Empfänger und einen Sender, dann können sich die Pfade überschneiden. In diesem Fall
senden alle Empfänger ihre RESV-Messages, die sich in einem Router treffen und getrennt oder
gemeinsam behandelt werden. Verlangen z. B. zwei Empfänger die selbe Zusicherung bezüglich der
Netzwerkverzögerung, dann braucht nur eine Reservierung durchgeführt werden, wenn sie die
gleichen Daten erhalten. Bei Anfragen bezüglich Datenrate müssen die Datenraten aller Empfänger
addiert werden.
Gibt es mehrere Sender, sammeln die Empfänger die Flow Specs aller Sender und machen erst dann
ihre Reservierungs-Anfrage. Dabei wird es etwa bei einer Audiokonferenz trotz vieler Teilnehmer
ausreichen, Ressource für maximal zwei gleichzeitige Sprecher zu reservieren; mehrere Sprecher
gleichzeitig würde kaum Sinn machen.
54
Sichere Multimediakonferenzen
Windows Sockets
5. Windows Sockets
Dieses Kapitel ist eine Darstellung der Netzwerkprogrammierung unter Windows. Windows Sockets,
oder kurz WinSock, stellt einen Quasi-Standard für die Nutzung der Netzwerkdienste von Windows
und Windows NT dar. Es wird das Client/Server Modell beschrieben, das die Grundlage aller
Netzwerkprogramme darstellt. Weiters wird die Herstellung von virtuellen Verbindungen und das
Austauschen von Daten zwischen zwei Hosts erläutert, sowie verschiedene Operationsmodi und die
neuen Konzepte von WinSock 2 mit besonderem Augenmerk auf die Layered Protocol Architektur.
Ein Socket bezeichnet ein abstraktes Objekt und stellt ein Kommunikationsmedium dar, über das
Informationen über ein Netzwerk ausgetauscht werden können. Es dient als Übergabepunkt von
Applikationen an die Netzwerkdienste des Betriebssystems. Mit Hilfe von Sockets können Daten
zwischen Applikationen auf verschiedenen Hosts gesendet und empfangen werden. Jedes Socket
entspricht einer bestimmten Protokollfamilie (z. B. TCP oder UDP) und wird durch das Tupel aus IPAdresse und Port definiert.
5.1. Das WinSock-Modell
OSI Layers
WinSock Modell
7
Application
6
Presentation
5
Session
4
Transport
3
Network
2
Data link
Network Driver
1
Physical
Network Interface
Bild 5-1:
Windows
Sockets
Application
WinSock
API
Protocol Stack
(z. B.. TCP/IP)
Netzwerk
System
Windows Sockets Modell im Vergleich zum OSI Referenzmodell
Ausgehend von der OSI Struktur kann man einen Vergleich zum WinSock-Modell anstellen [QS96].
Die oberen Schichten (OSI layers 5-7) entsprechen der WinSock Applikation, darunter liegen die den
OSI Layers 1-4 entsprechenden Schichten des Netzwerk-Systems. Dazwischen liegt das Application
Programming Interface (API), das von WinSock zur Verfügung gestellt wird.
55
Windows Sockets
Sichere Multimediakonferenzen
Eine Winsock-Applikation ist typischerweise eine ausführbare Datei, kann aber auch eine DLL sein.
Beide sind in der Lage, die WinSock API einzubeziehen und die Dienste zu nutzen. Die WinSock API
(WSA) ermöglicht Zugriff auf das Netzwerk. Das Netzwerk nimmt Daten von der Applikation
entgegen. Es behandelt dabei die Daten, ohne sie in irgendeiner Weise zu interpretieren, d. h. die
Übertragung erfolgt unabhängig vom Informationsgehalt. Nicht das Netzwerk, sondern die
Applikationen tauschen Informationen aus. Für das Netzwerk erscheinen alle übergebenen
Informationen als strukturlose Datenansammlungen ohne weitere Bedeutung.
Das WinSock API ist protokoll-unabhängig. Das API darf nicht gleichgesetzt werden mit der
Protokoll-Suite, die es unterstützt. Das API gibt Zugang zu den Netzwerk-Services der Protokolle,
aber die Palette der installierten Protokolle entscheidet nicht unmittelbar über das Aussehen des API.
Verschiedene APIs können die selben Services und damit dasselbe API exportieren;
Andererseits kann ein Protokoll seine Services auch durch eine andere API anbieten – WinSock ist
nicht die einzige API für TCP/IP;
Das selbe API ist nur dann auf zwei miteinander kommunizierenden Hosts notwendig, wenn der
selbe Quellcode lauffähig sein soll.
5.2. Programm-Schema
Trotz einer Vielzahl an möglichen Netzwerk-Applikationen, die mit Hilfe von WinSock realisiert
werden können, bauen alle auf einem einfachen Schema auf [QS96, Sin96], das in diesem Abschnitt
behandelt wird. Zunächst wird das Client/Server-Modell betrachtet, das die Grundlage für die
Kommunikation mit Sockets darstellt. Daran schließt eine Beschreibung an, welche Reihenfolge von
Operationen ausgeführt wird, wenn ein TCP- oder UDP-Datenaustausch erfolgt. Die einzelnen
Schritte werden danach weiter ausgeführt.
5.2.1.
Client/Server Modell
Jede Netzwerkapplikation ist ein Kommunikations-Endpunkt. Man unterscheidet zwischen zwei Arten
von Endpunkten: Client und Server. Der Client sendet das erste Paket, der Server empfängt es. Da es
schwierig zu koordinieren wäre, brauchen nicht beide zur exakt selben Zeit ihre Aktionen setzen.
Stattdessen werden komplementäre Netzwerk-Operationen sequenziell ausgeführt:
•= Der Server startet zuerst, indem er ein Socket erzeugt und wartet;
•= Danach erzeugt der Client ein Socket und sendet damit das erste Paket in Richtung Server;
•= Nachdem der Kontakt hergestellt ist, können beide senden und empfangen.
Client-Server Assoziation
Die Sockets werden nach dem Protokoll typisiert, das sie unterstützen; Häufig anzutreffen sind
Stream-Sockets (sie unterstützen z. B. TCP) und Datagram-Sockets (z. B. UDP). Die Sockets an
beiden Endpunkten müssen vom gleichen Typ sein. Server benennen ihre Sockets, damit Clients sie
im Netzwerk lokalisieren können. Der Name besteht aus drei Teilen:
Socket-Name = (Protokoll, IP Adresse, Port),
56
Sichere Multimediakonferenzen
Windows Sockets
also z. B. (TCP, 129.27.142.140, 80) für einen Endpunkt einer HTTP Verbindung. Der Client muss
also den Namen des Servers kennen, damit der Datenaustausch initiiert werden kann.
Nach der Kontaktierung sind Client und Server assoziiert. Ein Assoziation wird aus den beiden Namen
der Endpunkte gebildet, wobei das Protokoll das selbe ist:
Assoziation = (Protokoll, Client IP Adresse, Client Port, Server IP Adresse, Server Port).
Bei TCP besteht die Assoziation von Beginn der TCP-Verbindung bis zu ihrer Terminierung, bei UDP
ist dies nicht ganz klar, da keine virtuelle Verbindung erzeugt wird; Theoretisch entsteht die
Assoziation bei jeder Datagramm-Übertragung neu.
5.2.2.
Programm-Skizze
Alle Netzwerk-Programme – sowohl Client also auch Server – führen diese fünf Schritte aus, die in
den folgenden Abschnitten näher erläutert werden:
Socket öffnen;
Socket benennen;
Mit einem anderen Socket assoziieren;
Senden/Empfangen zwischen den Sockets;
Socket schließen.
Es sind dies die selben Schritte wie für File I/O, außer dass Dateien nicht erst benannt und mit dem
System Device assoziiert werden müssen. Der Name eines Sockets wird eliminiert, wenn es
geschlossen wird.
5.2.3.
Socket öffnen
Ein Socket ist eine Software-Abstraktion, äquivalent zum Netzwerk Hardware Interface.
Applikationen können damit Zugang zum Netz erhalten. Viele Sockets können sich ein gemeinsames
Interface teilen, es besteht also eine 1:n Beziehung. Ein Socket wird mit folgendem Befehl erzeugt:
SOCKET PASCAL FAR socket(int af, int type, int protocol);
Der Rückgabewert ist ein opakes Handle zum Verweisen auf das Socket. Es ist kein bestimmter Wert
zu erwarten, außer den Fehlercode für einen Mißerfolg: INVALID_SOCKET. Die genaue Ursache für
den Fehler erhält man mittels WSAGetLastError().
af steht für die Adress-Familie, type für den Protokolltyp (AF_INET für die TCP/IP Suite) und
protocol wählt ein Protokoll aus der Protokoll-Suite.
5.2.4.
Socket benennen
Ein Server muss seine Sockets benennen, damit Clients sie lokalisieren können. Die Namensattribute –
Protokoll, Adresse, Port – spiegeln sich in der sockaddr_in Struktur wider. Es handelt sich um eine
zentrale Datenstruktur, die für mehrere Socket Kommandos verwendet wird:
57
Windows Sockets
struct sockaddr_in {
short
u_short
struct
char
};
Sichere Multimediakonferenzen
sin_family;
sin_port;
in_addr sin_addr;
sin_zero[8];
/* adress family (AF_INET) */
/* port (service) Nummer */
/* IP Adresse (32-bit) */
/* Padding, unbenutzt */
Wenn der Server ein Socket benennt, wird in sin_addr die lokale IP Adresse eingetragen. Das Makro
INADDR_ANY sorgt für eine automatische Zuweisung der lokalen Adresse, selbst bei mehreren
Interfaces. Das angebotene Service kommt in das Feld sin_port. Das Kommando bind() weist den
Inhalt der sockaddr_in Struktur dem Socket zu:
int PASCAL FAR bind (SOCKET s, struct sockaddr FAR *addr, int namelen);
Das bind()-Kommando akzeptiert die protokoll-unabhängige Struktur sockaddr, um nicht auf eine
Adress-Familie eingeschränkt zu sein. Die allgemein übliche Praxis ist, die sockaddr_in-Struktur
mittels Typecast in den Typ sockaddr überzuführen. Beide Strukturen haben die selbe Länge, die
mittels namelen (in Bytes) spezifiziert wird. Return Value ist entweder SOCKET_ERROR oder der
Wert 0, der dem Makro NOERROR entspricht.
Bei Clients ist die Benennung optional. Obwohl jedes Socket einen eindeutigen Namen benötigt,
brauchen Clients ihre Sockets nicht explizit zu benennen. Die implizite Zuweisung bei der Assoziation
(connect() bei TCP, sendto() bei UDP) ist üblich und ratsam, denn dadurch entstehen keine Konflikte
bei der Vergabe von Portnummern.
In jedem Fall ist der Name später mit getsockname() abrufbar. Die Namensgebung ist einmalig; Bei
einem wiederholten Versuch resultiert eine Fehlermeldung.
5.2.5.
Socket-Assoziation
Die Assoziation ist gekennzeichnet durch die Kombination zweier Socket-Namen. Sie erfolgt in drei
Schritten:
TCP
UDP
Vorbereitung des Servers
listen()
dispatch recv() oder select()
Client initiiert Assoziation
connect()
sendto()
Server vollendet Assoziation
accept()
complete recv()
Szenario UDP
Die Assoziation erfolgt während des Sendens bzw. Empfanges des ersten Datenpaketes. Der Server
startet recv() oder recvfrom() und wartet darauf, bis Daten von einem Client ankommen. Der Client
sendet mittels send() oder sendto() und der Server kann die Daten empfangen. Damit sind die Sockets
assoziiert.
58
Sichere Multimediakonferenzen
Windows Sockets
Szenario TCP
Der Server hat ein explizites Kommando zur Verfügung, um die Assoziation vorzubereiten. Mit der
Operation listen() geht ein Server in den Wartezustand:
int PASCAL FAR listen (SOCKET s, int backlog);
Der Parameter backlog gibt die Anzahl der Connection Requests an, die gebuffert werden sollen,
während gerade andere Verbindungen behandelt werden. Er liegt zwischen 1 und 5. Das Socket s wird
in den Wartezustand versetzt. Connection Requests werden mit select() oder accept() erkannt. Der
Unterschied zwischen den beiden ist, dass select() lediglich den Status berichtet, während accept() die
Assoziation effektiv durchführt.
int PASCAL FAR connect (SOCKET s, struct sockaddr FAR *addr, int namelen);
Der Client initiiert den Verbindungsaufbau, indem er connect() aufruft. Wenn das Socket noch nicht
benannt wurde, wird das hiermit erledigt. Die sockaddr-Struktur beschreibt hier den Namen des
Servers. Ein häufiger Fehlercode ist 10061: WSAECONNREFUSED. Dies tritt etwa dann auf, wenn
der Server nicht aktiv ist.
SOCKET PASCAL FAR accept (SOCKET s, sockaddr FAR *addr, int FAR *addrlen);
Die Assoziation ist abgeschlossen, nachdem accept() erfolgreich ausgeführt wurde. Als Rückgabewert
erhält man ein neues Socket-Handle oder INVALID_SOCKET. Die sockaddr-Struktur wird hier nicht
vor dem Aufruf von accept() mit Werten versehen, sondern von accept() selbst. Nach der Ausführung
enthält die Struktur den Namen des Clients.
Der Socket s kann für weitere Connection Requests verwendet werden, da mit jeder neuen Verbindung
ein neues Socket generiert wird. Damit kann ein Multi-Threaded Server erstellt werden, indem für jede
neue Verbindung ein neuer Thread gestartet wird.
5.2.6.
Senden und Empfangen
Nachdem eine Assoziation aufgebaut ist, sind Client und Server gleichberechtigte Peers, das heißt
beide können jederzeit senden und empfangen. Zum Senden stehen zwei Funktionen zur Verfügung:
send() und sendto(). send() ist nur dann möglich, wenn zuvor ein connect() für dieses Socket
aufgerufen wurde, das die Default Ziel-Adresse definiert. Für TCP ist der Aufruf von connect()
obligat. sendto() erwartet einen Adress-Parameter, der das Ziel angibt, und wird häufig für UDP
Sockets verwendet.
int PASCAL FAR send (SOCKET s, const char FAR *buf, int len, int flags);
int PASCAL FAR sendto (SOCKET s, const char FAR *buf, int len, int flags,
struct sockaddr FAR *to, int tolen);
buf und len spezifizieren die Attribute des Buffers, der gesendet werden soll. Als Rückgabewert erhält
man die Anzahl der gesendeten Bytes oder die Standard-Fehlermeldung SOCKET_ERROR. Da TCP
Stream-orientiert ist, kann der Rückgabewert durchaus kleiner sein als die Buffergröße und die
restlichen Bytes werden später gesendet. UDP hingegen bricht mit einer Fehlermeldung ab, wenn
nicht die gesamte Message zugestellt werden kann.
59
Windows Sockets
Sichere Multimediakonferenzen
Generell heißt eine erfolgreiche Ausführung lediglich, dass die Daten an den Protokoll-Stack
weitergegeben werden konnten – die Buffer waren also groß genug. Es heißt aber nicht, dass sie am
Socket des Peers ankommen.
int PASCAL FAR recv (SOCKET s, char FAR *buf, int len, int flags);
int PASCAL FAR recvfrom (SOCKET s, char FAR *buf, int len, int flags,
struct sockaddr FAR *from, int fromlen);
Zum Empfangen gibt es wieder ein Funktionen-Paar. Die beiden unterscheiden sich lediglich im
zusätzlichen Buffer from und seiner Längenangabe. from enthält Angaben über den Sender, nachdem
die Operation erfolgreich abgeschlossen wurde. Als Rückgabewert gibt es wieder die Anzahl an Bytes
der erfolgten Transaktion, in diesem Fall die Größe des eingegangenen Datenblocks.
Die Verfügbarkeit von Daten wird mit select() oder WSAAsyncSelect() festgestellt. Die asynchrone
Variante veranlasst das Windows-System, eine Nachricht zu senden, sobald Daten darauf warten,
abgeholt zu werden.
So wie send() kann auch recv() nur auf „connected“ Sockets angewendet werden. Der Aufruf von
connect() hat für recv() die Funktion eines Filters. IP Pakete, bei denen nicht IP Adresse und Port
übereinstimmen, werden vom Protokoll-Stack verworfen.
Socket Demultiplexing
Das Socket-Handle erscheint in den Paketen nicht selbst. Es ist also ein Verfahren notwendig, die die
ankommenden Pakete dem richtigen Socket und damit dem gewünschten Empfänger zuordnet. Das
geschieht über das 5-Tupel der Assoziation (Protokoll, IP Source Adresse, Source Port, IP Dest
Adresse, Dest Port), das in jedem Paket in den Headern von IP und TCP bzw. UDP zu finden ist; Die
IP Adressen finden sich im IP Header, die Ports im TCP/UDP Header.
5.2.7.
Socket schließen
Zum Schließen eines Sockets gibt es zwei Kommandos. Das Schließen eines Sockets läuft im
allgemeinen in zwei Schritten ab. Zunächst teilt man die Absicht mit, ein Socket zu schließen. Dies
erfolgt mit dem Kommando shutdown(). Damit beendet man die eigene Datenübertragung und und
wartet darauf, dass eventuell noch im Umlauf befindliche Daten ankommen. Wenn alle Daten
empfangen wurden, werden die Ressourcen des Sockets durch den Befehl closesocket() freigegeben.
Der Syntax der beiden Operationen ist:
int PASCAL FAR shutdown (SOCKET s, int how);
int PASCAL FAR closesocket (SOCKET s);
60
Sichere Multimediakonferenzen
Windows Sockets
Client
Server
socket()
socket()
initialisiere sockaddr_in mit Server Namen
initialisiere sockaddr_in mit lokalem Namen
bind()
listen()
connect()
accept()
/* Assoziation erzeugt – beide Seiten können senden und empfangen */
send()
recv()
recv()
send()
closesocket()
closesocket()
/* connected Socket */
closesocket()
/* Listener-Socket */
Bild 5-2:
Verbindungsorientierte Netzwerk-Programme (TCP)
Für den how Parameter von shutdown() können drei Werte eingesetzt werden. Diese Werte
beeinflussen die Art, wie die Schließung des Socktes initiiert wird. Man spricht von einem graceful
shutdown, wenn zuerst noch im Umlauf befindliche Daten empfangen werden, bevor das Socket
terminiert wird.
0: Empfangen ab sofort unterbunden
1: Senden unterbunden
2: Beides
Ein graceful shutdown erreicht man bei Verwendung von how = 1. Bei dieser Variante wird ein
TCP FIN an den Peer gesendet, das diesem mitteilt, dass keine Pakete mehr zu erwarten sind. Das
Empfangen für den Initiator des shutdown() ist aber weiterhin möglich. Es sollen noch alle Daten
empfangen werden, die im Umlauf sind – das sind jene Pakete, die die Gegenseite gesendet hat, bevor
die Nachricht TCP FIN erhalten wurde. Danach ist der korrekte Zeitpunkt, das Socket freizugeben.
Mit how = 0 ist ein graceful shutdown nicht möglich, da ein Empfangen von im Umlauf befindlichen
Daten nicht mehr möglich ist. Außerdem bekommt der Sender keine direkte Information, dass sein
Gegenüber keine Daten mehr entgegennimmt.
Mit how = 2 gibt man die Möglichkeit des graceful shutdown ebenfalls aus der Hand, da keine Pakete
empfangen werden können. Aber immerhin wird die Gegenseite benachrichtigt. Sollte es sich also um
einen unidirektionalen Datenaustausch handeln, ist diese Option die richtige Wahl.
61
Windows Sockets
5.2.8.
Sichere Multimediakonferenzen
Skizzen für TCP und UDP
Das Zusammenspiel der bisher beschriebenen Operationen lässt sich am anschaulichsten mit Hilfe von
einfachen Skizzen zeigen. Es gibt nicht die eine Skizze, die für alle Fälle gilt, denn dafür sind Stream(siehe Bild 5-2) und Datagramm-Service (siehe Bild 5-3 und Bild 5-4) zu unterschiedlich.
Client
Server
socket()
socket()
initialisiere sockaddr_in mit Server Namen
initialisiere sockaddr_in mit lokalem Namen
bind()
connect()
send()
recv()
/* Assoziation erzeugt – beide Seiten können senden und empfangen */
recv()
send()
closesocket()
closesocket()
Bild 5-3:
Verbindungslose Netzwerk-Programme (UDP) – Setze den Namen des Empängers explizit
Client
Server
socket()
socket()
initialisiere sockaddr_in mit Server Namen
initialisiere sockaddr_in mit lokalem Namen
bind()
sendto()
recvfrom()
recvfrom()
sendto()
closesocket()
closesocket()
Bild 5-4:
Verbindungslose Netzwerk-Programme (UDP) – Setze den Namen des Empfänger bei jedem Datagramm
Für Datagramm-orientierte Programme gibt es die Möglichkeit, den Namen des Servers mit connect()
zu setzen. Jedes folgende send() benutzt diese Adresse als Default. Alternativ steht der sendto()
Befehlt zur Verfügung, der den Namen des Servers als Parameter übernimmt, und auch einen
eventuellen Default-Wert übertrifft. Dies ist besonders dann nützlich, wenn der Client an
unterschiedliche Server sendet.
62
Sichere Multimediakonferenzen
Windows Sockets
5.3. Operationsmodi
Sockets lassen sich in verschiedenen Modi betreiben. WinSock 1.1 unterstützt Blocking und
Nonblocking Mode. In der aktuellen Version 2.0 kommt noch der Overlapped-Modus dazu. Die
Operationsmodi erlauben die flexible Unterstützung von Applikationsbedürfnissen – je nachdem, ob
der Datendurchsatz oder die simultane Behandlung mehrerer Sockets Priorität haben. Beide
Kommandos zum Senden und beide Kommandos zum Empfangen unterstützen jeweils alle drei Modi.
5.3.1.
Blocking I/O
Diese ist die einfachste Form, I/O zu betreiben. Jedes Socket, das nicht mit dem Overlapped-Flag
erzeugt wird, befindet sich zunächst in diesem Modus. Sämtliche Sende- und Empfangsoperationen
blockieren, d. h. kehren nicht zurück, solange die Operation nicht vollständig abgeschlossen wird. Das
bedeutet, ein Thread ist während dieser Zeit im Wartezustand. Sollen mehrere Sockets bedient werden,
empfiehlt sich eine Applikation aus mehreren parallelen Threads.
5.3.2.
Nonblocking I/O
Sockets können nach ihrer Erzeugung vom Blocking in den Nonblocking Zustand versetzt werden und
umgekehrt. Dies geschieht mit dem Kommando ioctlsocket(). Im Nonblocking-Modus kehren Socket
Operationen stets unmittelbar zurück, auch wenn die Aufgabe nicht bereits vollendet werden konnte.
Dies macht sich in einem speziellen Rückgabewert bemerkbar (WSAEWOULDBLOCK), der zwar
den Status eines Fehlercodes hat, aber im Fall von nicht blockierenden Sockets keinen Fehler
diagnostiziert, sondern nur darüber informiert, dass die angeordnete Operation noch im Gang ist. Sie
wird im Hintergrund ausgeführt. Die Benachrichtigung über den Abschluss erfolgt über Events. Sie
können mit select() auf ihren Status überprüft werden. Für diese Art von Socket I/O empfiehlt sich
eine zentrale Routine, die sämtliche Events überwacht, auswertet und die entsprechenden Schritte
einleitet.
5.3.3.
Overlapped I/O
Sockets können mit dem Overlapped-Flag erzeugt werden. Ein späteres Hin- und Herwechseln
zwischen Overlapped und Non-Overlapped Status ist nicht mehr möglich. Diese Sockets blockieren
niemals.
Overlapped I/O erspart einen Kopiervorgang zwischen den Buffern von Applikation und ProtokollStack. Das Resultat ist ein besserer Durchsatz. Besonders interessant ist dieses Verfahren für
speicherintensive sowie zeitkritische Übertragungen wie etwa Ton- und Videokonferenzen. Die
Applikation gibt bei einem WSASend() oder WSARecv() Kommando seine Buffer – es kann auch mehr
als ein Buffer sein – an den Protokoll-Stack bekannt und signalisiert damit, die Buffer nicht zu stören
(zu verändern), solange die I/O Operation nicht abgeschlossen ist.
Das Ende des I/O wird durch Events oder Completion Routines angekündigt. Bei Verwendung von
Completion Routines werden diese nach Beendigung des I/O automatisch aufgerufen.
63
Windows Sockets
Sichere Multimediakonferenzen
WinSock 2
Applikation
WinSock 2
Applikation
WinSock 2 API
WinSock 2 DLL
WS2-32.DLL (32 Bit)
WinSock 2
Transport SPI
WinSock 2
Name Space SPI
Transport
Service
Provider
Bild 5-5:
Transport
Service
Provider
Name
Space
Service
Provider
Name
Space
Service
Provider
Windows Sockets 2 Struktur als WOSA-Komponente in Windows
5.4. Service Provider Interface
In der Version 2 von Windows Sockets wurde eine neue Architektur eingeführt. Bestand die
WinSock 1.1 Implementierung lediglich aus einer DLL, die die API-Funktionen exportierte, handelt es
sich nun um eine Struktur nach dem Vorbild von WOSA (Windows Open Services Architecture), wie
in [SPI97] erläutert wird.
Diese neue Architektur öffnet neue Möglichkeiten zur Erweiterung der Dienste von WinSock um
beliebige Nerzwerkdienste. Eine eigene Schnittstelle, das Service Provider Interface, steht in
WinSock 2 zur Verfügung und erlaubt es, Zugang zu den Daten zu erlangen, die von
Netzwerkapplikationen gesendet und empfangen werden. Damit können diese Daten in gewünschter
Weise bearbeitet werden. Im Fall eines Security Service Providers können die Daten auf dem Rechner
des Senders verschlüsselt und auf dem Rechner des Empfängers wieder entschlüsselt werden. Die
Architektur nach WOSA bietet somit äußert gute Voraussetzungen, um einen Netzwerkdienst
anzubieten. In diesem Abschnitt wird zunächst genauer auf die Architektur eingegangen. Die
einzelnen Aspekte der Einbindung eines Dienstes in das WinSock-System folgt darauf. Dazu wird
unter anderem die Aufgabenteilung zwischen den einzelnen Komponenten der WOSA-Architektur
analysiert.
5.4.1.
WinSock 2 als WOSA
Beim WOSA-Standard (Windows Open Services Architecture) handelt es sich um ein Set von
Interfaces für Front End Applikationen und Back End Services. Applikationen und Services brauchen
64
Sichere Multimediakonferenzen
Windows Sockets
API
WinSock 2 DLL
SPI
Layered Protocol
SPI
Layered Protocol
SPI
Base Protocol
Bild 5-6:
Layered Protocol Archtitektur
nicht direkt mit einander kommunizieren, denn dazwischen liegt eine zentrale Komponente, die als
Bindeglied fungiert. Diese Architektur ist in Bild 5-5 dargestellt und erlaubt die Kombination von
beliebigen Applikationen mit beliebigen Services. Beide können unabhängig weiterentwickelt werden.
So wie viele andere WOSA kompatible Komponenten nutzt auch WinSock 2 die Möglichkeiten von
DLLs. Damit ist es möglich, dass Applikationen die erforderlichen Services erst bei ihrer Ausführung
(Runtime) binden. Die Applikation braucht jedoch nur das exportierte Interface des Services kennen,
nicht dessen Implementierung.
Die WOSA kompatible WinSock 2 Architektur besteht aus Application Programming Interface (API),
Service Provider Interface (SPI) und der zentralen WinSock 2 DLL (ws2_32.dll). Es gibt zwei Arten
von Service Providern: Transport Service Provider (Datenübertragung) und Name Space Service
Provider (Interface mapping z. B. zu DNS). Beide müssen registriert und damit ins Windows System
eingebunden werden, damit sie aktiv sein können. Sie bleiben so lange registriert, bis sie explizit
abgemeldet werden, also auch nach einem System-Neustart. Die Liste der installierten Service
Provider kann von Applikationen abgerufen und durchgesehen werden. Hier sollen nur Transport
Provider diskutiert werden, weitere Informationen zu Name Space Provider finden sich in [SPI97].
5.4.2.
Interface Modell
Transport Service Provider sind DLLs mit nur einer exportierten Funktion: WSPStartup(). Wenn diese
Funktion von der WinSock 2 DLL aufgerufen wird, enthält sie als Parameter die Dispatch Table mit
den Adressen der Funktionen des darunter liegenden Providers. Der Service Provider behält sich eine
Kopie und überschreibt die Einträge der Funktionen, die der Service Provider selbst anbietet.
Einerseits dient der Tabellenaustausch dazu, der WinSock 2 DLL die Einsprungadressen des Service
Providers mitzuteilen (z. B. für WSPSend()). Die WinSock 2 DLL leitet dann API-Calls (z. B. send())
an den Service Provider weiter anstatt direkt an den Base Provider. Andererseits gibt es auch Upcalls
vom Service Provider zur DLL (z. B. WPUCompleteOverlappedRequest(), deren Adressen der Service
Provider benötigt.
65
Windows Sockets
Sichere Multimediakonferenzen
Im Zusammenhang mit den Funktionen treten folgende Präfixe auf:
WSA (WinSock API) – Funktionen, die zum WinSock API gehören
WSP (WinSock Service Provider) – Transport Service Provider-Einstiegspunkte
WPU (WinSock Provider Upcall) - WinSock 2 DLL-Funktionen für Service Provider
WSC (WinSock Configuration) – WinSock 2 DLL-Funktionen zur Installation
NSP (Name Space Provider) – Einstiegspunkte für Name Space Provider
5.4.3.
Layered Service Provider
Wie in Bild 5-6 zu sehen ist, besteht die Layered Protokoll-Architektur von WinSock 2 neben der
WinSock 2 DLL aus einem Base Provider und einer beliebigen Anzahl an Layern, die dazwischen
installiert werden können. Um die Architektur zu organisieren, gibt es das Konzept der Protocol
Chain, einer Verkettung von ein oder mehreren Layered Protokollen mit dem Basis-Protokoll. Der
Base Provider ist z. B. der TCP/IP Stack, der Stream und Datagramm Dienste anbietet.
Das Layered Protocol nutzt den darunter liegenden Transport Stack für den Datenaustausch und
implementiert ein Service, z. B. ein Security Layer mit Authentifizierung und Verschlüsselung. Es
exportiert das selbe SPI wie der Base Provider und kann zwischen WinSock 2 DLL und Base Provider
installiert werden, ohne dass eine Anwendung davon etwas weiß. Damit ist also ein anwendungsunabhängiges Security-Layer möglich, das sämtlich Daten während der Übertragung sichert.
5.4.4.
Aufgabenteilung
Die WinSock 2 DLL kümmert sich um die Organisation des Netzwerkverkehrs: der Zuordnung von
Datenströmen zu Sockets und zum entsprechenden Service Provider. Die Service Provider
implementieren gemeinsam mit den Base Providern die Low-Level Netzwerk-Protokolle. Die
WinSock 2 DLL ist damit das Verbindungsstück zwischen Applikationen und Service Providern.
Ein Service Provider implementiert ein Transport-Protokoll und erledigt damit Verbindungs-Setup,
Datenübertragung, Flusskontrolle, Fehlerkontrolle und anderes mehr. Die WinSock 2 DLL hat keine
Kenntnis darüber, wie Services implementiert werden, diese Details werden versteckt.
Die WinSock 2 DLL ist hauptsächlich „Traffic Manager“ zwischen Service Provider und Applikation.
Die Auswahl eines Service Providers erfolgt aufgrund der Parameter des socket() Calls, nämlich durch
Übereinstimmung des Tupels (Adressfamilie, Socket Type, Protokoll) mit den Eigenschaften des
Service Providers. Der ausgewählte Service Provider wird dem Socket für nachfolgende Calls
zugeordnet (z. B. send()). Bei einem API Call der Applikation wird von der WinSock 2 DLL die
entsprechende Funktion des Service Providers aufgerufen.
Daneben bietet die WinSock 2 DLL einige Dienste für Applikationen und Service Provider an:
Byte Swapping zwischen Netzwerk und Host Byte Order
Queuing von asymmetrischen Completion Routines für Overlapped I/O
Versions-Verhandlungen zwischen Applikationen und WinSock 2 DLL bzw. zwischen DLL und
Service Providern
66
Sichere Multimediakonferenzen
5.4.5.
Windows Sockets
Mapping zwischen API- und SPI-Funktionen
In WinSock 1.1 hatten die API Socket-Befehle einen einfachen Syntax: socket(), send(), recv(), etc. In
WinSock 2 haben viele dieser Operationen eine erweiterte Palette an Parametern erhalten und damit
einen neuen Namen mit Präfix: WSASocket(), WSASend(), etc. Es existieren also teilweise zwei
Versionen von Befehlen, andere sind neu dazugekommen. Der Grund liegt in der erweiterten
Funktionalität vieler Socket-Befehle, z. B. der Unterstützung des Overlapped-Modus (siehe
Abschnitt 5.3.3) für Sende- und Empfangsbefehle. Dafür sind oft eine größere Zahl an Parametern für
die Socket-Befehle und damit neue Versionen der Befehle notwendig.
Auf der SPI Ebene gibt es jedoch nur eine Version von Befehlen, die das Präfix WSP trägt:
WSPSocket(), WSPSend(), etc. Sie haben dieselben Parameter wie die WSAxxx() Befehle. Auch die
WinSock 1.1 Versionen werden daher auf die erweiterten Versionen gemapped: socket() resultiert im
Aufruf von WSPSocket(). Das selbe gilt für WSASocket(). Dabei haben die gemappten Socket-Befehle
stets den Satz an Parametern der erweiterten WinSock 2-Befehle, damit eine vollständige ParameterÜbergabe gewährleistet wird.
Einige Funktionen sind nur in der WinSock 2 DLL implementiert und haben kein Gegenstück im SPI:
Byte Swapping: htons(), ntohs(), etc.
Protokoll-Aufzählung sämtlicher Service Provider: WSAEnumProtocols()
Fehlerinformation der letzten Socket-Operation: WSAGetLastError()
TCP-spezifische Konversionen: gethostbyaddr(), gethostbyname()
Daneben gibt es auch noch Funktionen, die direkt auf Services des Operationssystems abgebildet
werden. Dazu zählen Event-Management- sowie Warte-Funktionen: z. B. WSASetEvent(),
WSAWaitForMultipleEvents().
5.4.6.
Installation
Es ist eine Eintragung in die Configuration Database von WinSock 2 notwendig, damit ein Service
Provider aktiviert werden kann. Die WinSock 2 DLL exportiert eine Installations-Funktion
(WSCInstallProvider()), die der Hersteller des Service Providers in einem eigenen
Installationsprogramm aufrufen kann, um den Service Provider zu registrieren. Dabei wird eine Liste
von Service bzw. Base Providern verlangt, die dieser Service Provider unterstützt. Als Gegenstück
existiert die Funktion WSCDeinstallProvider(), wodurch die Informationen aus der Datenbank entfernt
werden.
Entscheidend dafür, dass der installierte Service Provider auch den entsprechenden Applikationen
zugeordnet wird, ist die Reihenfolge, in der die einzelnen Service Provider in der WinSock 2 DLL
erscheinen, denn der erste passende Service Provider wird gewählt. Ein Service Provider, der auf
TCP/IP aufsetzt, sollte also vor dem TCP/IP Base Provider selbst erscheinen. Eine Änderung der
Reihenfolge ist mit Hilfe von sporder.dll und sporder.exe möglich.
67
Windows Sockets
Sichere Multimediakonferenzen
Der Parameter ChainLen steuert, ob ein Base Provider, ein Layered Protocol oder eine Protocol Chain
registriert wird:
0: Layered Protocol
1: Base Protocol – oder Kette mit nur einem Element
2: Protocol Chain
Zuerst werden alle Layered Protokolle und Base Provider ins System eingefügt, danach die Ketten, die
sich aus diesen zusammensetzen. Eine Kette listet alle Provider auf, aus der sie besteht. Das Element 0
entspricht dem ersten Provider, z. B. die des Security Services. Das nächste Element ist der darunter
liegenden Provider, z. B. TCP. Es ist nicht möglich, in einer Kette einen Provider mehrmals zu
instanzieren.
68
Sichere Multimediakonferenzen
Benutzung des RLSP
6. Benutzung des RLSP
Im praktischen Teil der Diplomarbeit sollte eine Möglichkeit gefunden werden,
Sicherheitsmechanismen für den Einsatz mit Multimedia-Konferenzsystemen zu finden. Das Ergebnis
ist eine dynamische Bibliothek, die in das Windows-System eingebunden werden kann und
applikationsunabhängig eine mit SSL kryptographisch gesicherte Verbindung zwischen Hosts im
Netzwerk bereitstellt. Das folgende Kapitel erläutert die Motivation und den Einsatz dieses
Sicherheitsmechanismus.
6.1. Aufgabenstellung
Ausgangspunkt war, eine Möglichkeit zu finden, dass Teilnehmer einer Videokonferenz über
Instrumente verfügen, sich gegenseitig zu authentifizieren sowie einen gesicherten Datenaustausch zu
gewährleisten, sodass Integrität und Vertraulichkeit gewahrt bleiben. Dazu galt es, einen
entsprechenden Zugang zu wählen. Einerseits kann man sich an den verwendeten Protokollen
orientieren, die hinter den verbreiteten Videokonferenzsystemen stecken, und davon ausgehend
Authentifizierungs- und Verschlüsselungsmaßnahmen implementieren. Hier gibt es mehrere
Schwierigkeiten: Zunächst muss man festhalten, dass es zwar Standards gibt, diese aber von
verschiedener Herstellern auch verschieden interpretiert werden. Dazu kommt, dass Standards sich
stets weiterentwickeln. Das bedeutet, dass eine regelmäßige Anpassung der Sicherheitslösung erfolgen
müsste.
Andererseits kann man bestimmte Kombinationen von IP-Adressen und Portnummern heranziehen,
die vom Benutzer spezifiziert werden, und auf diese Kanäle die Sicherheitsmechanismen anwenden.
Dies hat den entscheidenden Vorteil, unabhängig von Applikationen und Protokollen zu sein. Man ist
also nicht auf Multimediakonferenzen beschränkt, sondern kann auch andere Netzwerkapplikationen
wie etwa FTP und VNC mit einem Sicherheitsdienst unterstützen.
Von Beginn an war es eine klare Anforderung, dass für die Applikationen selbst keine Änderungen
entstehen dürfen. Das heißt insbesondere, dass für sie nach Einbeziehung des Sicherheitsdienstes die
Verbindungen, die zwischen Hosts aufgebaut werden, exakt die selben sind wie sie es ohne
Verschlüsselung sind. Dies bedeutet, dass bei Verwendung zusätzlicher Verbindungen diese in Form
von Tunneling erfolgen und die von den Applikationen zwischen Sender und Empfänger initiierte
Verbindung beim Empfänger wieder aufgelöst werden muss, sodass aus seiner Sicht alles beim alten
bleibt. Sender- und Empfänger-Applikation wissen also gar nicht, dass ihre Daten auf sicherem Weg
übertragen werden.
69
Benutzung des RLSP
Sender
Host A
Bild 6-1:
RLSP:
Redirect?
Ja Nein
Proxytunnel
Client
Sichere Multimediakonferenzen
Empfänger
Backrouter
Proxytunnel
Server
Host B
Funktionsweise des RLSP
6.2. Funktionsweise
Eine weitere Entscheidung musste gefällt werden: Welches Security-Protokoll soll eingesetzt werden?
Die Wahl fiel auf den Proxytunnel des Instituts, der SSL verwendet. Eine Alternative war Open SSL,
das als Bibliothek frei verfügbar ist. Die Kommunikation mit dem Proxytunnel erfolgt über TCPVerbindungen. Das bedeutet als Konsequenz, dass aus einer Verbindung zwischen Sender um
Empfänger mehrere werden. Zuerst eine Verbindung zum Proxytunnel-Client, die nächste zum
Proxytunnel-Server des Empfängers und die dritte zur Applikation des Empfängers.
Als hilfreich erwies sich das Layered Service Provider Konzept von Windows Sockets. Dieses
ermöglicht es, einen Security Service auf einer Ebene zu implementieren, die ohne jegliche
Änderungen an den Applikationen auskommt. Dabei wird das Security Service in Form einer
dynamischen Bibliothek (DLL) in das Windows System eingebunden. Danach wird der
Netzwerkverkehr dieses Hosts von WinSock an die DLL übergeben, die die Daten verschlüsseln kann,
bevor sie ins Netzwerk gelangen. Dies geschieht, indem die Daten zum Proxytunnel gesendet werden.
Aufgrund des Umleitens der Daten mit Hilfe eines Layered Service Providers ist der Name des
Security-Dienstes RLSP.DLL.
Das Schaltbild in Bild 6-1 verdeutlicht den Systemzusammenhang. Die Netzwerkdaten der
Applikation durchlaufen den RLSP-Client. Dieser entscheidet aufgrund von Benutzerwünschen, ob die
Daten über den SSL-Kanal laufen sollen. Ist dies der Fall, werden die Daten zum Proxytunnel-Client
umgeleitet. Dies setzt voraus, dass am Host des Empfängers RLSP im Server-Modus und ProxytunnelServer installiert sind. Nachdem die Daten wieder entschlüsselt wurden, ist es noch notwendig, den
Status der Verbindung gegenüber der Applikation wiederherzustellen, damit die Applikation am
Empfänger weiß, dass die Verbindung vom Host A kommt und nicht vom eigenen Host. Dies wird im
Backrouter erledigt.
Die Verwendung von SSL hat zur Folge, dass vom Proxytunnel nur TCP Verbindungen angenommen
werden. Das bedeutet, dass TCP Verkehr zwar einfach zum Proxytunnel umgeleitet werden kann, dass
für UDP aber ein Mapping auf TCP erfolgen muss. UDP Messages werden also für die SSL
Übertragung in TCP Segmente verpackt und am Empfänger wieder zurückgewandelt. Dabei ist zu
beachten, dass UDP byte-orientiert, TCP aber stream-orientiert ist. Während TCP Datenströme Byte
für Byte betrachtet und Datenblöcke während der Übertragung eventuell fragmentiert, erwartet ein
70
Sichere Multimediakonferenzen
Benutzung des RLSP
App:
App:
"connect to a.b.c.d:x"
"Accept"
x
Daten
Daten
RLSP
RLSP
x
C1 C2 Info
Daten
Info
30001
1111
Proxytunnel
C2 Info
Bild 6-2:
Daten
Proxytunnel
Daten
Szenario TCP: Informationsfluss
UDP-Empfänger die Messages unfragmentiert. Andernfalls verwirft der UDP-Empfänger die
ankommenden Daten als fehlerhaft. Auf der Empfängerseite wurde daher ein Ringbuffer
implementiert, der Messages in ihre originale Gestalt bringt, bevor sie die Applikation erreichen.
6.2.1.
Szenario TCP
Dieses Szenario zeigt die notwendigen Schritte, die vom RLSP ausgeführt werden, um die Verbindung
über den Proxytunnel umzuleiten. Für diesen Zweck wurde eine Modifikation des Proxytunnel
vorgenommen, das eine Ansteuerung des Proxytunnels mit Zielinformationen erlaubt. Das heißt, die
Adresse des Proxytunnel-Servers stehen nicht wie sonst üblich in der ‚client.ini’ Datei des
Proxytunnel-Clients, sondern diese Informationen werden dem Proxytunnel-Client über TCP
mitgeteilt. Das ermöglicht einen sehr flexiblen Einsatz und hilft, die Anzahl der entstehenden
Verbindungen einzuschränken. Ohne diese Eigenschaft wäre es notwendig, eine Verbindung vom
Proxytunnel-Client zurück zum RLSP zu erzeugen, bevor die Verbindung zum Target-Host erfolgen
kann. Dort erfolgt das selbe Spiel: Der Proxytunnel-Server wird ebenfalls mit Informationen versorgt,
unter welcher Adresse und welchem Port der Backrouter bzw. die Applikation erreichbar ist.
Bild 6-2 zeigt, wie der Informationsfluss abläuft. Der RLSP-Client erzeugt die Kontrolldaten, die die
beiden Proxytunnel und der RLSP-Server benötigen, um die umgeleitete Verbindung zu erzeugen.
D. h. bevor die Applikationsdaten gesendet werden, werden Connect-Daten (C1 und C2) für die
beiden Proxytunnel sowie der Infoblock für den RLSP-Server gesendet. Jede dieser Einheiten liest die
für ihn bestimmten Informationen und sendet die restlichen Daten weiter. Die Connect-Daten
enthalten je eine vollständige Transport-Adresse (IP Adresse und Port). Der Infoblock beschreibt die
gesamte Verbindung (IP Adressen und Ports von Sender und Empfänger) sowie den Typ der
Verbindung (TCP oder UDP).
Zusätzlich sind in der Abbildung auch die während der Entwicklung benutzten Ports eingezeichnet.
Diese sind über die Initialisierungsdatei RLSP.INI einstellbar. Es handelt sich um einen Port für die
Kommunikation zwischen RLSP-Client und Proxytunnel-Client (SSL-Client-Port) sowie einen Port
für die Kommunikation zwischen den beiden Proxytunnel, der die verschlüsselte Verbindung
71
Benutzung des RLSP
Sichere Multimediakonferenzen
App:
App:
"connect to a.b.c.d:x"
"Accept"
x
RLSP
RLSP:
UDP->TCP
x
TcpUdpMapper
(Ringbuffer)
30001
Proxytunnel
Bild 6-3:
1111
Proxytunnel
x +Offset
Szenario UDP mit Mapping zwischen Udp und Tcp
repräsentiert (Safe Port). Die Portnummern müssen jeweils beiden Partnern bekannt sein. Der
Proxytunnel-Server baut seine Verbindung bereits zum Port der Applikation auf. Der RLSP-Server
erkennt, dass die Verbindung umgeleitet wurde und stellt aus Sicht der Applikation die ursprüngliche
Verbindung wieder her. Dies ist möglich, da der Accept()-Call vom RLSP abgefangen wird.
So wie beim Empfangen das Accept() abgefangen wird, erfolgt dies beim Senden mit connect(), wenn
der RLSP im Windows-System registriert ist. In dieser Funktion passiert also das Umleiten und das
Erzeugen der Connect-Daten und des Infoblocks. Für die Sender-Applikation scheint es, also wäre
eine Verbindung zum gewünschten Zielsocket aufgemacht worden. In Wirklichkeit wurde jedoch eine
Verbindung zum Proxytunnel erstellt.
6.2.2.
Szenario UDP
Die Umleitung erfolgt ähnlich. Allerdings werden die ausgehenden Pakete mit send() und sendto()
abgefangen. Es gibt zwar auch in UDP die Möglichkeit, connect() zu verwenden; dabei wird jedoch
keine Verbindung wie in TCP aufgebaut. Was hier also hinzukommt, ist das Mapping der UDP-Pakete
in einen TCP-Stream. Dazu ist einerseits notwendig, ein geeignetes Mapping zu finden, andererseits
die Rekonstruktion des TCP-Streams in die UDP-Messages am Empfänger.
Die Transportadresse des Empfängers (IP Adresse und Port) wird auf einen TCP-Socket gemapped.
D. h., alle Messages, die an denselben Empfänger gehen sollen, laufen über einen Kanal. Ein wichtiger
Punkt ist auch die Wahl des TCP-Ports, der für den gemappten Kanal verwendet werden sollen.
Einerseits müssen sich die Portnummern je nach Applikation unterscheiden, da sonst der
TcpUdpMapper nicht unterscheiden könnte, zu welche Applikation die Messages gehören; es kann
also nicht ein fixer Port verwendet werden. Andererseits erscheint es nicht sinnvoll, die selbe
Portnummer zu verwenden wie UDP (z. B. UDP-Port 53 auf TCP-Port 53), da es speziell in den
niederen Portbereichen zu Portkonflikten kommen kann. Deshalb wird ein Offset verwendet, um die
gemappten TCP-Kanäle in den oberen Bereichen (z. B. ab Port 40000) anzuordnen. Der
TcpUdpMapper ist ein Thread, der für jeden erwarteten Port am Empfänger gestartet wird und der sich
dann nur um diesen Port kümmern braucht.
72
Sichere Multimediakonferenzen
Benutzung des RLSP
Zur Rekonstruktion der Messages wurde ein Ringbuffer implementiert. Dieser liest jeweils den TCPStream solange ein, bis alle Bytes eingetroffen sind, die zur Message gehören. Dazu wertet der
TcpUdpMapper den Infoblock aus, denn dieser enthält Angaben zur Größe der Message. Das Mapping
zwischen UDP und TCP hat auch zur Folge, dass ein größerer Kommunikationsaufwand betrieben
werden muss: Neben den drei TCP-Verbindungen RLSP-Proxytunnel, Proxytunnel-Proxytunnel und
Proxytunnel-TcpUdpMapper müssen die Daten noch einmal den UDP-Stack durchlaufen, wenn sie
vom TcpUdpMapper zur Applikation gesendet werden.
6.3. Komponenten
Das gesamte System zur sicheren Übertragung zwischen Netzwerkapplikationen setzt sich aus einer
Reihe von Komponenten zusammen. Ausgehend vom Proxytunnel und seinen Initialisierungsdateien
wird diese Infrastruktur durch den RLSP erweitert, der das Verbindungsmanagement übernimmt,
sodass sich Applikationen nicht mehr um die Anbindung an den Proxytunnel kümmern brauchen. Der
RLSP ist über die Steuerdatei RLSP.INI konfigurierbar, in der unter anderem die IP:Port-Paare
spezifiziert werden können, die umgeleitet werden sollen. Die An- und Abmeldung des RLSP erfolgt
mit dem Installer, der wahlweise eine graphische Oberfläche anbietet oder von der Kommandozeile
aus aufrufbar ist. Schließlich steht ein Monitor zur Verfügung, der Informationen zu umgeleiteten
Verbindungen protokolliert.
6.3.1.
RLSP
Der RLSP ist die zentrale Steuereinheit, die den Netzwerkverkehr auf Wunsch umleitet und auf Seite
des Empfängers wieder entgegennimmt. Er fängt Socket-Calls ab, wenn er registriert ist. Im Fall von
TCP sind das in erster Linie connect() und accept(), die für den Verbindungsaufbau verantwortlich
sind.
Im connect()-Call werden die Einträge in der RLSP.INI geprüft, ob eine Umleitung für den Peer der
aufzubauenden Verbindung gewünscht ist. Wenn das nicht der Fall ist, greift der RLSP nicht weiter in
ein. Es ändert sich also nichts an der Verbindung. Wenn eine Umleitung erwünscht ist, wird der
connect()-Call des Base Providers mit anderen Parametern für IP-Adresse und Port aufgerufen.
Im accept() prüft der RLSP ebenso die Einträge der RLSP.INI-Datei, um zu erfahren, ob die
eingehende Verbindung umgeleitet wurde. Ist das nämlich der Fall, wird vor den eigentlichen Daten
noch der Infoblock empfangen. Damit kann dann die effektive Verbindung zwischen Source und
Destination wieder hergestellt werden.
Wenn UDP-Messages gesendet werden, sind es die Sende- und Empfangsfunktionen, in denen die
Umleitung erfolgt. UDP-Messages werden entweder mit sendto() gesendet oder mit der Kombination
aus connect() und send(). connect() legt dabei das Default-Ziel fest, das für folgende send()Kommandos gilt. In jedem Fall erfolgt die Umleitung im sendto(), denn auch das abgefangene send()
ruft sendto() auf. Dort wird, wenn in der RLSP.INI gewünscht, aus der UDP Message eine TCPVerbindung erzeugt, die dann über die beiden Proxytunnel und den TcpUdpMapper den Server-RLSP
erreicht.
73
Benutzung des RLSP
Sichere Multimediakonferenzen
Im Gegensatz zu TCP wird bei UDP kein accept() verwendet. Die Identifikation des Senders erfolgt in
recvfrom(). Hier hat der Server-RLSP also darauf acht zu geben, den effektiven Sender zu ermitteln
und diesen entsprechend zurückzuliefern. Auch für das Empfangen von Messages gibt es eine zweite
Funktion, nämlich recv(). In beiden Fällen wird der Infoblock empfangen, der Informationen über die
Verbindung beinhaltet. Diese Informationen sind auch über getpeername(), das ebenfalls vom RLSP
abgefangen wird, später abrufbar.
6.3.2.
RLSP.INI
Die Datei RLSP.INI ermöglicht die Konfiguration des Systems. Es setzt sich aus mehreren Sektionen
zusammen: Zuerst gibt es einen allgemeinen Teil (Configuration). Danach folgen jeweils eine Sektion
für jeden Proxytunnel, der verwendet wird. Anschließend folgen die beiden Teile für TCP, nämlich für
eingehende und ausgehende Verbindungen. Zum Schluss gibt es noch die selben beiden Sektionen für
UDP.
[Configuration]
Hier stehen allgemeine Parameter, die UDP und TCP ein- oder ausschalten und steuern, ob diese
Instanz des RLSP ein Client, ein Server oder beides sein soll. Zusätzlich werden die Ports spezifiziert,
die für eine sichere Übertragung verwendet werden sollen: Im Fall von TCP der SafePort, im Fall von
UDP ein Offset, der zum UDP-Port addiert wird und damit den verwendeten TCP-Port ergibt.
Ausserdem hat man noch die Möglichkeit, zu entscheiden, ob ein Logging durch einen Monitor
erfolgen soll und wo sich dieser im Netzwerk befindet. Schließlich gibt es noch einen Eintrag zum
Festlegen der IP-Adresse des lokalen Host. Dies hat Bedeutung, wenn mehrere Interfaces am Host
präsent sind, denn damit kann eines auswählt werden. Die Auswahl kann händisch oder mit der
graphischen Version des Installers erfolgen, der die Auswahl dann in die RLSP.INI-Datei schreibt.
Client_Enabled = true | false
Server_Enabled = true | false
UDP_Enabled = true | false
TCP_Enabled = true | false
SafePort = 40000
UDP_Port_Offset = 10000
Monitor = on | off
Monitor_Host = 127.0.0.1
Monitor_Port = 5051
Localhost=129.27.142.140
Die angegebenen Zahlenwerte sind Beispielwerte. Sinnvoll ist es, Ports stets über 10000 zu wählen.
Ports zwischen 0 und 1023 sind die sogenannten well-known ports, die in der Regel von
Systemprozessen verwendet werden. Danach folgen die registrierten Portnummern, die von
Herstellern angemeldet werden können. Die registrierten Ports liegen zwischen 1024 und 65535,
erstrecken sich also bis zum Ende des Portraums. Beinahe alle registrierten Ports liegen jedoch im
Bereich unter 10000, deshalb sind die Möglichkeiten für Konflikte für Ports größer als 10000 geringer.
74
Sichere Multimediakonferenzen
Benutzung des RLSP
Wenn UDP bzw. TCP deaktiviert werden, werden die Einträge in den UDP- bzw. TCP-Sektionen
nicht berücksichtigt. Dasselbe gilt für Client- und Server-Aktivierung. Hier werden die jeweiligen
Incoming- bzw. Outgoing-Sektionen nur dann ausgelesen, wenn sie aktiviert wurden.
[Proxytunnel]
Es kann mehrere Proxytunnel-Einträge geben. Diese Einträge werden dann in den Outgoing-Sektionen
für TCP und UDP angeführt. Zwei Beispiele:
[pille]
host = 129.27.142.148
port = 30001
[Home]
host=127.0.0.1
port=30001
Der Proxytunnel-Client muss sich nicht am selben Host befinden wie die Applikation selbst. Host und
Port spezifizieren die Transportadresse des Proxytunnels. Entweder wird die IP-Adresse eingegeben,
oder das Kürzel für den Localhost (127.0.0.1). Die letztere Schreibweise hat den Vorteil, dass sie nicht
adaptiert werden muss, wenn der RLSP und der Proxytunnel auf einem anderen Rechner gestartet
werden.
[TCP Outgoing], [UDP Outgoing]
Hier wird angegeben, welche Verbindungen verschlüsselt werden sollen. Der Syntax ist für die TCPund UDP-Sektionen gleich. Einige Beispiele:
129.27.142.229:* = Home
129.27.142.229:23 = pille
129.27.*:* = Home
129.27.142.229:23-25 = Home
129.27.142.229:23 = –
; alle Verbindungen zum Host 129.27.142.229
; Verbindungen auf Port 23 zu 129.27.142.229
; alle Verbindungen zu Hosts mit 129.27....-Adresse
; Verbindungen auf Port 23, 24 und 25
; diese Verbindungen nicht umleiten
Es gibt die Möglichkeit, Intervalle zu spezifizieren. Man kann Bereiche von Ports spezifizieren, die
zwischen zwei Werten liegen. Außerdem kann man Wildcards (*) für Ports und IP-Adressen
verwenden. Schließlich kann man auch Transportadressen von der Umleitung wieder ausschließen.
Dafür wird ein Minus (–) anstatt des Namens des Proxytunnels geschrieben.
[TCP Incoming], [UDP Incoming]
Hier werden die Ports spezifiziert, die über umgeleitete Verbindungen zum Host gelangen, die also
von einem Client-RLSP über die Proxytunnel initiiert wurden. Es gelten dieselben Syntaxregeln für
die Portspezifikation wie in der vorangegangenen Beschreibung. Hier wird allerdings kein
Proxytunnel nach dem Gleichheitszeichen spezifiziert. Die Ausnahme von Ports ist aber möglich.
* =
23-25 =
24 = -
; alle Ports werden als umgeleitet interpretiert
; Port 23, 24 und 25 werden als umgeleitet interpretiert
; Port 24 wird als nicht umgeleitet interpretiert
75
Benutzung des RLSP
6.3.3.
Sichere Multimediakonferenzen
Proxytunnel
Der Proxytunnel ist ein Produkt des Instituts für Angewandte Informationsverarbeitung und wurde
plattformunabhängig in Java implementiert. Er bietet SSL-Verschlüsselung für TCP-Verbindungen.
Der Proxytunnel ist multithreaded und wartet auf konfigurierbaren Ports auf Peers, die sich über TCP
verbinden. Über die Steuerdateien client.ini und server.ini wird festgelegt, wohin die Verbindung
aufgebaut werden soll.
client.ini, server.ini
In den beiden Dateien client.ini und server.ini werden einerseits Informationen über die Zertifikate
und den zu verwendenden Cipher gemacht, andererseits werden hier die Ports und andere Parameter
für die Proxytunnel-Instanzen spezifiziert. In der Regel stehen in der client.ini Tunnel, die
unverschlüsselte Daten übernehmen und verschlüsselt versenden und in der server.ini umgekehrt.
Allerdings können beide Arten von Tunnel in beiden Dateien spezifiziert werden.
Interessant im Zusammenhang mit dem RLSP sind vor allem die Tunnelspezifikationen. Jeder Tunnel
wird zuerst deklariert:
NumTunnels=2
Tunnel.1=RlspTunnel
Tunnel.2=FTPTunnel
Später werden die einzelnen Tunnel näher parametrisiert. Hier ein Beispiel für FTP in der client.ini:
FTPTunnel.acceptHost = localhost
FTPTunnel.InPort = 21
FTPTunnel.InputUsesSSL = false
FTPTunnel.connectHost = 129.27.142.229
FTPTunnel.OutPort = 20021
FTPTunnel.OutputUsesSSL = true
Auf Port 21 werden unverschlüsselte Verbindungen empfangen, die vom Localhost initiiert wurde.
Der FTPTunnel baut eine verschlüsselte Verbindung zum Host 129.27.142.229 auf Port 20021 auf, wo
dann der FTPTunnel-Server auf verschlüsselte Verbindungen wartet.
Eine wesentliche Eigenschaft für den Einsatz mit dem RLSP ist die Möglichkeit, den OutPort sowie
den connectHost über Connect-Daten mitzuteilen. Dafür ist beim Outport der Wert –1 einzutragen.
Die ersten 7 Byte, die nach dem Verbindungsaufbau zwischen den Sockets von Applikation und
Proxytunnel gesendet werden, enthalten die Connect-Daten: ein Byte als Id, vier Bytes für den Host
und zwei Bytes für den Port.
6.3.4.
Installer
Der Installer registriert die RLSP.DLL am Windows-System. Sobald dies geschehen ist, wird die
RLSP.DLL bei Programmstarts von Netzwerkapplikationen, die die WinSock-API benutzen,
zusammen mit der WinSock-DLL geladen. Für Applikationen, die bereits laufen, während die
Registrierung stattfindet, hat dies keinen Einfluss.
76
Sichere Multimediakonferenzen
Bild 6-4:
Benutzung des RLSP
Die graphische Version des Installers
Der Installer kann auf zwei Arten aufgerufen werden: Die graphische Version ist in Bild 6-4 zu sehen.
Daneben kann dieselbe Datei (Installer.exe) von der Kommandozeile mit Parametern aufgerufen
werden. Im letzteren Fall wird dann kein Fenster angezeigt. Damit ergibt sich folgender Syntax für
den Installer:
Installer [ /? | /t | /u | filename ]
/?: Damit erhält man Hilfe
/t: Test, ob die RLSP.DLL registriert ist
/u: Uninstall RLSP.DLL
filename: Die angegebene Datei wird als RLSP.DLL registriert
In der graphischen Version hat man die Möglichkeit, das Interface des Localhost aus einer Liste
auszuwählen und mittels Apply in die RLSP.INI einzutragen. Dieses hat dann Bedeutung, wenn wie
im Fall von FTP die eigene Adresse (die des Localhost) an den Peer kommuniziert wird und dieser
dann eine Verbindung zurück zum eigenen Host eröffnet. Dafür sollte die Adresse korrekt sein, denn
sonst kann kein FTP-Datentransfer zustande kommen.
In der unteren Hälfte des Fenster werden Statusmeldungen geschrieben, die den
Registrierungsvorgang beschreiben. Man sieht, dass nach dem Installieren des neuen Layered Service
Providers die protocol chains neu festgelegt werden, sodass ab jetzt der RLSP Vorzug vor dem
77
Benutzung des RLSP
Bild 6-5:
Sichere Multimediakonferenzen
Der Monitor
eigentlichen TCP- bzw. UDP-Protokoll hat, das dann vom RLSP selbst aufgerufen wird. Zum Schluss
des Registrierungsvorgangs werden Informationen über die angemeldete RLSP.DLL in der Windows
Registry gespeichert. Diese Informationen werden jedes mal versucht zu lesen, wenn der Installer
gestartet wird. Damit kann der Installer feststellen, ob der RLSP augenblicklich registriert ist und
dementsprechend die Buttons für Register oder Unregister anbieten.
Wenn der RLSP abgemeldet wird, bedeutet dies, dass alle Netzwerkapplikationen, die ab diesem
Zeitpunkt gestartet werden, den RLSP nicht mehr benutzen. Für Applikationen, die vor dem Zeitpunkt
des Abmeldens den RLSP in Verbindung mit TCP oder UDP benutzen, ändert sich nichts, solange sie
nicht geschlossen und neu gestartet werden.
6.3.5.
Monitor
Der Monitor ist ein optionales Element in der RLSP-Architektur. Er hat die Aufgabe, ein graphisches
Protokoll des Netzwerkverkehrs zu erstellen, der von RLSP und Proxytunnel übertragen wird. Dazu
kann man mittels des dafür vorgesehenen Eintrags in der RLSP.INI veranlassen, dass LogInfoStrukturen vom RLSP an den Monitor gesendet werden, wenn der RLSP eine Aktion wie connect()
oder send() ausführt. Der Monitor zeigt Informationen über den Zeitpunkt der Übertragung sowie über
den Typ (TCP oder UDP), die Adressen von Sender und Empfänger, den Port des Empfängers und die
Anzahl der übertragenen Bytes bei Sende- oder Empfangsoperationen.
78
Sichere Multimediakonferenzen
Benutzung des RLSP
Der Monitor ist multithreaded, kann also bei Bedarf auch für mehrere verschiedene RLSPs eingesetzt
werden, denn er kann auf einem beliebigen Host laufen, nicht notwendigerweise am selben Host wie
der RLSP.
79
Benutzung des RLSP
80
Sichere Multimediakonferenzen
Sichere Multimediakonferenzen
Zusammenfassung
7. Zusammenfassung
In dieser Arbeit wurde untersucht, wie Sicherheitskonzepte in Konferenzsystemen implementiert
werden können. Dazu wurde mit Windows Sockets 2 eine Möglichkeit gewählt, die es in einer
flexiblen Weise erlaubt, Authentifizierung, Integrität und Verschlüsselung in bestehende Systeme
einzubauen. Dazu wird das Layered Service Provider Interface von Windows Sockets in Kombination
mit Secure Socket Layer eingesetzt.
Im vorliegenden Text wurde zunächst der theoretische Hintergrund aufgearbeitet, der die
Themenbereiche Netzwerke, Datensicherheit und Konferenzsysteme betrifft. Daran anschließend
folgte eine Erläuterung praktischer Aspekte bezüglich der Implementierung in Windows Sockets.
Schließlich wurde das Ergebnis der Implementierung vorgestellt.
81
Zusammenfassung
82
Sichere Multimediakonferenzen
Sichere Multimediakonferenzen
Abkürzungen
A. Abkürzungen
3DES
Triple DES
AES
Advanced Encryption Standard
AH
Authentication Header
API
Application Programming Interface
ARP
Address Resolution Protocol
ARPA
Advanced Research Projects Agency
ASN.1
Abstract Syntax Notation One
ATM
Asynchronous Transfer Mode
BER
Basic Encoding Rules
BGP
Border Gateway Protocol
CA
Certification Authority
CBC
Cipher Block Chaining
CCITT
Comité Consultif International de Télégraphique et Téléphonique
jetzt ersetzt durch ITU-T
CFB
Cipher Feedback
CHAP
Challenge Handshake Authentication Protocol
CRC
Cyclic redundancy check
CSMA/CD
Carrier Sense Multiple Access with Collicion Detection
DES
Data Encryption Standard
DLL
Dynamic Link Library
DNS
Domain Name System
DSA
Digital Signature Algorithm
DSS
Digital Signature Standard
83
Abkürzungen
Sichere Multimediakonferenzen
ECB
Electronic Codebook Mode
ESP
Encapsulating Security Payload
FDDI
Fiber Distributed Data Interface
FDM
Frequency division multiplexing
FIFO
First in – first out
FTP
File Transfer Protocol
HTML
HyperText Markup Language
HTTP
HyperText Transport Protocol
IAB
Internet Activities Board
IANA
Internet Assigned Numbers Authority
ICMP
Internet Control Message Protocol
IDEA
International Data Encryption Algorithm
IEEE
Institute for Electrical and Electronics Engineers
IETF
Internet Engineering Task Force
IKE
Internet Key Exchange
IP
Internet Protocol (IPv4)
IPng
Internet Protocol – Next Generation (IPv6)
IPSec
IP Security Architecture
ISAKMP
Internet Security Association and Key Management Protocol
ISDN
Integrated Services Digital Network
ISO
International Standards Organization
ITU
International Telecommunications Union (der Vereinten Nationen)
LAN
Local area network
MAC
Message Authentication Code
MAC
Media access control
MAN
Metropolitan area network
MBone
Multicast Backbone
MC
Multipoint Controller
84
Sichere Multimediakonferenzen
MCU
Multipoint Control Unit
MD5
Message Digest version 5
MIB
Management Information Base
MIME
Multipurpose Internet Mail Extensions
MP
Multipoint Processor
MS-CHAP
Microsoft Challenge Handshake Authentication Protocol
MTU
Maximum transmission unit
NIC
Network Information Center
NIST
National Institute for Standards and Technology
NRZ
Non Return to Zero
NSF
National Science Foundation
NSP
Name Space Provider
OC
Optical Carrier, z.b. OC-1 ≡ 51.84 Mbps
OFB
Output Feedback
OSI
Open Systems Interconnection
OSPF
Open Shortest Path First
PAP
Password Authentication Protocol
PGP
Pretty Good Privacy
POTS
Plain old telephone service
PPP
Point to Point Protocol
PSTN
Public Switched Telephone Network
QoS
Quality of Service
RC4
Rivest Cipher version 4
RFC
Request for Comments
RIP
Routing Information Protocol
RPC
Remote Procedure Call
RSA
Rivest-Shamir-Adelman
RSVP
Resource Reservation Protocol
Abkürzungen
85
Abkürzungen
Sichere Multimediakonferenzen
RTCP
RTP Control Protocol
RTP
Real Time Protocol
RTSP
Real Time Streaming Protocol
RTT
Round-trip time
SHA
Secure Hash Algorithm
SET
Secure Electronic Transaction
S-HTTP
Secure HTTP
SIP
Session Initiation Protocol
S-MIME
Secure MIME
SMTP
Simple Mail Transfer Protocol
SNMP
Simple Network Management Protocol
SONET
Synchronous Optical Network
SSL
Secure Socket Layer
STDM
Synchronous time division multiplexing
STS
Synchronous Transport Signal, z.b. STS-1 ≡ 51.84 Mbps
TCP
Transmission Control Protocol
TLS
Transport Layer Security
UA
User Agent
UAC
User Agent Client
UAS
User Agent Server
TTL
Time to live
UDP
User Datagram Protocol
URL
Uniform resource locator
VCI
Virtual Circuit Identifier
VPN
Virtual private network
WAN
Wide area network
WOSA
Windows Open Services Architecture
WPU
WinSock Provider Upcall
86
Sichere Multimediakonferenzen
WSA
WinSock Application Programming Interface
WSP
WinSock Service Provider
WWW
World Wide Web
Abkürzungen
87
Abkürzungen
88
Sichere Multimediakonferenzen
Sichere Multimediakonferenzen
Bibliographie
B. Bibliographie
B.1. Networking
[Bor96]
Borowka, Petra: 1996. Internetworking. Konzepte, Komponenten,
Protokolle, Einsatz-Szenarios. Bergheim: Datacom.
[PD96]
Peterson, Larry L.; Bruce S. Davie: 1996. Computer Networks. A
System Approach. San Francisco: Morgan Kaufmann.
[Tan92]
Tanenbaum, Andrew S.:1992. Computer-Netzwerke [ Computer
Networks, deutsch ]. Attenkirchen: Wolfram’s Fachverlag.
[Sta97]
Stallings, William: 1997. Data and Computer Communications. Fifth
Edition (International). Upper Saddle River, New Jersey: Prentice Hall.
[Rob96]
Roberts, David: 1996. Internet Protocols Handbook. Scottsdale,
Arizona: Coriolis Group.
[MAB98]
Murhammer, Martin W.; Orcun Atakan; Stefan Bretz u.a.: 1998. TCP/IP
Tutorial and Technical Overview. IBM Redbooks.
http://www.redbooks.ibm.com
[RFC2001]
Stevens, W.: 1997. TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms. RFC 2001. Network
Working Group.
[RFC1700]
Reynolds, J.; Jon Postel: 1994. Assigned Numbers. RFC 1700. Network
Working Group.
[RFC0768]
Postel, Jan: 1980. User Datagram Protocol. RFC 768.
[RFC0791]
1981. Internet Protocol. RFC 791.
[RFC0792]
Postel, Jan: 1981. Internet Control Message Protocol. RFC 792.
Network Working Group.
89
Bibliographie
Sichere Multimediakonferenzen
[RFC0793]
1981. Transmission Control Protocol. RFC 793.
[RFC0959]
Postel, J.; J. Reynolds: 1985. File Transfer Protocol. RFC 959. Network
Working Group.
[RFC1034]
Mockapetris, P.: 1987. Domain Names – Concepts and Facilities. RFC
1034. Network Working Group.
[RFC1035]
Mockapetris, P.: 1987. Domain Names – Implementation and
Specification. RFC 1035. Network Working Group.
[RFC1071]
Braden, R.: 1988. Computing the Internet Checksum. RFC 1071.
Network Working Group.
[RFC1122]
Braden, R..: 1989. Requirements for Internet Hosts – Communication
Layers. RFC 1122. Network Working Group.
[RFC1123]
Braden, R..: 1989. Requirements for Internet Hosts – Application and
Support. RFC 1123. Network Working Group.
[RFC1521]
Borenstein, N; N. Freed: 1993. MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies. RFC 1521. Network Working
Group.
B.2. Security
[CZ95]
Chapman, D. Brent; Elizabeth D. Zwicky: 1995. Building Internet
Firewalls. Sebastopol, California: O’Reilly & Associates.
[MOV97]
Menezes, A; P. van Oorschot; S. Vanstone: 1997. Handbook of Applied
Cryptography. CRC Press.
[Pfl97]
Pfleeger, Charles P.: 1997. Security in Computing. Upper Saddle River,
New Jersey: Prentice Hall.
[Sch96]
Schneier, Bruce: 1996. Applied Cryptography. Protocols, Algorithms,
and Source Code in C. New York: John Wiley & Sons.
[SS94]
Shaffer, Steven L.; Alan R. Simon: 1994. Network Security. Cambridge,
Massachusetts: Academic Press.
[Wob98]
Wobst, Reinhard: 1998. Abenteuer Kryptologie. Methoden, Risiken und
Nutzen der Datenverschlüsselung. Reading, Massachusetts: Addison
Wesley-Longman.
90
Sichere Multimediakonferenzen
Bibliographie
[Beu96]
Beutelspacher, Alfred: 1996. Kryptologie. 5. Auflage. Braunschweig:
Vieweg.
[RFC2246]
Dierks, T.; C. Allen: 1999. The TLS Protocol. RFC 2246. Network
Working Group.
[BSW98]
Beutelspacher, Alfred; Jörg Schwenk; Klaus-Dieter Wolfenstetter: 1998.
Moderne Verfahren der Kryptologie. 2. Auflage. Braunschweig:
Vieweg.
[Kya98]
Kyas, Othmar: 1998. Sicherheit im Internet. 2. Auflage. Bonn:
Thompson.
B.3. Internet Telefonie
[RAR99]
Rensing, Christoph; Ralf Ackermann; Utz Roedig u.a.: 1999.
„Sicherheitsunterstützung für Internet Telefonie“. In: Patrick Horster
(Hrsg.). Sicherheitsinfrastrukturen.Buchreihe DuD-Fachbeiträge.
Braunschweig: Vieweg
[Pot97]
Pott, Oliver: 1997. Webphoning & Netfax. 2. Auflage. Kilchberg,
Schweiz: SmartBooks Publishing.
[ITU235]
ITU-T: 1998. Security and encryption for H-Series (H.235 and other
H.245-based) multimedia terminals. ITU-T Recommendation H.235.
[ITU245]
ITU-T: 1998. Control protocol for multimedia communication. ITU-T
Recommendation H.245.
[ITU323]
ITU-T: 1998. Packet-based multimedia communications systems. ITU-T
Recommendation H.323.
[RFC1889]
Schulzrinne, H.; S. Casner u.a.: 1996. RTP: A Transport Protocol for
Real-Time Applications. RFC 1889. Network Working Group.
[RFC2326]
Schulzrinne, H.; R. Lanphier: 1998. Real Time Streaming Protocol
(RTSP). RFC 2326. Network Working Group.
[deC99]
deCarmo, Linden: 1999. „Internet Telephony Protocols“. In: Dr. Dobb’s
Journal. July 1999. San Francisco, CA: Miller Freeman.
http://www.ddj.com
[DF99]
Dalgic, Ismail; Hanlin Fang: 1999. Comparison of H.323 and SIP for IP
Telephony Signaling. CA: 3Com Corporation, Cisco Systems.
91
Bibliographie
Sichere Multimediakonferenzen
[SR98]
Schulzrinne, Henning; Jonathan Rosenberg: 1998. Internet Telephony:
Architecture and Protocols. An IETF Perspective. Columbia University,
Lucent Technologies.
[RFC2543]
Handley, M.; H. Schulzrinne; E. Schooler u.a.: 1999. SIP: Session
Initiation Protocol. RFC 2543. Network Working Group.
[RFC2327]
Handley, M.; V. Jacobson: 1998. SDP: Session Description Protocol.
RFC 2327. Network Working Group.
B.4. Windows Sockets
[QS96]
Quinn, Bob; Dave Shute: 1996. Windows Sockets Network
Programming. Reading, Massachusetts: Addison-Wesley.
[SPI97]
The Winsock Group: 1997. Windows Sockets 2 Service Provider
Interface. A Service Provider Interface for Transparent Network
Programming under Microsoft Windows, Revision 2.2.2.
ftp://ftp.microsoft.com/bussys/winsock/winsock2/wsspi22.doc
[API97]
The Winsock Group: 1997. Windows Sockets 2 Application
Programming Interface. An Interface for Transparent Network
Programming Under Microsoft Windows, Revision 2.2.2.
ftp://ftp.microsoft.com/bussys/winsock/winsock2/wsapi22.doc
[And96]
Andersen, David B.: 1996. A Proposal for Managing the Ordering of
Layered Providers in Protocol Chains.
http://www.sockets.com/apiorder.txt
[ANX97]
The Winsock Group: 1996. Windows Sockets 2 Protocol-Specific Annex.
ftp://ftp.microsoft.com/bussys/winsock/winsock2/wsanx203.DOC
[Sin96]
Sinha, Alok: 1996. Network Programming in Windows NT. Reading,
Massachusetts: Addison Wesley.
B.5. Weiterführende Literatur
[Rich97]
92
Richter, Jeffrey: 1997. Windows Programmierung für Experten. Übers.
v. Wolfgang Augustin, Titel des Originals: Advanced Windows.
Unterschleißheim: Microsoft Press Deutschland.