Praktikum Mobile Systeme

Praktikum Mobile Systeme SS 2005 Betreuung: Prof. Dr. Burkhard Stiller Dipl. Inf. Peter Racz Dipl. Inf. Cristian Morariu LEHRMATERIAL Nr. 494 März 2005 Universität Zürich Institut für Informatik Winterthurerstrasse 190, CH-8057 Zürich

B. Stiller, P. Racz, C. Morariu: Praktikum Mobile Systeme März 2005 Communication System Research Group Institut für Informatik (IFI) Universität Zürich Winterthurerstrasse 190, CH-8057 Zürich, Schweiz URL: http://www.ifi.unizh.ch/

Inhaltsverzeichnis 1 Einleitung 9 1.1 Motivation..................................... 9 1.2 Ziele des Praktikums............................... 9 1.3 Informationen zum Ablauf............................ 10 1.4 Aufbau des Dokuments.............................. 10 2 Technische Grundlagen 13 2.1 Wireless LAN................................... 13 2.1.1 IEEE 802.11............................... 15 2.1.2 Systemarchitektur............................ 16 2.1.3 Protokollarchitektur........................... 18 2.1.4 Physical Layer.............................. 18 2.1.5 MAC Layer................................ 20 2.1.6 Sicherheitsmechanismen......................... 22 2.2 AAA-Architektur und RADIUS......................... 24 2.2.1 Die generische AAA-Architektur.................... 25 2.2.2 Das RADIUS Protokoll.......................... 26 2.3 Dynamic Host Configuration Protocol...................... 28 2.3.1 Ablauf.................................. 28 2.3.2 DHCPv6................................. 29 2.4 Domain Name System.............................. 29 2.4.1 Technischer Aufbau........................... 29 3

4 INHALTSVERZEICHNIS 2.4.2 Logische Aufteilung der TLDs...................... 31 2.5 Mobile IP..................................... 31 2.5.1 Forderungen an Mobile IP........................ 32 2.5.2 Begriffsdefinitionen........................... 32 2.5.3 Ablauf der Paketzustellung....................... 33 2.5.4 Tunneln................................. 35 2.5.5 Agent Discovering............................ 36 2.5.6 Registrierung der Care-of Address.................... 37 2.5.7 Handover................................. 38 2.5.8 Probleme von Mobile IP......................... 39 2.5.9 Mobile IPv6............................... 40 2.6 Security...................................... 41 2.6.1 Firewalling................................ 41 2.6.2 Virtual Private Network......................... 44 2.6.3 IPSec................................... 46 2.7 Voice over IP................................... 48 2.7.1 SIP.................................... 49 2.7.2 H.323................................... 50 3 Verwendete Hardware und Software 51 3.1 Praktikumsnetz.................................. 51 3.2 Hardware..................................... 52 3.2.1 Cisco Aironet 1100............................ 52 3.3 Software...................................... 53 3.3.1 DHCP-Server unter Linux........................ 53 3.3.2 DNS-Server unter Linux......................... 54 3.3.3 Dynamics................................. 57 3.3.4 Ethereal.................................. 59 3.3.5 FreeRADIUS............................... 60

INHALTSVERZEICHNIS 5 A Begriffsregister 63 A.1 Protokolle..................................... 63 A.2 Allgemeine Begriffe und Hardwarekomponenten................ 65 A.3 Speziell verwendete Produkte........................... 69

6 INHALTSVERZEICHNIS

Vorwort Das am Institut für Informatik der Universität Zürich angebotene Mobile Systeme Praktikum basiert auf dem gleichnamigen Praktikum, das am Institut für Informationstechnische Systeme der Universität der Bundeswehr München erstellt und durchgeführt wurde. Dieses Dokument nimmt deshalb das Praktikum Mobile Systeme [20] als Grundlage. Ferner basieren Teile des Dokuments auf Seminararbeiten, erstellt an der Universität der Bundeswehr München. Für die Beschreibung von WLAN wurden Teile aus den Arbeiten [21] und [22] bezüglich MAC Layer und WEP übernommen und überarbeitet, der Abschnitt über 802.1x stammt aus [23]. Aus [24] wurden Teile für die AAA-Architektur übernommen. Die Beschreibung von Mobile IP basiert auf [25]. Für Voice over IP wurden Teile aus [27] verwendet. Die aufgeführten Seminararbeiten sind ferner für weiterführende Informationen in den entsprechenden Themenbereichen geeignet. 7

8 INHALTSVERZEICHNIS

Kapitel 1 Einleitung 1.1 Motivation Kabelgebundene LANs werden aus Gründen der Flexibilität, vereinfachter Planung und Möglichkeit der Erweiterung immer häufiger durch drahtlose WLANs erweitert. Der Trend zur Mobilität ist erkennbar. Beispielsweise bieten viele Universitäten WLAN Zugang für ihre Studenten an, welche auch während der Vorlesung Informationen im Netz nachschauen können. WLANs werden aber nicht nur in Universitäten eingesetzt, viele Firmen, private Haushalte, sogar in Zügen lässt sich diese Technik einsetzten. Die WLAN Technologie bietet eine drahtlose Datenübertragung. Um eine nahtlose Mobilität zu ermöglichen, braucht man aber weitere Mechanismen auch auf der Netzwerk-Schicht. Diese Funktionalität wird von Mobile IP bereitgestellt. Mobile IP ermöglicht, dass ein Benutzer immer mit der gleichen Adresse adressiert werden kann, unabhängig davon, wo sich der Benutzer gerade aufhält. Dies ermöglicht auch die Weiterführung bestehender Verbindungen ohne eine Unterbrechung der laufenden Applikationen, wenn der Benutzer den Zugangspunkt und das Netzwerk wechselt. In drahtlosen Netzwerken hat die Sicherheit auch eine größere Bedeutung. Authentifizierung der Benutzer und die Verschlüsselung der Datenübertragung können für eine höhere Sicherheit sorgen. Firewalls bieten eine Möglichkeit, interne Netzwerke gegen Attacken von außen zu schützen. Der Einsatz von IPSec und die Bildung von VPNs (Virtual Private Networks) ermöglichen eine sichere Datenübertragung über öffentliche Netzwerke. 1.2 Ziele des Praktikums Das Praktikum soll durch praktische Aufgaben die Kenntnisse im Bereich der mobilen Systeme festigen und vertiefen. Die Studenten lernen den Aufbau und die Konfiguration moderner Wireless LAN s und deren Benutzung an ausgewählten Beispielen kennen. Die Aufgaben des Praktikums behandeln die folgenden Themenbereichen: Netzwerkprotokolle, ISO/OSI Protokollstack 9

10 KAPITEL 1. EINLEITUNG Der Praktikumsteilnehmer soll seine praktische Kenntnisse im Bereich der Netzwerkprotokolle erweitern und Fragen zum ISO/OSI Referenzmodell beantworten. Aufbau eines WLANs Mobile IP Der Praktikumsteilnehmer soll Verständnis für den Aufbau eines WLAN-Netzes entwickeln. Er soll ein funktionierendes WLAN aufbauen, die Sicherheitsmechanismen in WLAN kennenlernen und weitere Netzwerkdienste wie AAA, DHCP, DNS konfigurieren. Der Praktikumsteilnehmer soll Probleme in Verbindung mit Mobilität verstehen, Mobile IP kennenlernen und dessen Funktionalität untersuchen. Sicherheit in IP Netzen Der Praktikumsteilnehmer soll die Möglichkeiten für Netzweksicherheit kennenlernen und eine Firewall und VPN basierend auf IPSec einrichten. Voice over IP Der Praktikumsteilnehmer soll eine Voice over IP Verbindung zwischen zwei Clients aufbauen und eine Möglichkeit entwickeln, die Qualität der bestehenden Verbindung analysieren zu können. 1.3 Informationen zum Ablauf Das Praktikum besteht aus mehreren Terminen. Jeder Termin behandelt eine Aufgabe, die aus mehreren Teilaufgaben besteht und einen bestimmten Themenbereich zusammenfasst. Die Aufgaben werden vor dem jeweiligen Termin separat ausgehändigt. Vor jeder Übung ist eine theoretische Vorbereitung anhand der bereitgestellten Informationen nötig. Das Praktikum vermittelt auch praxisnahes Wissen und beinhaltet praktische Kenntnisse, die anhand der Aufgaben erarbeitet werden. Die Studenten werden in Gruppen à 2-3 Personen eingeteilt. Die Gruppen lösen die Aufgaben selbständig. Am letzten Termin sollen die Studenten jeweils einen Vortrag von 15 Minuten Länge zu einem gewählten Themenbereich der gelösten Aufgaben halten, so dass das im Praktikum erlangte Wissen an diesem Termin rekapituliert wird. 1.4 Aufbau des Dokuments Nach diesem einleitenden Kapitel wird in Kapitel 2 ein Überblick über die nötigen technischen Grundlagen gegeben. In dem Kapitel werden die Grundlagen eines WLAN Netzes und des IEEE 802.11 Standards sowie die verfügbare Sicherheitsmechanismen vorgestellt. Ferner wird die AAA-Architektur, das RADIUS Protokoll und die Funktionen eines DHCP und DNS Servers beschrieben. Danach werden die Mobile IP Komponenten mit ihrer Funktionalität vorgestellt. Die Grundlagen von Firewalls, VPN und IPSec werden auch in diesem Kapitel beschrieben. Ein

1.4. AUFBAU DES DOKUMENTS 11 Überblick über Voice over IP und die Grundlagen für die Protokolle SIP und H.323 schliessen dieses Kapitel. In Kapitel 3 werden die im Praktikum verwendeten Hardware und Software Komponenten beschrieben. Kurz wird die Struktur des Praktikumsnetzes vorgestellt zusammen mit den verwendeten Netzkomponenten wie z.b. WLAN Access Point. Danach wird ein Überblick über die Software Komponenten und Anwendungen gegeben, die zum Einsatz kommen. In Anhang A befindet sich ein Begriffsregister, in dem die verwendeten Begriffe kurz erklärt werden.

12 KAPITEL 1. EINLEITUNG

Kapitel 2 Technische Grundlagen 2.1 Wireless LAN Kabellose lokale Netze sind flexibel und lassen sich kostengünstig in Büroumgebungen, in Privatwohnungen oder in Fabrikhallen einsetzten. Die Reichweite von WLANs ist typischerweise auf ein Stockwerk, ein Firmengelände, einzelne Räume etc. beschränkt. Die Betreiber sind Privatpersonen, Firmen oder Behörden. Das generelle Ziel von WLANs ist der Ersatz einer unflexiblen Verkabelung und zusätzlich die Schaffung neuer Möglichkeiten der Ad-hoc Kommunikation für spontane Treffen. Die folgenden Punkte beschreiben Vorteile und Nachteile von drahtlosen Netzen im Vergleich zu herkömmlichen kabelgebundenen LANs. Vorteile drahtloser lokaler Netze: Flexibilität Innerhalb des Übertragungsbereiches können alle Netzknoten ohne weitere Einschränkungen miteinander kommunizieren. Radiowellen können Wände durchdringen, die Sender und Empfänger können an verschiedenen Stellen untergebracht werden (z.b. von außen unsichtbar, innerhalb tragbarer Rechner oder in Zwischendecken, hinter Blenden usw.). Weiterhin erschweren Brandschutzmauern sehr oft eine zusätzliche oder nur vorübergehende Verkabelung, da diese Mauern nicht durchbrochen werden dürfen bzw. Durchbrüche sorgfältig verschlossen werden müssen. Vereinfachte Planung Nur drahtlose Ad-hoc-Netzwerke erlauben eine spontane Kommunikation ohne vorherige Planung. Alle leitungsgebundenen Netze benötigen mindestens die Planung oder Mitnahme einer Verkabelung mit passenden Steckern und Buchsen plus zusätzliche Komponenten wie Hubs oder Switches. Bei WLANs ist die einzige Voraussetzung die Einhaltung des gleichen Übertragungsstandard bei allen Kommunikationspartnern. Erweiterte Entwurfsfreiheit Nur mit Hilfe drahtloser Netze können kleine, unabhängige Geräte entworfen werden, die auch noch in Jackentaschen oder Rucksäcken kommunizieren können. Kabel schränken 13

