Projekt WiTAP Wireless Switch und Thin Access Points für KMU

Projekt WiTAP
Wireless Switch und Thin Access Points
für KMU
Pflichtenheft
BFH-TI, Juni 2008
Version 4.0
Abstract:
In Wireless Netzwerken kann mit Wireless fähigen Mobile Phones über VoIP telefoniert werden.
Diese Funktion ist jedoch auf das nähere Umfeld eines einzigen Access Points beschränkt. Mit der
Erarbeitung eines neuen kostengünstigen Lösungsansatzes mit einer zentralen Verwaltung der
gesicherten Kommunikationsverbindung, wird ein Wechsel der Funkzellen während des
Gesprächs ohne merkbaren Unterbruch oder andere Qualitätseinbussen realisierbar.
Schlüsselwörter:
Linux, IEEE802.11, CAPWAP, Thin-AP, Wireless-Switch, AC, WTP
Projektbeteiligte:
Michael Bernhard
Jlcoweg 1
3400 Burgdorf
034 426 68 92
Gerhard Hassenstein
Morgartenstr. 2c
3014 Bern
031 848 32 28
Rolf Lanz
Wankdorffeldstrasse 102
3014 Bern
031 848 32 73
Roger Weber
Jlcoweg 1
3400 Burgdorf
034 426 68 45
Pflichtenheft
Dokumentenverlauf
Version
Datum
Autor
Bemerkung
0
17.3.2008
M. Bernhard
Erstellung des Dokuments
1
16.4.2008
R. Weber
Cleanup des Vorhandenen
2
20.5.2008
R. Lanz
Erweiterungen, Ausbau der Kap. 3-8
3
22.5.2008
M. Bernhard
Erweiterungen
4
24.6.2008
R. Lanz
Korrekturen und Ergänzungen aus dem ersten Review
Seite 2
Pflichtenheft
Inhaltsverzeichnis
1
Einführung.............................................................................................................................1
1.1 Zweck.................................................................................................................................1
1.2 Zielsetzungen.....................................................................................................................1
1.3 Leserkreis...........................................................................................................................1
1.4 Einsatzgebiet......................................................................................................................1
1.5 Vorgesehene Erweiterungen..............................................................................................2
1.6 Abgrenzungen....................................................................................................................2
1.7 Aufbau des Dokuments......................................................................................................3
1.8 Definitionen und Abkürzungen............................................................................................3
2
Umfeld....................................................................................................................................5
2.1 CAPWAP............................................................................................................................5
2.2 Linux...................................................................................................................................5
2.3 HostAP Daemon.................................................................................................................5
2.4 WPA-Supplicant.................................................................................................................6
2.5 Kommerzielle Produkte.......................................................................................................6
2.6 Berner Fachhochschule, Technik und Informatik................................................................6
2.7 Verwandte Arbeiten............................................................................................................7
2.7.1 Stand der internationalen Forschung und Entwicklung ..................................................7
2.7.2 Arbeiten und Publikationen in Zusammenhang mit 'Switched WLAN' ...........................7
3
Wireless Switch.....................................................................................................................8
3.1 Übersicht............................................................................................................................8
3.2 Anforderungen....................................................................................................................8
3.2.1 Verwaltung.....................................................................................................................8
3.2.2 Überwachung und Konfiguration....................................................................................9
3.3 Hardware............................................................................................................................9
3.4 Software.............................................................................................................................9
4
Thin-AP................................................................................................................................10
4.1 Übersicht..........................................................................................................................10
4.2 Anforderungen..................................................................................................................10
4.2.1 Konfiguration................................................................................................................10
4.2.2 Funktionen und Dienste...............................................................................................11
4.2.3 Monitoring....................................................................................................................11
4.3 Hardware..........................................................................................................................11
4.3.1 Entwicklungssystem.....................................................................................................12
4.3.2 Schulungssystem.........................................................................................................12
4.3.3 Zielsystem....................................................................................................................12
4.4 Software...........................................................................................................................12
4.4.1 Entwicklungssystem.....................................................................................................12
4.4.2 Zielsysteme..................................................................................................................12
5
Supplicant............................................................................................................................13
5.1 Übersicht..........................................................................................................................13
Seite 3
Pflichtenheft
5.2
5.3
5.4
Anforderungen..................................................................................................................13
Hardware..........................................................................................................................13
Software...........................................................................................................................13
6
Zusammenfassung der Anforderungen............................................................................14
7
Schnittstellen.......................................................................................................................15
7.1 Externe Schnittstellen.......................................................................................................16
7.2 Interne Schnittstellen........................................................................................................16
8
Datenbasis...........................................................................................................................17
9
Testfälle...............................................................................................................................18
9.1 Übersicht..........................................................................................................................18
9.2 Durchführung....................................................................................................................18
9.2.1 Aufbau eines Tests......................................................................................................18
10
Referenzen ..........................................................................................................................19
Seite 4
1 Einführung
Pflichtenheft
1 Einführung
1.1 Zweck
Dieses Dokument beschreibt die Anforderung an Architektur und Implementation eines Wireless
Switch und Thin-AP. Diese beiden Komponenten sollen im Rahmen des BFH-Forschungsprojekts
„WiTAP – Wireless Switch und Thin Access Point für KMU“ spezifiziert und als Prototyp realisiert
werden. Es enthält somit die im Projekt WiTAP zu erreichenden Ziele. Diese werden priorisiert.
1.2 Zielsetzungen
Mit der Entwicklung eines Wireless-Switch und Thin-AP sollen folgende Ziele erreicht werden:
●
Zentrale Verwaltung von sicheren Kommunikationsverbindungen im Wireless-Switch
●
Minimale Anforderungen an Hard- und Software für die Thin-APs, damit eine kostengünstige Hardware genutzt werden kann
●
Schnelles und unterbrechungsfreies Roaming um VoIP in einem WLAN zu ermöglichen
●
Gesicherte Verbindungen bis in ein geschütztes Netzwerk
●
Kostengünstige Lösung basierend auf Standardhardware
●
Open-Source Implementierung
1.3 Leserkreis
Dieses Dokument richtet sich an alle Beteiligten des Projekts. Für die direkt am Projekt arbeitenden Personen dient es als Zielvorgabe. Die Projektpartner können sich mit diesem Dokument über
die Details der angestrebten Ziele informieren und so das Projekt im Rahmen ihrer Möglichkeiten
unterstützen. Alle weiteren Personen erhalten durch dieses Dokument einen Überblick der zu erfüllenden Requirements.
1.4 Einsatzgebiet
Mit dem Resultat des Projekts WiTAP soll es möglich sein, eine Switched-WLAN Infrastruktur für
KMU kostengünstig zu realisieren. Die Software für Wireless Switch und Thin-AP laufen auf Standardhardware.
Dies ergibt die folgenden Vorteile für den Anwender:
●
Durch den angestrebten tiefen Preis der Hardwarekomponenten können auch kleinere Unternehmen von den Vorteilen dieser Technologie profitieren. Mit der Überwachung der optimalen Sendeleistung und der Empfangsempfindlichkeit aller Thin-APs kann eine hohe
Kommunikationsqualität erreicht werden. Zudem gewährleistet eine niedrige Sendeleistung
eine geringe Gesamtbelastung der Mitarbeiter durch die von den Thin-APs ausgehende
nicht ionisierende Strahlung.
●
Der Einsatz von Wireless LAN fähigen Mobile Phones ermöglicht den Verzicht von parallel
betrieben Netzen für Personensuch- und DECT-Anlagen. Statt drei parallel betriebener Wi-
Seite 1
1 Einführung
Pflichtenheft
reless-Installationen, genügt eine einzige Technologie mit einer auf einen Zehntel verringerten Sendeleistung. Gleichzeitig reduziert sich damit auch der Unterhaltsaufwand.
Der Gewinn für einen Anbieter liegt in den damit zu erbringenden Dienstleistungen wie:
●
Projektengineering
●
Ausmessen des Gebäudes
●
Planung der Anzahl benötigter Thin-APs und der dazu notwendigen Verkabelung
●
Installation der Verkabelung und der Thin-APs
●
Inbetriebnahme der Wireless-Infrastruktur
●
Kundenschulung und Übergabe der Anlage
●
Maintenance der WLAN-Installation mit einem Wartungsvertrag
Das Einsatzgebiet ist jedoch praktisch unbeschränkt, da die entwickelte Software Open-Source
und somit frei zugänglich ist. Das Ergebnis kann somit von jedermann an seine eigenen Bedürfnisse angepasst und erweitert werden.
1.5 Vorgesehene Erweiterungen
Das Projektresultat sieht einen Prototypen vor. Darauf aufbauend sind mehrere Erweiterungen
denkbar:
●
Redundante Wireless Switch
●
Dezentrale Verwaltung der Security Credentials aller vorhandenen Clients
●
GUI zur Konfiguration, Verwaltung und Überwachung
●
Verwendung von Beschleunigungs-Hardware für die Ver- und Entschlüsselung des WLAN
Traffics auf dem Wireless-Switch
1.6 Abgrenzungen
Die Arbeit hat zum Ziel, ein Switched WLAN für einige wenige Thin-APs zu realisieren. Im Vordergrund steht die Realisierbarkeit das gewählten Ansatzes. Ein Produkt mit hoher Performance bei
grösseren Installationen ist daher nebensächlich. Der im Forschungsprojekt entwickelten Prototyp
muss daher auch noch nicht Produktereife erlangen. Erstes Ziel ist es, ein lauffähiges System zu
erhalten, mit dem die Funktionalität geprüft und demonstriert werden kann. Unterstützt werden vorerst nur die weit verbreiteten Standards IEEE802.11b/g und ev. IEEE802.11a, jedoch noch nicht
die deren Erweiterung nach IEEE802.11n.
Das Resultat des Projekts soll Open-Source sein. Auf den Einsatz von proprietären oder lizenzpflichtigen Software-Produkten wird klar verzichtet.
Die Steuerung und Kontrolle des Wireless-Switch erfolgt über Konfigurationsdateien, Programm
Argumente beim Start und falls notwendig, über ein einfaches Kommandozeilen-Interface. Alle notwendigen Schnittstellen für eine spätere Erweiterungen mit einem GUI, werden jedoch im Design
bereits vorgesehen.
Seite 2
1 Einführung
Pflichtenheft
1.7 Aufbau des Dokuments
Dieses Dokument ist in verschiedene Kapitel unterteilt. Das Kapitel 2 bespricht das Umfeld für diese Arbeit. Dabei wird auch auf Komponenten eingegangen, welche die Grundlage für das Projekt
darstellen.
Im Kaptiel 3 sind die Anforderungen an den Wireless Switch definiert. Die Anforderungen an die
Software für den Thin-AP wird im Kapitel 4 festgelegt. Die Besonderheiten und Anforderungen an
den Supplicant werden in im Kapitel 5 beschrieben. Schliesslich werden in Kapitel 6 auf Seite 14
alle Anforderungen zusammengefasst und priorisiert.
Die Schnittstellen werden im Kapitel 7 beschrieben und die benötigte Datenbasis in Kapitel 8 erklärt. Zum Schluss wird im Kapitel 9 das Vorgehen für die durchzuführenden Test beschrieben.
1.8 Definitionen und Abkürzungen
Abkürzung
Erklärung
AAA
Authentication, Authorization and Accounting
AC
Access Controller (Wireless Switch bei CAPWAP)
AP
Access-Point, Funkzugangs-Knoten, im Projekt WiTAP meist ein Thin-AP
respektive ein WTP
Authenticator
Ein AP, der eine Station nach IEEE 802.1X authentifiziert übernimmt die Rolle
des Authenticator.
BFH
Berner Fachhochschule
BSS
Basic Service Set. Eindeutige Funknetzkennung eines einzelnen APs
CAPWAP
Control And Provisioning of Wireless Access Points ein IETF Protokoll-Darft
DS
Distributed System, mehrere Access-Points mit identischer SSID, die über ein
gemeinsames LAN miteinander verbunden sind und im Workgroup-Mode betreiben werden.
ESS
Extended Service Set. Identische Funknetzkennung mehrerer APs eines
Distributed Systems
IEEE
Institute of Electrical and Electronics Engineers
IETF
Internet Engineering Task Force
MRU-MIG
Master Research Unit - Mobile Informationsgesellschaft, ein
Forschungsschwerpunkt des Departements TI der BFH
Radius
Remote Authentication Dial-In User Service, definiert ein Verfahren wie sich
Benutzer in ein Netz einwählen und anmelden können.
SSID
Service Set ID, ein 31 Byte langer String zu Funknetzkennung
SOHO
Small Office / Home Office
Station
Endpunkt der Wireless-Verbindung beim Benutzer. z.B. Laptop, Subnotebook,
PDA, Mobile, usw.
Supplicant
Hier der WPA-Client, d.h. die Authentisierungs- und Verschlüsselungs-Software
auf der WLAN nutzenden Station.
Seite 3
1 Einführung
Pflichtenheft
Abkürzung
Erklärung
Thin-AP
Access-Point mit minimaler Funktionalität; wird dadurch preiswert
TI
Hier die Abkürzung für das Departement Technik und Informatik der BFH
VoIP
Voice over IP
WG
Working Group bei den Standardisierungsgremien
WirelessSwitch
Zentrale Koordinationsstelle für alle APs, Verbindet die APs sternförmig. Je
nach Ansatz auf dem ISO/OSI-Layer 1 , 2 oder 3
WLAN
Wireless LAN
WPA
Wi-Fi Protected Access ist eine sicheres Verschlüsselungsverfahren für WLAN.
WTP
Wireless Termination Point (Access-Point bei CAPWAP)
Seite 4
2 Umfeld
Pflichtenheft
2 Umfeld
2.1 CAPWAP
CAPWAP ist ein Protokoll, das die Interoperabilität von WLAN-Produkte für zentralisierte WLANs
ermöglichen soll. Eine Working Group (WG) bei der IEFT beschäftigt sich mit der Definition dieses
Protokolls. Auch in der IEEE befassen sich eine Working Group mit Einsatz von CAPWAP für zukünftige Standards.
Die CAPWAP Working Group hat sich zum Ziel gesetzt, das CAPWAP Protokoll zu entwickeln, um
die Interoperabilität zwischen verschiedenen WLAN Backend-Architekturen sicherzustellen.
Der Zweck des CAPWAP Protokolls ist, die Kontrolle, das Management und die Beschaffung von
WTPs zu vereinfachen. Es spezifiziert die Dienste, Funktionen und Ressourcen der WTPs und des
ACs um interoperable Implementation zu ermöglichen. So kann des Anwender bei der Beschaffung und bei eventuellen späteren Erweiterungen frei und ohne Rücksicht auf bereits vorhandenes
Material, den für ihn optimalsten Hersteller wählen kann.
2.2 Linux
Das Linux Betriebssystem mit seinem quelloffenen Kernel hat heute einen Funktionsumfang und
Qualitätsstandard, der sich mit anderen Betriebssystem-Hersteller messen kann. Eine Schwachstelle bleiben jedoch Treiber für aktuelle Hardware. Leider veröffentlichen Hardware-Hersteller
nicht immer ihre Spezifikationen und Treiber. So bleibt oft nur der Weg über ein Reverse-Engineering. Die damit erzielten Ergebnisse beherrschen dann meist nur die absolut notwendigen Funktionen und sind damit entsprechend eingeschränkt.
In der Kernel-Version 2.6.22 ist bereits der neue IEEE 802.11 Stack aufgenommen worden und
seither bauen mehrere Treiber darauf auf. Durch die Vereinheitlichung der Infrastruktur wird die
Funktionalität zuverlässiger und auch für Programme im User-Space ist es nun wesentlich einfacher die WLAN-Hardware zu verwenden.
Die Unterstützung für den AP-Modus ist zwar noch nicht vollständig, dass dürfte sich aber in kurzer
Zeit bereits deutlich verbessern. Viele Kernel-Entwickler arbeiten intensiv daran, die restlichen Probleme zu beheben und noch fehlende Funktionen zu implementieren.
2.3 HostAP Daemon
Um einen AP unter Linux zu betreiben, braucht es ein geeignetes User-Space-Programm. Mit dem
Programm "hostapd" wurde dies bereits erfolgreich realisiert. Dieses konfiguriert die WLAN-Hardware für den AP-Modus, verwaltet die angemeldeten Stations und ist Authenticator für den Aufbau
der sicheren Verbindung.
Der Support für den neuen WLAN-Stack gibt es im Moment nur in einer Entwicklungsversion, welche jedoch bereits brauchbar ist.
Seite 5
2 Umfeld
Pflichtenheft
2.4 WPA-Supplicant
Für den Aufbau einer sicheren Verbindung nach IEEE 802.11i braucht es auch auf der Client-Seite, der Station, ein User-Space Programm. Es wird Supplicant genannt und hat zur Aufgabe das
EAP-Protokoll zu verarbeiten und den Schlüssel in der WLAN-Hardware zu installieren.
Unter Linux gibt es das Programm "wpa_supplicant". Es wurde vom selben Entwickler wie das
Programm "hostapd" erstellt und teilt sich auch einen Teil des Source-Codes mit diesem. Die modernen Distributionen integrieren den Supplicant in ihre Netzwerkkonfigurationstools.
Natürlich verfügt auch Windows, OS X und alle anderen Betriebssysteme mit WLAN-Unterstützung
über einen Supplicant. Diese werden meist vom Betriebssystemhersteller zusammen mit dem Betriebssystem zur Verfügung gestellt.
2.5 Kommerzielle Produkte
Es existieren bereits ein grosse Zahl von Produkten die einen zentralen Ansatz verfolgen. Die
meisten sind gut geeignet um grosse Gebiete oder mehrere Gebäude mit vielen Etagen mit WLAN
zu erschliessen. Bei allen ist jedoch der Einstiegspreis für die notwendige Grundinstallation die HW
und SW-Lizenzen sehr hoch und rechtfertigt daher keine Installationen mit nur wenigen APs.
Hersteller von leistungsstarken Systemen sind:
●
Aruba
●
Cisco
●
Trapeze
●
Enterasys
Daneben versuchen erste Firmen mit einem stark vereinfachten Konzept, eine günstigere Lösung
mit nur wenigen Access Points zu erreichen. Die möglichst einfache Handhabung durch den Betreiber steht bei allen klar im Vordergrund. Nicht alle legen dabei jedoch einen grossen Wert auf
ein schnelles Handover beim Zellenwechsel.
Bekannte Hersteller sind:
●
Ruckus
●
Zyxel
●
Netgear
2.6 Berner Fachhochschule, Technik und Informatik
Das Projekt WiTAP wird innerhalb der MRU MIG des Departements TI durchgeführt. Beteiligt sind
Dozenten und Mitarbeiter aus den Fachbereichen EKT (Elektro und Kommunikationstechnik), Informatik und der Weiterbildung SWS (Software-Schule Schweiz).
Seite 6
2 Umfeld
Pflichtenheft
2.7 Verwandte Arbeiten
2.7.1 Stand der internationalen Forschung und Entwicklung
Nahezu alle vorhandenen WLAN-Installationen sind noch nicht in der Lage VoIP in genügender
Qualität bei einem Zellenwechsel zu übertragen. Der Hauptgrund liegt beim Aushandeln des
Schlüsselmaterials zwischen den Stations und den APs bei einem Wechsel der Funkzellen. Neue
Installationen können diesem Nachteil mit einem zentralen Wireless-Switch entgegen wirken. Die
Security Credentials werden hierbei nicht mehr pro Verbindung auf den zuständigen APs verwaltet,
sondern zentral auf dem Wireless-Switch. Die APs werden so, zu einfachen Thin-APs umfunktioniert und dienen nur noch zur Umsetzung der Daten auf den untersten Layern des ISO/OSI-Modells.
Alle aktuell erhältlichen Produkte sind firmenspezifische Lösungen und sind daher untereinander
nicht kompatibel. Für kleine Installation, wie sie typischerweise in KMUs benötigt werden, sind sie
wegen der relativ hohen Startinvestition meist wenig interessant.
Versuche einzelner Firmen wie Airespace [1] mit LWAPP eine offene Architektur mit offen gelegten
Protokollen und Komponenten zu definieren, erhielten nicht die gewünschte Beachtung. Auch die
IETF hat erst in einem zweiten Anlauf eine Arbeitsgruppe für ein offenes Protokoll ins Leben gerufen. Aktuell ist ein Draft [6] des von dieser Arbeitsgruppe definierten Protokolls CAPWAP verfügbar.
2.7.2 Arbeiten und Publikationen in Zusammenhang mit Switched WLAN
Einen Ansatz in diese Richtung verfolgt Prof. Dr. Martin Gergeleit von der FH in Wiesbaden [5],
wobei er seinen Lösungsansatz insbesondere für Anlagen in der Automatisierung mit Echtzeitanforderungen positioniert. So wie wir im Jahre 2005 mit einer Diplomarbeit im Fachbereich Informatik eine Machbarkeitsstudie [2] für eine Open Source Switched WLAN Lösung durchführten, wurde
auch an der FH Wiesbaden von Uwe Mülder [4] bereits eine Arbeit zu diesem Thema geleistet.
Eine Diplomarbeit an der Hochschule Rapperswil [3] mit dem Titel CWLAN befasste sich mit der
zentralisierten Verwaltung von Wireless-LANs und mit dem automatisierten Installationsprozess
von APs. In einer weiteren Diplomarbeit openCAPWAP [7] im Fachbereich Informatik an der BFHTI konnte gezeigt werden, dass sich das Protokoll CAPWAP auf den heute zur Verfügung stehenden SOHO-APs installieren und betreiben lässt. Diese für das Projekt WiTAP vorgesehene günstige Hardware verfügt aktuell über genügend Ressourcen wie CPU-Leistung, RAM und Flash-Speicher.
Seite 7
3 Wireless-Switch
Pflichtenheft
3 Wireless-Switch
3.1 Übersicht
Der Wireless-Switch ist der zentraler Verschlüsselungs- und Kontrollpunkt für den WLAN Datenverkehr. Er verwaltet die Thin-APs und ist der Authenticator für alle Stations. Er dient auch als
Transferstelle zwischen den Thin-APs und den eigentlichen Zielsystem im Netz.
Daneben koordiniert er alle Thin-APs um den zu erschliessenden Funkraum mit einer möglichst
tiefen Sendeleistung vollständig abdecken zu können.
3.2 Anforderungen
Alle für den korrekten Betrieb eines Thin-APs notwendigen Parameter und Konfigurationsdaten
sind auf dem Wireless-Switch zu verwalten und persistent zu halten, da die Thin-APs dazu nicht in
der Lage sein werden.
Ein Auswertung aller anfallenden Kommunikationsparameter ist in diesem Projekt noch nicht vorgesehen. Ebenso ist vorerst nur der Betrieb mit einer einzigen SSID innerhalb eines einzigen DS
(Distributed System) zu realisieren. In weiterführenden Arbeiten soll ein Ausbau auf mehrere SSID
jedoch möglich bleiben.
3.2.1 Verwaltung
Anforderung 1:
Verwaltung der Thin-AP mit ihren Parametern
(Prio: A)
Der Wireless-Switch muss alle Thin-APs verwalten können. Die Basiskonfiguration muss persistent gespeichert werden.
Anforderung 2:
Verwaltung der Stations
(Prio: A)
Während des Betriebs muss der Wireless-Switch alle Stations und je nach
gewählter Authentisierung auch dessen Benutzer kennen. Diese Daten müssen nach einem Neustart nicht mehr vorhanden sein.
Anforderung 3:
Verwaltung der Schlüsseldaten
(Prio: A)
Alle für eine gesicherte (verschlüsselte) Kommunikation notwendigen Daten
sind während des Betriebs zu unterhalten. Davon sind jedoch nur die für den
Aufbau einer sicheren Kommunikation notwendigen Daten persistent zu halten.
Anforderung 4:
Zulassen von Thin-APs
(Prio: B)
Thin-APs können in der Setup-Phase zugelassen oder abgewiesen werden.
Dies erfolgt in einer ersten Phase anhand der MAC- oder der IP-Adresse. Ein
zukünftige Überprüfung des Thin-APs anhand eines Zertifikats sollte aber dadurch nicht verhindert werden.
Seite 8
3 Wireless-Switch
Anforderung 5:
Pflichtenheft
Einfacher DHCP-Server
(Prio: B)
Der Wireless-Switch ist in der Lage für seine ihm zugewiesenen Thin-APs als
einfacher DHCP-Server zu agieren und den Thin-APs die minimal notwendige Basiskommunikationsparameter zu zuweisen.
3.2.2 Überwachung und Konfiguration
Anforderung 6:
Erfassen der aktuellen Kommunikationsparameter
(Prio: C)
Es sind alle für die Erfüllung der Anforderung 7 benötigten Daten zu erfassen. Weitergehende Auswertungen sollten dabei nicht behindert werden.
Anforderung 7:
Automatische Erstellung aller Betriebsparameter
(Prio: C)
Dazu gehören:
●
Ermitteln der minimal notwendigen Sendeleistung
●
Optimale Verteilung der zugelassenen Sendekanäle
●
Erkennen von ausgefallen Thin-APs und Einleiten von Gegenmassnahmen, wie z.B. Erhöhen der Sendeleistung der umliegenden ThinAPs.
3.3 Hardware
Für den Wireless Switch soll ein aktueller Standard-PC ohne spezielle Leistungsanforderungen
zum Einsatz kommen. Gegebenenfalls ist eine Erweiterung mit zusätzlicher VerschlüsselungsHardware vorzusehen. Es muss mindestens ein Fastethernet-Interface mit VLAN-Fähigkeit vorhanden sein.
3.4 Software
Als Betriebssystem ist eine aktuelle Linux-Distribution zu verwenden. Die zu verwaltenden Daten
sind in einer kleinen, einfachen und SQL-fähigen Datenbank abzulegen.
Seite 9
4 Thin-AP
Pflichtenheft
4 Thin-AP
4.1 Übersicht
Ein Thin-AP ist ein Access-Point, der zur Erfüllung seiner Funktion auf den Wireless-Switch angewiesen ist. Er dient als Schnittstelle zwischen der Wireless-LAN und dem Wired-LAN und damit
nötigenfalls für die Umcodierung der verschlüsselten Daten. Um die Hardware-Anforderungen an
den Thin-AP so gering wie möglich zu halten, ist auch die Software sehr schlank zu halten. Das
heisst auch, dass auf dem Thin-AP keine Konfigurationsdaten gespeichert werden. Ein Thin-AP
muss somit nach dem Einschalten immer zuerst eine gültige Konfiguration vom seinem WirelessSwitch beziehen, bevor er seine Arbeit aufnehmen kann.
4.2 Anforderungen
Zur Erfüllung der nachfolgenden Anforderungen können soweit sinnvoll und möglich die in Kapitel
2 aufgeführten Produkte, Protokolle und Lösungen herangezogen werden. Die gestellten Anforderungen sind innerhalb dieses Projekts nur für ein auf Ethernet und IPv4 basierendem Netzwerk zu
erfüllen.
4.2.1 Konfiguration
Anforderung 8:
Zuweisen der Basiskommunikationsparameter
(Prio: A)
Ein Thin-AP erhält seine IP-Adresse, Netzmaske, Default-Gateway und DNSServer-Adressen von einem für ihn zuständigen DHCP-Server.
Anforderung 9:
Finden des zuständigen Access Controllers
(Prio: A)
Der Thin-AP muss in der Lage sein, einen für ihn zuständigen WirelessSwitch selbständig zu finden.
Anforderung 10:
Laden der benötigten Software/Firmware
(Prio: B)
Der Thin-AP muss die Fähigkeit haben, die Firmware, welche er vom Wireless-Switch erhält, zwischenzuspeichern und nach einem Reboot einzuspielen (Autoupdate).
Anforderung 11:
Autokonfiguration
(Prio: B)
Der Thin-AP konfiguriert sich so, dass er mit dem Wireless-Switch kommunizieren kann, auf der WLAN-Seite aber noch deaktiviert bleibt.
Anforderung 12:
Setzen von Sende- und Empfangsparametern
(Prio: A)
Der Thin-AP muss die Parameter für das WLAN vom Access Controller entgegennehmen und die Einstellungen ausführen können. Dies sowohl bei der
Betriebsaufnahme direkt nach der Kontaktaufnahme zum Wireless-Switch,
wie auch während des Betriebs durch einen Auftrag des Wireless-Switches.
Seite 10
4 Thin-AP
Pflichtenheft
4.2.2 Funktionen und Dienste
Anforderung 13:
Verbindungsaufbau mit den vorhandenen Stations
(Prio: A)
Der Thin-AP muss in der Lage sein, Stations die keine Authentisierung unterstützen und keine Datenverschlüsselung benötigen zu assoziieren. z.B. für
den Einsatz in als public Hotspot.
Anforderung 14:
Verbindungsaufbau mit WPA2 fähigen Stations
(Prio: A)
Der Thin-AP muss in der Lage sein, Stations die den WPA2-Standard unterstützen zu assoziieren.
Anforderung 15:
Datenübertragung zwischen Wireless-Switch und Station
(Prio: A)
Der Thin-AP überträgt den Datenstrom zwischen Station und Access Controller verschlüsselt.
Anforderung 16:
Datenübertragung zwischen Thin-AP und Wireless-Switch
(Prio: A)
Die Datenübertragung zwischen dem Thin-AP und dem Wireless-Switch erfolgt gesichert. Dies gilt sowohl für die zu übertragenden Benutzerdaten wie
auch für die Kontroll- und Steuerdaten. Das genutzte Verfahren für die gesicherte Datenübertragung ist unabhängig davon zu wählen, ob die Thin-APs
den Wireless-Switch direkt im ISO/OSI-Layer 2 (im selben Subnetz) oder
über einen Router erreichen. Eine verbindungslose Kommunikation zwischen
Wireless-Switch und dem Thin-AP ist zumindest für die Benutzerdaten zu bevorzugen, da sich nur so eine brauchbare Qualität für VoIP realisieren lässt.
4.2.3 Monitoring
Anforderung 17:
Messen des RF-Raumes
(Prio: C)
Der Thin-AP muss in der Lage sein, periodisch Messungen auf allen WLANKanälen durchzuführen. Dabei sollen die auf einem Kanal sendenden und
empfangbaren APs ermittelt werden. Durch die Messung darf die normale
Kommunikation mit den assoziierten Stationen nicht gestört werden.
Anforderung 18:
Erfassen der weiterer Kommunikationsparameter
(Prio: C)
Es sind alle für die Erfüllung der Anforderung 7 benötigten Daten zu erfassen
und für die Auswertung auf dem Wireless-Switch bereit zu halten. Weitergehende Auswertungen sollten dabei nicht behindert werden.
Anforderung 19:
Melden der Ereignisse an den Access Controller
(Prio: B)
Die Resultate und Ergebnisse der Messungen müssen dem Wireless-Switch
auf Anfrage mitgeteilt werden können.
Seite 11
4 Thin-AP
Pflichtenheft
4.3 Hardware
Für das Projekt WiTAP sind soweit möglich, gebräuchliche und günstige Standard-Komponenten
aus dem SOHO-Segment zu verwenden.
4.3.1 Entwicklungssystem
Als Entwicklungssystem ist ein Standard-PC mit einer geeigneten WLAN-Karte für die Software-Erstellung zu verwenden. Zusätzlich sind ein bis zwei Laptop zu nutzen, die sich sowohl als Thin-AP
wie auch als Client einsetzen lassen.
4.3.2 Schulungssystem
Für den Unterricht im FB-EKT ist eine Portierung auf das CARME-Kits wünschenswert. Als WLANInterface ist eine WLAN-Adapter mit USB 2.0 vorzusehen.
4.3.3 Zielsystem
Das eigentliche Zielsystem für den Prototypen soll ein geeigneter WLAN-AP aus dem SOHO-Bereich sein. Dabei sind die noch genauer zu spezifizierenden Anforderungen an die vorhandenen
System-Ressourcen wie: Flash- und RAM-Speicher sowie CPU-Leistung für den Einsatz als ThinAP zu erfüllen.
Aktuell mögliche Produkte sind:
●
Buffalo; WHR-HP-G54
●
Linksys; WRT54GL
●
Weitere für openWRT geeignete Geräte
4.4 Software
Sowohl das Entwicklungssystem mit der Entwicklungssoftware, wie auch das Zielsystem sollen auf
Open-Source Produkten basieren.
4.4.1 Entwicklungssystem
Für das Entwicklungssystem ist eine weit verbreitete Linux-Distribution zu wählen. Eventuell erforderliche Anpassungen sind durch das Neubilden eines geeigneten Kernels vorzunehmen.
4.4.2 Zielsysteme
Während der Entwicklungsphase ist es sinnvoll für die genutzten Laptops die selbe Software wie
für das Entwicklungssystem zu verwenden. Die einzusetzenden Treiber für den WLAN-Stack mit
Master-Mode, müssen das Senden von selbst zusammengestellten Beacon-Frames erlauben.
Für den Betrieb auf einem SOHO-AP kommt die Linux Distribution OpenWRT in Frage, welche auf
diese Geräte zugeschnitten ist. Für das Carme-Kit hingegen, soll die im FB-EKT genutzte Entwicklungsumgebung zur Anwendung kommen.
Seite 12
5 Supplicant
Pflichtenheft
5 Supplicant
5.1 Übersicht
Das Gesamtsystem WiTAP soll mit aktuell verfügbaren Standard-Supplicants von Microsoft und
Linux genutzt werden können. Diese müssen heute aktuelle und gängige Erweiterungen unterstützen. Es ist von einer Modifikation dieser Komponenten soweit als möglich abzusehen. Verbesserungen des Linux "wpa_supplicant" können vorgenommen werden, wenn diese in das wpa_supplicant-Projekt zurück fliessen.
5.2 Anforderungen
Anforderung 20:
Standard Supplicant
(Prio: A)
Alle Standard-Suppplicants die aktuell unter Windows oder Linux zur Anwendung kommen, sollen unterstützt werden.
Anforderung 21:
Proactive Key Caching
(Prio: A)
Die auf dem Supplicant eingesetzte Software (WLAN-Treiber und Utilities)
unterstützen das Proactive Key Caching oder Opportunistic Key Caching.
Anforderung 22:
Sinnvolle Erweiterung das Linux "wpa_supplicant"
(Prio: C)
Erweiterungen am Linux "wpa_supplicant" sollen nur vorgenommen werden,
wenn diese einen klare Verbesserung der angestrebten Projektziele ergeben
und in das wpa_supplicant-Projekt zurück fliessen können.
5.3 Hardware
Alle aktuellen, handelsüblichen WLAN-Komponenten sollen unterstützt werden.
5.4 Software
Die von den Betriebssystem- oder Hardware-Herstellern wie auch von den LINUX-Distributionen
zur Verfügung gestellten Treiber und Utilities sollen ohne Anpassungen oder Erweiterungen genutzt werden können.
Seite 13
6 Zusammenfassung der Anforderungen
Pflichtenheft
6 Zusammenfassung der Anforderungen
Die verschiedenen Anforderungen an die Thin-AP und Wireless-Switch sind hier nochmals aufgelistet und priorisiert. Die Bedeutung der Prioritäten ist folgende:
A: Die Anforderungen mit dieser Priorität müssen zwingend implementiert werden, da nur so
die Funktionalität gewährleistet ist.
B: Diese Anforderungen sollten nach Möglichkeit implementiert werden.
C: Diese Anforderungen sollen im Rahmen dieser Arbeit angedacht werden und im Design
vorgesehen sein, müssen jedoch nicht implementiert werden.
Liste der Anforderungen:
Anforderung 1:
Verwaltung der Thin-AP mit ihren Parametern (Prio: A).................................8
Anforderung 2:
Verwaltung der Stations (Prio: A)...................................................................8
Anforderung 3:
Verwaltung der Schlüsseldaten (Prio: A).......................................................8
Anforderung 4:
Zulassen von Thin-APs (Prio: B)....................................................................8
Anforderung 5:
Einfacher DHCP-Server (Prio: B)...................................................................9
Anforderung 6:
Erfassen der aktuellen Kommunikationsparameter (Prio: C).........................9
Anforderung 7:
Automatische Erstellung aller Betriebsparameter (Prio: C)............................9
Anforderung 8:
Zuweisen der Basiskommunikationsparameter (Prio: A)................................10
Anforderung 9:
Finden des zuständigen Access Controllers (Prio: A)....................................10
Anforderung 10:
Laden der benötigten Software/Firmware (Prio: B)........................................10
Anforderung 11:
Autokonfiguration (Prio: B).............................................................................10
Anforderung 12:
Setzen von Sende- und Empfangsparametern (Prio: A)................................10
Anforderung 13:
Verbindungsaufbau mit den vorhandenen Stations (Prio: A).........................11
Anforderung 14:
Verbindungsaufbau mit WPA2 fähigen Stations (Prio: A)..............................11
Anforderung 15:
Datenübertragung zwischen Wireless-Switch und Station (Prio: A)...............11
Anforderung 16:
Datenübertragung zwischen Thin-AP und Wireless-Switch (Prio: A).............11
Anforderung 17:
Messen des RF-Raumes (Prio: C).................................................................11
Anforderung 18:
Erfassen der weiterer Kommunikationsparameter (Prio: C)...........................11
Anforderung 19:
Melden der Ereignisse an den Access Controller (Prio: B)............................11
Anforderung 20:
Standard Supplicant (Prio: A)........................................................................13
Anforderung 21:
Proactive Key Caching (Prio: A)....................................................................13
Anforderung 22:
Sinnvolle Erweiterung das Linux "wpa_supplicant" (Prio: C)..........................13
Seite 14
7 Schnittstellen
Pflichtenheft
7 Schnittstellen
Abbildung 1: Schnittstellenübersicht
Seite 15
7 Schnittstellen
Pflichtenheft
7.1 Externe Schnittstellen
Als externe Schnittstellen werden die Kommunikation zwischen Supplicant und Thin-AP, sowie die
Kommunikation zwischen Wireless-Switch und zukünftigen Management-System verstanden.
Die Schnittstelle zwischen Supplicant und Thin-AP hat den aktuellen Standards zu entsprechen
und ist sinnvollerweise 1:1 zu übernehmen. Das heisst, an der Software der Supplicants muss im
Normalfall nichts modifiziert oder angepasst werden.
Für eine zukünftige Erweiterung mit einem Management-System ist eine dafür geeignete Schnittstelle vorzusehen. Die Implementation diese Schnittstelle ist jedoch nicht Teil dieser Arbeit.
7.2 Interne Schnittstellen
Für die Kommunikation zwischen Thin-AP und Wireless-Switch wird CAPWAP verwendet. Um die
Daten auch über öffentliche Strecken im Internet transportieren zu können, sind diese zu Verschlüsseln. Hierzu ist nach Möglichkeit das DTLS-Protokoll zu verwenden. Der Prototyp soll vorerst nur Ethernet auf dem Access Layer und IP auf dem Network Layer unterstützen.
Seite 16
8 Datenbasis
Pflichtenheft
8 Datenbasis
Auf den Thin-APs sollen keine persistenten Daten abgelegt werden. Ein Thin-AP erhält seine IPAdresse von einem für ihn zuständigen DHCP-Server. Anhand seiner MAC- oder IP-Adresse (in
Zukunft eventuell anhand seines Zertifikats) kann er vom Wireless-Switch identifiziert und konfiguriert werden.
Die gesamte Datenhaltung erfolgt auf dem Wireless-Switch. Die Daten sind in einer einfachen,
kleinen SQL-fähigen DB abgelegt. Dies kann eine Memorybasierte DB-Lösung sein, wobei in diesem Fall die persistenten Daten in einem Konfiguration-File abzulegen sind.
Zu den persistent zu verwaltenden Daten gehören die folgenden, für den Betrieb des WirelessSwitch und der Thin-APs notwendigen Informationen:
●
Ein Frequenzplan, der beschreibt welche Kanäle genutzt werden dürfen.
●
Maximal zulässige Sendeleistung pro Thin-APs
●
Bekannte Thin-APs (MAC-Adresse, IP-Adresse, Seriennummer oder Zertifikat)
●
Gewählte Verschlüsselung (Open, WEP, WPA2)
Diverse weitere Daten die nur während des Betriebs von Bedeutung sind und daher nicht persistent gehalten werden müssen, sind:
●
Benutzername und MAC-Adresse der Station
●
Thin-AP und assoziierte Stationen (MAC-Adresse)
●
Verwendeter Sendekanal jedes Thin-AP
●
Benachbarte Thin-AP inkl. deren benutzte Kanäle
Es ist vorzusehen, dass in Zukunft weitere Daten für eine statistische Auswertung des Kommunikationsaufkommens erhoben werden können. Nur so ist ein Ausbau der Funktionalität möglich und
würde z.B. die Fehlersuche oder das Auffinden von fremden oder unbekannte APs erlauben.
Ebenso ist damoit später eine volumen- oder zeitabhängige Nutzungsberechnung realisierbar.
Seite 17
9 Testfälle
Pflichtenheft
9 Testfälle
Die zu erfüllenden Testfälle werden während der Designphase definiert. Alle Testfälle und deren
Ergebnisse werden in einem separaten Dokument zusammengefasst.
9.1 Übersicht
Während der Implementation sind alle bereits erstellten Funktionen und Module fortlaufen zu testen. Hierzu sind Unit-Tests, System-Tests und Integrations-Test sowie zum Projektende auch Abnahme-Tests durchzuführen.
Beim Testen der gesamten Anlage sind neben der normalen Kommunikation einer Station über
den Thin-AP und Wireless-Switch in einem LAN, auch der Aufbau einer sicheren Kommunikationsverbindung zu prüfen. Als wichtigste Test gelten die Kontrolle des schnellen Ablaufs im Zellenwechsel. Hierfür sind vor allem die erreichten Verbesserungen in der Umschaltdauer und damit der
Kommunikationsunterbruchsdauer zu messen und zu analysieren. Diese Ergebnisse sind mit kommerzielle erhältlichen Produkten zu vergleichen. Im Weiteren sind Tests mit einem WLAN-fähigen
VoIP-Telefon durchzuführen, um so auch eine subjektive Aussage über die Sprachqualität während eines Zellenwechsels zu erhalten.
9.2 Durchführung
Die Testfälle werden alle einzeln definiert. Jeder Testfall wird im Detail beschrieben und erhält
einen eindeutige Nummer. Das zu erwartende Ergebnis wird ebenfalls im Voraus definiert. Nach
der Durchführung des Tests, gilt dieser abhängig vom erzielten Ergebnis als erfüllt, teilweise erfüllt
oder nicht erfüllt. In den beiden letzten sind die vermuteten oder bekannten Gründe soweit als
möglich zu nennen. Die durchzuführenden Tests sind wann immer möglich und sinnvoll mit einem
geeigneten Tool zu automatisieren.
9.2.1 Aufbau eines Tests
Testfall 1:
Testfall (Name, Nummer, Durchführungsdatum, geprüfte Version)
Beschreibung des Testfalls (Aktion)
Ausgangslage
Erwartetes Ergebnis
Erreichtes Ergebnis
Erfüllt: (ja/Nein)
eventuell notwendige Korrekturmassnahmen
Seite 18
10 Referenzen
Pflichtenheft
10 Referenzen
[1] Airespace, Switched WLAN Hersteller, von Cisco übernommen
http://www.airespace.com
[2] WisWi, Erarbeitung eines Konzeptes für einen 'Open-Source Wireless Switch', Eine Diplomarbeit der BFH-TI, FB-Informatik von Manuel Haag und Thomas Heiz, Dezember 2005
http://www.hti.bfh.ch/fileadmin/img/HTI/Diplomarbeiten06/book_120.pdf
[3] CwLan, Centralized WLAN Management Application/Framework, HSR, Dezember 2006
[4] Mülder, 'Konzept und Implementierung einer offenen Switched WLAN Infrastruktur' Fachhochschule Wiesbaden, Uwe Mülder, Februar 2005
http://www.informatik.fh-wiesbaden.de/~gergelei/Dipl_Uwe_Muelder.pdf
[5] Gergeleit, Switched WLAN in der Automatisierung, Prof. Dr. Martin Gergeleit, Februar 2006
http://www.ttn-hessen.de/npkpublish/filestore/77/ws1_2_gergeleit.pdf
[6] CAPWAP, (Control And Provisioning of Wireless Access Points)
http://tools.ietf.org/wg/capwap
[7] OpenCAPWAP, Eine Objektorientierte Implementation des aktuellen CAPWAP-Drafts, Eine
Diplomarbeit der BFH-TI, FB-Informatik von Philip Schaller und Andreas Dröscher, November 2007
http://book.bfh.ch/pdf_book/Book-2007ok.pdf (Seite 100)
Seite 19