14 KAPITEL 2. TECHNISCHE GRUNDLAGEN nicht nur Anwender, sondern auch Entwickler solcher Geräte stark ein. Weiterhin können drahtlose Netze weitgehend unsichtbar installiert werden, also auch in historischen Gebäuden oder bei Anlässen, bei denen Kabel störend wirken würden. Robustheit Drahtlose Netze können meist Katastrophen wie Erdbeben oder Feuer besser überstehen, solange die Stromversorgung gesichert und die Sender und Empfänger nicht zerstört sind. Leitungsgebundene Netze sind sehr fehleranfällig, sobald die Leitungen frei herumliegen hier stellen unachtsame Anwender die grösste Gefahr dar. Kosten Nachdem ein drahtloser Zugangspunkt zum Festnetz geschaffen ist, können beispielsweise Netze in Hörsälen sehr kostengünstig betrieben werden. Unabhängig davon, ob nur wenige oder hunderte von Studenten drahtlos angebunden sind, so wird stets nur ein Zugangspunkt (bzw. wenige Zugangspunkte) benötigt. Bei einer Verkabelung müssen alle möglichen Sitzplätze mit Buchsen für einen Netzanschluss versehen werden, auch wenn viele Anschlüsse nicht genutzt werden. Weiterhin können gerade Netzanschlüsse (Stecker und Buchsen) bei intensivem Gebrauch schnell mechanisch abnutzen. Eine drahtlose Verbindung kennt keinen Verschleiss. Natürlich bringen WLANs auch Nachteile mit sich: Dienstgüte Ein drahtloses LAN ist praktisch hinsichtlich aller Dienstgüteparameter schlechter als ein leitungsgebundenes LAN. Die Bandbreiten sind um Grössenordnungen niedriger (ca. 10 Mbit/sec statt 100-1000 Mbit/sec), die Übertragungsfehlerrate um mehrere Grössenordnungen höher (ca. 10 4 statt 10 12 ) und die Verzögerungen und Verzögerungsschwankungen aufgrund meist umfangreicher Fehlerkorrekturmassnahmen grösser. Proprietäre Lösungen Aufgrund teilweise langwieriger Standardisierungsprozesse und regionaler Bestimmungen haben sich im drahtlosen Bereich schon früh verschiedene inkompatible Lösungen unterschiedlicher Hersteller herausgebildet. Zwar bieten jetzt mehr und mehr Firmen immerhin eine Kompatibilität mit Standards an, doch können Erweiterungen nur im homogenen Umgebungen genutzt werden (meist höhere Transferraten oder bestimmte Dienstgütegarantien). Einschränkungen Drahtlose Techniken müssen natürlich immer in Übereinstimmung mit nationalen Regelungen auf den jeweiligen Markt gebracht werden. Weltweit gibt es sehr viele Einrichtungen, welche die Nutzung der Frequenzen regeln leider jedoch meist unterschiedlich. Es dauert lange, bis weltweit einheitliche Regelungen wie IMT-2000 gefunden werden. WLANs arbeiten daher meist auf einem kleinsten gemeinsamen Nenner. Sicherheit Die Verwendung von Funk für die Kommunikation kann andere empfindliche Geräte stören. So sind in Krankenhäusern oder an Bord von Flugzeugen besondere Richtlinien einzuhalten. Weiterhin macht die einfach und frei zugängliche Luftschnittstelle ein Mithören

2.1. WIRELESS LAN 15 der Kommunikation wesentlich einfacher. Daher müssen Produkte Möglichkeiten zur automatischen Datenverschlüsselung anbieten. Kosten Die Kosten von Netzadaptern sind bei drahtlosen im Vergleich zu leitungsgebundenen Netzen (noch) höher, ebenso muss in einen Zugangspunkt investiert werden. Jedoch können sich die Preise hier bei der Massenanfertigung schon bald anpassen. Es werden bereits einige Rechner serienmässig mit Funknetzkarten ausgeliefert. 2.1.1 IEEE 802.11 Der IEEE 802.11 Standard beschreibt die derzeit am weitesten verbreitete Familie drahtloser LANs, zu der bereits vielfältige Produkte verfügbar sind. Dieser Standard spezifiziert die Bitübertragungsschicht und die Medienzugriffsverfahren, welche speziell für die drahtlose Übertragung notwendig sind, bietet aber nach oben hin die gleichen Schnittstellen wie andere Mitglieder der Standardfamilie (z.b. Ethernet 802.3, Token Ring 802.5) an, um eine Interoperabilität zu gewährleisten. Primäres Ziel dieses Standards war die Spezifikation eines einfachen und robusten drahtlosen LANs, das zeitbeschränkte und asynchrone Datendienste anbieten kann. Zudem sollte die Medienzugriffssteuerung über verschiedene Bitübertragungsschichten einsetzbar sein, um so auf unterschiedliche Eigenschaften hinsichtlich der Signalübertragung eingehen zu können. Zur Auswahl stehen bei diesem Standard eine Infrarottechnik und mehrere Funktechniken mit Bandspreizverfahren zur Verfügung. Übersicht In der 802.11 Familie gibt es eine Reihe von Spezifikationen. Einige werden kurz vorgestellt. 802.11 Der Ur-Standard, welcher 1997 verabschiedet wurde, bietet eine Übertragungsrate von 2 Mbit/s und funkt im 2.4 GHz ISM (Industry, Science and Medical) Band. Mittlerweile gibt es Verbesserungen und Erweiterungen dieses Standards, welche die Bezeichnung um einen Buchstaben erweitert 802.11a, 802.11b, etc. 802.11b/g Diese Spezifikationen sind für den 2.4 GHz Bereich vorgesehen und stellen 14 Kanäle zur Verfügung. Kanal 1, 6 und 11 sind nicht überlappend. Je nach Land können mehrere dieser Kanäle verwendet werden (in den USA erlaubte Kanäle: 1-11, in Europa: 1-13). Moduliert wird mit Direct Sequence Spread Spectrum (DSSS), 802.11g verwendet dazu noch Orthogonal Frequency Division Multiplexing (OFDM), welches zu höheren Datenraten führt. Die theoretische Geschwindigkeit liegt bei 11 Mbit/s mit 802.11b resp. 54 Mbit/s mit 802.11g. Die Reichweite beträgt ca. 100 Meter, in Gebäuden weniger, bei freier Sicht mehr. Mit speziellen Richtantennen lässt sich das Signal bei Sichtverbindung auf über mehrere Kilometer übertragen. Die Sendeleistung ist bei beiden Standards gleich und beträgt 100mW.

16 KAPITEL 2. TECHNISCHE GRUNDLAGEN 802.11a/h 802.11a und 802.11h arbeiten im 5 GHz Band und benutzen wie der 802.11g Standard OFDM. Das 5 Ghz Band hat den Vorteil, dass es weniger Interferenzen gibt, jedoch auch wieder den Nachteil, dass das Signal von der Umgebung stärker absorbiert wird, was mit einer höheren Sendeleistung kompensiert wird. Die Datenrate beträgt 54 Mbit/s und besitzt 12 nicht überlappende Kanäle. 802.11h besitzt zudem noch Dynamic Frequency Selection und Transmit Power Control, welches den Einsatz in Europa mit einer Sendeleitung mit bis zu 200mW erlaubt. 802.11a/h ist nicht kompatibel zu 802.11b/g. 802.11i Diese Spezifikation, welche auch unter dem Namen WPA2 (Wi-Fi Protected Access) bekannt ist, beschreibt die Authentifizierung und die Verschlüsselung der Daten. Nach dem Bekanntwerden von Schwachstellen in WEP wurde WPA eingeführt, welches ein Teil der 802.11i Spezifikation beinhaltet. WPA2 erweitert WPA um das Advanced Encryption Standard (AES) Verfahren und Extensible Authentication Protocol (EAP). 2.1.2 Systemarchitektur Drahtlose Netze können in zwei grundlegende Varianten hinsichtlich der Systemarchitektur zerlegt werden. Infrastrukturbasierte-Netzwerke Bild 2.1 zeigt die Komponenten der Infrastruktur und des drahtlosen Bereichs eines IEEE 802.11-Netzes, wie sie im Standard festgelegt wurden. Mehrere Endgeräte, hier als Stationen (STA i ) bezeichnet, sind drahtlos über AccessPoints (AP) verbunden. Die Stationen enthalten alle Mechanismen für den Medienzugriff und die funktechnischen Komponenten für die Anbindung an die Zugangspunkte. Alle Stationen und der für sie zuständige AP innerhalb eines Übertragungsbereiches bilden ein Basic Service Set (BSS i ). Das Beispiel zeigt zwei BSSs, BSS 1 und BSS 2, die durch ein Distribution System (DS) miteinander verbunden sind. Ein DS verbindet mehrere BSS über die Zugangspunkte, formt damit ein logisch grösseres Netz, das über den Übertragungsbereich eines einzelnen AP hinausgeht. Dieses erweiterte Netz wird mit Extended Service Set (ESS) bezeichnet. Weiterhin verbindet das DS die drahtlosen Netze mit einem Portal, das den Übergang in beliebige andere Netze bildet. Die Architektur des DS selbst wird nicht näher in IEEE 802.11 festgelegt. Es könnte aus mehreren lokalen Netzen bestehen, die mit Brücken verbunden sind, oder weitere Funkkomponenten enthalten. Die Dienste des DS, die sogenannten Distribution System Services, wurden jedoch im Standard festgelegt. Endgeräte können sich einen Zugangspunkt auswählen und sich an diesen binden (association). Die APs unterstützen ein Roaming zwischen den APs mit dem DS, welches für eine transparente Datenübertragung zuständig ist. Die Zugangspunkte: bieten eine Synchronisation aller Stationen innerhalb ihres BSS,

2.1. WIRELESS LAN 17 Abbildung 2.1: Architektur eines Infrastrukturbasierenten IEEE 802.11-Netzwerkes unterstützen die Verwaltung von Energiesparmassnahmen (power Managment), und steuern den Medienzugriff für zeitbeschränkte Dienste. Ad-hoc-Netzwerke Wie Bild 2.2 zeigt, unterstützt IEEE 802.11 auch die Errichtung von Ad-hoc-Netzen (auch Independent Basic Service Set (IBSS) genannt) zwischen Stationen, um dadurch eine oder mehrere BSS zu bilden. In diesem Fall umfasst ein BSS alle Stationen, die im selben Übertragungsbe- Abbildung 2.2: Architektur eines Ad-hoc-IEEE 802.11-Netzwerkes

18 KAPITEL 2. TECHNISCHE GRUNDLAGEN reich liegen und im Falle der Funktechnik auch mit den gleichen Verfahren auf der gleichen Frequenz arbeiten. Im Beispiel befinden sich die Stationen STA 1, STA 2 und STA 3 im BSS 1, die Station STA 4 und STA 5 im BSS 2. Dies bedeutet, dass STA 3 direkt mit STA 2 kommunizieren kann, nicht jedoch mit STA 5. Mehrere BSS können entweder mit Hilfe von Raummultiplex (also durch genügend Abstand) oder durch Verwendung unterschiedlicher Trägerfrequenzen (Frequenzmultiplex) gebildet werden. IEEE 802.11 standardisiert keine ausgezeichneten Stationen, welche die Weiterleitung von Daten, die Wegwahl oder den Austausch von Zustandsinformationenen unterstützt. 2.1.3 Protokollarchitektur Wie bereits durch die Nummer der Standards angedeutet wird, passt sich IEEE 802.11 nahtlos in die Welt der 802.x-Standards für leitungsgebundene lokale Netze ein. Abbildung 2.3 zeigt die wohl häufigste Architektur, ein IEEE 802.11 drahtloses LAN, welches über eine Brücke mit einem IEEE 802.3 Ethernet (z.b. 10 oder 100 Mbit/sec) verbunden ist. Anwendungen in diesem Szenario sollten von der Existenz des drahtlosen Netzes bis auf eine eventuell geringere Bandbreite und längere Zugriffszeiten auf das Medium nichts mitbekommen (das Netz verhält sich wie ein etwas langsameres leitungsgebundenes LAN). Daher sind auch Protokolle und Anwendungen höherer Schichten identisch für drahtlose wie leitungsgebundene Endgeräte. Die obere Hälfte der Sicherungsschicht, die Verbindungsabschnittssteuerung (LLC, Logical Link Control) verdeckt alle Unterschiede, die zwischen den Medienzugriffsverfahren für die verschiedenen Medien bestehen. Abbildung 2.3: IEEE 802.11-Protokollarchitektur mit Brücke 2.1.4 Physical Layer Der IEEE 802.11-Standard umfasst lediglich die Bitübertragungsschicht PHY und die Medienzugriffssteuerung MAC, wie dies auch bei den anderen IEEE 802.x-LANs der Fall ist. Die Bitübertragungsschicht ist, wie in Bild 2.4 gezeigt, weiterhin unterteilt in:

2.1. WIRELESS LAN 19 Physical Layer Convergence Protocol (PLCP) Physical Medium Dependent (PMD) Die grundlegenden Aufgaben der MAC-Schicht sind: die Steuerung des Medienzugriffs, die Fragmentierung von Nutzdaten und die Verschlüsselung Link PHY LLC Logical Link Control MAC Medium Access Control PLCP Physical Layer Convergence Protocol PMD Physical Medium Dependent MAC Management PHY Management Station Management Abbildung 2.4: Detailliertere IEEE 802.11-Protokollarchitektur mit Management Die PLCP-Unterschicht stellt ein Signal zur Überwachung des Mediums zur Verfügung (Clear Channel Assessment, CCA) und bietet einen einheitlichen PHY-Dienstzugangspunkt unabhängig von der Übertragungstechnik an. Schliesslich umfasst PMD die Modulation der Daten und die Codierung und Decodierung der Signale. Neben den Protokollschichten legt der Standard auch Management-Schichten und die Verwaltung des Endgerätes fest. Das MAC-Management unterstützt: die erstmalige und die erneute Anbindung eines mobilen Endgerätes an einen Zugangspunkt, das Roaming zwischen Zugangspunkten, Energiesparmechanismen, und verwaltet die lokale Management Informations Base (MIB). Die Aufgabe des PHY-Managements umfasst: die Kanalwahl,

20 KAPITEL 2. TECHNISCHE GRUNDLAGEN die Verwaltung der PHY-MIB Schliesslich verbindet die Stationsverwaltung alle Management-Schichten und ist für zusätzliche Funktionen für höhere Schichten zuständig (z.b. Steuerung der Brückenfunktion, Interaktion mit dem Distribution System). 2.1.5 MAC Layer Die MAC-Schicht, die zweite im OSI-Modell steht für Medium Access Control und ist für die einheitliche Verwendung des gewählten Übertragungsmediums durch die oberen Schichten zuständig und regelt somit die Übertragung von Informationen. Hierbei wird sichergestellt, dass die Information am anderen Ende wirklich ankommt und richtig übertragen wurde. Die MAC-Schicht des IEEE 802.11 hat grosse Ähnlichkeiten zu seinem Bruder IEEE 802.3 (Ethernet). Dennoch gibt es besondere Änderungen, die sich gerade wegen des verwendetem Mediums Funkwelle ergaben. IEEE 802.11 verwendet für die Übertragung einen CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) -Algorithmus, im Unterschied zu 802.3, welches CSMA/CD (Carrier Sense Multiple Access / Collision Detection) einsetzt. CSMA/CA steht für folgendes: Carrier Sense Jeder Teilnehmer des Übertragungsmediums überwacht dieses durchgängig und passt seine eigenen Aktionen dem momentanen Zustand an. Multiple Access Mehrere Teilnehmer teilen sich das selbe Medium, hier im besonderen die selbe Frequenz. Collision Avoidance Da bei Funkübertragungen eine Kollision nicht immer feststellbar ist, wird versucht, diese gänzlich zu verhindern, was mehr oder weniger gut gelingen kann. Um sicherzustellen, dass ein Datenpaket ohne eine Kollision, die dieses ja zerstören würde, übertragen wird, musste man sich ein Verfahren ausdenken, was die Anzahl der Kollisionen minimiert. Distributed Coordination Function Ein Teil der Lösung der Collision Avoidance ist mit Hilfe von Timing-Massnahmen realisiert worden. Hierfür wird eine Zeitspannen, die Interframe Space (IFS) genannt wird, definiert. Diese gibt an, wie lange eine sendewillige Station wartet, bis sie versucht, ihr Paket zu senden. Hiermit lassen sich auch bedingt Prioritäten definieren und realisieren, denn eine Station, die eine kürzere IFS hat, wird automatisch eher anfangen zu senden und andere werden das feststellen und ihre Sendung entsprechend zurückstellen (Carrier Sense). Dennoch sind diese Zeitspannen ein gefährliches Gebiet, da schon kleinere Änderungen der Zeitspannen, grosse Auswirkungen auf den Datendurchsatz haben können. Es gibt 4 IFS-Zeiten: SIFS, PIFS, DIFS, EIFS. Je nach Priotrität der Meldung wartet eine Station eines dieser IFS Zeiten ab, bevor es eine Übertragung beginnt.

2.1. WIRELESS LAN 21 Jedes Paket das empfangen wird, wird auch bestätigt. So kann eine Station sicher sein, dass der Empfänger das Paket auch wirklich empfangen hat. Eine Bestätigung eines empfangenen Paketes, welches eine kurze IFS Zeit hat, hat höhere Priorität als ein Datenpaket, welches eine längere IFS Zeit hat. Sollte das Medium aber in dieser Zeit besetzt sein, so beginnt der sog. Backoff-Prozess. Dieser Prozess ist änhlich dem Prozess in den kabelgebundenen Netzten. Es wird eine Zeit gewartet, danach wird nochmals versucht zu senden, schlägt das Fehl wird die Wartezeit exponentiell erhöht bis nochmals versucht wird zu senden. Dennoch kann dieses Verfahren das Kollisionsproblem nicht verhindern, sondern nur minimieren. Hidden Station Problem RTS und CTS Es gibt ein klassisches Beispiel für dieses Phänomen. Es seien zwei Rechner durch ein Hindernis derart getrennt, dass sie keine Verbindung aufbauen können. Ein dritter Rechner habe Kontakt zu beiden. Nun kann jeder der beiden voneinander getrennten Rechnern ein Paket zu dem dritten schicken. Beide werden das Medium auf eine laufende Übertragung hin überprüfen. Tun das beide gleichzeitig, werden beide einen freien Raum finden, da sich sich ja gegenseitig nicht wahrnehmen. Nun beginnen beide zu senden und die Pakete werden nahezu gleichzeitig ankommen, womit beide zerstört sind. Da aber nur auf Empfängerseite geprüft werden kann, ob eine Übertragung fehlerfrei war, wird dem Sender das nicht auffallen. Das Problem wird mit dem RTS und CTS Mechanismus gelöst. Das Wesen dieses Mechanismuses besteht darin, dass eine anstehende Übertragung durch den Sender angekündigt wird (Request to Send, RTS) und der Empfänger diese bestätigt (Clear to Send, CTS). In der RTS wird die Identifikation des Senders zusammen mit der Länge des Paketes gesendet. Die selben Informationen, aber mit geändertem Absender wird dann vom Empfänger zurückgeschickt. Hieraus ergibt sich folgende Situation zur Lösung des Hidden-Station-Problems: Der Sender (A) sendet sein RTS an den Empfänger (B). Diese RTS wird durch die verdeckte Station (C) natürlich nicht wahrgenommen, womit dieses ihre DIFS Zeit wartet, um eine Übertragung zu beginnen. Jetzt wird aber die Empfangsstation (B) das CTS senden, welche die verdeckte Station (C) genauso mitbekommt, wie die sendende (A). Hiermit erfährt aber die verdeckte Station (C), dass eine Übertragung am laufen ist und wird einen Countdown starten, der genau so lange wartet, wie die angekündigte Übertragung gemäss der CTS benötigen wird. Hiermit wird die anstehende Kollision ausgeschlossen und das Hidden-Station-Problem gelöst. Dennoch erkauft man sich diese Lösung mit einem erheblich höherem Datenaufkommen, was den effektiven Datendurchsatz verringert. In der Praxis werden diese beiden Verfahren gemischt eingesetzt. Bei geringen Verkehr wird auf das RTS-CTS-Verfahren gänzlich verzichtet. Bei vielen Kollisionen und Hidden Stations wird dieses Verfahren eingesetzt. Point Coordination Function Mit der Point Coordination Function ist eine Möglichkeit durch die IEEE 802.11 spezifiziert worden, mit der zeitkritische Anwendungen unterstützt werden. Hiermit wird dem Point Coordinator, üblicherweise einem Access Point, der ausschliessliche, priorisierte Zugriff auf das

22 KAPITEL 2. TECHNISCHE GRUNDLAGEN Medium erteilt. Dieser regelt dann den Zugriff für alle anderen im Empfangsbereich liegenden Geräte. Hierfür synchronisiert der Point Coordinator mit Hilfe eines Beacon, welches er in einem wettbewerbsfreien Zeitraum sendet, alle anderen. In diesem Beacon ist die Dauer der Contention Free Period untergebracht. Innerhalb dieser Zeitspanne nach dem Beacon fragt der Point Coordinator nun alle Station ab, ob sie einen Übertragungswunsch haben und bildet intern eine Polling List. Nach der Contention Free Period beginnt nun einheitlich, da durch das Beacon synchronisiert, der Übertragungszeitraum. In diesem senden nun die einzelnen Stationen anhand der Polling List des Point Coordinator. 2.1.6 Sicherheitsmechanismen Die Anforderungen an ein drahtloses Netzwerk sind nicht die gleichen wie die Anforderungen an ein kabelgebundenes System. Während man Kabel unter die Erde oder in eine Wand legen kann, lässt sich bei einer drahtlosen Verbindung mit kleinem Aufwand die übertragenen Daten abhören und abändern. Deshalb hat bei der Spezifikation der 802.11 [35] Standards die Sicherheit grosse Bedeutung. WEP Da Wireless LAN im Gegensatz zu Ethernet auf Funkwellen übertragen wird und diese sehr schwer bis zu überhaupt nicht gegen unbefugten Zugriff sicher sind, hat man in der IEEE 802.11 einen Sicherheitsstandard vorgesehen, der eine ähnliche Sicherheit gewährleisten soll, wie es von leitungsgebundenen zu erwarten wäre. Dieser Standard ist WEP und steht für Wired Equivalent Privacy. WEP nutzt RC4 für die Datenverschlüsselung und CRC-32 für die Datenintegrität. Der WEP Standard wurde 1999 eingeführt, gilt aber heute als unsicher. Zum einem war die Verschlüsselung optional, was dazu führte, dass vielfach diese Option gar nicht benutzt wurde. Zum anderen gibt es eine bekannte Schwachstelle, nach dem ein Abhören des Datenstroms der Schlüssel wiederhergestellt werden kann. RC4 generiert einen Strom von Bits. Dieser stream cipher in WEP besteht aus RC4 (IV + Geheimschlüssel). IV steht für Initial Vector und besteht aus einer 24bit grossen zufälligen Zahl, die im Klartext übertragen wird. Der Geheimschlüssel beträgt 40bit. Bei WEP2 ist die Grösse von IV gleich geblieben, dagegen beträgt der Geheimschlüssel 104bit. Der stream cipher und der Originaltext wird mit XOR verknüpft (Text + CRC-32 (Text) XOR RC4 (IV + Geheimschlüssel)) und kann auf einem unsicheren Medium übertragen werden. Das Problem bei dieser Verschlüsselung ist, dass wenn ein Angreifer zwei mal den gleichen stream cipher mitschneidet, kann er, falls er eine Nachricht kennt, alle anderen Nachrichten entschlüsseln ohne den Schlüssel zu kennen. Diese sogenannten Kollisionen, das heisst wenn der gleiche IV für die Verschlüsselung mehrerer Pakete verwendet wird, können aber auch genutzt werden ohne irgend eine Nachricht zu kennen. Dazu nutzt man die Redundanz des Protokolls aus. So lässt sich zum Beispiel dazu das ACK Paket verwenden, welches oft ähnlich aussieht. Mit einer statistischen Auswertung von mehreren Kollisionen lässt sich das Netz ebenfalls aushorchen. Durch aktives Einfügen von Paketen lässt sich dieser Vorgang noch

2.1. WIRELESS LAN 23 beschleunigen. Eine andere Schwachstelle ist RC4, bei dem man unter bestimmten Voraussetzungen den geheimen Schlüssel wiederherstellen kann [37]. 2003 wurde der WEP Standard durch WPA abgelöst und 2004 durch WPA2 respektive 802.11i [36]. WPA und WPA2 WPA (Wi-Fi Protected Access) war eine Zwischenlösung, die Eingeführt wurde nachdem WEP als nicht mehr sicher galt. WPA setzt ebenfalls RC4 für die Datenverschlüsselung ein, ersetzt aber CRC-32 durch MIC (Message Integrity Check), da CRC-32 die Datenintegrität nicht gewährleisten kann. Die Schlüsselänge wurde ebenfalls vergrössert (IV ist 48bit lang), sodass ein Entschlüsseln durch mitschneiden des Traffics nicht mehr einfach zu bewerkstelligen ist, so muss man bei WPA nun mehrere hundert Jahre Abhören um eine Kollision anzutreffen und um so den Schlüssel wiederherzustellen. Zudem wird der Schlüssel periodisch neu generiert. Die Schlüsselverwaltung in WPA lässt sich entweder mit einem zentralen Server realisieren oder über WPA-PSK (pre-shared-keys), welches ähnlich zu WEP funktioniert und für den privaten Gebrauch geeignet ist. WPA2 benutzt Advanced Encryption Standard (AES [38]) anstatt RC4 und Extensible Authentication Protocol (EAP) zur Authentifizierung. 802.1x Port-based Authentication In der Definition von 802.1x existieren drei interagierende Systeme. Zum einen auf der Benutzerseite der sogenannte Supplicant, das System des zu authentifizierenden Benutzers. Auf der anderen Seite der Authentication Server, das System, dass entscheiden kann, ob ein Benutzer berechtigt ist, den angefragten Zugriff auf Netzwerkressourcen zu erhalten. Zwischen diesen steht der sogenannte Authenticator, dieses System ist der Zugangspunkt zu einem Netzwerk für den Supplicant, so zum Beispiel ein Einwahlknoten eines ISP, aber auch ein Access Point in einer drahtlosen Netzwerkumgebung Supplicant und Authenticator werden nach Spezifikation jeweils auch als Port Authentication Entities (PAE) bezeichnet. Der Authenticator selbst markiert nur einen Zugang zu einem bestimmten Netzwerk, respektive das Ende eines bestimmten Netzwerks. Er selbst hat keinerlei Informationen über erlaubte Benutzer und deren konkrete Zugriffsrechte. Jeglichen eingehenden Verkehr prüft er lediglich auf Rechtmäßigkeit und leitet dann gegebenenfalls eingehende Authentifizierungsanfragen an einen oder mehrere ihm bekannte Authentication Server weiter. Verkehr von bereits authentifizierten Systemen lässt er in das hinter ihm liegende Netzwerk passieren. Diese Überprüfung geschieht mittels Zuweisung eines bestimmten Status für jeden logischen Port, authorized und unauthorized. Letzterer sorgt dafür, dass über einen Port kein Benutzerverkehr zugelassen wird. Die Spezifikation erlaubt es allerdings, Verkehr zum Management des Clients zuzulassen, wie zum Beispiel DHCP oder eine Webseite, die als Informationsseite dient. Solche Ausnahmen werden in der Konfiguration des Authenticator festgelegt. Ein Authentifizierungsvorgang findet, logisch gesehen, zwischen Supplicant und Authentication Server statt, der Authenticator dient ausschliesslich als Vermittler. Um die Authentifizierungsdaten zwischen den relevanten Systemen zu transportieren, verwendet der Authenticator ein

24 KAPITEL 2. TECHNISCHE GRUNDLAGEN von EAP abgeleitetes Protokoll, wahlweise EAP over LAN bzw. EAP over Wireless (EAPOL bzw. EAPOW, sie unterscheiden sich nur im Format ihrer zugehörigen Frames), um die Kommunikation mit dem Supplicant zu bearbeiten. Für die Kommunikation mit dem Authentication Server kommt das RADIUS-Protokoll zum Einsatz. 802.1x selbst implementiert keine Authentifizierungsmethoden. Es stellt lediglich ein Framework zur Verfügung, um verschiedene Authentifizierungsalgorithmen zu transportieren. Es stellt Mechanismen zur Verfügung, um Authentifizierungsanfragen zu stellen und deren Resultat zu präsentieren. Damit lösen Änderungen der Authentifizierungsmechanismen keine gravierenden Anpassungen auf dem Benutzersystem aus. 2.2 AAA-Architektur und RADIUS Der Bedarf und die Nutzung des Internets zur Bereitstellung kommerzieller Dienste, kommerziell genutzten Daten und als Kommunikationsmittel für Geschäftabwicklungen ist stark angestiegen und wird auch weiter steigen. Als Folge erhöht sich der Bedarf die sensitiven Daten zu schützen, Dienste vor Mißbrauch zu sichern und Kosten zu berechnen. Dies führt im wesentlichen zu drei Dingen die gefordert werden: 1. Authentifizierung (Authentication): Bei der Authentifizierung wird die Identität eines Nutzers der einen Dienst nutzen will bestätigt. Dies ist wichtig, da die Nutzung eines Dienstes meistens auf einen bestimmten Personenkreis beschränkt sein soll (meist die, die dafür bezahlt haben oder die zu einem bestimmten Unternehmen gehören) und da der Nutzer jederzeit verantwortbar gemacht werden können muss sei es bei Missrauch oder sei es bei der Bezahlung des geleisteten Dienstes. Authentifizierung wird meist durch ein Geheimnis, das nur zwei Seiten (Dienstleister und Nutzer) kennen oder durch eine vertrauenswürdige dritte Instanz realisiert. 2. Authorisierung (Authorisation): Als Authorisierung bezeichnet man die Erlaubnis einen Dienst nutzen zu dürfen. Nachdem sich ein Nutzer authentifiziert hat muss sichergestellt werden, dass er die Dienste für die er zugelassen ist auch Nutzen kann. Hinderlich hierbei wäre wenn der Nutzer sich jedesmal neu authentifizieren müsse. In der Praxis werden meist ACLs (Access Control Lists) oder Policies genutzt. 3. Abrechnung (Accounting): Bei der Abrechnung werden vom Dienstleister Daten zur Nutzung seiner Dienste gesammelt zwecks Auswertung für Rechnungen und Kapazitätsplanungen. Hier kommt der ökonomische Aspekt am meisten zur Geltung, da letztendlich der Dienstleister Geld verdienen möchte und somit den Nutzer zur Zahlung der geleisteten Dienste herangezogen wird. Es werden grundsätzlich meist die transferierten Daten oder die Zeit, die der Dienst genutzt wurde, gemessen und dem Nutzer in Rechnung gestellt. Als Folge des oben Genannten wurden Protokolle entwickelt um diese Aufgaben zu übernehmen. Vorschläge für AAA-Protokolle kommen u.a. von der AAA Working Group [2], deren Ziel ist es ein Protokoll zu entwickeln das Authentication, Authorisation und Accounting realisiert. Protokolle, die alle drei Aufgaben implementieren sind RADIUS [4] und dessen Nachfolger Diameter [6].

2.2. AAA-ARCHITEKTUR UND RADIUS 25 2.2.1 Die generische AAA-Architektur In einem Netzwerk werden die verschiedenen Dienste meistens von verschiedenen Komponenten angeboten. Bei einem Zugangsnetz zum Beispiel existieren viele Zugangspunkte, die verteilt im Netz eingesetzt werden. Außerdem wollen viele Benutzer die angebotenen Dienste nutzen können. Um die Authentifizierung, Authorisierung und Abrechnung effizient durchführen zu können, die Benutzerdaten mit geringem Aufwand verwalten zu können, und trotz laufender Änderung der Daten die Konsistenz im Netz gewährleisten zu können, ist es wünschenswert, dass diese Aufgaben zentralisiert sind. Ein AAA-System entspricht diesen Anforderungen und sieht in den meisten Fällen vor, dass im Netz AAA-Server verteilt sind, die untereinander mit AAA-Protokollen kommunizieren. Diese AAA-Server führen die Authentifizerierung und Authorisierung durch und sammeln die erforderlichen Benutzungsdaten. In dem Netz können weiterhin sogenannte Broker vorhanden sein, die als vertrauenswürdige dritte Instanz fungieren, wenn sich zwei Objekte gegenseitig nicht trauen. Abb. 2.5 zeigt die generische AAA-Architektur von IETF [3]. Die Architektur teilt die AAA- Funktionalität in einen generischen und in einen applikationsspezifischen Teil auf. Der generische Teil beinhaltet die allgemeine Funktionen, die bei allen Diensten und Applikationen gleich sind. Der applikationsspezifischen Teil ist dagegen auf die Anwendung zugeschnitten. Die Architektur besteht aus den folgenden Komponenten: AAA-Server: Der Server stellt die AAA-Funktionalität zur Verfügung und fällt die AAA- Entscheidung. Der Server kann mit weiteren Servern im Netz kommunizieren. Application Specific Module (ASM): Das ASM bietet ein einheitliches Interface für den AAA-Server und verbirgt die SE-spezifische Details. Das ASM ist eine abstrakte, generische Repräsentation des SE. Service Equipment (SE): Das SE stellt dem Benutzer den Service zur Verfügung. Das SE kann z.b. ein Zugangspunkt im Netzwerk sein. Policy Repository: Dieses enthält Informationen über verfügbare Dienste und Resourcen und über die Entscheidungsrichtlinien die angewendet werden. Abbildung 2.5: Generische AAA-Architektur Als erster Schritt des AAA-Vorgangs in der generischen AAA-Architektur empfängt der AAA- Server eine AAA-Anfrage. Die Anfrage kann vom SE oder vom Benutzer abhängig von dem

26 KAPITEL 2. TECHNISCHE GRUNDLAGEN angewendeten AAA-Mechnismus kommen. Der Server prüft die Anfrage, erkennt welches Art der Authorisierung erwünscht ist und holt Richtlinien aus dem Policy Repository. Wenn die Anfrage lokal bearbeitet werden kann, wird auf Grundlage der Richtlinien eine Entscheidung über die Anfrage getroffen (meist Annahme der Ablehnung). Die Entscheidung wird dem SE oder dem Benutzer mitgeteilt. Wenn die Anfrage lokal nicht beantwortet werden kann, wird sie an einen weiteren AAA-Server weitergeleitet, der dann ebenfalls entweder die Anfrage lokal bearbeitet oder an einen anderen Server weiterleitet. Dies kann so lange geschehen bis endlich ein AAA-Server die Entscheidung für oder gegen die Gewährung des Dienstes trifft. 2.2.2 Das RADIUS Protokoll Das RADIUS (Remote Authentication Dial In User Service) Protokoll [4], [5] wurde entworfen um Authentifizierungs-, Authorisierungs- und Accountingdaten zwischen einem NAS (Network Access Server) und einem RADIUS-Server zu transportieren. Typischerweise wird es bei verteilten Netzwerkzugangspunkten wie z.b. Modempools benutzt, um die AAA-Funktionalität und Benutzerdaten zentral zu verwalten. RADIUS basiert auf dem Client-Server Modell. Der Server speichert alle relevanten Nutzerdaten in nur einer Datenbank und stellt die AAA-Funktionalität bereit. Der NAS agiert als Client und sendet jegliche Anfragen mit den relevanten Nutzerdaten an den RADIUS-Server und verhält sich dann entsprechend der Antwort des Servers. Der RADIUS-Server übernimmt die Aufgabe, die Anfragen zu bearbeiten, den Nutzer zu authentifizieren und gegebenenfalls zu authorisieren und den Client so zu konfigurieren, dass der Benutzer den Dienst nutzen kann. Der Server kann auch als Client agieren und Anfragen an einen anderen Server weiterleiten, wenn die Anfrage lokal nicht bearbeitet werden kann. Dies ermöglicht, eine hierarchische Struktur von RADIUS-Servern aufzubauen und die AAA-Aufgaben zwischen Servern zu verteilen. Abbildung 2.6: Das RADIUS Paketformat Das Paketformat des RADIUS Protokolls zeigt die Abb. 2.6. Der Paketkopf besteht aus den folgenden Felder: Code Das Code Feld ist ein Byte lang und legt den Pakettyp fest. Die folgenden Typen von RADIUS Paketen sind definiert: Access-Request (1) Access-Accept (2)

2.2. AAA-ARCHITEKTUR UND RADIUS 27 Access-Reject (3) Access-Challenge (11) Accounting-Request (4) Accounting-Response (5) Identifier Das Identifier ist auch ein Byte lang und es wird benutzt um die Anfrage-Antwort Paaren zu identifizieren. Der Server kann auch anhand des Identifiers duplizierte Anfragen erkennen. Length Das Feld ist zwei Byte lang und gibt die Länge des Paketes zusammen mit Header an. Authenticator Das Authenticator ist 16 Byte lang und es wird benutzt um die Antwort des Server zu authentifizieren und die Integrität der Nachricht zu überprüfen. Ferner wird das Authenticator auch bei der Verschlüsselung von Nutzerpasswörter benutzt. Die Sicherheit der Nachrichten zwischen Client (NAS) und RADIUS-Server wird durch ein Shared Secret Verfahren gewährleistet, bei dem ein Geheimnis, das nur diese beiden kennen, zur Authentifizierung benutzt wird. Das Authenticator in Anfragen ist eine Zufallszahl. Der Server benutzt diese Zufallszahl und das Shared Secret, um einen MD5 Hashwert für das Paket zu erstellen. In die Berechnung werden der Paketkopf und auch die Attribute-Value-Pairs einbezogen: MD5(Code+ID+Length+Authenticator+Attributes+Secret) Um verschiedene Daten im Payload zu transportieren, verwendet RADIUS sogenannte Attribute- Values-Pairs (AVPs). Ein AVP besteht aus drei Feldern: AVP-Code, AVP-Länge und AVP-Wert. Wobei der Code aussagt, was für Daten das AVP enthält, die Länge, die Länge des Datenfeldes spezifiziert und der AVP-Wert die eigentlichen Nutzdaten enthält. Jegliche Daten werden in dieser Form versendet. RADIUS ermöglicht die AVPs mit vendorspezifischen Attributen zu erweitern, um das Protokoll speziellen Anforderungen anpassen zu können. Der Attributwert kann einem der folgenden Datentypen entsprechen: Integer (INT) Enummerated (ENUM) IP Address (IPADDR) Character String (STRING) Date (DATE) Binary (BINARY) RADIUS benutzt UDP als Transportprotokoll für die Kommunikation zwischen Client und Server und es unterstützt verschiedene Verfahren zur Authentifizierung wie beispielsweise PAP (Password Authentication Protocol) und CHAP (Challenge Handshake Authentication Protocol). Der Vorgang der Authentifizierung über RADIUS sieht wie folgt aus. Der Nutzer möchte z.b. Netzwerkzugang bei einem NAS bekommen und schickt deshalb eine Anfrage mit seinen Authentifizierungsdaten (Nutzername, Passwort) an den NAS. Die Daten können z.b. über PPP

28 KAPITEL 2. TECHNISCHE GRUNDLAGEN (Point-to-Point Protocol) oder EAP (Extensible Authentication Protocol) übermittelt werden. Um den Nutzer zu authentifizieren, schickt der NAS eine Anfrage (Access-Request) an den RADIUS-Server. Ist dieser nicht erreichbar kann sich der RADIUS Client auch an einen anderen RADIUS-Server wenden. Ist der Server für den Benutzer nicht zuständig, so leitet der Server die Anfrage weiter. Wenn der zuständige RADIUS-Server die Anfrage erhält, prüft er die Identität des Nutzers anhand eines Vergleichs der Authentifizierungsdaten aus der Anfrage mit denen aus seiner Datenbank. Ist der Nutzer authentisiert, so prüft der RADIUS-Server anhand seiner Datenband welche Rechte dem Nutzer zustehen und ob die angeforderten darin enthalten sind. Ist der Nutzer authorisiert schickt der Server die Antwort (Access-Accept), sowie Konfigurationsdaten an den NAS, der dann den Nutzer benachrichtigt sobald der Dienst zur Verfügung steht. 2.3 Dynamic Host Configuration Protocol DHCP [8] (Dynamic Host Configuration Protocol) ermöglicht Client Rechnern, eine IP-Adresse von einem anderen Rechner (dem DHCP-Server) zu beziehen. Der Benutzer muss hierbei keine IP-Adresse vom Netzwerkadministrator erfragen und selbst konfigurieren. Subnetzmaske, Default-Gateway und DNS Server, unter Umständen auch die Domain werden ebenfalls mitgeliefert. DHCP basiert auf BOOTP [7] (Bootstrap Protocol), und erweitert diese Spezifikation. BOOTP wurde dazu verwendet, um Terminals eine IP Adresse zuzuweisen. Als nächster Schritt in der BOOTP Spezifikation wird den Terminals mittels TFTP, SFTP oder FTP ein Kernel übermittelt, mit dem die Terminals booten können. Eine automatische Konfiguration mittels DHCP hat vor allem dann einen Vorteil wenn eine Netzwerktopologie sich häufig ändert. Das heisst wenn zum Beispiel aus einen grossen Netzwerk zwei kleine werden. Das erspart den Administratoren den Aufwand die Netzwerkeinstellungen jedes Clients zu ändern. Auf der anderen Seite kann ein Client nun von einem Netzwerk ins andere wechseln ohne die Netzwerkeinstellungen ändern zu müssen. DHCP hat ein Konfigurationsfile, welches festlegen kann, welcher Client wie lange welche IP haben kann. Dabei steht ein Pool von IPs zur Verfügung. 2.3.1 Ablauf Ein Client, welcher eine IP Adresse verwenden will, schickt zuerst ein DHCP-DISCOVER Nachricht per Broadcast. Daraufhin antwortet ein oder mehrere DHCP Server mit einem DHCP- OFFER. Der Client entscheidet sich für ein Angebot und schickt ein DHCP-REQUEST, worauf der Server mit einem DHCP-ACK antwortet. Wenn ein Client keine IP mehr benötigt, dann wird ein DHCP-RELEASE geschickt. Der Server hat die Möglichkeit die vergebene IP für eine bestimmte Zeit zu vermieten. Wird solch eine lease-time vergeben, so muss der Client vor Ablauf dieser Zeit erneut einen DHCP-REQUEST schicken, damit ihm eine neue lease-time zugewiesen wird.

2.4. DOMAIN NAME SYSTEM 29 2.3.2 DHCPv6 In IPv6 ist eine Art Autokonfiguration schon integriert, so errechnet sich eine lokale IP Adresse aus der MAC Adresse. Den Router sucht ein Client mit einer Multicast Anfrage. Das Problem ist, dass der Client auf diese Weise keinen DNS Server findet. Hier kommt DHCPv6 zum Einsatz. Bezüglich der Funktionalität ist es Vergleichbar mit DHCP, wobei noch andere Informationen mitgeschickt werden, wie zum Beispiel Konfigurationsinformation zu SIP Diensten. DHCPv6 bietet außerdem eine Authentifikation von Nachrichten. 2.4 Domain Name System Das Domain Name System (DNS) ermöglicht lesbare Domain Namen auf IP Adressen abzubilden. Dabei stellt es eine weltweit verteilte Datenbank dar, die zentral organisiert wird. Die Top Level Domains (TLDs) werden von der Organisation ICANN vergeben. Für die weitere Aufteilung (2nd Level Domain) sind so genannte Registratoren zuständig. Für die Schweiz ist SWITCH, für Deutschland DeNIC und für Österreich nic.at zuständig. Die Liste aller Registratoren ist im Internet auf der Seite http://www.iana.org/cctld/cctld-whois.htm verfügbar. Der 2nd Level Domainname muss bei den jeweiligen TLD-Registratoren gekauft werden. Der Name wird zentral in einer Datenbank des Registrators eingetragen. 2.4.1 Technischer Aufbau Das DNS ist ein hierarchisches Gebilde wie die Abb. 2.7 zeigt..(root) ch org de unizh nope ethz leo olat source f orge www dict search Abbildung 2.7: DNS-Baum. (root) Es gibt 13 Root Server, die für die TLDs (hier ch, org, de) verantwortlich sind. Die Anzahl 13 wurde zu einer festen Grösse, weil unter anderem die Grösse einer DNS- Nachricht auf 512 Bytes beschränkt ist. ch, org, de Die TLDs werden von ICANN bestimmt und an bestimmte Registratoren vergeben.

30 KAPITEL 2. TECHNISCHE GRUNDLAGEN unizh, ethz, leo,... Serverbetreiber können bei den Registratoren einen Namen registrieren lassen (2nd Level Domain). www, dict,... Für die weitere Verwendung der Namen ist der Serverbetreiber selber verantwortlich. Die Adresse wird von unten nach oben gelesen. Ein Beispiel ist dict.leo.org.. Diese Adresse führt auf die Übersetzungsseite der Technischen Universität München. Bei den meisten Programmen und Applikationen muss der letzte Punkt nicht geschrieben werden (vgl. dict.leo.org). 13 Root Server Es gibt 13 Root Server. Wird eine Anfrage an den Root Server mit einem Namen durchgeführt, der die maximale Länge von 255 Zeichen hat, dann antwortet der Root Server mit einer 511 Byte grossen Antwort. Wären es 14 Root Server, dann wird die Antwort fragmentiert. Im Beispiel unten wird eine Abfrage mit einer maximalen Länge eines Namens durchgeführt. In der Antwort werden 13 Name Server (NS) Einträge und 1 IPv4 Adresse zurückgegeben. Bei 14 Root Servern hätten nicht mehr alle NS Einträge Platz ohne die Grösse von 512 Bytes zu übersteigen. In der Antwort müsste das TC (truncated) Bit gesetzt werden. Die Antwort ist fragmentiert und vielleicht sogar nutzlos. In diesem Fall wird versucht die Antwort mit TCP zu übermitteln, was einen grösseren overhead mit sich bringt. Gemäss RFC 2181, Kapitel 5 werden entweder alle Antworten, hier NS Einträge, geschickt oder es wird das TC Bit gesetzt. Beispiel einer maximalen Anfrage host -d 123456789.123456789.123456789.123456789 \.123456789.123456789.123456789.123456789.123456789 \.123456789.123456789.123456789.123456789.123456789 \.123456789.123456789.123456789.123456789.123456789 \.123456789.123456789.123456789.123456789.123456789 \.123456789.com a.root-servers.net ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15369 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.com, type = A, class = IN ;; Querying server (# 1) udp address = 198.41.0.4 ;; got answer, 511 bytes: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15369 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1 ;; 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.123456789.123456789.123456789.123456789.123456789. 123456789.com, type = A, class = IN com. 2D IN NS A.GTLD-SERVERS.NET. com. 2D IN NS G.GTLD-SERVERS.NET. com. 2D IN NS H.GTLD-SERVERS.NET. com. 2D IN NS C.GTLD-SERVERS.NET. com. 2D IN NS I.GTLD-SERVERS.NET. com. 2D IN NS B.GTLD-SERVERS.NET. com. 2D IN NS D.GTLD-SERVERS.NET. com. 2D IN NS L.GTLD-SERVERS.NET. com. 2D IN NS F.GTLD-SERVERS.NET.

2.5. MOBILE IP 31 com. 2D IN NS J.GTLD-SERVERS.NET. com. 2D IN NS K.GTLD-SERVERS.NET. com. 2D IN NS E.GTLD-SERVERS.NET. com. 2D IN NS M.GTLD-SERVERS.NET. A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30 Jeder Root Server ist durch einen Buchstaben (A-M) gekennzeichnet. Wie im Beispiel oben zu sehen ist, gibt es einen A-Root Server, einen G-Root Server, H-Root Server, etc. Jeder dieser Root Server steht an einem anderen Ort. Der E-Root Server steht zum Beispiel in Mountain View, California, USA und wird vom NASA Ames Research Center betrieben. 2.4.2 Logische Aufteilung der TLDs Die TLDs sind unterteilt in cctld und gtld. Unter die cctlds fallen alle zweistelligen TLDs. Sie wurden für Länder und Territorien eingeführt und werden als country-code bezeichnet. Jedes Land oder Territorium ist für seine cctld verantwortlich. Die gtld werden als generic bezeichnet und haben drei oder mehr Buchstaben. Die gtlds können nochmals in stld und utld unterteilt werden. Die so genannten sponsored TLDs (stld) werden durch ein Konsortium von Sponsoren verwaltet. Im Jahr 2001/2002 wurden drei stlds eingeführt.aero,.museum,.coop. In derselben Periode wurden nicht gesponserte TLDs (unsponsored TLDs oder utlds) eingeführt. So wurden die schon vorhandenen utlds.com,.edu,.gov,.int,.mil,.net, und.org um.biz,.info,.name, und.pro erweitert. T LD cct LD gt LD.arpa st LD ut LD Abbildung 2.8: TLD-Hierarchie Wie man aus der Abbildung 2.8 sieht, gibt es neben den cctlds und gtlds die TLD.arpa, die nur für technische Zwecke gebraucht wird. 2.5 Mobile IP Mit Hilfe von Mobile IP kann die Mobilität von Systemen, wie z.b. Laptops und PDAs, gewährleistet werden. Mobile IP ist eine Erweiterung des Internet Protokolls, das ursprünglich in RFC 2002 [10] definiert wurde und mit RFC 3344 [11] erweitert wurde, wobei bei der Einführung von Mobile IP keine Änderungen an den Systemen vorausgesetzt werden dürfen, welche Mobile IP nicht unterstützen (Transparenz von Mobile IP).

32 KAPITEL 2. TECHNISCHE GRUNDLAGEN 2.5.1 Forderungen an Mobile IP An eine Implementierung von Mobile IP werden zahlreiche Forderungen gestellt. Als erste Forderung kann angeführt werden, daß Mobile IP keine Änderungen an Systemen erzwingen darf, die bereits verwendet werden und die keine Mobilität brauchen, dies gilt sowohl für Hosts als auch für Router. Begründet werden kann dies mit der Vielzahl von Rechnern, die TCP/IP zur Kommunikation einsetzen. Es wäre utopisch zu verlangen, daß Nutzer, die keine mobilen Systeme nutzen, Änderungen an ihren Systemen vornehmen müssen, nur um die Mobilität anderer zu unterstützen. Deswegen muß bei der Entwicklung von Mobile IP auch darauf geachtet werden, daß eine Kommunikation mit Systemen, welche normales TCP/IP benutzen, weiterhin möglich ist. Weiterhin muß Mobile IP effizient sein. Das bedeutet, daß nicht zuviele Daten zur Verwaltung des Netzes gesendet werden dürfen. Dies spielt v.a. bei drahtlosen Netzen eine Rolle, da diese eine geringere Bandbreite bieten. Würden diese Netze auch noch mit einer Unzahl von Verwaltungsdaten belastet werden, würde man nicht mehr effizient über das Netz arbeiten können. Auch den Gesichtspunkt der Skalierbarkeit darf nicht vergessen werden, denn es kann davon ausgegangen werden, daß immer mehr mobile Systeme an das Internet angeschlossen werden. Deswegen ist es wichtig, daß Mobile IP auf eine wachsende Anzahl von Nutzern ausgelegt wird. Ein sehr wichtiger Aspekt in Mobile IP ist Sicherheit. Es muß darauf geachtet werden, daß alle Daten, welche von Mobile IP zur Verwaltung gesendet werden, mit Hilfe von AAA (Authentication, Authorization und Accounting) Mechanismen authentifiziert und authorisiert werden. Ein Problem würde z.b. dann entstehen, wenn Pakete zu einem System gelangen würden, das diese Daten nicht erhalten darf. Mit normalem IP kann nur festgestellt werden, ob eine IP-Adresse korrekt ist, nicht aber, ob Daten an einen rechtmäßigen Empfänger gesendet werden. Würden die genannten Anforderungen nicht erfüllt werden, so würde man riskieren, daß Mobile IP nicht akzeptiert werden würde und folglich zum Scheitern verurteilt wäre. 2.5.2 Begriffsdefinitionen In diesem Abschnitt werden die Begriffe eingeführt, welche nötig sind, um die Mechanismen von Mobile IP zu verstehen. Hierbei beziehen wir uns auf Mobile IP, wie es in RFC 2002 [10] festgelegt ist. Abbildung 2.9 zeigt den Aufbau eines Beispielnetzes, welches alle Komponenten enthält, die durch Mobile IP eingeführt wurden. Hierbei ist ein Mobile Node (MN, mobiler Knoten) ein Endsystem (z.b. Laptop oder PDA), welches seine Zugehörigkeit zu einem Netz von einem Netzwerk zu einem anderen verlagern kann. Ein MN besitzt eine statische IP-Adresse (Home Address) und kann mit anderen Systemen im Internet eine Verbindung aufrechterhalten, egal in welchem Netz der MN sich befindet, solange eine Verbindung auf Ebene der Vermittlungsschicht vorhanden ist. Das Home Network (HN, Heimatnetzwerk) ist das Netz, welchem der MN aufgrund seiner statischen IP- Adresse angehört. Befindet sich der MN in seinem HN, so ist keine Unterstützung durch Mobile IP notwendig. Das Foreign Network (FN, Fremdnetzwerk) ist das Netzwerk, in welchem sich der MN gegenwärtig aufhält und nicht sein HN ist. Ein Correspondent Node (CN, Kommunikationspartner) ist ein System, mit welchem der MN eine Verbindung unterhält. Dieser kann sowohl ein stationäres als auch ein mobiles System sein. Der Home Agent (HA, Heimatagent)

2.5. MOBILE IP 33 Abbildung 2.9: Aufbau des Beispielnetzes [1] bezeichnet einen Router, welcher sich im Heimatnetz des MN befindet. Seine Aufgabe ist es, alle Pakete, welche für den MN bestimmt sind, falls sich dieser nicht in seinem Heimatnetz aufhält, abzufangen und an den MN weiterzuleiten. Um die Weiterleitung von Datenpaketen zu ermöglichen, unterhält der HA eine Liste mit den Aufenthaltsorten aller MNs. Ein Foreign Agent (FA, Fremdagent) ist ein Router in dem Netz, in welchem sich der MN zur Zeit befindet. Dieser hat die Aufgabe Datenpakete, welche für den MN bestimmt sind zu entpacken und an diesen weiterzuleiten. Für Pakete, die der MN aus dem Fremdnetz heraussendet, fungiert der FA als Standard-Router. Desweiteren müssen zwei Adressen definiert werden, welche den MN eindeutig identifizieren: 1. Home Address Dies ist die statische IP-Adresse, welche dem MN zugeordnet ist. Diese Adresse ändert sich nie, unabhängig davon wo sich der MN befindet. 2. Care-of Address (COA) Die COA gibt den aktuellen Aufenthaltsort des MN an. Alle Pakete, welche an den MN gesendet werden, werden an die COA geliefert und nicht direkt an die Home Address des MN. Die Zustellung geschieht durch sogenanntes tunneln, welches in Abschnitt 2.5.4 erläutert wird. Es werden zwei Arten von COA unterschieden: (a) Foreign Agent COA: Hierbei ist die COA die Adresse eines FA. Der FA ist das Ende des Tunnels und für die weitere Zustellung der Pakete an den MN verantwortlich. (b) Co-located COA: In diesem Fall wird dem MN eine IP-Adresse zugeordnet, welche dem Adress-Pool des FN entstammt. Diese Adresse kann der MN beispielsweise durch DHCP (Dynamic Host Configuration Protocol [8]) erhalten. Wenn dem MN eine co-located COA zugeordnet wird, so ist der MN selbst der Tunnelendpunkt und für das Entpacken der Pakete verantwortlich. Ein Nachteil ist bei dieser Art der COA, daß ein Adress-Pool vorhanden sein muß, aus welchem der MN eine Adresse erhält. Dies führt, falls IPv4 verwendet wird, zu einer Verknappung der IP-Adressen. 2.5.3 Ablauf der Paketzustellung Nachdem die grundlegenden Begriffe eingeführt wurden, wird an dieser Stelle die Weiterleitung von Paketen von einem CN zu einem MN erläutert (siehe Abbildung 2.10). Es ist anzumerken,

34 KAPITEL 2. TECHNISCHE GRUNDLAGEN Abbildung 2.10: Ablauf der Paketzustellung [1] daß dem CN nicht bekannt sein muß, ob der MN mobil ist oder nicht. Desweiteren muß der CN nicht wissen, wo sich der MN zur Zeit befindet, er muß nur dessen Home Address kennen. Im ersten Schritt (1. in der Abbildung) sendet der CN ein Datenpaket an die Home Address des MN. Im Internet wird das IP-Paket weitergeleitet. Nachdem das Paket im HN angekommen ist, fängt der HA es ab. Diesem ist bekannt, daß sich der MN nicht im HN aufhält und er sendet deswegen das Datenpaket an die COA des MN (hierbei nehmen wir an, daß dem MN eine Foreign Agent COA zugeordnet wurde). Dies geschieht, indem er das Datenpaket an den FA durch einen Tunnel weiterleitet (2.). Der genaue Ablauf wird in Abschnitt 2.5.4 dargestellt. Nachdem das Datenpaket am FA angekommen ist, leitet der FA das Datenpaket an den MN weiter (3.). Will der MN, nachdem er das Datenpaket erhalten hat, Daten an den CN senden, so sendet der MN Pakete mit seiner Home Address als Quelladresse an die Adresse des CN (4.). Hierbei könnten Probleme auftreten, welche hier kurz vorgestellt werden. 1. Das FN, in welchem sich der MN befindet, wird durch eine Firewall vom Internet abgeschirmt. Diese Firewall könnte Pakete abblocken, welche eine Sendeadresse besitzen, welche nicht zum Adreßbereich des Netzwerks gehört (d.h. die Adressen stellen für das Netzwerk eine topologisch nicht korrekte Adresse dar). Da der MN aber mit seiner Home Address als Sende-Adresse Pakete verschickt, werden seine Pakete nicht durchgelassen. 2. Weiterhin könnte die TTL (Time to Live) so eingestellt sein, daß z.b. ein Manager im Netzwerk des Verwaltungsgebäude (hier das HN) alle Rechner erreicht. Befindet sich der Manager aber auf einer Konferenz, so kann es passieren, daß er auf Grund der zu geringen TTL nicht mehr alle Rechner im HN erreicht. In diesem Fall müßte man die TTL manuell, je nach Ort, einstellen. Dies verstößt aber gegen die Transparenz, welche man von Mobile IP verlangt. Die aufgeführten Probleme führten zur Entwicklung von Reverse Tunneling (RFC 2344, Reverse Tunneling for Mobile IP), welches die obengenannten Problem löst, aber neue (Sicherheits-) Probleme einführt, die teilweise bis jetzt noch nicht gelöst wurden. Für eine vertiefte Darstellung sei auf den RFC 2344 [14] und [15] verwiesen.

2.5. MOBILE IP 35 2.5.4 Tunneln In Abschnitt 2.5.3 wurde bereits kurz angemerkt, wie der HA Pakete an den FA weiterleitet (siehe 2. in Abbildung 2.10). An dieser Stelle wird die Vorgehensweise der Weiterleitung detaillierter dargestellt. Das Weiterleiten von Datenpaketen bezeichnet man im Allgemeinen als tunneln. Der Weg eines Datenpakets hat folgende Gestalt: Quelle Verpacker (encapsulator) Entpacker (decapsulator) Ziel. } {{ } Tunnel Der Tunnel beginnt beim Verpacker und endet beim Entpacker. Der Verpacker wird auch als Tunneleingangspunkt, der Entpacker als Tunnelausgangspunkt bezeichnet. Die Quelle ist im Fall von Mobile IP der CN, welcher Daten an den MN senden möchte. Befindet sich der MN nicht in seinem HN, so werden die Pakete vom HA abgefangen, der die Rolle des Verpackers inne hat. Der HA sendet dann das Datenpaket als ein neues Datenpaket an die COA. Dem Ursprungs-Paket wird hierzu einfach ein neuer IP-Header vorangestellt, der sogenannte äußere IP-Header (Outer IP Header, siehe Abbildung 2.11). Dieser Vorgang wird als IP in IP Encapsulation bezeichnet [12]. Abbildung 2.11: Verpacken eines Pakets [12] Die folgende Abbildung (Abb. 2.12) zeigt den Aufbau des Pakets, wenn es sich im Tunnel befindet. An dem IP-Header des eingegangenen Pakets wird nur eine Änderung vorgenommen, die TTL wird um 1 vermindert. Dies hat zur Folge, daß der Tunnel, aus der Sicht des Pakets, eine Länge von 1 hat. Abbildung 2.12: Aufbau des Pakets im Tunnel [12] Kommt das Paket beim Entpacker, dem Ende des Tunnels, an, so entfernt dieser den äußeren IP- Header und leitet das Paket an den MN weiter. Wir können also feststellen, daß mit Hilfe von IP

36 KAPITEL 2. TECHNISCHE GRUNDLAGEN in IP Encapsulation die Zustellung von Paketen vom CN zum MN bewerkstelligt werden kann. Beim Tunneln muß an folgende Punkte gedacht werden: 1. Die Größe des Datenpakets nimmt aufgrund des Hinzufügens des äußeren IP-Headers zu. 2. Man muß vor dem Senden wissen, daß das System am Ende des Tunnels das Entpacken durchführen kann. Desweiteren kann festgestellt werden, daß es Informationen gibt, die bei der IP in IP Encapsulation in beiden IP-Headern vorkommen, z.b. wird der Type of Service-Eintrag vom inneren in den äußeren IP-Header kopiert, also doppelt übertragen werden. Ein verbessertes Tunneling Protokoll mit weniger Overhead ist das Minimal Encapsulation, welches im RFC 2004, [13], festgelegt ist. 2.5.5 Agent Discovering Eine wichtige Frage ist, wie ein MN überhaupt feststellen kann, wo er sich zur Zeit befindet, d.h. vor allem, ob er sich von einem Netzwerk in ein anderes bewegt hat. Eine Beantwortung der Frage ist vor allem deswegen wichtig, da der MN bei einem Wechsel seines Zugangspunktes eine neue COA erhalten muß, um seine Erreichbarkeit sicherzustellen. Die angesprochene Frage kann der MN mittels Agent Discovery ( Entdecken eines Agenten ) beantworten. FAs und HAs senden spezielle ICMP Router Advertisement Messages (hier kurz als Advertisement Message bezeichnet). Wenn diese Nachrichten in gleichen Abständen gesendet werden, so sollte der Abstand zwischen den Nachrichten 1 / 3 der Lebensdauer/Gültigkeitsdauer der Advertisement Message betragen. Dies erlaubt dem MN 3 Nachrichten zu verpassen, bevor er den Agenten für sich als ungültig erklärt. In diesen Advertisement Messages wird die sogenannte Mobility Agent Advertisement Extension als Nutzlast transportiert (siehe Abbildung 2.13). Abbildung 2.13: Aufbau einer Agent Advertisement Message [10], [17] Ein wichtiges Feld des ICMP Headers ist der Eintrag Lifetime, welches die bereits erwähnte Gültigkeitsdauer der Advertisement Message angibt. Die wichtigsten Einträge der Agent Advertisement Extension sind Registration Lifetime, welche die maximale Dauer der Gültigkeit einer Registrierung angibt (gemessen in Sekunden), die der jeweilige Agent akzeptiert, und die Einträge für die COAs, welche die durch den Agenten angebotenen COAs enthalten (in Abbildung 2.13 sind es in diesem Fall 2 COAs, es können aber auch keine, eine oder mehr als zwei

2.5. MOBILE IP 37 angeboten werden). Empfängt der MN eine Advertisement Message, so kann er daraus seinen Aufenthaltsort entnehmen und dann auf einen möglichen Ortswechsel reagieren. Andererseits kann der MN auch selbst nach einem Agenten suchen. Hierfür verwendet er Agent Solicitation Messages. Diese Nachrichten sollten aber nur dann von einem MN gesendet werden, wenn er keine Advertisement Messages empfängt und wenn er auch nicht durch andere Maßnahmen, wie DHCP, eine COA erhalten hat. Der MN verwendet für das Suchen die gleichen Nachrichten, wie sie für ICMP Router Solicitation Messages festgelegt sind. Zu beachten ist hier außerdem, daß der MN die Rate, mit welcher er die Solicitation Messages sendet, nicht zu hoch wählen sollte, um das Netzwerk nicht unnötig zu belasten (für weitere Details sei hier auf [10] und [11] verwiesen). Abschließend muß der MN seinem HA seine erhaltene COA mitteilen. Dieser Vorgang wird in dem folgenden Abschnitt erläutert. 2.5.6 Registrierung der Care-of Address Nachdem der MN eine neue COA erhalten hat, muß er diese dem HA mitteilen, um seine Erreichbarkeit sicherzustellen. Diesen Vorgang bezeichnet man als Registrierung. Bevor wir den Ablauf der Registrierung vorstellen, muß darauf hingewiesen werden, daß alle Pakete, welche für den Registrierungsvorgang verschickt werden, authorisiert werden müssen. Würde dies nicht geschehen, wäre der Vorgang anfällig für Angriffe. Der Ablauf der Registrierung findet auf zwei verschiedene Arten statt. Das Unterscheidungsmerkmal ist die Art der COA (co-located COA bzw. Foreign Agent COA). Wurde einem MN eine co-located COA zugewiesen, so sendet der MN eine Registrierungsanfrage (registration request) direkt an den HA. Der HA sendet dem MN dann eine Registrierungsantwort (registration reply) an die COA. Mit dieser Nachricht teilt der HA dem MN mit, ob er der Anfrage zustimmt oder ob er diese ablehnt. Den Ablauf dieser Art der Registrierung zeigt Abbildung 2.14. Abbildung 2.14: Ablauf der Registrierung bei Vorliegen einer co-located COA [1] Besitzt der MN hingegen eine Foreign Agent COA, so besteht der Ablauf der Registrierung aus folgenden Schritten: 1. Der MN sendet eine Registrierungsanfrage an seinen FA. 2. Der FA verarbeitet die Anfrage und leitet diese dann an den HA des MN weiter. 3. Der HA sendet nach der Bearbeitung der Anfrage eine Registrierungsantwort an den FA. Der HA hat die Möglichkeit die Anfrage abzulehnen oder ihr zuzustimmen. 4. Zum Abschluß der Registrierung sendet der FA die Antwort des HA an den MN.

38 KAPITEL 2. TECHNISCHE GRUNDLAGEN Abbildung 2.15: Ablauf der Registrierung, wenn eine Foreign Agent COA vorliegt [1] Während des Registrierungsprozeßes wird auch die Dauer der Gültigkeit der Registrierung verhandelt. Der HA speichert die Gültigkeitsdauer zusammen mit dem Aufenthaltsort des MN in einer Liste. Nach Ablauf der Gültigkeitsdauer löscht der HA den Eintrag, deswegen muß sich der MN regelmäßig beim HA registrieren. Für Registrierungsanfragen und -antworten werden UDP-Pakete eingesetzt. Den Aufbau der jeweiligen Nutzdaten zeigen die folgenden beiden Abbildungen (2.16 und 2.17). An dieser Stelle soll nur die Bedeutung des Eintrags Lifetime erwähnt werden, denn dieser gibt die Gültigkeitsdauer der Registrierung an. Die Bedeutung der anderen Felder ist entweder selbsterklärend oder kann [10] entnommen werden. Abbildung 2.16: Aufbau der Nutzlast einer Registrierungsanfrage [10] Abbildung 2.17: Aufbau der Nutzlast einer Registrierungsantwort [10] 2.5.7 Handover Handover oder Handoff in mobile IP bezeichnet das Wechsel des Foreign-Agents und damit auch die COA. Das Nachführen der bestehenden Verbindungen bzw. das Umleiten von Benutzerdaten in Fall eines Handovers müssen sichergestellt werden. Die neue COA muss dazu beim HA neu registriert werden. Der Ablauf der Registrierung beim Handover, wenn der MN eine Foreign-Agent Care-of-Address benutzt, besteht aus den folgenden Schritten:

2.5. MOBILE IP 39 Der Client empfängt beim Eintritt in das neue Subnetz die Agent Advertisment vom neuen FA. Damit bemerkt der Client, dass er sich in einem neuen Subnetz befindet, und dass er sich neu registrieren muss. Von dem Agent Advertisment kennt der Client seine neue COA (das ist die Adresse von FA). Der Client sendet dem FA ein Register Request. Der FA sendet ein Register Request weiter zu dem HA des mobilen Endgerätes. Der HA antwortet dem FA mit einem Register Reply, in dem es mitgeteilt wird, ob sich der Client registrieren darf. Der FA sendet dem Client ein Register Reply, und damit ist die Registrierung unter der neuen COA erfolgreich abgeschlossen. Um das Weiterleiten der Pakete zu optimalisieren, kann der neue FA dem alten FA mitteilen, dass sich der Client neu registriert hat. Der alte FA bestätigt dies und leitet die Pakete, die fälschlicherweise noch an die alte COA adressiert sind, weiter an den neuen FA. 2.5.8 Probleme von Mobile IP Durch Mobile IP wird zwar das Problem mobiler Systeme gelöst, das Protokoll hat aber dennoch einige Nachteile, gerade im Bereich des schnellen Zellenwechsels, welche im folgenden vorgestellt werden. Ein erstes Problem ist, daß eine schnelle Übergabe (fast handoff) von einem Zugangspunkt zu einem anderen nicht möglich ist. Jedesmal, wenn der MN seine COA ändert, muß er dies seinem HA mitteilen. Es kann aber lange dauern, bis der HA von der Änderung der COA informiert wird, was durch Verzögerungen bei der Übertragung bedingt ist. Desweiteren wird der nahtlose Übergang (seamless handoff) von einem Zugangspunkt zu einem anderen durch Mobile IP nicht erreicht. Dies liegt an dem umfangreichen Registrierungsprozeß, bei dem es zwangsläufig auch zu Paketverlusten kommt. Dies führt auch zu einem erhöhten Verkehrsaufkommen, da verlorengegangene Pakete erneut gesendet werden müssen. Ein weiteres Problem ist die große Menge an Signalisierungsnachrichten (signaling traffic overhead), welche sich v.a. bei mobilen Systemen ergibt, welche häufig ihren Zugangspunkt wechseln. Bei Echtzeit- und Multimedianwendungen spielt auch Quality of Service (QoS) eine große Rolle. Bewegt sich der MN an einen neuen Ort, so wird zwischen HA und neuem FA eine Verhandlung der QoS-Parameter stattfinden, obwohl möglicherweise ein Großteil der Strecke zwischen einem CN und MN gleich geblieben ist. Insgesamt kann man also feststellen, daß Mobile IP im Bereich der Makro-Mobilität das Mobilitätsproblem löst. Bewegt sich der MN aber nur in einem kleinem Bereich und wechselt er in diesem auch noch häufig seinen Zugangspunkt, so treten die zuvor erwähnten Probleme auf. Dies führte zur Entwicklung von Protokollen, welche das Problem der Mikro-Mobilität lösen sollen.

40 KAPITEL 2. TECHNISCHE GRUNDLAGEN 2.5.9 Mobile IPv6 Das vorgestellte Mobile IP Protokoll basiert auf dem Internet Protokoll in der Version 4 (IPv4). An dieser Stelle werden wir kurz einige wesentliche Vorteile darstellen, die sich beim Umstieg von Mobile IP auf Mobile IPv6, das auf dem Internet Protokoll Version 6 (IPv6) basiert, ergeben. In die Entwicklung von Mobile IPv6 sind die Erfahrungen, welche bei der Entwicklung und dem Einsatz von Mobile IP gemacht wurden, eingeflossen. Weiterhin profitiert Mobile IPv6 auch von den Möglichkeiten, die IPv6 bietet. Als erstes kann festgestellt werden, daß der Adressraum von IPv6 größer ist als der von IPv4 (die Adresslänge von IPv4 beträgt 32 bit, die von IPv6 hingegen 128 bit). Dadurch wird die Adressknappheit beseitigt, welche bei der Vergabe von co-located COAs auftreten könnte. Zusätzlich bietet IPv6 Mechanismen, welche die Zuordnung einer COA zu einem MN erleichtern. Es handelt sich hierbei um das Neighbor Discovery-Verfahren, mit welchem jeder Knoten seine Nachbarn finden kann, und Stateless Address Autoconfiguration, wodurch dem MN eine IP-Adresse zugeordnet wird. Diese beiden Verfahren führen dazu, daß weder DHCP noch FAs benötigt werden, um einem MN in einem FN eine COA zuzuordnen. Weiterhin implementieren alle IPv6-Knoten Authentifizierungs- und Verschlüsselungsverfahren, um die Sicherheit im Internet zu gewährleisten. Diese Verfahren können von Mobile IPv6 genutzt werden und müssen nicht zusätzlich, wie in Mobile IP, implementiert werden. Um der Verschwendung von Bandbreite bei der Datenübertragung entgegenzuwirken, wurde zusätzlich das Verfahren Route Optimization (Wege-Optimierung) zum Protokoll von Mobile IP hinzugefügt. Route Optimization ist integraler Bestandteil von Mobile IPv6, in Mobile IP musste dieses Verfahren zusätzlich implementiert werden. Das Verfahren, welches hinter Route Optimization steht, wird in dem folgenden Beispiel erläutert (siehe Abbildung 2.18). Zwei Manager treffen sich auf einer Konferenz und wollen Daten zwischen ihren PDAs (MN1 Abbildung 2.18: Aufbau des Beispiel-Netzwerks bzw. MN2) austauschen. Im Normalfall läuft die Datenübertragung über die jeweiligen HAs (HA1 bzw. HA2) der Manager. Dass dies nicht sinnvoll sein kann, ist sofort einsichtig, denn die Manager sind vielleicht 1m voneinander entfernt, die jeweiligen HAs können aber beliebig

2.6. SECURITY 41 weit entfernt sein. Es wäre also besser, die Daten direkt zwischen den beiden PDAs auszutauschen, als diese über weite Strecken zu verschicken. Deswegen gibt es in Mobile IPv6 auch die Möglichkeit einem CN (der sowohl stationär als auch mobil sein kann), mit welchem der MN verbunden ist, die COA des MN mitzuteilen. Das heißt, dass die Manager ihre Daten direkt austauschen können, was Bandbreite spart. Ein weiterer Mechanismus, welcher durch Mobile IPv6 angeboten wird, kommt dann zum Einsatz, wenn ein MN keine Adresse eines HAs kennt. Dieser Mechanismus, Dynamic Home Agent Discovery, wird verwendet, um die Adresse eines HA zu ermitteln. Hierzu sendet der MN eine Nachricht an die Home Agents anycast address (RFC 2526, Reserved IPv6 Subnet Anycast Addresses), wodurch der MN einen Router in seinem HN erreicht, der auch als HA fungiert. Dieser HA sendet dem MN eine Liste mit allen HAs im HN. Daraufhin sendet der MN dem ersten HA auf der Liste eine Nachricht, um sich bei diesem anzumelden. Antwortet dieser nicht oder lehnt der potentielle HA eine Anbindung des MN ab, so geht er die Liste von oben nach unten durch, bis er eine Bestätigung der Anbindung an den HA erhält. In diesem Abschnitt wurden nur einige wenige Vorteile von Mobile IPv6 vorgestellt. Aber bereits die genannten Vorteile lassen das Potential erahnen, welches bei der Einführung von Mobile IPv6 zur Verfügung steht. Dennoch darf nicht vergessen werden, daß Mobile IPv6 nicht alle Probleme löst, welche bei der Nutzung mobiler Systeme auftreten. Zu diesen Problemen zählen nach [16] u.a. die folgenden Beispiele: 1. Es ist weiterhin nicht möglich, zwischen Paketverlusten aufgrund von Bitfehlern und Verlusten aufgrund von Stausituationen zu unterscheiden. 2. Es wird auch kein Verfahren genannt, mit welchem es möglich ist, angebotene Dienste zu finden. Weitere Beispiele für Vorteile von Mobile IPv6 und auch für die Unvollständigkeit von Mobile IPv6 finden sich in [16]. 2.6 Security 100% Sicherheit gibt es nicht, aber dennoch ist es wichtig Daten und Geschäftsgeheimnisse zu schützen. Im nachfolgenden Teil werden verschieden Methoden beschrieben wie man sich gegen Angriffe von Aussen schützen kann. Diese Methoden sind aber nur Teile des Sicherheitsmanagements und nicht vollständig. 2.6.1 Firewalling Eine Firewall ist ein Zugansschutzsystem, welchen den Zugang zwischen zwei Netzen regelt. In der Regel ist es das Intranet und das Internet. Firewalls können den Netzverkehr regeln und unerwünschte Daten vom internen Netz fernhalten. Es gibt verschiedene Arten von Firewalls, so gibt es Paketfilter, die auf der Netzwerkebene oder Transportebene arbeiten und Proxies, die auf der Applikationsebene arbeiten.

42 KAPITEL 2. TECHNISCHE GRUNDLAGEN Paket Filter Paket Filter analysieren den gesamten Verkehr des Netzes und entscheiden je nach Adresse, Port oder Transportprotokoll ob das Paket durchgelassen wird. Der Filter funktioniert in beide Richtungen, ausgehend sowie eingehend. Paket Filter können auch den Inhalt der Pakete analysieren, jedoch wird in der Regel nur der Header angeschaut, was resourcensparender gemacht werden kann. So kann zum Beispiel bei einem Webserver nur der Port 80 zugelassen werden, oder aber man kann die Firewall so konfigurieren, dass nur noch das Intranet erreicht wird. Mit Paketfiltern lässt sich unter anderem NAT (Network Address Translation) und Port Forwarding realisieren. NAT bietet die Möglichkeit eine IP durch eine andere zu maskieren. Das wird vor allem dazu benutzt wenn mehrere Benutzer sich eine IP im Internet teilen. Somit wird es möglich das mehrere Benutzer mit einer internen IP, z.b 192.168.x.y auf das Internet mit einer externen IP zugreifen. Die Rechner im Internet sehen dabei nur die externe IP. Anhand einer Tabelle kann der Traffic den einzelnen Rechner zugeordnet werden, und so die eintreffenden Pakete richtig verteilt werden. Abbildung 2.19: Firewall mit ausgehendem und eingehendem Anschluss Desktop-Firewalls Eine Desktop Firewall ist ebenfalls ein Paketfilter, aber mit zusätzlichen Eigenschaften. Eine Firewall auf dem Rechner des Benutzers hat den Vorteil, dass nicht nur generell Ports oder Adressen gesperrt oder erlaubt werden können, sondern man erreicht eine Filterung auf Applikationsbasis. So ist es denkbar den Internet Explorer nicht auf Port 80 zugreifen zu lassen, Firefox dagegen schon. Die Desktopfirewall kann bei keiner gefundenen Regel den Benutzer Fragen was er machen möchte, und daraus eine Regel generieren. Diese Regel wird gespeichert und beim nächsten mal wiederverwendet.