Abrechnung von Wireless LAN Roamingverträgen

Transcription

Freie wissenschaftliche Arbeit
zur Erlangung des akademischen Grades eines
Master of Science in Business Computing (Wirtschaftsinformatik)
über das Thema
Abrechnung von Wireless LAN Roamingverträgen
eingereicht im Fachbereich 4, Studiengang Wirtschaftsinformatik der
Fachhochschule für Technik und Wirtschaft Berlin
von
Diplom-Wirtschaftsinformatiker (FH)
Gandolf Holler
Zähringerstraße 29, 10707 Berlin
gandolf.holler@gmx.de
Erstbetreuer:
Prof. Dr. Burkhard Messer
Zweitbetreuer:
Prof. Dr. Ingo Claßen
Matrikelnummer:
76900258524
Berlin, 17. November 2003
Die nachfolgende Arbeit ist mit Unterstützung der T-Systems Nova GmbH in Berlin-Tegel
(Entwicklungszentrum Berlin) – genauer dem Bereich E21.5 – entstanden. Ich möchte mich
hiermit bei allen Kollegen für die nette Arbeitsatmosphäre und die fachliche Unterstützung
herzlich bedanken – insbesondere bei Michael Tschernigow für betriebswirtschaftliche und
konzeptionelle Anregungen, Michael Knuth für konzeptionelle und technische Vorschläge
sowie Kirti Singh-Kurbel, Sebastian Berg und David Sebastian Schmidt für zahlreiche
technische Diskussionen.
Weiterhin danke ich meiner Verlobten Caroline Heinemeyer, dass sie Verständnis für
teilweise lange Arbeitszeiten und auch gelegentliche nächtliche Schreibanfälle meinerseits
hatte.
Zu guter letzt vielen Dank an Prof. Burkhard Messer und Prof. Ingo Claßen, die mir in
organisatorischer und inhaltlicher Hinsicht sehr geholfen haben.
Inhaltsverzeichnis
Inhaltsverzeichnis ..................................................................................... I
Abbildungsverzeichnis ........................................................................... IV
Tabellenverzeichnis ................................................................................. V
Abkürzungsverzeichnis .......................................................................... VI
1
2
3
Einleitung ......................................................................................... 1
1.1
Problemstellung und Zielsetzung .................................................................. 1
1.2
Aufbau der Arbeit .......................................................................................... 2
Wireless LAN .................................................................................... 3
2.1
Technik ......................................................................................................... 3
2.2
Internationale Standards............................................................................... 6
2.3
Sicherheitsaspekte........................................................................................ 8
2.4
Aufbau von Hotspots................................................................................... 10
Wireless LAN Roaming ....................................................................13
3.1
Authentication, Authorization, Accounting nach Wi-Fi................................. 13
3.2
Strategien der Serviceanbieter ................................................................... 15
3.2.1
Wireless Internet Service Provider (WISP) .......................................... 15
3.2.2
Virtuelle WISP (V-WISP) ..................................................................... 16
3.3
Abrechnung zwischen Roamingpartnern .................................................... 16
I
4
5
6
7
Wireless LAN Marktübersicht ..........................................................18
4.1
WISP-Systemhersteller............................................................................... 20
4.2
Abrechnungssysteme ................................................................................. 26
4.3
Hotspotbetreiber (WISPs) ........................................................................... 26
4.4
Serviceanbieter (V-WISPs) ......................................................................... 27
4.5
Roamingbroker / Clearinghouse Betreiber.................................................. 28
Rechtliche Aspekte ..........................................................................30
5.1
Überwachung der Telekommunikation........................................................ 30
5.2
Speicherung und Qualität der Verbindungsdaten ....................................... 31
T-Systems Wireless LAN Lösung ....................................................33
6.1
WISP-Plattform ........................................................................................... 33
6.2
Roaming-Plattform ...................................................................................... 35
6.3
Clearinghouse-Plattform ............................................................................. 36
Schnittstelle für AAA-Daten.............................................................38
7.1
Anforderungen für das WLAN-Roaming ..................................................... 38
7.2
Analyse gängiger Schnittstellen.................................................................. 38
7.2.1
Radius ................................................................................................. 39
7.2.2
Diameter .............................................................................................. 44
7.2.3
Andere ................................................................................................. 48
7.2.4
Fazit..................................................................................................... 48
7.3
Definition der AAA-Schnittstelle .................................................................. 50
7.3.1
RADIUS-Schnittstelle aufbauend auf Wi-Fi ......................................... 50
7.3.2
Gesicherte Authentifizierung über anonyme Identifikation................... 61
II
8
Abrechnungsschnittstelle zwischen den Roamingpartnern ............68
8.1
8.1.1
IPDR .................................................................................................... 68
8.1.2
TAP3.................................................................................................... 72
8.1.3
Weitere Formate .................................................................................. 74
8.1.4
Fazit..................................................................................................... 75
8.2
Empfang der Daten von WISPs .................................................................. 76
8.2.1
Funktionalität ....................................................................................... 76
8.2.2
Datenstruktur ....................................................................................... 79
8.3
9
Standards zur Abrechnung von Verbindungsdaten .................................... 68
Versand der Daten an V-WISPs ................................................................. 84
8.3.1
Funktionalität ....................................................................................... 84
8.3.2
Datenstruktur ....................................................................................... 87
Zusammenfassung und Schlussbetrachtungen...............................91
Literaturverzeichnis ................................................................................. X
Glossar................................................................................................ XVIII
CD-Rom zur Arbeit ................................................................................ XIX
III
Abbildungsverzeichnis
Abbildung 1: Wireless LAN – Ad-Hoc-Modus.............................................................. 4
Abbildung 2: Wireless LAN – Infrastructure-Mode ...................................................... 5
Abbildung 3: Beispiel für ein Wi-Fi Zertifikat................................................................ 7
Abbildung 4: Aufbau eines öffentlichen Hotspots ...................................................... 11
Abbildung 5: Roaming nach Wi-Fi............................................................................. 14
Abbildung 6: Anzahl öffentlicher Hotspots – Prognose nach Gartner........................ 18
Abbildung 7: Anzahl der Nutzer öffentlicher Hotspots – Prognose nach Gartner ...... 19
Abbildung 8: Umsatz pro Hotspot – Prognose nach Gartner .................................... 20
Abbildung 9: Aufbau der T-Systems Wireless LAN Lösung ...................................... 33
Abbildung 10: T-Systems WISP-Plattform – Schematische Darstellung ................... 34
Abbildung 11: T-Systems Roaming-Plattform – Schematische Darstellung.............. 36
Abbildung 12: T-Systems Clearinghouse – Schematische Darstellung..................... 37
Abbildung 13: RADIUS – Struktur der Pakete ........................................................... 40
Abbildung 14: RADIUS – AAA-Sequenzdiagramm ................................................... 41
Abbildung 15: ANID-Roaming – Aufruf der Anmeldeseite......................................... 63
Abbildung 16: ANID-Roaming – Nutzer-Authentifizierung und ANID-Übermittlung ... 64
Abbildung 17: ANID-Roaming – Autorisierung und Accounting ................................ 66
IV
Tabellenverzeichnis
Tabelle 1: IEEE Standards für Wireless LAN .............................................................. 7
Tabelle 2: RADIUS-Attribute Access-Request .......................................................... 52
Tabelle 3: RADIUS-Attribute Access-Request (Vendor specific)............................... 53
Tabelle 4: RADIUS-Attribute Access-Reject ............................................................. 54
Tabelle 5: RADIUS-Attribute Access-Accept............................................................. 55
Tabelle 6: RADIUS-Attribute Access-Accept (Vendor specific) ................................. 56
Tabelle 7: RADIUS-Attribute Accounting-Request .................................................... 59
Tabelle 8: RADIUS-Attribute Accounting-Request (Vendor specific) ........................ 60
Tabelle 9: Parameterbeschreibung für den Aufruf der Roaming-Verteilerseite ......... 63
Tabelle 10: Parameterbeschreibung für die ANID-Übermittlung an T-Systems ........ 65
Tabelle 11: IPDR-Attribute für den Versand der Verbindungsdaten.......................... 81
Tabelle 12: Transformationslogik von IPDR in die Datenbankstruktur ...................... 83
Tabelle 13: Werte für den Status beim Versand von Verbindungsdaten................... 86
Tabelle 14: Verfügbare Attribute für den Versand von Verbindungsdaten ................ 88
V
Abkürzungsverzeichnis
AAA
Authentifizierung, Autorisierung, Abrechnung
ANID
Anonymer Identifier
API
Application Programming Interface
ASCII
American Standard Code for Information Interchange
ASN.1
Abstract Syntax Notation, Version 1
BER
Basic Encoding Rules
BPM
Business Process Manager
BSS
Business Support System
CAMEL
Customised Application for Mobile Network Enhanced Logic
CDR
Call Detail Record
CHAP
Challenge Handshake Authentication Protocol
CRM
Customer Relationship Management
CSV
Comma Separated Values
DIN
Deutsche Institut für Normung
DTD
Document Type Definition
EAP
Extensible Authentication Protocol
ERP
Enterprise Resource Planning
FTP
File Transfer Protocol
GPRS
General Packet Radio Service
VI
GSM
Global System for Mobile communications
GUI
Graphical User Interface
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
HTTP mit SSL Verschlüsselung
HCSDS
Hazardous Component Safety Data Statement
IANA
Internet Assigned Numbers Authority
IEEE
Institute of Electric and Electronic Engineers
IP
Internet Protocol
IPDR
Internet Protocol Detail Record
IPsec
Internet Protocol Security
IPv6
Internet Protocol Version 6
LAN
Lokal Area Network
LDAP
Lightweight Directory Access Protocol
MAC
Media Access Control (MAC-Adresse)
NAI
Network Access Identifier
NAS
Network Access Server
NASREQ Network Access Server Requirements
PAC
Public Access Controller
PAP
Password Authentication Protocol
PPP
Point To Point Protocol
VII
RADIUS Remote Authentication Dial In User Service
RAP
Returned Accounts Procedure
RegTP
Regulierungsbehörde für Telekommunikation und Post
RFC
Request For Comment
SCTP
Stream Control Transmission Protocol
SLIP
Serial Line Internet Protocol
SNMP
Simple Network Management Protocol
SOAP
Simple Object Access Protocol
SSID
Service Set Identity (Netzwerkname)
SSL
Secure Sockets Layer
TAP3
Transferred Account Procedure, Version 3
TCP
Transmission Control Protocol
TDSV
Telekommunikations-Datenschutzverordnung
TLS
Transport Layer Security
TKÜV
Telekommunikations-Überwachungsverordnung
TKV
Telekommunikations-Kundenschutzverordnung
UDP
User Datagram Protocol
UML
Unified Modelling Language
UMTS
Universal Mobile Telecommunications Systems
URL
Uniform Resource Locator
UTF8
Unicode Transformation Format-8
VIII
V-WISP
Virtual Wireless Internet Service Provider
VAS
Value Added Services (Mehrwertdienste)
VPN
Virtual Private Network
WECA
Wireless Ethernet Compatibility Alliance
WEP
Wired Equivalent Privacy
Wi-Fi
Wireless Fidelity (Markenname der WECA)
WISP
Wireless Internet Service Provider
WLAN
Wireless LAN
WPA
Wi-Fi Protected Access
XML
Extensible Markup Language
IX
1 Einleitung
1.1 Problemstellung und Zielsetzung
Aufgrund der immer größeren Verbreitung von drahtlosen Technologien – im privaten, im öffentlichen und im Unternehmensbereich – wird die Nachfrage nach einheitlichen Wireless LAN Zugangsdaten an verschiedenen Standorten immer größer. Wer
möchte sich schon in jedem Hotel oder jedem Café separat für die Nutzung des
Internets über Wireless LAN registrieren?
Ziel von T-Systems ist die Schaffung einer Wireless LAN Roaming-Plattform, die es
dem Endkunden ermöglicht, mit denselben Zugangsdaten Hotspots von verschiedenen WLAN-Anbietern zu nutzen (Flughäfen, Hotels, Bahnhöfe). Dazu muss nach
einer
Lösung
gesucht
werden,
wie
eine
sichere
und
trotzdem
einfache
Authentifizierung in verschiedenen Hotspots möglich ist. Außerdem ist zu klären, wie
eine dem Endkunden transparente Abrechnung der Nutzungsentgelte gewährleistet
werden kann. Im Backend-Bereich muss dafür gesorgt werden, dass eine korrekte
Abrechnung mit den Hotspot-Betreibern und den Service-Providern garantiert wird.
Der Endkunde hat hierbei einen Vertrag mit einem Service-Provider (z.B. T-Online,
Mobilfunkanbieter), nutzt dessen Dienste aber in einem externen Hotspot.
Im Rahmen der Master-Arbeit werden die vorhandenen Ansätze der T-Systems
Plattform hinsichtlich AAA (Authentifizierung,
Autorisierung
und
Accounting)
analysiert und mit Produkten anderer Anbieter verglichen. Daraus erfolgt eine
Schnittstellendefinition zu den Betreibern der Hotspots.
Weiterhin erfolgt eine Analyse von Schnittstellen zu verschiedenen RoamingPartnern bzw. Service-Providern, um einen gemeinsamen standardisierten Datenaustausch einerseits für AAA andererseits aber auch für den Austausch von aufbereiteten Verbindungsdaten zu definieren.
1
1.2 Aufbau der Arbeit
Im ersten Teil dieses Werkes wird zunächst auf die theoretischen Grundlagen eingegangen, die für das Verständnis der Arbeit notwendig sind. Dazu werden im folgenden Kapitel die Wireless LAN (WLAN) Technologie und die entsprechenden
Protokolle vorgestellt. Das darauf folgende Kapitel beschäftigt sich mit den
Grundlagen des Wireless LAN Roamings, definiert die Rollen der mitwirkenden
Parteien und erörtert die Möglichkeiten der Abrechnung.
Mit Zahlen und Fakten zum Thema öffentliches Wireless LAN beschäftigt sich das
dritte Kapitel. Hier werden Marktanalysen zusammengefasst sowie Produkte und
Marktanteile dargelegt. Anhand der Verfügbarkeit von einzelnen Protokollen in verschiedenen Produkten wird die Grundlage zur Auswahl eines geeigneten Übertragungsprotokolls gegeben.
Auf juristische Anforderungen und die notwendige Transparenz gegenüber den Endkunden wird im fünften Kapitel eingegangen.
Die weiteren Kapitel befassen sich explizit mit der Wireless LAN Lösung von TSystems. Dazu werden zunächst der geplante Aufbau und die Aufgaben der Plattform beschrieben. Im siebenten Kapitel erfolgen die Analyse möglicher AAAProtokollen, die Auswahl des optimal geeignetsten Protokolls sowie die Definition der
zu übertragenden Attribute. Im siebten Kapitel erfolgt die Analyse möglicher AAAProtokolle
sowie
die
Definition
der
zu
übertragenden
Attribute.
Für
die
Abrechnungsschnittstelle erfolgt Analyse, Auswahl und Attributdefinition im achten
Kapitel.
2
2 Wireless LAN
Der Wunsch nach öffentlichen oder halböffentlichen drahtlosen Netzwerken
(Wireless LANs) wird vor allem von Flughäfen, Hotels oder Betreibern anderer Einrichtungen, in denen sich Geschäftsreisende aufhalten, getrieben. Denn während der
Reise ist es häufig nur schwer möglich, komfortabel auf Online-Inhalte zuzugreifen.
Modem- oder ISDN-Anschlüsse sind meist nicht vorhanden oder können nicht genutzt werden. Sind Anschlüsse vorhanden, kann es leicht zu Kompatibilitäts- oder
Anwahlproblemen kommen. Der Zugriff auf fest installierte Internet-Terminals ist hierbei in der Regel keine Alternative, weil die Daten auf dem eigenen Notebook-PC
benötigt werden, z.B. im lokalen E-Mail-Programm. Drahtlose Verfahren bieten sich
hier für den Einsatz an. Die aktuellen Weitverkehrsnetze wie GSM, HCSDS, GPRS
werden allerdings wenig genutzt, denn der Zugang ist für die Anwender entweder zu
langsam oder aufgrund der benötigten Hardware und der Übertragungskosten zu
teuer. Der Nachfolgestandard UMTS wird in Europa nicht vor 2004 flächendeckend
verfügbar sein. Auch was die Online-Kosten anbetrifft kann man davon ausgehen,
dass UMTS nicht günstiger sein wird als heutige GSM-Dienste. Eine zehnminütige
Internetverbindung kann dann leicht 4 bis 5 Euro kosten. An lokalen Stellen – den so
genannten Public Hotspots – ist deshalb der Einsatz von Wireless LANs eine echte
Alternative zum Modemkabel oder zu UMTS.1
2.1 Technik
In dieser Arbeit möchte ich mich nicht ausführlich mit dem Thema Wireless LAN
Technik beschäftigen, da der Schwerpunkt auf der Abrechnung von Roamingverträgen liegt. Trotzdem ist es zum allgemeinen Verständnis zwingend erforderlich,
einen Überblick über die Wireless LAN Technik zu bekommen.
Wireless LANs – also Funknetzwerke – lassen sich in zwei verschiedenen Modi
betreiben: dem ‚Ad-hoc-Modus’ oder dem ‚Infrastructure Mode’. Im Ad-Hoc-Modus
1
vgl. Lancom (2003)
3
kommunizieren die PCs, ohne eine feste Basisstation untereinander. Die PCs bauen
miteinander Punkt-zu-Punkt-Verbindungen auf. Ein PC kann dabei mehrere
Verbindungen gleichzeitig öffnen. Dabei müssen sie sich natürlich innerhalb der
maximalen Reichweite befinden. Diese unterscheidet sich durch den benutzen
Standard (dazu später mehr), die Umgebungsbedingungen sowie die verwendete
Hardware.
Weiter
voneinander
entfernte
Stationen
können
hingegen
nicht
miteinander kommunizieren. Die Reichweite schwankt im Normalfall zwischen 30
und 150 Meter. Den Clients muss mitgeteilt werden, zu welchem Netzwerk sie
gehören. Dieses legt man über den Netzwerknamen, die so genannte SSID (Service
Set Identity), fest. „Der Ad-hoc-Modus ist letztlich am besten geeignet, wenn man gar
kein großes Funknetz aufbauen will“2, sondern nur eine geringe Anzahl von
Stationen auf kleinem Raum betreiben möchte. Er kommt daher für das in dieser
Arbeit betrachtete Roaming nicht in Frage, da in der Regel große Funknetze
verbunden werden sollen.
Abbildung 1: Wireless LAN – Ad-Hoc-Modus3
2
Siering (2001), S. 122
3
http://www.tecchannel.de/special/1045/images/0011282_PIC.jpg (27.05.2003)
4
Um einen Übergang vom WLAN in ein kabelgebundenes Netz zu schaffen ist eine
Basisstation notwendig. Der Betrieb von solchen Access Points ist nur im
Infrastructure Mode möglich. In diesem Modus kommunizieren die Clients nicht
untereinander sondern mit dem Access Point. Dieser dient dann als Repeater
zwischen den Clients und als Router zwischen drahtlosem und kabelgebundenem
Netzwerk. Der Netzwerkname (SSID) braucht – sofern nur genau ein drahtloses Netz
betrieben wird – ausschließlich im Access Point festgelegt werden. Bei den Clients
genügt die Einstellung ‚ANY’ als Netzwerkname.
Um große Funknetze aufzubauen, können mehrere Access Points zu einem Netz
zusammengeschlossen werden. Diese sollten so installiert werden, dass sich ihr
Wirkungsradius überschneidet. Für alle zum Netz gehörenden Access Points muss
dieselbe SSID konfiguriert werden, damit ein unproblematisches (lokales) Roaming
möglich ist. Roaming bedeutet hierbei den unterbrechungsfreien Wechsel zwischen
zwei Access Points und nicht den Wechsel zwischen Hotspots verschiedener Betreiber, so wie dies im Rest der Arbeit der Fall sein wird.
Abbildung 2: Wireless LAN – Infrastructure-Mode4
4
http://www.tecchannel.de/special/1045/images/0011284_PIC.jpg (27.05.2003)
5
Auch um zwei bestehende Netze zu verbinden können Access Points eingesetzt
werden. Mit speziellen Antennen können Entfernungen von bis zu 7 Kilometern
überbrückt werden.5 Dies wäre dann eine Art Richtfunk auf Ethernet-Basis, nicht
jedoch ein für verschiedene Endnutzer offenes System.
Access Points gibt es heute in den verschiedensten Ausführungen. Als einfacher
Access Point mit Ethernetanschluss, integriert in einen Router für ISDN oder DSL
und mit eingebautem Switch oder Printserver, um drahtgebundene Geräte anzuschließen.
Vereinfacht wird die Installation von Access Points in größeren Hotspots durch den
jüngst verabschiedeten Standard IEEE 802.3af-2003 (Power over Ethernet)6. Dieser
Standard definiert, wie die Access Points über das Netzwerkkabel mit Strom versorgt
werden, wodurch nur noch ein einzelnes Kabel verlegt werden muss.
2.2 Internationale Standards
Das IEEE (Institute of Electric and Electronic Engineers) befasst sich – ähnlich wie
das Deutsche Institut für Normung (DIN) – mit der Standarisierung von Technologien.
Im Auftrag des IEEE hat 1997 die Wireless Ethernet Compatibility Alliance (WECA)
den Standard 802.11 herausgegeben, die eine Kompatibilität zwischen den Geräten
verschiedener Hersteller gewährleistet. Inzwischen gibt es Anpassungen des ersten
Standards, andere Weiterentwicklungen sind noch vor der Verabschiedung:
IEEE-
Kurzbeschreibung
Standard
802.11
Datenrate bis 2 MBit/s im 2,4 GHz Band
802.11a
802.11 Erweiterung: Datenrate bis 54 MBit/s im 5,1 GHz Band;
in Europa nur eingeschränkt zugelassen
5
vgl. BSI (2002), S. 3
6
vgl. Heise (2003)
6
802.11b
802.11 Erweiterung: Datenrate bis 11 MBit/s im 2,4 GHz Band;
hohe Marktdurchdringung in Europa
802.11e
Zukünftige 802.11 Ergänzung: Quality Of Service; Priorisierung des
Datenverkehrs für einzelne Clients
802.11f
Zukünftige 802.11 Ergänzung: Weiterleitung von Benutzern zwischen
Access Points
802.11g
802.11 Erweiterung: Datenrate bis 20 MBit/s im 2,4 GHz Band
802.11h
Zukünftige 802.11a Anpassung für den Einsatz in Europa: Datenrate bis
54 MBit/s im 5,1 GHz Band
802.11i
Zukünftige 802.11 Erweiterung mit zusätzlichen Sicherheitsmerkmalen
802.1x
Spezifikation eines portbasierten Authentisierungsmechanismus durch
IEEE
Tabelle 1: IEEE Standards für Wireless LAN7
Zu einem Standard kompatible Geräte erhalten das ‚Wi-Fi’ Logo, welches die Kompatibilität bestätigt. Wi-Fi ist ein Markenname der WECA und bedeutet ‚Wireless
Fidelity’.8
Abbildung 3: Beispiel für ein Wi-Fi Zertifikat9
7
vgl. BSI (2002), S. 14; Mobileaccess.de (2003); Keene (2003a)
8
vgl. glossar.de
9
http://www.wi-fi.org/membersonly/images/labels/0106685.jpg (27.05.2003)
7
Die Technik entwickelt sich jedoch schnell weiter. So hat U.S. Robotics im Mai 2003
WLAN-Produkte vorgestellt, die mit bis zu 100 MBit/s funken.10
2.3 Sicherheitsaspekte
Ein hohes Sicherheitsrisiko beim Wireless LAN ist die Tatsache, dass Funkwellen
deutlich einfacher abgehört werden können als drahtgebundene Technologie. Das
liegt zum einen daran, dass sich Funkwellen nicht örtlich begrenzen lassen. Sie
breiten sich auch durch die Gebäudewände aus. Zum andern kann man bei Funkwellen nicht feststellen, ob sie abgehört werden.
Die von Wi-Fi standardisierte Verschlüsselungstechnik WEP (Wired Equivalent
Privacy) hat sich als nicht ausreichend erwiesen. Dieses Verschlüsselungsverfahren
basiert auf einem festen Schlüssel, der bei allen angeschlossenen Geräten gleich ist.
Wird genügend Funkverkehr abgehört kann man Rückschlüsse auf den Schlüssel
ziehen.11
Eine von Wi-Fi unabhängige Lösung für diese Sicherheitslücke ist die Nutzung eines
VPN-Clients, welcher die Daten beispielsweise zwischen Laptop und Firmennetzwerk verschlüsselt. Diese Sicherung der Daten erfolgt auf Netzwerkebene, ist also
unabhängig von der Art des Mediums. Als Standard ist hier IPsec zu nennen,
welcher TCP-Pakete verschlüsselt.
Die Schwächen von WEP wurden schon kurze Zeit nach der Veröffentlichung bekannt. Um die Datenübertragung auch ohne externe Software sicher zu gestalten
arbeitet die WECA an einem Nachfolger von WEP in Form eines überarbeiteten
Standards mit der Bezeichnung 802.11i. Dieser soll zwar erst Ende 2003 verabschiedet werden, einen eigenständigen Teil namens WPA (Wi-Fi Protected Access)
ist aber bereits auf dem Markt und beispielsweise von Microsoft in Windows XP
10
vgl. USR (2003)
11
vgl. Ahlers (2003), S. 172
8
implementiert.12 Das Update für Windows XP ist seit 31.03.2003 bei Microsoft
verfügbar.13
Der Standard 802.11i baut auf 802.1x auf, einem Standard der unabhängig vom
Transportmedium ist, also nicht nur bei Wireless LAN eingesetzt werden kann. Mit
dem neuen Standard ist es möglich, einen Nutzer direkt durch den Access Point zu
authentifizieren, ohne dass dieser seine Authentifizierungsdaten über eine Webseite
(Login Formular) eingeben muss. Es wird eine Client-Software beim Endkunden
benötigt, die beispielsweise im Betriebssystem integriert sein kann. In heutigen
Implementationen wird als Authentifizierungsprotokoll zwischen Access Point und
AAA-Server das RADIUS-Protokoll eingesetzt.14
Die größte Sicherheitslücke ist jedoch die fehlende Authentifizierung des Access
Points selbst. Zwar muss sich ein Nutzer am Access Point authentifizieren, nicht
jedoch der Access Point beim Nutzer. Ein WLAN-Nutzer kann nicht erkennen, mit
welchem Access Point er verbunden ist. Es kann also sein, dass jemand einen
Access Point vortäuscht und den unwissenden Kunden seine Nutzerdaten eingeben
lässt (Man-in-the-Middle-Attack). Die Nutzerdaten gelangen also nicht zum echten
Authentifizierungsserver sondern werden vorher abgefangen. Indem man dem
Nutzer eine fiktive Fehlermeldung übermittelt mindert man das Misstrauen. Die abgefangenen Benutzerdaten können nun genutzt werden, um sich am echten Authentifizierungsserver anzumelden.
Neben der Man-in-the-Middle-Attack ist eine weitere Sicherheitslücke bei allen
(bisherigen) Wireless LAN Standards bekannt als Session Highjacking. Das SessionHighjacking glückt, weil das 802.11 Protokoll „für Management-Frames keine
Authentifizierung- und Integritätsmechanismen vorsieht“15. Ein Angreifer schickt „eine
802.11-MAC-Disassociate-Nachricht an den WLAN-Client“16, der dadurch die Verbin-
12
vgl. Wi-Fi (2003)
13
vgl. Microsoft (2003)
14
vgl. Network Computing (2003)
15
Network Computing (2002)
16
9
dung verliert, und übernimmt deren MAC-Adresse (eindeutige Nummer der Netzwerkkarte). Der Angreifer hat nun die gleichen Rechte wie der Angegriffene.
2.4 Aufbau von Hotspots
Wireless LAN Hotspots sind Orte, an denen Besucher drahtlos im Internet surfen
können. Meist handelt es sich hierbei um Bereiche, die von vielen Personen besucht
werden, wie beispielsweise Cafés, Restaurants, Tankstellen, Bahnhöfe und
Flughäfen.
Im privaten Bereich ist normalerweise ein einzelner Access Point ausreichend, da
meist nur eine kleine Fläche mit Funk erschlossen werden soll. Dieser ist dann meist
auch gleichzeitig Router ins drahtgebundene LAN und ins Internet.
Bei der Erschließung von großen Hotspots – beispielsweise Hotels oder gar Flughäfen – ist eine große Anzahl von Access Points nötig. Sie müssen so aufgestellt sein,
dass der zu versorgende Bereich möglichst gut ausgeleuchtet wird. Die Access
Points sind in der Regel per Kabelverbindung mit dem lokalen (öffentlichen)
Netzwerk verbunden. Das private bzw. firmeninterne Netzwerk ist ausschließlich für
Mitarbeiter zugänglich. Privates und öffentliches Netzwerk sind über einen Router
miteinander verbunden. Dieser muss so konfiguriert sein, dass die WLAN-Nutzer
keinen Zugriff auf das Firmennetzwerk haben, aber alle Zugriff auf das Internet
haben. Der Internetzugang sollte durch eine Firewall gegen Angriffe aus dem Internet
geschützt sein. Unabhängig vom Firmennetzwerk ist meist noch ein lokaler ContentServer vorhanden, auf dem beispielsweise Hotel-Gäste über Ausflugsmöglichkeiten
informiert werden können.
Das beschriebene Szenario ist in der folgenden Grafik dargestellt.
10
PDA
PDA
Laptop
Laptop
PDA
Laptop
PDA
Laptop
Laptop
Laptop
PDA
PDA
Gast-PC
Gast-PC
Öffentliches Netzwerk
Internet
Router
Content-Server
Firewall
Firmennetzwerk
Mitarbeiter-PC
Mitarbeiter-PC
Mitarbeiter-PC
Mitarbeiter-PC
Mitarbeiter-PC
Unternehmens-Server
Abbildung 4: Aufbau eines öffentlichen Hotspots
In diesem Szenario ist jedoch noch nicht berücksichtigt, dass die Gäste für den Internetzugang im Normalfall bezahlen sollen. Eine Authentifizierung ist hiermit nicht
möglich. Um kostenpflichtigen Internetzugang über Wireless LAN anzubieten ist ein
weiteres Gerät notwendig, der so genannte PAC (Public Access Controller – oder
auch Access Controller oder Access Gateway genannt). Solch ein PAC fungiert als
Gateway zwischen Wireless LAN und Internet. Möchte ein Kunde mit einem Laptop
oder einem anderen Endgerät ins Internet gehen öffnet er seinen Browser und gibt
die gewünschte Internetadresse ein. Ist er noch nicht frei geschaltet, wird er durch
das Gateway auf eine Seite umgeleitet, auf der er seine Zugangsdaten zum Wireless
11
LAN eingeben muss. Sind die Daten korrekt wird er im Gateway frei geschaltet und
kann im Internet surfen. PACs gibt es von verschiedenen Herstellern, der
Funktionsumfang variiert dementsprechend. Viele Hersteller bieten eine so genannte
„Walled Garden“ Funktionalität an. Dies bedeutet, dass bestimmte Server vom
Hotspot aus ohne Anmeldung erreicht werden können. Beispielsweise können so
Inhalte von Sponsoren oder der lokale Wetterbericht zur Verfügung gestellt werden.
Weitere Verwendungsmöglichkeiten eines Walled Garden werden später in dieser
Arbeit beschrieben.
Für die Abrechnung von Wireless LAN werden meist Voucher (Gutscheine, ähnlich
wie Prepaid Karten im Mobilfunk-Bereich) eingesetzt. Es handelt sich hierbei um
Rubbelkarten, meist in der Größe von Visitenkarten, welche an Serviceständen
innerhalb eines Hotspots im Auftrag des Hotspot-Betreibers verkauft werden. Auf
jedem Voucher ist ein Benutzername und ein Passwort aufgedruckt, die der Käufer
freirubbelt und als Benutzerdaten für den Internetzugang eingibt. Voucher gibt es oft
zu verschiedenen Preisen, je nachdem wie viel der Nutzer im Internet surfen kann.
Das genutzte Kontingent wird in einer Datenbank innerhalb des Hotspots oder
zentral beim Betreiber gespeichert. Ist das gekaufte Kontingent aufgebraucht kann
der Voucher nicht mehr verwendet werden.
12
3 Wireless LAN Roaming
Der schnelllebige Public WLAN Markt hat einen großen Nachteil. Die Systeme der
verschiedenen Hotspot-Betreiber sind nicht so kompatibel wie sich dies ein Endkunde wünschen würde. Zwar kann ein Surfer meist innerhalb der Betreiber eigenen
Hotspots mit den gleichen Zugangsdaten surfen (oft von den Betreibern als Roaming
bezeichnet), für fremde Hotspots braucht er aber andere Zugangsdaten. Die Betreiber untereinander haben sehr selten Roamingabkommen, wie Sie beispielsweise im
Mobilfunkbereich üblich sind. Hier ist es inzwischen fast selbstverständlich, dass
Telefonate im Ausland über die heimische Telefonrechnung abgerechnet werden.
3.1 Authentication, Authorization, Accounting nach Wi-Fi
Seit Februar 2003 gibt es einen inoffiziellen Standard für das Roaming zwischen
Wireless LAN Anbietern. Die Wi-Fi Allianz hat einen Draft17 veröffentlicht, in dem der
Fluss der AAA-Daten beschrieben wird (AAA = Authentication, Authorization,
Accounting). Wi-Fi setzt hierbei auf das RADIUS-Protokoll (vgl. Kapitel 7.2.1),
welches zur Übermittlung der Daten zwischen dem Access Gateway und dem
Authentifizierungs-Server bis hin zum heimischen Provider genutzt werden kann.
Die folgende Grafik zeigt den Datenfluss in einem Roaming-Szenario.
17
Wi-Fi (2003)
13
Abbildung 5: Roaming nach Wi-Fi18
In diesem Szenario gibt es den Endkunden (End User), der im Vertragsverhältnis mit
einem Provider steht. Möchte dieser mit seinem Laptop in einem Hotspot surfen, der
nicht dem eigenen Provider gehört, spricht man vom Roaming.
Wie der Endkunde in diesem Fall das Internet nutzen kann, ist im Draft beschrieben.
Der Endkunde baut zunächst die Funkverbindung zum Access Point auf. Anschließend gibt er im Browser eine Internetadresse ein und wird direkt auf eine Seite
umgeleitet, auf der er Benutzernamen und Kennwort eingeben muss. Nach Wi-Fi
kann er nun den Benutzernamen von seinem eigenen Provider (Home Entity) verwenden, gefolgt von einem eindeutigen Bezeichner (z.B. max@t-online.de). Ebenso
muss er das Kennwort des eigenen Providers angeben. Benutzername und Kennwort werden nun über RADIUS an den lokalen Authentifizierungs- und AccountingServer gesendet. Dieser erkennt anhand des Bezeichners (z.B. T-Online), an welchen Provider er die Daten weiterleiten muss. Ist der Benutzer durch den heimischen
Provider authentifiziert und autorisiert, wird er für die Internetnutzung frei geschaltet
18
Wi-Fi (2003), S. 3
14
und kann somit das Internet nutzen. Die Abrechnungsdaten (Nutzungsdauer, Volumen, …) werden ebenfalls über das RADIUS-Protokoll an den heimischen Provider
gesendet, welcher die Daten auswertet und dem Kunden in Rechnung stellt. Für die
Nutzung des Hotspots bekommt der externe Provider dann einen Teil der
Nutzungsgebühren.
Nachteil an diesem Verfahren ist, dass die Hotspot-Betreiber untereinander
Roamingverträge abschließen müssen. Es muss sogar jeder Hotspot-Betreiber mit
jedem anderen einen Vertrag abschließen. Diese Vertragsbeziehungen müssen
außerdem technisch abgebildet werden, wodurch ein enormer Pflegeaufwand entsteht. Dies ist vermutlich auch der Grund, warum Roaming bisher in der Praxis kaum
umgesetzt wurde.
Eine weitere Möglichkeit Roaming abzubilden beschreibt Wi-Fi ebenfalls in diesem
Dokument. Statt die Daten an den jeweiligen Provider zu senden werden die Daten
an eine zentrale Instanz (Roaming Intermediary) übermittelt, welche die Vertragsverhältnisse zu den einzelnen Providern aufbaut und die Abrechnung übernimmt.
Dadurch wird der Verwaltungsaufwand seitens der Provider erheblich gesenkt, da
nur noch eine einzelne Vertragsbeziehung gepflegt werden muss.
3.2 Strategien der Serviceanbieter
Grundsätzlich kann in zwei Arten von Serviceanbietern unterschieden werden.
Unternehmen, die Hotspots betreiben, und Unternehmen, die einen großen Kundenstamm in einem anderen Bereich (z.B. Telefon, Internetzugang) aufgebaut haben.
3.2.1 Wireless Internet Service Provider (WISP)
Unter Wireless Internet Service Provider versteht man Unternehmen, die eigene
Hotspots betreiben. Sie sind verantwortlich für den Aufbau und den Betrieb der
Standorte. Dazu gehört, neben der Installation von Access Points und Gateways,
mindestens der Anschluss an das Internet.
15
In der Regel hat der Hotspot-Betreiber eigene Kunden, denen er Voucher (Prepaid
Cards) verkauft. In diesem Fall braucht er zusätzlich einen Server zur Authentifizierung und den Kundenservice (Verkauf der Voucher, Support zum Zugang).
3.2.2 Virtuelle WISP (V-WISP)
Virtuelle WISPs haben sich darauf spezialisiert, Ihren Kunden Wireless LAN Dienste
zur Verfügung zu stellen. Sie konzentrieren sich auf den Aufbau und die Pflege der
Vertragsbeziehung mit dem Endkunden und bieten ihm die Möglichkeit in Hotspots
zu surfen. Ein V-WISP muss mit einem (oder mehreren) WISPs kooperieren, für den
er dann die Abrechnung mit dem Surfer übernimmt.
Die meisten V-WISPs haben schon bevor es Public WLAN gab Vertragsbeziehungen
mit Endkunden gehabt. Viele davon sind Telefongesellschaften oder Internet Service
Provider (Modem / ISDN). Die Endkunden können im günstigsten Fall mit den
Zugangsdaten über Wireless LAN surfen, mit denen sie auch Ihre Mails abrufen.
Ein besonderer Fall ist das Roaming. Bietet ein WISP für seine eigenen Kunden die
Möglichkeit an, Hotspots von anderen WISPs zu nutzen, tritt er gegenüber den
anderen WISPs als V-WISP auf. In diesem Fall interessiert es nicht, ob er eigene
Hotspots betreibt.
3.3 Abrechnung zwischen Roamingpartnern
Alle beteiligten Parteien werden am Surfen eines Endkunden verdienen wollen.
Daher ist eine Abrechnung zwischen den Parteien (WISP und V-WISP) notwendig.
Die Abrechnung fordert einen gültigen Vertrag, welcher zwischen den Partnern für
einen Hotspot aufgesetzt werden muss. Doch ein Vertrag ist noch nicht ausreichend,
die Verbindungsdaten müssen auch noch abgerechnet werden. Dazu werden die
Daten zwischen den Parteien auf elektronischem Wege verglichen und Rechnungen
generiert. Es gibt verschiedene proprietäre Systeme auf dem Markt, für fast jeden
neuen Partner muss eine neue Schnittstelle programmiert werden. Dies hindert
natürlich die Verbreitung des WLAN-Roamings.
16
Gelindert wird dieses Problem durch eine zentrale Instanz, die zwischen den Parteien vermittelt. Zwar nimmt auch diese Gebühren, im Vergleich zu den Einsparungen im sich schnell ändernden WLAN-Markt mit ständig neuen WISPs und V-WISPs
sollte sich der Einsatz einer Vermittlungsinstanz jedoch schnell rentieren. Ein Unternehmen muss hierbei nur noch eine Schnittstelle zum Vermittler implementieren,
statt für jeden neuen Partner Anpassungen vorzunehmen. Die zentrale Instanz übernimmt neben Authentifizierung und Autorisierung auch das Accounting, also die
Sammlung und Aufbereitung der Verbindungsdaten, sowie den regelmäßigen Ausgleich der Gebühren zwischen den Parteien. Hier wird die Differenz berechnet, die
eine Partei an die andere zahlen muss, und es werden Rechnungen und Gutschriften
generiert. Die Zahlungseingänge werden zentral überwacht. Durch die zentrale Instanz kann also auch noch die Anzahl der Buchungen deutlich reduziert werden, da
Zahlungen und Gutschriften für alle Partner gegeneinander aufgerechnet werden.
17
4 Wireless LAN Marktübersicht
Der WLAN-Markt ist noch in der Anfangsphase – das zeigen alle Prognosen. Die
Anzahl der öffentlichen Hotspots wird in den nächsten Jahren stark ansteigen,
ebenso die Anzahl der Nutzer öffentlicher Wireless LAN Zugänge.
Anzahl der öffentlichen Hotspots
180000
Rest der Welt
160000
140000
Asien/Pazifik
Nord-Amerika
Europa
120000
100000
80000
60000
40000
20000
0
2003
2004
2005
2006
2007
2008
Abbildung 6: Anzahl öffentlicher Hotspots – Prognose nach Gartner19
Die Hotspots werden zunächst vorwiegend geschäftlich genutzt, beispielsweise um
an Flughäfen oder Messen Mails zu lesen. Mit wachsender Verbreitung wird aber
auch die Anzahl der privaten Nutzer von öffentlichen Hotspots steigen. Unterstützt
wird diese Steigerung der Nutzerzahl durch die Verbreitung des Wireless LANs im
privaten Bereich. Viele Familien scheuen die Verkabelung und nutzen stattdessen
WLAN. Außerdem werden mehr und mehr Wireless LAN Karten in Notebooks eingebaut sein, bis 2004 werden schätzungsweise mehr als die Hälfte darüber verfügen20.
19
vgl. Keene (2003b), S. 7
20
18
Nutzeranzahl von Öffentlichen Hotspots in Millionen
80
Rest der Welt
70
Asien/Pazifik
Nord-Amerika
60
Europa
50
40
30
20
10
0
2003
2004
2005
2006
2007
2008
Abbildung 7: Anzahl der Nutzer öffentlicher Hotspots – Prognose nach Gartner 21
Die Preise für öffentliches Wireless LAN werden hingegen in den nächsten Jahren
fallen. In den USA, wo WLAN bereits an vielen Orten verfügbar ist, liegen die Preise
schon jetzt deutlich niedriger als in Europa. Die Kosten für 24 Stunden WLAN betragen in den USA etwa acht Euro, während europäische Anbieter zehn bis 15 Euro
verlangen22. In Deutschland liegen die Preise sogar noch deutlich darüber.
Trotz der fallenden Preise wird der Umsatz pro Hotspot aber aufgrund der stark
wachsenden Nutzeranzahl steigen, zumindest gilt dies für Europa, Nord-Amerika und
Asien/Pazifik.
21
22
vgl. Kecman / Paolini / Pow (2003)
19
Umsatz pro Hotspot in US$
80.000
70.000
60.000
50.000
40.000
30.000
20.000
Europa
Nord-Amerika
10.000
Asien/Pazifik
Rest der Welt
0
2003
2004
2005
2006
2007
Abbildung 8: Umsatz pro Hotspot – Prognose nach Gartner23
Nach einem Überblick über sie Zukunftsaussichten von öffentlichen Wireless LAN
soll im Folgenden untersucht werden, welchen Protokolle (z.B. RADIUS, Diameter,
IPDR, TAP3) bereits auf dem Markt befindliche Produkte unterstützen. Dies wird
Entscheidungsgrundlage sein, welche Technologien für die Schnittstellenentwicklung
sinnvollerweise genutzt werden.
4.1 WISP-Systemhersteller
Verschiedene Unternehmen entwickeln WISP-Plattformen, um Hotspots zu aggregieren, Benutzer verwalten und externe Provider anzubinden (Roaming). Im Folgenden
werden die bekanntesten hiervon kurz beschrieben.
23
Berechnet nach Keene (2003b), S. 7f
20
Garderos
Die „i250 Platform“ von Garderos besteht aus einer Serverkomponente (NOC) und
einer Client-Plattform (SAT). 24
Der SAT (Abkürzung von Satellite) ist der Access Controller (PAC) am Hotspot, der
den Zugang zum Internet freigibt oder sperrt. Er beinhaltet einen DHCP-Server zur
Vergabe von lokalen IP-Adressen, eine Firewall und übermittelt die Accountingdaten
zum NOC (über ein proprietäres Protokoll). Die Verwaltung der SAT erfolgt zentral
über einen NOC. Für kleinere Hotspots gibt es eine kleinere Version der SAT
„Hotspot-in-a-box“, welche die gleichen Aufgaben erfüllt und zusätzlich einen Access
Point beinhaltet. Die kleinere Version unterstützt dabei weniger gleichzeitig surfende
Nutzer. Für jeden Hotspot kann ein Walled Garden eingerichtet werden. Dies ist ein
Bereich (IP-Adressen) in denen die Nutzer ohne Anmeldung kostenlos surfen
können. Meist werden Sponsorenseiten oder Veranstaltungsinformationen kostenlos
zur Verfügung gestellt.
Der NOC (Network Operation Center) dient der zentralen Verwaltung der SATs. Die
Authentifizierung der Nutzer erfolgt über ein auf dem NOC befindliches Portal, über
das Voucherdaten eingegeben werden können. Die Datenbank für die Voucher
befindet sich ebenfalls auf dem NOC, auch Statistiken können darüber erstellt
werden.
Die Garderos-Lösung unterstützt bilaterales Roaming nach Wi-Fi. Der dafür notwendige RADIUS-Server befindet sich auf dem NOC. Zusätzlich wird die Authentifizierung über andere Provider (Mobilfunkanbieter) unterstützt.
ServiceFactory
Das schwedische Unternehmen ServiceFactory bietet unter dem Namen „Orbyte
Wireless System“ ebenfalls ein System, das mehrere Hotspots zu einer Plattform
aggregieren kann.25
24
vgl. Garderos (2003), S. 4
25
vgl. ServiceFactory (2003)
21
Das System wird zusammen mit der Hardware ausgeliefert. Die PACs sind ebenfalls
eine Entwicklung von ServiceFactory. An diese Gateways können Access Points von
beliebigen Herstellern angeschlossen werden
Das besondere an dem System ist, dass auch Reseller unterstützt werden. Von
einem zentralen Administrator können Operatoren angelegt werden, die Standorte
pflegen können. Sie können über ein HTML-Portal Tarife festlegen, für jeden Standort individuelle Portalseiten erstellen und Statistiken anzeigen lassen.
Das System ist für große Unternehmen zugeschnitten und besteht aus einer Serverhierarchie. Mehrere zentrale Rechner dienen zur Pflege der Daten und replizieren
sich auf weitere Server (so genannte SCS), die an vielen Standorten verteilt stationiert sein können. Dadurch ist eine hohe Ausfallsicherheit gewährleistet.
Die Public Access Controller (bei ServiceFactory RLAS genannt) verbinden sich
dann einem oder mehreren einstellbaren SCS und rufen die Konfiguration und die
Portalseiten ab, welche dann lokal am Hotspot ausgeführt werden. Ein RLAS beinhaltet außerdem einen DNS-Server und einen DHCP-Server, über den die Clients
ihre Netzwerkkonfiguration erhalten. Die AAA-Kommunikation zwischen den PACs
erfolgt über das RADIUS-Protokoll. Auch ein Walled Garden ist konfigurierbar.
Ebenfalls zentral konfiguriert wird das Roaming. Die Lösung unterstützt bilaterales
RADIUS-Roaming mit anderen WISPs. Der Roamingpartner muss zum einen direkt
im RADIUS-Server eines SCS eingetragen werden, zum andern muss ein Operator
den Roamingpartner über das HTML-Portal einpflegen. Das Accounting zwischen
dem Orbyte System und dem externen Roamingpartner kann über RADIUS oder
über IPDR erfolgen.
Eine Besonderheit an dieser Lösung ist, dass auch externe Provider unterstützt
werden, die nicht über einen RADIUS-Server verfügen. Die Authentifizierung über
einen Mobilfunkanbieter kann beispielsweise über SMS erfolgen. Damit dieser die
Verbindungen in Rechnung stellen kann, generiert das Orbyte Wireless System
IPDR Datensätze, die alle zur Abrechnung benötigten Daten enthalten.
22
Wificom
Wificom bietet zwei Softwareprodukte an, die zusammen eine WISP-Plattform bilden.
Die Produkte erfordern auf Linux basierende Standard-PCs.
Das Wificom SAB Gateway bietet die Möglichkeit ein externes Portal als Startseite
festzulegen, die Einrichtung von Walled Garden ist möglich. Authentifizierung, Autorisierung und Accounting erfolgen über RADIUS. Der DHCP-Server versorgt die
Clients mit den Netzwerkeinstellungen. Sicherheitsmerkmale, wie Firewall und VPN
Client für die gesicherte Verbindung mit der zentralen Komponente, dem Wificom
SAB Server sind vorhanden, ebenso Statistiken zur Auslastung.26
Die Konfiguration des Access Controllers erfolgt über den Wificom SAB Server. Dort
werden Preismodelle verwaltet; möglich ist die Bezahlung über Kreditkarten,
Vouchers, Mobiltelefonrechnung, mit Prepaid- und Postpaid Accounts. Weiterhin
unterstützt der SAB Server die Authentifizierung von Nutzern bei Mobilfunkanbietern,
die Abrechnung erfolgt über IPDR oder TAP3. Anzumerken ist noch, dass eine
Integration von PACs von Drittherstellern möglich ist.27
WirelessCreation
Im Gegensatz zu den bereits beschriebenen Systemen bietet WirelessCreation keine
Kombination aus Hard- und Software an, sondern die reine Software an sich. Diese
Software nennt sich WPS 2.0 und ermöglicht es, wie jede andere WISP-Plattform,
verschiedene Hotspots zu aggregieren.28
WPS 2.0 ist eine reine Software-Lösung, die für Linux, Solaris und Windows NT/2000
verfügbar und frei skalierbar ist. Das System wird zentral betrieben, die Hotspots
werden über das Internet angeschlossen. Für jeden Hotspot wird ein Access
Gateway benötigt; unterstützt werden neben einer Eigenentwicklung (auf Basis von
Linux) u.a. PACs von Nomadix, Cisco und LANCOM sowie RADIUS-basierte
Lösungen (z.B. von den Firmen Colubris, Handlink und Orinoco). Die Integration von
26
vgl. Wificom (2003a)
27
vgl. Wificom (2003b)
28
vgl. WirelessCreation (2003)
23
anderen Endgeräten geschieht über eine API (Plugin-Connector). Ob eine
Konfiguration eines Walled Garden möglich ist hängt daher von den verwendeten
Endgeräten ab.
Die Lösung unterstützt bilaterales Roaming zwischen WISP-Systemen. Auf der VWISP Seite werden laut Homepage29 folgende Funktionalitäten unterstützt: Authentifizierung über Kreditkarte (post- und prepaid), Lastschrift (post- und prepaid),
RADIUS, Voucher/Gutschein, Firstgate, LDAP, SQL, iPass u.a. Es können also
andere Provider als der Location Owner genutzt werden. Eine Anbindung von
fremden Hotspots (WPS 2.0 als V-WISP-System) ist mit diesem System nicht
möglich.
Für jeden Hotspot können unterschiedliche Benutzer-Rollen definiert werden, die den
Hotspot lokal administrieren können. Hierzu gehört neben dem Content auch die
Hardware und AAA-Konfiguration. Jeder Location Owner kann für seinen Standort
über eine Webschnittstelle Voucher anlegen und verwalten. Damit eignet sich das
System auch für Wiederverkäufer. Weiterhin können sich Endkunden auch am
System registrieren. Auch eine zentrale Konfiguration der Hotspots wird unterstützt.
Es ist ein Ratingsystem vorhanden, dass die Accountingdaten auswertet und verpreist. Dabei sind volumen- und zeitabhängige Tarife möglich. Ebenfalls gibt es die
Möglichkeit von „Billing Events“ (kostenloses Surfen nach einem Einkauf) und das
Konfigurieren von Rabatten (z.B. Feiertage, Promotion). Eine Anbindung an gängige
Property-Managment-Systeme / Hotelabrechnungssysteme oder anderen vorhandenen Billing-Systemen ist möglich.
Als weitere Funktion ist ein Content Management System integriert, dass für jeden
Hotspot / Access Point unterschiedlichen Content im Portal bereitstellt. Weiterhin gibt
es einen Startseiten-Baukasten mit News und Gästebuch.
29
WirelessCreation (2003)
24
Cisco Systems
Das Unternehmen Cisco Systems hat zwei unterschiedliche Systeme entwickelt. Das
schon längere Zeit angebotene Produkt „Service Selection Gateway“ erfordert im
Gegensatz zu den vorgestellten Systemen anderer Hersteller die Übertragung des
gesamten Datenverkehrs (Signalisierungs- und Wirkdaten) über ein zentrales
Gateway. Die Freischaltung eines Nutzers für einen Service erfolgt dort. Nachteil
daran ist, dass teurere Standleitungen vorgehalten werden müssen und das zu
übertragene Datenvolumen deutlich höher ist. Interessant ist diese Lösung vor allem
für Internetprovider, die über eine Dateninfrastruktur verfügen.
Das neuere System „BBSM“ (auch in einer kleineren Version namens „BBSM
Hotspot“ verfügbar)30 arbeitet hingegen wie die Systeme der anderen Hersteller: Die
Wirkdaten werden am Hotspot selbst abgeleitet, ohne den Umweg über das zentrale
Gateway zu nehmen. Nur die Authentifizierung, die Autorisierung und das
Accounting erfolgen gegenüber einem zentralen Server.
Die Authentifizierung kann bei beiden Systemen über das RADIUS-Protokoll erfolgen. Cisco hält sich dabei jedoch nicht genau an die von Wi-Fi veröffentlichte Richtlinie.
Die PACs beim Hotspot sind Cisco-Server, Fremdhardware kann nicht eingesetzt
werden. Das Management der einzelnen Geräte erfolgt über eine komfortable
Verwaltungsoberfläche. Ein Walled Garden kann über diese Oberfläche für jeden
Hotspot separat eingestellt werden.
Fazit
Fast alle Systeme unterstützen RADIUS-Roaming nach Wi-Fi. Die Nutzbarkeit eines
Walled Garden ist bei den Systemen gegeben. Eine Integration eines externen
Abrechnungssystems ist nur bei Service Factory (über IPDR) möglich. RADIUS hat
sich offenbar als AAA-Standard auf dem Markt durchgesetzt.
30
vgl. Cisco (2002), S. 4
25
4.2 Abrechnungssysteme
Es gibt einige Produkte, welche die Abrechnung von Dienstleistungen unterstützen.
Dazu gehören große, branchenübergreifende Produkte wie DATOS von T-Systems
und eView von ADC und branchenspezifische, wie beispielsweise Micros Fidelio für
die Hotelbranche. Neben den reinen Abrechnungssystemen sind auch komplexere
ERP Systeme für die Abrechnung von Verbindungen geeignet. Alle haben eines
gemeinsam: Sie sind offen für die Integration mit anderen Systemen. Über geeignete
Schnittstellen könnten Verbindungsdaten auch in diese Systeme exportiert werden,
wo dann eine weitere Verarbeitung erfolgt.
Der Vorteil der Integration anderer Abrechnungssysteme liegt darin, dass man
vorhandene Systeme nutzen kann. So ist Fidelio in der Hotelbranche sehr verbreitet,
und es wäre nicht sinnvoll zwei verschiedene Abrechnungssysteme – eines für
WLAN und ein anderes für Hotelbuchungen – zu betreiben.
Da im Rahmen dieser Arbeit aber nicht für jedes System eine Schnittstelle entwickelt
werden kann, wird eine möglichst flexible Schnittstelle definiert, für die dann
gegebenenfalls eine kleine Übersetzungssoftware geschrieben werden muss. (Vgl.
Kapitel 8).
4.3 Hotspotbetreiber (WISPs)
Es gibt eine breite Masse von Hotspotbetreibern, einige von ihnen haben bereits
Roamingverträge untereinander, um ihren Nutzern einen Mehrwert dadurch anzubieten, dass sie ihre Zugangsdaten auch in fremden Hotspots nutzen können. In
diesem Fall wären sie dann gleichzeitig V-WISPs (vgl. 3.2.2).
Zu den WISPs in Deutschland gehören überregional agierende Unternehmen, wie
beispielsweise die WLAN AG / jetzt Swisscom Eurospot (68 Hotspots), Netcheckin
(35 Hotspots), Global Airnet AG (20 Hotspots) und M3 Connect (16 Hotspots).
26
Aber auch lokale Anbieter, die bereits über einen stadtweite Infrastruktur verfügen,
können mit wenig Aufwand Hotspots aufbauen. So betreiben Hamburg@Work (40
Hotspots), Innovationsforum AG (20 Hotspots), BerlinNet (25 Hotspots) und ISIS (12
Hotspots) regional begrenzte WLAN-Inseln.
Die deutschen Mobilfunkanbieter wollen sich ebenfalls im WLAN-Markt etablieren, so
hat Vodafone bisher 12 Hotspots in Deutschland aufgebaut. T-Mobile betreibt weltweit bereits 2.300 Hotspots vor allem in den USA, wo sie mit der Starbucks-Kette
(Cafés) kooperieren und viele Filialen versorgt haben31.
Die Zahlen stammen aus einem monatlich erscheinenden Newsletter32.
4.4 Serviceanbieter (V-WISPs)
Als Serviceanbieter sind vor allem die großen Internetprovider, die Mobilfunkanbieter
und die Telefonanbieter im Festnetzbereich zu sehen.
T-Online beispielsweise mit ihren 12,2 Millionen Kunden33 hat keine eigenen
Hotspots, kann aber mit Roamingverträgen ihren Kunden die Benutzung fremder
Hotspots ermöglichen.
Vodafone und T-Mobile haben dagegen in Deutschland bereits eigene Hotspots (vgl.
Abschnitt 4.3), könnten aber durch Roaming mehr Standorte abdecken.
AOL hat gerade die ersten Hotspots in Deutschland aufgebaut, E-plus ist im Mai eine
Kooperation mit Netcheckin eingegangen34 und O2 germany kooperiert mit der
Global Airnet AG35 und Swisscom Eurospot36.
31
vgl. Starbucks (2003)
32
vgl. Gebert (2003)
33
vgl. Holtrop (2003), S. 3
34
vgl. Netcheckin (2003)
35
vgl. GlobalAirNet AG (2003)
36
vgl. O2 (2003)
27
Weiterhin sind Unternehmen vertreten, die sich auf Wireless LAN Access spezialisiert haben. Hierzu gehört beispielsweise iPass, dessen System weltweit an 2.800
Hotspots genutzt werden kann.
Einige Hotspotbetreiber schließen bereits Roamingverträge untereinander ab. Hierzu
nutzen sie im Allgemeinen das bereits beschriebene bilaterale Roaming nach Wi-Fi.
4.5 Roamingbroker / Clearinghouse Betreiber
Aktuell gibt es nur einen Anbieter für die Abrechnung von Roamingleistungen in
Deutschland. Dies ist der Verband der deutschen Internetwirtschaft, eco Forum e.V.
mit seinem Konzept namens Greenspot. In einem Arbeitskreis widmet sich dieser
Verband der Erstellung eines Roamingstandards mit demselben Ziel wie T-Systems.
Erste Diskussionspapiere zeigten, dass es ein langwieriger Prozess wird, die Interessen aller Teilnehmer des Arbeitskreises gerecht zu werden. T-Systems – auch
ein Mitglied des Arbeitskreises – hat sich daher entschlossen, einen eigenen Standard zu schaffen, der mit dieser Arbeit definiert wird, und sich auch mehr mit den
Belangen der großen V-WISPs (insbesondere T-Online) zu beschäftigen.
Das Konzept des eco-Verbands und T-Systems haben eine ähnliche Struktur37. Es
gibt eine zentrale Instanz – das Greenspot Clearinghouse. An dieses werden WISPs
angeschlossen, welche mehrere Hotspots aggregieren. Im Unterschied zur TSystems Lösung gibt es keine Roaming-Plattform, die alle Accounting-Daten von
allen Nutzern in Echtzeit erhält. Dies übernehmen die WISPs, welche nach Ende der
Nutzung einen Verbindungsdatensatz an das Clearinghouse senden. Dadurch kann
beispielsweise nicht überprüft werden, ob bereits ein Nutzer mit den gleichen
Authentifizierungsdaten angemeldet ist.
Das Greenspot-Konzept hat jedoch auch andere Schwachstellen, wie beispielsweise
die unsichere Anmeldung eines Nutzers. Der Nutzer erhält Benutzername und
Kennwort durch seinen Serviceprovider. Mit diesen Daten kann er sich an jedem
37
vgl. ECO (2003)
28
Hotspot anmelden. Das Problem hierbei ist, dass die Authentifizierungsdaten von
jedem Unternehmen auf der Strecke zwischen Hotspot und Clearinghouse abgehört
werden können. Dieses Problem ist dem eco Verband natürlich bekannt, nach der
Pilotphase soll daher eine Client Software genutzt werden, über die eine sicherere
Authentifizierung möglich ist. Nachteil hieran ist jedoch, dass jeder Nutzer zunächst
diese Software installieren muss, was bei Firmen-Laptops aufgrund von fehlenden
Rechten nicht immer möglich ist. Wie dieses Sicherheitsrisiko minimiert werden kann,
wird im Kapitel 7.3.2 beschrieben.
29
5 Rechtliche Aspekte
Auch wenn der Schwerpunkt der Arbeit nicht bei den rechtlichen Grundlagen liegt,
möchte ich in diesem Kapitel kurz auf juristische Faktoren eingehen.
5.1 Überwachung der Telekommunikation
Seit August 2002 ist die Telekommunikations-Überwachungsverordnung (TKÜV)38
rechtskräftig. Dieses bundesdeutsche Gesetz regelt die Überwachung von öffentlichen Telekommunikationsverbindungen, also beispielsweise Telefon- und Internetverbindungen. Aufgrund dieser Vorschrift müssen Betreiber von öffentlichen Telekommunikationsanlagen Vorkehrungen für die Umsetzung von Überwachungsmaßnahmen treffen und nach richterlichem Beschluss den entsprechenden Stellen den
Datenverkehr zukommen lassen.
Von der Vorhaltung von geeigneten Vorkehrungen sind u. a. allerdings Telekommunikationsanlagen befreit, die „Netzknoten sind, die der Zusammenschaltung mit dem
Internet dienen,“39. Die Regulierungsbehörde für Telekommunikation und Post
(RegTP) benennt ausdrücklich Internet Access Provider als Beispiel für solche Netzknoten40, daher kann davon ausgegangen werden, dass diese Überwachungsvorkehrungen auch nicht von Wireless LAN Providern bereitgestellt werden muss.
Um dadurch entstehende Lücken in der Abhörkette zu vermeiden, müssen aber die
Betreiber von Übertragungswegen, die dem unmittelbaren teilnehmerbezogenen Zugang zum Internet dienen (beispielsweise DSL-Anschlüsse) Abhöranlagen installieren, d.h. der Internetanschluss des Hotspots muss überwachbar sein.
Über den Sinn der Verordnung lässt sich streiten, da die Verbrechensbekämpfung
damit nicht unbedingt verbessert wird. Die abgefangenen Daten müssen nur in
Rohform an die Behörden geliefert werden, eine Entschlüsselung von verschlüsselter
38
TKÜV (2002)
39
TKÜV (2002), § 3, Abs. 2
40
vgl. RegTP (2003)
30
Kommunikation wird bei geeigneten Verfahren in den meisten Fällen nicht möglich
sein. Weiterhin besteht die Gefahr, dass die zu schaffenden Schnittstellen durch
unbefugte genutzt werden könnten.
5.2 Speicherung und Qualität der Verbindungsdaten
In Deutschland gelten hohe Anforderungen an den Datenschutz und an die Qualität
der Verbindungsdaten. Die Bundesregierung hat in der TelekommunikationsKundenschutzverordnung (TKV)41 festgelegt, welche Anforderungen für die Ermittlung der Verbindungsdaten gelten. So dürfen beispielsweise gemäß § 5 TGV – technisch genauer beschrieben in einer separaten Verfügung (Vfg. 168/1999; im Amtsblatt 23/99 der Reg TP vom 22.12.1999) – die Systemuhren maximal drei Sekunden
von der amtlichen Zeit (Atomuhr) abweichen. „Die Ganggenauigkeit, also die Abweichung der Systemuhr in Abhängigkeit von der Zeit, muss innerhalb jeder Sekunde
besser als 10 exp (-7) sein.“42 Die einwandfreie Funktionsweise des Systems ist von
einer akkreditierten Zertifizierungsstelle für Qualitätssicherungssysteme oder einem
vereidigten, öffentlich bestellten Sachverständigen zu überprüfen und der Regulierungsbehörde für Telekommunikation und Post vorzulegen.43 Die Verbindungsdaten
dürfen laut § 7 TDSV höchstens sechs Monate nach Rechnungsversand gespeichert
werden und sind dann zu löschen, falls der Kunde keinen Widerspruch gegen die
Höhe der Verbindungsentgelte eingelegt hat. Der Endkunde kann jedoch auch
bestimmen, dass die Verbindungsdaten sofort nach der Versendung der Rechnung
gelöscht werden. In diesem Fall hat er kein Anrecht auf Widerspruch.44
Da die Verordnung auf einer Richtlinie der Europäischen Union (EU) basiert, ist
anzunehmen, dass auch die anderen EU-Staaten ähnliche Anforderungen an die
Qualität stellen. Außerhalb der EU können aber schlechtere gesetzliche Ansprüche
41
TKV (1997)
42
RegTP (1999), S. 4
43
vgl. RegTP (2001)
44
vgl. TDSV (2000), S. 5
31
an die Qualität gelten. Andererseits sind die europäischen Gesetze außerhalb Europas nicht unbedingt bekannt. Um den Kunden die Sicherheit zu geben, dass die
Abrechnung der Verbindungen rechtmäßig erfolgt, kann es sinnvoll sein, die eingehenden Rohdaten als Kopie an einen Notar weiterzuleiten. Im Streitfall könnten die
dort hinterlegten Daten dann als Beweis vor Gericht genutzt werden.
32
6 T-Systems Wireless LAN Lösung
Die Wireless LAN Lösung von T-Systems ist in drei Teilbereiche aufgeteilt. Die
WISP-Plattform, an die die einzelnen Hotspots angeschlossen werden, die RoamingPlattform als AAA-Instanz für das Roaming und das Clearinghouse, welches die
Abrechnung zwischen den Partnern übernimmt. Die WISP-Plattform ist fertig gestellt
und wurde in etwas abgewandelter Form bereits zur CeBIT 2003 eingesetzt,
während die Spezifikation und Entwicklung der Roaming-Plattform und des
Clearinghouses parallel zu dieser Arbeit erfolgt.
Provider
Provider
Roaming-Plattform
WISP
Plattform
HS
HS
Clearinghouse
WISP
Plattform
HS
Provider
HS
WISP
Plattform
HS
HS
Abbildung 9: Aufbau der T-Systems Wireless LAN Lösung
6.1 WISP-Plattform
Die WISP-Plattform ist die logische Ebene, die mehrere Hotspots eines WISP
zusammenfasst. Bei T-Systems besteht die WISP-Plattform aus dem Portal, über
das sich ein im Hotspot surfender Endkunde anmeldet. Weiterhin gibt es eine Datenbank, in welcher die Benutzer- und Abrechnungsdaten sowie Texte abgelegt sind.
Die logische Verarbeitung aller Benutzeraktivitäten (Login, Logout, …) und die Erfas33
sung der AAA-Daten erfolgt durch den Kernel. Zurzeit unterstützt das System die
Abrechnung nach Guthaben (Prepaid Voucher) und das Roaming. Bei beiden ist eine
Abrechung nach Zeit oder Volumen möglich. Die Hotspots und Voucher können über
eine Weboberfläche zentral verwaltet werden.
Als Public Access Controller für angeschlossene Hotspots werden momentan Geräte
von den Firmen Nomadix und Datenlotsen eingesetzt, welche über XML bzw.
RADIUS angesprochen werden. Der Signalisierungsverkehr, also die AAA-Daten,
zwischen Hotspot und WISP-Plattform erfolgt verschlüsselt (IPsec), die Nutzdaten
selbst werden ohne Umweg über die WISP-Plattform direkt am Hotspot ins Internet
abgeleitet.
Abbildung 10: T-Systems WISP-Plattform – Schematische Darstellung
34
6.2 Roaming-Plattform
Die Roaming-Plattform wird immer dann genutzt, wenn der Endkunde keine lokale
Authentifizierung wünscht, sondern einen angeschlossenen Roaming-Provider nutzen möchte. Die Roaming-Plattform soll so aufgebaut sein, dass auch andere WISPs
außer T-Systems angeschlossen werden können. Ziel ist eine AAA-Schnittstelle für
alle angeschlossenen WISPs und für alle angeschlossenen V-WISPs, um den
Integrationsaufwand seitens T-Systems möglichst gering zu halten.
Die Roaming-Plattform wird dafür sorgen, dass ein im fremden Hotspot anmeldender
Endkunde mit den Zugangsdaten seines bevorzugten Providers im Internet surfen
kann. Hierzu muss der Kunde im fremden Hotspot seinen Benutzernamen gefolgt
vom so genannten Realm eingeben (z.B. m.mustermann@t-online.de). Die fremde
WISP-Plattform erkennt an der Endung (Realm), dass es sich um einen fremden
Surfer handelt und leitet die Anfrage an die Roaming-Plattform weiter. Diese soll nun
die Endung erkennen und anhand in der Datenbank abgelegter Regeln bestimmen,
ob dieser Provider an dem Hotspot genutzt werden darf. Falls dies der Fall ist wird
die Anfrage an den entsprechenden Provider (V-WISP) weitergeleitet. Sobald der
Nutzer authentifiziert wurde, soll er durch den WISP frei geschaltet werden, sodass
er im Internet surfen kann. Die Schnittstelle, die dieses Verfahren ermöglichen soll,
wird im Kapitel 7.3 spezifiziert.
Die Accounting-Daten sollen weiter an die Roaming-Plattform und – wenn vertraglich
vereinbart – auch an den V-WISP geleitet werden. In jedem Fall werden aber die
aufbereiteten Verbindungsdaten an den V-WISP gesendet, damit diese die genutzten
Dienste dem Endkunden in Rechnung stellen können.
Es gibt zwei Tarifmodelle. Ein WISP kann die Tarifstruktur von T-Systems anerkennen oder individuelle Tarife mit bestimmten Providern aushandeln. Falls er das
Tarifmodell von T-Systems anerkennt, erfolgt das Settlement, also die Abrechnung
zwischen den einzelnen Partnern, innerhalb der Roaming-Plattform. Werden individuelle Tarife ausgehandelt, erfolgt eine Übermittlung von unverpreisten Verbindungsdaten an das Clearinghouse.
35
Der Versand an das Clearinghouse und an die V-WISPs erfolgt über die in dieser
Arbeit zu spezifizierende Abrechnungsschnittstelle (vgl. Kapitel 8.3).
Roaming-Plattform
V-WISP
WISP
V-WISP
Clearinghouse
Mediator
Settlement
Kernel
Datenbank
WISP
WISP
Abbildung 11: T-Systems Roaming-Plattform – Schematische Darstellung
6.3 Clearinghouse-Plattform
Das T-Systems Clearinghouse soll die Abrechnung von Roaming-Verbindungen
übernehmen. Es soll nicht nur die Anbindung der Roaming-Plattform und somit der
daran angeschlossenen Partner, sondern auch die Abrechnung von anderen WISPs
bzw. V-WISPs möglich sein. Im letzteren Fall übernimmt nicht mehr die RoamingPlattform die Authentifizierung, sondern die jeweiligen Partner untereinander.
Die angeschlossenen Systeme (Roaming-Plattform, sonstige WISPs) werden die
Accountingdaten sammeln und an das Clearinghouse (genauer das MediationModul) schicken. Für jede Verbindung (also jede WLAN-Session) soll genau ein
Datensatz gesendet werden, welcher alle für die Abrechnung benötigten Verbindungsdaten enthält. Welche das sind wird im Kapitel 8.2 analysiert. Das Clearinghouse wird dafür sorgen, dass die Partner regelmäßig Daten schicken und bei
fehlenden Daten eine Meldung ausgeben.
36
Durch das Clearinghouse sollen die Roamingtarife verwaltet und die Verbindungsdaten mit Preisen versehen werden. Die Partner vereinbaren hierbei die Tarife untereinander und informieren das Clearinghouse. Anhand der hinterlegten Tarife werden
für jeden Verbindungsdatensatz die Gebühren berechnet (Rating). Die Tarife beinhalten neben dem Gesamtpreis pro Zeiteinheit oder pro Volumeneinheit auch Prozentwerte für jede beteiligte Partei. Der Prozentwert beschreibt den Anteil, den die
jeweilige Partei – WISP, Roamingpartner und Clearinghouse – von den Einnahmen
bekommt. Die verpreisten Datensätze werden an die V-WISPs geschickt. Hierfür wird
die gleiche Schnittstelle genutzt, die auch den Versand der Verbindungsdaten von
der Roaming-Plattform an die V-WISPs ermöglicht (vgl. 8.3).
WISP
V-WISP
V-WISP
Settlement
Rating
Mediator
RoamingPlattform
WISP
Datenbank
Clearinghouse
V-WISP
WISP
Abbildung 12: T-Systems Clearinghouse – Schematische Darstellung
In der Regel wird ein WISP sowohl Einnahmen generieren, indem ein fremder Kunde
in seinem Hotspot surft, als auch Ausgaben erzeugen, indem einer seiner Kunden in
einem fremden Hotspot surft. Hat ein WISP sowohl Forderungen als auch Verbindlichkeiten gegenüber anderen WISPs sollen diese durch das Clearinghouse gegeneinander aufgerechnet und die entsprechenden Rechnungen und Gutschriften generiert werden (Settlement).
Das Clearinghouse bildet somit den Roamingvertrag zwischen zwei Partnern ab und
sorgt für die korrekte Abrechnung aller anfallenden Gebühren.
37
7 Schnittstelle für AAA-Daten
Die AAA-Schnittstelle ist das Verbindungsglied zwischen WISP und Roamingbroker,
dient also der Authentifizierung, der Autorisierung und der Abrechnung (AAA) eines
im fremden Hotspot surfenden Endkunden über die Roaming-Plattform.
7.1 Anforderungen für das WLAN-Roaming
Für ein Authentifizierungsprotokoll beim Roaming sind folgende Merkmale besonders
wichtig:
•
Das Protokoll muss weit verbreitet oder für nahezu alle Systeme auf dem
Markt
einfach
installierbar
sein,
damit
schnell
viele
Unternehmen
angeschlossen werden können.
•
Die Daten müssen gesichert übertragen werden, um einen Missbrauch der
übertragenen Daten zu unterbinden.
•
Eine vollständige Übertragung der Daten muss sichergestellt sein
(Transaktionskontrolle).
•
Ein Missbrauch von Daten muss weitestgehend ausgeschlossen sein, das
heißt, auch die Parteien, welche die Anmeldedaten nur weiterleiten, dürfen
diese nicht entschlüsseln können.
Unter diesem Aspekt erfolgt eine Analyse von verschiedenen Protokollen.
7.2 Analyse gängiger Schnittstellen
Im Folgenden werden Protokolle analysiert, die in Verbindung mit WLAN Authentifizierung, Autorisierung und Accounting eingesetzt werden. Dazu gehören insbesondere das RADIUS-Protokoll und dessen Nachfolger Diameter.
38
7.2.1 Radius
Wie schon die Produktanalyse (Kapitel 4.1) gezeigt hat, ist RADIUS das am meisten
verbreitete Protokoll. Viele Hardware- und Softwareanbieter haben es in ihren
Produkten implementiert und bieten bereits Roamingfunktionen hierüber an.
Das RADIUS-Protokoll hat seinen Ursprung in der Modem-Einwahl und wird dort seit
1997 (Verabschiedung als RFC45) eingesetzt. Die Abkürzung RADIUS steht für
„Remote Authentication Dial In User Service“. Eine Erweiterung des RADIUSProtokolls, insbesondere um Accounting, ist in zwei neueren RFCs46 spezifiziert.
Aufgrund neuer Technik (DSL, Mobile IP, Wireless LAN) sind einige Erweiterungen
nötig gewesen, die als RFCs standardisiert wurden. Weiterhin sind Schwachstellen
bekannt geworden, die durch andere RFCs behoben wurden.
Protokoll
Das RADIUS-Protokoll arbeitet nach dem Client-Server-Prinzip, wobei der so
genannte NAS (Network Access Server) als Client agiert. Der gesamte AAA-Verkehr
wird vom Client aus initialisiert. Der Server kann nur auf Anfragen des Clients
antworten, nicht aber selbst Daten an den Client senden. Der Transport der Daten ist
paketbasiert.
Der Aufbau der Pakete unterteilt sich in einen Paketkopf, welcher eine feste Länge
hat, und einen variable Anzahl von Attribut-Wert-Paaren. Der Paketkopf enthält nur
Basisinformationen zum Paket. Dazu gehören ein Paket-Typ-Code, welches die Art
des Paketes definiert (z.B. Access-Request, Access-Accept) und ein Feld, das die
Länge der Nachricht beschreibt. Für jeden Anfrage (Request) des Clients wird eine
Antwort des Servers gesendet. Um eine Zuordnung der Antwort zu ermöglichen, gibt
es ein Identifier-Feld, dessen Wert für zusammengehörende Pakete immer gleich ist.
Weiterhin gibt es ein Feld Authenticator, welches für die Verschlüsselung benutzt
wird. Die Nutzdaten werden in Attribut-Wert-Paaren transportiert. Jedes Paar be-
45
RFC2138 (1997)
46
RFC2865 (2000); RFC2866 (2000)
39
steht aus drei Feldern: Code, Länge und Wert, wobei der Code den Namen des
Paketes beschreibt und im RFC definiert ist.
Abbildung 13: RADIUS – Struktur der Pakete47
AAA
RADIUS unterstützt Authentifizierung mit NAI (Network Access Identifier), CHAP
(Challenge Handshake Authentication Protocol) und PAP (Password Authentication
Protocol). In der RADIUS-Erweiterung RFC 286948 ist zusätzlich die Authentifizierung
über EAP (Extensible Authentication Protocol) beschrieben.
Authentifizierung und Autorisierung sind beim RADIUS-Protokoll in einer Anfragezyklus zusammengefasst. Der Client (NAS) sendet ein Access-Request-Paket an
den Server, in dem der gewünschte Service (z.B. Internet) angegeben wird. Der
Server antwortet im Erfolgsfall mit einem Access-Accept-Paket, andernfalls mit
Access-Reject.
Das Accounting über RADIUS ist präzise und in Echtzeit möglich, wobei auch hier
aufgrund des UDP-Protokolls darauf geachtet werden muss, dass alle Pakete ankommen (siehe Paketübertragung). Hierbei werden Accounting-Request-Pakete
gesendet, in dem alle für die Abrechnung relevanten Daten (z.B. Session ID, Ort,
Provider usw.) enthalten sind. Weiterhin ist ein Status-Code des Requests
angegeben, 1 bedeutet Start des Accountings, 2 bedeutet Zwischeninformation und
3 das Ende des Accountings. Vom Server bestätigt wird jedes Paket durch ein
Accounting-Response-Paket.
47
http://ing.ctit.utwente.nl/WU5/D5.1/Technology/radius/radiuspacket.gif (05.08.2003)
48
RFC2869 (2003)
40
Abbildung 14: RADIUS – AAA-Sequenzdiagramm49
Paketübertragung
Die Daten werden als UDP-Pakete gesendet. UDP ist ein schlankes Protokoll, das
eine einfache Implementierung eines Multithreaded RADIUS-Servers ermöglicht und
sehr performant ist. Da bei UDP-Paketen im Gegensatz zu TCP keine erfolgreiche
Übertragung erkannt werden kann, muss für jede Anfrage ein Antwort Paket
geschickt werden. Es muss ein Mechanismus implementiert werden, der bei fehlender Antwort (z.B. Netzwerkproblem) die Übertragung wiederholt. Da das RADIUSProtokoll jedoch nicht erkennen kann, warum keine Antwort empfangen wird (Server
offline, Verbindung abgebrochen, Firewallkonfiguration usw.) kann das wiederholende Senden von Paketen schnell zur Überlastung des Netzwerks führen,
49
Quelle: http://ing.ctit.utwente.nl/WU5/D5.1/Technology/radius/radius.gif (05.08.2003)
41
weshalb das RADIUS-Protokoll für große Netzwerke mit vielen gleichzeitigen Verbindungen ungeeignet erscheint.
Die RADIUS-Spezifikation erwähnt auch die Weiterleitung eines Paketes über
mehrere Server. Die genaue Funktion dieser Proxyserver wird jedoch nicht definiert
sondern kann je nach Implementierung variieren. Grundsätzlich verhält sich ein
Proxyserver wie ein Server, der Pakete von Clients empfängt, analysiert und ggf. an
andere RADIUS-Server weiterleitet.
Wie bereits erwähnt ist bei RADIUS nur eine vom Client ausgehende Kommunikation
möglich, wobei eine Erweiterung (RFC 357650) in Arbeit ist, die auch vom Server
ausgehende Kommunikation ermöglichen soll.
Eine weitere Schwachstelle des RADIUS-Protokolls ist die Tatsache, dass keine
Fehlermeldungen verschickt werden. Falls ein Paket nicht korrekt empfangen wurde
oder unbekannte Attribute vorhanden sind, wird das Paket vom Server ignoriert.
Erweiterbarkeit
Der RADIUS-Standard sieht die Möglichkeit vor, eigene Attribut-Wert-Paare hinzuzufügen. Dafür ist das Attribut mit der Nummer 26 (Vendor Specific) vorgesehen. Es
beinhaltet eine eindeutige Nummer des Herstellers. Durch die flexible Erweiterung
der Attribute können alle benötigten Informationen übertragen werden. Jedoch ist für
die Attributnummer nur ein 8 Bit Feld vorgesehen, wodurch die maximale Anzahl der
Attribut-Wert-Paare auf 256 begrenzt ist.
Zuverlässigkeit
Wie bereits erwähnt kann bei UDP-Paketen eine Übertragung nicht garantiert
werden. Außerdem kann es sein, dass der Server ein Paket ignoriert, da es nicht
bekannte Attribute beinhaltet. Die RADIUS-Spezifikation sieht hierfür vor, dass ein
Paket mehrmals wiederholt geschickt wird, wenn in einer bestimmten Zeit keine
Antwort empfangen wurde („if no response is returned within a length of time, the
50
RFC3576 (2003)
42
request is re-sent a number of times“51). Wie genau dieser Mechanismus implementiert wird kann für jedes System jedoch variieren.
Ähnlich verhält es sich mit Ausfallsicherheit, ein Mechanismus wird nicht genau
beschrieben. Es ist jedoch möglich, dass ein RADIUS-Client durch fehlende Rücksendung von Paketen erkennt, dass der Server nicht erreichbar ist. In diesem Fall
können die Pakete an einen alternativen Server geschickt werden.
Skalierbarkeit
Eine Schwachstelle von RADIUS ist die fehlende Skalierbarkeit. Da der Identifier nur
acht Bit lang ist, können maximal 256 Anfragen gleichzeitig unbeantwortet sein. Man
kann dieses Problem aber umgehen, indem man für die eindeutige Bezeichnung
einer Anfrage die Kombination aus IP-Adresse und Port-Nummer des anfragenden
Clients, der IP-Adresse und Port-Nummer des Servers und dem Identifier verwendet.
Vorteilhaft erweist sich hier aber das UDP-Protokoll, welches eine geringe Netzwerklast und Speicherverbrauch fordert.
Ein für die Zukunft entscheidendes Merkmal ist die Nutzbarkeit des neuen IPv6
Protokolls. Diese ist zwar in der RADIUS-Spezifikation nicht vorgesehen, jedoch
beschreibt das RFC 316252 wie mit geringen Anpassungen ein Betrieb mit IPv6
möglich ist.
Sicherheit
RADIUS-Pakete werden nicht verschlüsselt, mit Ausnahme des Kennwort-Feldes. Da
die Verschlüsselung über einen MD5 Hash mit Shared Secrets erfolgt, kann ein
Abhören und Entschlüsseln einer Nachricht aber nicht ausgeschlossen werden. Zum
anderen ist die Verwaltung von Shared Secrets (jede RADIUS-Verbindung sollte
unterschiedliche Secrets benutzen) sehr aufwendig. Daher ist eine zusätzliche
Verschlüsselung auf Netzwerkebene (z.B. durch IPsec) ratsam.
51
RFC2866, S. 3
52
RFC3162 (2001)
43
Ein weiteres Problem ist die Tatsache, dass RADIUS-Pakete von jedem weiterleitenden (Proxy-)Server gelesen werden. Jeder der Server kann Benutzername und
Kennwort lesen, da nur eine Verschlüsselung zwischen zwei Servern, nicht aber
zwischen den Endservern, erfolgt. Es sollten daher nur vertrauenswürdige Server die
RADIUS-Pakete empfangen können.
7.2.2 Diameter
Diameter53 gilt als der zukünftige Nachfolger des RADIUS-Protokolls. Aufgrund von
einigen Schwachstellen wird versucht, ein insbesondere für das Roaming optimiertes
Protokoll zu definieren. Die Spezifikationsphase ist jedoch noch nicht abgeschlossen,
befindet sich aber in der Abschlussphase. Mit der Standard-Spezifikation unterstützt
Diameter nur das Accounting, für weitere Funktionalitäten wie Authentifizierung und
Autorisierung sind Erweiterungen nötig. Zurzeit gibt es eine Erweiterung für Mobile
IPv4 und NASREQ für PPP/SLIP Einwahl, wobei letzteres insbesondere Authentifizierung und Autorisierung beschreibt.
Protokoll
Ebenso wie beim RADIUS-Protokoll gibt es bei Diameter mehrere Network Access
Server (NAS), die auf einen AAA-Server zugreifen. Im Unterschied zu RADIUS ist
jedoch auch eine vom Server ausgehende Kommunikation möglich.
Auch hier werden Pakete verschickt, deren Aufbau sich in Nachrichtenkopf und
Nutzdaten unterteilt. Der Nachrichtenkopf enthält neben einem Paket-Typ-Code und
der Länge des Pakets auch die Versionsnummer und die Application ID des
Diameter-Protokolls. Weiterhin gibt es einen Hop-by-Hop Identifier und einen End-toEnd Identifier, welche die Zuordnung zweier Nachrichtenpakete ermöglichen, ersterer zwischen den einzelnen Servern, welche evt. auch nur die Nachricht weiterleiten,
letzterer für die Gesamtstrecke zwischen Client und Server. Die Nutzdaten werden,
wie auch bei RADIUS, in Attribut-Wert-Paaren gehalten.
53
Calhoun / Loughney / Guttman / Zorn / Arkko (2002)
44
AAA
Diameter unterstützt mit der Basis-Spezifikation nur das Accounting. Hierbei wird der
Network Access Identifier (NAI) des anmeldenden Benutzers verwendet, welcher aus
Benutzername und Realm besteht (z.B. m.mustermann@t-online.de). Mit der
NASREQ Erweiterung ist die Authentifizierung mit CHAP (Challenge Handshake
Authentication Protocol), PAP (Password Authentication Protocol) und EAP
(Extensible Authentication Protocol) spezifiziert.
Authentifizierung und Autorisierung sind also nur mit der NASREQ-Erweiterung
möglich. Hierzu müssen Client und Server zunächst feststellen, ob beide diese
Erweiterung implementiert haben. Dies wird durch einen Capabilities-ExchangeRequest an den Server initialisiert, welcher mit Capabilities-Exchange-Answer
antwortet. Unterstützen beide Partner die Erweiterung sendet der Client einen AARequest, welcher durch eine AA-Answer bestätigt wird. AA bedeutet hierbei Authentifizierung und Autorisierung. Es können mehrere Authentifizierungs- und Autorisierungsanfragen nacheinander gesendet werden, bis beides abgeschlossen ist.
Im Unterschied zu RADIUS ist es jedoch möglich, einen Client zwangsweise zum
erneuten Authentifizieren aufzufordern. Hierfür sendet der Server ein Re-AuthRequest an den Client, welcher mit Re-Auth-Response antwortet.
Das Accounting verläuft ähnlich wie bei RADIUS, jedoch werden verschiedene
Request-Namen verwendet. Der Client sendet ein Accounting-Request und der
Server antwortet mit Accounting-Answer. Um das Accounting zu beenden sendet der
Client ein Session-Termination-Request oder der Server ein Abort-Session-Request,
worauf die Gegenstelle wieder mit der entsprechenden Answer antwortet.
Paketübertragung
Als Übertragungsprotokoll verwendet Diameter nicht wie RADIUS UDP, sondern
TCP (Transmission Control Protocol) oder SCTP (Stream Control Transmission
Protocol), wodurch der Erfolg und die Fehlerfreiheit der Übertragung erkannt sowie
Duplikate ausgeschlossen werden können. Nachteil an diesen Protokollen ist jedoch,
dass Implementierung, Betrieb und Ressourcenaufwand komplexer sind.
45
Es kann in zwei Arten von Fehlern unterschieden werden, Application- und Protokollfehler. Applicationfehler können beispielsweise fehlende Attribute sein, die
Fehlermeldung wird in einem dafür vorgesehenen Feld in der Antwort beschrieben.
Protokollfehler hingegen können ggf. von einem Relay- oder Proxyserver korrigiert
werden. Im Fehlerfall wird ein Statusflag in der Nachricht gesetzt.
Auch bei Diameter ist die Weiterleitung von Paketen an andere Server möglich. Im
Gegensatz zu RADIUS ist diese Weiterleitung auch explizit in der Spezifikation
vorgesehen. Es wird unterschieden in Relay, Proxy, Redirect und Translation-Server.
Relay-Server analysieren Nachrichten und leiten sie dann an andere Server weiter.
Proxy-Server leiten Pakete ebenso weiter, überprüfen aber zusätzlich bestimmte
Sicherheitsrichtlinien. Redirect-Server verweisen Clients an einen anderen Server
ohne die Daten zu analysieren. Translation-Server transformieren Nachrichten
zwischen Diameter und anderen AAA-Protokollen.
Erweiterbarkeit
Diameter baut auf RADIUS auf und ist bei den Attributen abwärtskompatibel. Die
Attribute 1 bis 255 sind für RADIUS reserviert, ebenso die Paket-Typ-Codes von 0
bis 255. Weiterhin sind Translation-Server vorgesehen, die Transformationen von
Diameter in andere Protokolle ermöglichen.
Für die Attribute und Paket-Type-Codes sind bei Diameter 2 Byte vorgesehen, was
einer maximalen Anzahl von 65.536 entspricht, für die Application ID sind es sogar 4
Byte, also über 4 Milliarden.
Durch die Versionskontrolle und die Überprüfung nach unterstützten Erweiterungen
durch Capabilities-Exchange Nachrichten ist eine einfache Erweiterung des Protokolls möglich.
Im Gegensatz zu RADIUS sind alle Erweiterungen des Diameter-Protokolls öffentlich, d.h. sie können von jedem benutzt werden. Für neue Attribut-Wert-Paare und
Erweiterungen (Applications) müssen öffentliche IDs zentral bei der IANA beantragt
werden. Dies sorgt für eine Konsistenz des Protokolls, hat aber vielleicht den Nachteil, dass eine Genehmigung einige Zeit in Anspruch nehmen kann und eventuell
eine Bearbeitungsgebühr fällig wird.
46
Zuverlässigkeit
Im Gegensatz zu RADIUS kann jeder Client bzw. Server aufgrund des zustandsbasierten Protokolls erkennen, ob eine Übertragung erfolgreich war. Zusätzlich kann
mit speziellen Nachrichtenpaketen (Device-Watchdog-Request und -Answer) überprüft werden, ob ein bestimmter Server (oder Client) noch online ist.
Weiterhin gibt es bei Diameter für jedes Paket einen Status, welcher beispielsweise
beschreibt, ob eine Antwort erhalten wurde oder nicht. Dadurch kann nach einem
Serverausfall genau erkannt werden, welche Pakete ggf. wiederholt gesendet
werden müssen.
Es gibt Ansätze eines Fail-over-Szenarios, jedoch ist dies nicht bis ins Detail spezifiziert. Es ist zwar definiert, dass bei Nichterreichbarkeit eines Servers die Pakete zu
einem Ersatzserver geschickt werden sollen, jedoch ist (noch) nicht beschrieben, ab
wann wieder der erste Server angesprochen werden soll.
Skalierbarkeit
Die Skalierbarkeit auf der Transportebene ist abhängig von der Anzahl der ClientServer-Verbindungen und auf Session-Ebene von der Anzahl der Benutzer. Die
Netzlast und auch die Ressourcenlast steigen aufgrund des zustandsbasierten
Protokolls schneller als bei RADIUS.
Da Diameter ein neues Protokoll ist, unterstützt es von Anfang an IPv6, ist also für
die Erweiterung des Internetadressraums geeignet.
Sicherheit
Alle Diameter Clients und Server müssen IPsec als Verschlüsselungsprotokoll unterstützen. TLS (Transport Layer Security) muss von allen Servern und sollte von den
Clients unterstützt werden. Weiterhin gibt es ein End-to-End-Sicherheitskonzept, das
bei RADIUS komplett fehlt, allerdings ist dessen Nutzung nicht vorgeschrieben
sondern nur empfohlen. Durch die vorgeschriebene Verschlüsselung und die mögliche End-to-End-Sicherheit ist eine sichere Authentifizierung auch über mehrere
Server hinweg möglich.
47
Anstatt der bei RADIUS verwendeten Shared Keys können auch Zertifikate verwendet werden. Dies mindert den Verwaltungsaufwand.
7.2.3 Andere
Es gibt noch weitere, vorwiegend proprietäre Protokolle, die zur Authentifizierung von
Anwendern genutzt werden können. Diese sind jedoch im Wireless LAN Bereich
kaum verbreitet. Da aber möglichst ein (heute oder zukünftig) verbreitetes Protokoll
genutzt werden soll, erfolgt hier nur eine Kurzbeschreibung.
Das TACACS+ Protokoll ist eine Entwicklung von Cisco Systems. Es baut auf dem
Terminal Access Controller Access Control Systems (TACACS) Protokoll auf,
welches im RFC 149254 beschrieben ist. TACACS+ wird von vielen Netzwerkkomponenten von Cisco unterstützt, jedoch nicht von anderen Unternehmen, weshalb es
als mögliches grundlegendes Protokoll in dieser Arbeit nicht in Frage kommt.
Das COPS Protokoll (Common Open Policy Service) wurde von der IETF speziell für
die Nutzung von Quality of Service im Datenverkehr entworfen. Es ist objektorientiert
aufgebaut, wodurch eine einfache Erweiterung des Protokolls möglich ist. Die Daten
werden in Objekte gekapselt innerhalb einer Nachricht gesendet. Die Übertragung
geschieht über das TCP-Protokoll.55
Ein Protokoll, welches von T-Online entwickelt wurde und dort für Authentifizierung
und Autorisierung sowie die Übermittlung von Verbindungsdaten genutzt wird, nennt
sich SAM. Es wird jedoch nur in Verbindung mit T-Online eingesetzt und entfällt
daher als mögliches AAA-Protokoll.
7.2.4 Fazit
Das RADIUS-Protokoll hat im Bereich Wireless LAN AAA zurzeit die größte Verbreitung. Das Zeigt die Marktanalyse (vgl. Kapitel 4.1). Sogar die GSM Association setzt
54
RFC1492 (1993)
55
vgl. Mallenius (2000), S. 8
48
auf RADIUS56. Da das Protokoll (mit Erweiterungen) für die gewünschten Zwecke
ausreicht, soll AAA über RADIUS erfolgen. Eine schnelle Integration von WISPSystemen sollte dadurch möglich sein.
Weil die Sicherheit bei diesem Protokoll jedoch nicht sehr ausgereift ist, wird auf
Sicherheitsbedenken genauer im folgenden Unterkapitel eingegangen.
Der Markt ist jedoch schnelllebig. Nach erfolgter Standardisierung des DiameterProtokolls werden viele Hersteller dieses Protokoll nutzen. Spätestens zu diesem
Zeitpunkt wird auch die Roaming-Schnittstelle auf das neue Protokoll umgestellt
werden müssen. Es wird dann ein Übersetzungs-Server implementiert werden, der
die vorhandenen Systeme weiter anschließt, also die Übersetzung zwischen
RADIUS und Diameter übernimmt. Wie eine solche Übersetzung auszusehen hat, ist
bereits im Diameter Draft beschrieben57.
Wie die Marktanalyse gezeigt hat, werden die Anzahl der Hotspotnutzer stark
steigen. Auch die Anzahl der Hotspots steigt enorm. Aus diesem Grund wird es
vermutlich immer mehr WISP-Systeme geben, welche zukünftig an die RoamingPlattform angeschlossen werden. Wie bei der Analyse des RADIUS-Protokolls festgestellt wurde (vgl. 7.2.1) kann über dieses Protokoll aber nur eine bestimmte Anzahl
von Paketen zuverlässig übertragen werden, ab einer bestimmten Anzahl steigt die
Netzauslastung und die Anzahl der verlorenen Pakete exponentiell. Daher ist in nicht
allzu ferner Zukunft – auch gerade bei internationaler Ausdehnung – ein System von
verteilten Servern notwendig, die Pakete annehmen und an den zentralen Server
über ein anderes Protokoll weiterleiten. Hierfür scheint das Diameter-Protokoll am
besten geeignet, da es u.a. wegen der Nutzung des TCP-Protokolls zuverlässiger in
der Übertragung ist. Weiterhin unterstützt es bereits Proxy-Mechanismen und
Transformation zwischen RADIUS- und Diameter-Attributen (vgl. 7.2.2).
56
vgl. GSM-IR.61 (2003)
57
vgl. Calhoun / Mitton / Spence / Zorn (2003), S. 48ff
49
7.3 Definition der AAA-Schnittstelle
Aufgrund der großen Verbreitung bei den WISP-Systemen und teilweise auch bei
den V-WISPs wird für die AAA-Schnittstelle das RADIUS-Protokoll verwendet.
Hierbei gibt es aber zwei Probleme. Wie sich während den ersten Gesprächen mit
verschiedenen Herstellern von WISP-Systemen gezeigt hat, interpretieren diese das
schon angesprochene Wi-Fi Draft58 unterschiedlich, weshalb keine eindeutige
Schnittstellenbeschreibung möglich ist.
Weiterhin erlauben nicht alle V-WISPs die RADIUS-Authentifizierung, zumeist aus
Sicherheitsgründen, denn wie bereits im Kapitel 7.2.1 beschrieben wurde, können
auf den beteiligten (Proxy-)Servern die Authentifizierungsdaten abgefangen und
missbraucht werden. Dies kann zwar durch den Einsatz eines anderen Protokolls
verhindert werden, aber der Betreiber des vom Surfer besuchten Hotspots kann die
Anmeldedaten bei jedem Protokoll immer abfangen.
Es werden daher zwei verschiedene Schnittstellenbeschreibungen entwickelt. Die
anzuschließenden V-WISPs können sich aussuchen, ob sie eine Authentifizierung
über das RADIUS-Protokoll erlauben (vgl. 7.3.1), oder eine sicherere Methode
verwenden wollen, welche als zweites beschrieben wird (vgl. 7.3.2).
Die anzuschließenden WISPs müssen sich entscheiden, ob sie nur Roaming mit den
V-WISPs nutzen wollen, die das unsichere RADIUS-Roaming zulassen oder ob sie
das aufwendigere „ANID-Roaming“ implementieren wollen.
7.3.1 RADIUS-Schnittstelle aufbauend auf Wi-Fi
Die einfachere Methode der Authentifizierung eines Endkunden über die RoamingPlattform läuft über eine RADIUS-Schnittstelle. Im Folgenden wird beschrieben, wie
T-Systems den Wi-Fi Draft interpretiert und welche Ergänzungen für die Nutzung der
vollen Funktionalität der Roaming-Plattform notwendig sind.
58
Wi-Fi (2003)
50
Ermittlung der Anmeldedaten innerhalb des besuchten WISP-Systems
Durch den WISP – genauer durch eine bestimmte Webseite des WISPs – werden die
Anmeldedaten des Users erfragt und an den internen AAA-Server gesendet. Sollte
dieser den Dienstnutzer nicht kennen (z.B. fremder User, oder externes GutscheinSystem), so leitet er die Nutzungsdaten an die Roaming-Plattform von T-Systems
weiter.
Weiterleitung der Anmeldedaten an den Roamingbroker mittels RADIUS
Die Weiterleitung der Anmeldedaten von der WISP-Plattform an die RoamingPlattform erfolgt über eine RADIUS-Schnittstelle. Im Access-Request Paket werden
dabei die in der Tabelle 2 und Tabelle 3 angegebenen Attribute benötigt.
Attribute
User-Name (1)
Type
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
STRING REQUIRED
Full NAI as specified in [RFC2486],
e.g. donald.duck@provider.com
User-Password STRING REQUIRED
(2)
NAS-IP-
IPADDR REQUIRED
Address (4)
Service-Type
ENUM
REQUIRED
Must be set to Login (1)
(6) (Integer)
Framed-IP-
IPADDR REQUIRED
IP-Address of the End User
Address (8)
State (24)
STRING RECOMMENDED For future use
Called-Station-
STRING REQUIRED
MAC address of the Access
ID (30)
Gateway
Calling-Station- STRING REQUIRED
MAC Address of the End User
ID (31)
51
Attribute
NAS-Identifier
Type
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
STRING REQUIRED
(32)
NAS-Port-Type
ENUM
OPTIONAL
(61)
For future use of other connections,
presently only wireless connection
(19) is used
NAS-Port-ID
STRING OPTIONAL
(87)
IP Address of the Access Gateway. If
the IP addresses of the Access
Gateway and the NAS are not the
same then this attribute MUST be
sent.
Tabelle 2: RADIUS-Attribute Access-Request
Attribute
Vendor-Specific
Type
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
REQUIRED
The vendor ID MUST be the IANA
(26)
number of T-Systems Nova
International GmbH 16787
Location-ID (1)
STRING REQUIRED
ID of the Location (Hotspot) where
the End User is using the service
Location-Name
(2)
STRING REQUIRED
Name of the Location (Hotspot)
where the End User is using the
service
Logoff-URL (3)
STRING RECOMMENDED URL for the End User to perform
explicit logoff.
Billing-ClassOf-Service (11)
STRING RECOMMENDED Describes the service(s) the End
User demands to use
(authorization).
52
Attribute
Price-Of-
Type
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
STRING RECOMMENDED Price for an offered service per unit
Service (13)
Tabelle 3: RADIUS-Attribute Access-Request (Vendor specific)
Die Attribute User-Name und User-Password werden benötigt, um die Authentifizierung des Nutzers gegenüber dem Provider vorzunehmen. Das Attribut Service-Type
beschreibt die Art des Requests z.B. „login“. Über die NAS-IP-Address und den NASIdentifier wird der RADIUS-Client bestimmt, über den sich der Nutzer authentifiziert.
Called-Station-ID und NAS-Port-ID definieren den PAC, über den der Nutzer im
Internet surft, und kann mit RADIUS-Client identisch sein. Location-ID und LocationName definieren die Location (Zusammenfassung von PACs), in der sich der Nutzer
befindet. Die Attribute Framed-IP-Address und Calling-Station-ID enthalten Daten
des Nutzers. Die Logoff-URL enthält den Link, über den der Nutzer abgemeldet
werden kann. Die Attribute Billing-Class-Of-Service und Price-Of-Service dienen zur
Abrechnung. Für zukünftige Erweiterungen sind die Attribute State und NAS-PortType vorgesehen.
Wird als WISP-Plattform eine Standardsoftware eingesetzt, welche die Informationen
in einem anderen als dem hier beschriebenen Format sendet, muss der RADIUSServer von T-Systems die Transformation der Attribute übernehmen. Detaillierter
wird hierzu weiter unten eingegangen.
Überprüfung der Anmeldedaten
Als erstes wird überprüft, ob sich der Nutzer bereits in das System eingeloggt hat, ein
Doppel-Login wird nicht unterstützt.
Anschließend erfolgt eine Überprüfung des Regelwerkes, ob der entsprechende User
an diesem Standort auch über den Provider (ermittelt über die Endung im Usernamen, z.B. @provider.net) ein Nutzungsrecht hat oder nicht.
53
Weiterleitung der Anmeldedaten an den Provider
Nun erst wird bei dem entsprechenden Provider eine Anfrage gestellt, ob der User
den angeforderten Dienst (z.B. Internetzugang) auch benutzen darf. Dies geschieht
im Idealfall durch die Weiterleitung der RADIUS-Anfrage, die Roaming-Plattform
fungiert also als RADIUS-Proxy-Server. Jedoch gibt es auch hier das Problem, dass
die RADIUS-Schnittstellen der V-WISPs teilweise unterschiedliche Attribute anfordern, weshalb auch hier bei manchen Systemen eine Übersetzung nötig werden
kann.
Falls der V-WISP keinen RADIUS-Server betreibt, sondern über eine proprietäre
Schnittstelle verfügt, kann auch dieser eingebunden werden. In diesem Fall werden
Benutzername, Kennwort und ggf. Service ID und Hotspot ID über eine andere
Schnittstelle (z.B. HTTP-Request, Webservice) übermittelt. Eine Anbindung über
andere Schnittstellen erfolgt jedoch nur projektbezogen und wird in dieser Arbeit
nicht weiter beschrieben.
Weiterleitung der Antwort an die WISP-Plattform
Die negative RADIUS-Antwort des Providers (Access-Reject – Tabelle 4) oder
positive (Access-Accept – Tabelle 5 und Tabelle 6) wird dann ggf. übersetzt und an
die anfragende WISP-Plattform weitergeleitet. Hierbei werden die zurückgelieferten
Attribute ausgelesen und ggf. auf in der Datenbank hinterlegte Werte geändert oder
zusätzliche Attribute hinzugefügt.
Attribute Name Type
Reply-message STRING
Nomads
Comment
for
Clearinghouse
Clearinghouse
REQUIRED
Reason for rejection
Nomads
Tabelle 4: RADIUS-Attribute Access-Reject
Falls die Authentifizierung nicht erfolgreich durchgeführt werden kann, enthält die
RADIUS-Antwort nur ein Attribut, Reply-message, welches den Grund hierfür
beschreibt.
54
Attribute Name Type
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
See above
User-Name (1)
STRING
OPTIONAL
State (24)
STRING
RECOMMENDED See above
Class (25)
STRING
OPTIONAL
Session-Time-
INTEGER REQUIRED
out (27)
Idle-Timeout
For future use
Maximum allowed time for End
User to use a service (in seconds)
INTEGER REQUIRED
(28)
Acct-Session-ID STRING
RECOMMENDED
(44)
Acct-Interim-
INTEGER RECOMMENDED Interval (in seconds) to send
Interval (85)
accounting updates. If not sent by
server a default value MUST be
used at the client. A default value
of 60 seconds is
RECOMMENDED
Tabelle 5: RADIUS-Attribute Access-Accept
Attribute Name Type
Vendor-Specific
(26)
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
REQUIRED
The vendor ID MUST be the IANA
number of T-Systems Nova
International GmbH 16787
Redirection
URL (4)
STRING
RECOMMENDED After Login at a WISP hotspot,
End User SHOULD be redirected
to the given URL
55
Attribute Name Type
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
Bandwidth-Min- INTEGER OPTIONAL
Minimal upstream bandwidth
Up (5)
which should be reserved to the
End User (b/s)
Bandwidth-Min- INTEGER OPTIONAL
Minimal downstream bandwidth
Down (6)
which should be reserved to the
End User (b/s)
Bandwidth-
INTEGER OPTIONAL
Max-Up (7)
Bandwidth-
Maximal upstream bandwidth the
End User is allowed to use (b/s)
INTEGER OPTIONAL
Max-Down (8)
Maximal downstream bandwidth
the End User is allowed to use
(b/s)
Session-
INTEGER OPTIONAL
Terminate-Time
Absolute time for terminating the
End Users session, see [WI-FI]
(9)
Session-
INTEGER OPTIONAL
If flag is set to one, End Users
Terminate-End-
session MUST be terminated at
Of-Day (10)
the end of the billing day
Billing-Class-
STRING
Of-Service (11)
RECOMMENDED Describes the service(s) the End
User is allowed to use
(authorization).
Price-OfService (13)
STRING
RECOMMENDED Accepted Prices for the offered
services (price per unit)
Tabelle 6: RADIUS-Attribute Access-Accept (Vendor specific)
Bei positiver Authentifizierung wird der User-Name nochmals zurück gesendet. Das
Attribut Session Time-out gibt an, nach wie viel Sekunden der Nutzer automatisch
abgemeldet werden soll, über Idle-Timeout wird die Anzahl der Sekunden angegeben, nach denen der Nutzer abgemeldet werden soll, falls keine Aktivität erkennbar
56
ist. Zusätzlich zu Session-Timeout kann durch das Attribut Session-Terminate-Time
auch eine absolute Zeit angegeben werden, zu der der Nutzer abgemeldet werden
soll. Durch Session-Terminate-End-Of-Day kann erreicht werden, dass die Session
am Ende eines Tages automatisch beendet wird. Weiterhin kann die Bandbreite
durch die Attribute Bandwidth-Min-Up, Bandwidth-Min-Down, Bandwidth-Max-Up und
Bandwidth-Max-Down eingeschränkt werden. Die Redirection URL ist die Adresse,
auf die der Nutzer nach positiver Authentifizierung weitergeleitet werden soll.
Für die Initialisierung des Accounting-Vorgangs werden die Attribute Acct-Session-ID
und Acct-Interim-Interval benötigt. Acct-Session-ID ist ein Wert, der durch den Client
bei jedem Schicken von Accounting-Informationen angegeben werden muss. In
welchen Abständen diese Informationen gesendet werden sollen wird durch AcctInterim-Interval festgelegt. Die erlaubten Services und deren Preis wird über die
Attribute Billing-Class-Of-Service und Price-Of-Service festgelegt.
Für zukünftige Erweiterungen sind die Attribute State und Class vorgesehen.
Accounting nach positiver Rückmeldung an den WISP
Nachdem der Provider (V-WISP) bestätigt hat, dass der entsprechende Nutzer auch
Zugriff auf den Dienst (z.B. Internetzugang) hat, beginnt das Accounting. Hierzu sendet die WISP-Plattfom ein Accounting-Request Paket (Tabelle 7 und Tabelle 8) mit
Status Start an die Roaming-Plattform. Während der Nutzer den Dienst in Anspruch
nimmt, sendet die WISP-Plattform in regelmäßigen Abständen (definiert im AccessAccept Paket) Accounting-Request Pakete mit dem Status Interim, die der RoamingPlattform bestätigen, dass der Dienst weiterhin genutzt wird.
Nach Beendigung der Nutzung des Dienstes (entweder durch explizierte Abmeldung
des Kunden, nach Abbruch der Verbindung oder nach Ablauf der im Access-Accept
angegebenen
maximalen
Nutzungsdauer)
sendet
die
WISP-Plattform
ein
Accounting-Request Paket mit Status Stop.
Auch hier gilt wieder, dass die Attribute ggf. auf das T-System Format übersetzt
werden müssen.
57
Attribute Name Type
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
STRING
REQUIRED
See above
IPADDR
REQUIRED
IPADDR
REQUIRED
Class (25)
STRING
OPTIONAL
Called-Station-
STRING
REQUIRED
See above
Calling-Station- STRING
REQUIRED
MAC Address of the End User
User-Name (1)
(String)
NAS-IP
Address (4) (IP
address)
Framed-IPAddress (8)
ID (30)
ID (31)
NAS-ID (32)
STRING
REQUIRED
Acct-Status-
ENUM
REQUIRED
Type (40)
1=start, 2=stop,
3= interim update
(Integer)
Acct-Delay-
INTEGER REQUIRED
Time (41)
Acct-Input-
Accounting-Stop
INTEGER REQUIRED
Octets (42)
Acct-Output-
In seconds, only used with
Only used with Accounting-Stop
and Accounting-Interim
INTEGER REQUIRED
Octets (43)
Used only with Accounting-Stop
and Accounting-Interim
Acct-Session-ID STRING
REQUIRED
(44)
Acct-SessionTime (46)
INTEGER REQUIRED
Sent with Accounting-Stop and
Accounting-Interim
58
Attribute Name Type
Acct-Input-
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
INTEGER REQUIRED
Packets (47)
Interim
(Integer)
Acct-Output-
INTEGER REQUIRED
Packets (48)
Interim
Acct-Terminate- ENUM
REQUIRED
Cause (49)
(Integer)
NAS-Port-Type
ENUM
OPTIONAL
See above
STRING
OPTIONAL
See above
(61) (Integer)
NAS-Port-ID
(87)
Tabelle 7: RADIUS-Attribute Accounting-Request
Attribute Name Type
Vendor-Specific
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
OPTIONAL
See above
(26)
Location-ID (1)
STRING
OPTIONAL
See above
Location-Name
STRING
OPTIONAL
See above
STRING
REQUIRED
The service the End User is using
(2)
Service-Name
(12)
in this accounting session.
Service-Name has to be the same
as defined in Billing-Class-ofService
59
Attribute Name Type
Price-Of-
STRING
Service (13)
Nomads
Comment for Nomads
Clearinghouse
Clearinghouse
RECOMMENDED Accepted price for the service the
user is consuming in this
accounting session (price per
unit).
Only in the Accounting-Start
packet
Tabelle 8: RADIUS-Attribute Accounting-Request (Vendor specific)
Die Attribute User-Name, NAS-IP-Address, Framed-IP-Address, Class, CalledStation-ID, Calling-Station-ID, NAS-ID, NAS-Port-Type, NAS-Port-ID, Location-ID,
Location-Name, Service-Name und Price-Of-Service sind bereits oben beschrieben.
Die weiteren Attribute dienen zur Abrechnung der Verbindung. Acct-Status-Type
definiert die Art des Accounting-Paketes. Hierbei bedeutet 1 Start einer AccountingSession, 2 bedeutet Ende und 3 Aktualisierung einer Session (interim update). Den
Zusammenhang zwischen den Paketen erkennt man am Attribut Acct-Session-ID. Da
in den Accounting-Paketen keine Uhrzeit angegeben ist, kann über Acct-Delay-Time
die Anzahl der Sekunden angegeben werden, die seit der eigentlichen Aktion (Login /
Logoff) vergangen ist. Die Attribute Acct-Input-Octets, Acct-Output-Octets, AcctSession-Time, Acct-Input-Packets und Acct-Output-Packets enthalten nur bei Stop
oder Interim-Paketen Informationen zu der Verbindungsdauer und der Menge der
übertragenen Daten. Acct-Terminate-Cause beinhaltet den Grund der Beendigung
der Session.
Je nach Vertragsbedingungen werden die RADIUS-Accountingdaten sofort an den
V-WISP weitergeleitet oder nur gesammelt und nach Beendigung des Dienstes
aggregiert übertragen.
Implementierungsaufwand
Wie sich in ersten Gesprächen mit potentiellen Kunden gezeigt hat, senden viele
WISP-Systeme die benötigten Informationen, jedoch in verschiedenen Attributen.
60
Wenn auf Seite des Kunden ein Standardsystem eingesetzt wird, erfolgt ein Integrationsprojekt. Der RADIUS-Server von T-Systems wird so angepasst, dass dieser die
Transformation vom Kunden-Format in das oben beschriebene Format durchführt.
Soll ein weiterer Kunde angeschlossen werden, der dieses Standardprodukt einsetzt,
ist kein weiteres Integrationsprojekt notwendig.
Anders verhält es sich, wenn der Kunde ein selbst entwickeltes System betreibt. Da
es wirtschaftlich nicht vertretbar ist, für jede Eigenentwicklung ein Integrationsprojekt
durchzuführen, dient das beschriebene Format als Spezifikation für den Kunden.
Dieser muss seine Software so anpassen, dass eine Kommunikation möglich ist.
Dieses Verfahren hat sich in den ersten Projekten als unproblematisch erwiesen.
7.3.2 Gesicherte Authentifizierung über anonyme Identifikation
Ein großer Nachteil an der gerade vorgestellten Authentifizierung über das RADIUSProtokoll ist – wie einleitend erwähnt – der mögliche Missbrauch der Anmeldedaten
durch den Hotspotbetreiber. Daher wird hier ein Konzept vorgestellt, dass weitaus
sicherer ist.
Grundlage ist die Anforderung, dass die Benutzerdaten nicht direkt beim WISP,
sondern auf einem Server des genutzten V-WISPs eingegeben werden sollen.
Gerade bei Accounts von großen Providern kann es sehr gefährlich werden, wenn
die Anmeldedaten abgefangen und missbraucht werden. Bei T-Online beispielsweise
können mit denselben Zugangsdaten, die auch für das Roaming verwendet werden,
die Vertragsdaten geändert und Mails gelesen werden.
Die Authentifizierung mit Hilfe eines ANID (Anonym Identifier) ist eine Erweiterung
zum normalen AAA über RADIUS. Jedoch werden nicht die Anmeldedaten per
RADIUS übertragen, sondern durch den Provider (V-WISP) anonymisierte Daten, ein
so genannter anonymer Identifier (ANID).
Aufruf der Anmeldeseite
Nach der Eingabe einer beliebigen Adresse wird der Nutzer – wie beim RADIUSRoaming auch – auf die Portalseite des Hotspots geleitet (Abbildung 15, Schritt 1).
61
Statt seine Anmeldedaten direkt auf der Portalseite des besuchten WISPs einzugeben, klickt der Nutzer beim ANID-Roaming einen auf der Startseite des angeschlossenen WISPs platzierten Button an, welcher auf eine „Verteilerseite“ der TSystems Roaming-Plattform verweist (Abbildung 15, Schritt 2). Beim Klicken auf den
Button wird ein Parameter übermittelt, aus dem der besuchte Hotspot abgeleitet werden kann. Weiterhin werden Parameter übermittelt, die für die weitere Verarbeitung
des Login-Vorgangs erforderlich sind. Dies sind die URL, die durch die RoamingPlattform aufgerufen werden soll um den ANID zu übermitteln, die Service ID des
gewünschten Services, der Name des Parameters, der die ANID enthalten soll und
der Name des Parameters, der das ANID-Kennwort enthalten soll (vgl. Tabelle 9 –
der Parameter provider muss in diesem Fall leer sein). Die WLAN-Plattform überprüft nun, welche Provider in dieser Lokation genutzt werden dürfen und zeigt diese
in einem neutralen Design an. Hierbei werden große Provider direkt aufgeführt, kleinere werden ggf. nur über einen Link „weitere“ angezeigt. Auch die Integration von
Kreditkartensystemen ist auf diese Weise möglich. Für jeden Provider wird ein Link
hinterlegt, der ebenfalls auf die Verteilerseite verweist. Alle übermittelten Parameter
werden auch hier angefügt. Zusätzlich gibt es den Parameter provider, der die
Provider ID beinhaltet.
Alternativ können die erlaubten Provider auch direkt auf der Portal-Seite des WISPs
dargestellt werden. Hierzu können die für die Lokation gültigen Provider in das
Design des WISPs integriert werden. Der Aufruf der Verteilerseite erfolgt auch hier
mit dem zusätzlichen Parameter provider. Die direkte Integration in das Design
des WISPs hat jedoch den Nachteil, dass ein erhöhter Pflegeaufwand entsteht,
beispielsweise wenn neue Provider erlaubt sind oder welche wegfallen.
Parameter
Beschreibung
Beispiel
location
Eindeutiger Bezeichner des Hotspots
dmag001
provider
Provider ID
t-online.de
service
Service ID
internet
url
Link, der zur Übermittlung des ANIDs an
https://10.0.0.6/login.php
die WISP-Plattform genutzt werden soll
62
value1
Parameter, der den ANID enthalten soll
username
value2
Parameter, der das ANID-Kennwort
password
enthalten soll
tsi-url
Link, der zur Übermittlung des ANIDs an
https://www.crossroam.com/
die Roaming-Plattform genutzt werden
addanid.aspx
soll
Tabelle 9: Parameterbeschreibung für den Aufruf der Roaming-Verteilerseite
Nachdem der Nutzer auf den gewünschten Provider geklickt hat, wird (ggf. nochmals) überprüft, ob der Provider an diesem Hotspot genutzt werden darf. Er wird auf
die für diesen Provider hinterlegte Seite geleitet, auf der er seine Anmeldedaten
eingeben muss (Abbildung 15, Schritt 3). Dabei werden die Parameter aus Tabelle 9
außer provider übermittelt. Zusätzlich zu den bisher genutzten Parametern gibt es
noch den Parameter tsi-url, der dem Provider mitteilt, wohin die ANID geschickt
werden soll. Im Unterschied zur unter 7.3.1 beschriebenen Anmeldung befindet er
sich jetzt jedoch auf einem Server des gewählten Providers. Die Verbindung
zwischen Nutzer und Provider ist mit SSL verschlüsselt.
Abbildung 15: ANID-Roaming – Aufruf der Anmeldeseite
Überprüfung der Anmeldedaten beim V-WISP
Die Authentifizierung des Nutzers gegenüber dem V-WISPs erfolgt nun in Eigenverantwortung des Providers. Im Normalfall gibt der Nutzer seine bekannten Anmeldedaten ein, es sind aber auch weitere Funktionen möglich (Kreditkarte, SMS usw.).
63
Der Provider muss keinen RADIUS-Server betreiben, sondern kann selbst seine
bevorzugte Authentifizierungsschnittstelle nutzen.
Außer der hohen Sicherheit hat die Authentifizierung direkt beim Provider den positiven Nebeneffekt, dass der Provider je nach anfragender Lokation verschiedene
Inhalte auf der Anmeldeseite darstellen kann. Dies können entweder Werbeinhalte
oder Preisauskünfte sein, die dem Endkunden direkt mitgeteilt werden können.
Erzeugung eines ANID und Weiterleitung an die WISP-Plattform
Nach erfolgreicher Authentifizierung (Abbildung 16, Schritt 1) wird vom Provider ein
ANID, welcher einen eindeutigen Bezeichner für diese Session darstellt, und ein
dazugehöriges Kennwort erzeugt. Der ANID besteht aus einer Session ID gefolgt
vom Realm des Providers (z.B. @t-online.de). Das Kennwort ist ein zufällig
erstellter, mindestens achtstelliger Wert.
Die Übersendung des ANIDs an die WISP-Plattform erfolgt durch HTTP-Redirect
(Abbildung 16, Schritt 2). Hierzu wird der Benutzer nach dem Eintragen der Anmeldedaten unter Verwendung der beim Aufruf der Verteilerseite gesendeten Parameter
(vgl. Tabelle 9) an die dort angegebene URL weitergeleitet. Der Aufruf der Seite
erfolgt also vom Browser des Nutzers selbst, weshalb eine aufwendige Übergabe
einer Session ID oder ähnliches nicht notwendig ist. Als Benutzername und Kennwort werden der erstellte ANID und das dazugehörige Kennwort verwendet.
Abbildung 16: ANID-Roaming – Nutzer-Authentifizierung und ANID-Übermittlung
64
Übermittlung des ANIDs an die Roaming-Plattform
Zusätzlich werden die anonymisierten Daten durch Aufruf einer URL an die TSystems Roaming-Plattform übermittelt und in der Datenbank hinterlegt (Abbildung
16, Schritt 3). Hierbei werden auch die Services übermittelt, welche dieser Nutzer an
dieser Lokation nutzen darf. Die Authentizität des Senders wird überprüft, indem die
übermittelnde IP-Adresse mit einem in der Datenbank hinterlegten Wert verglichen
wird.
Parameter
Beschreibung
Beispiel
anid
Erzeugte ANID
4v123p342lk334lg@t-online.de
password
Provider ID
w4x9nl2m
service
Service ID
internet
Tabelle 10: Parameterbeschreibung für die ANID-Übermittlung an T-Systems
Verarbeitung des ANID im WISP-System
Im WISP-System selbst wird der ANID als Einmal-Benutzername genutzt. Dieser
wird dann dazu verwendet, eine herkömmliche Authentifizierung (eigentlich ist es nur
eine Autorisierung) über die bereits beschriebene RADIUS-Schnittstelle (vgl. 7.3.1)
zu erreichen (Abbildung 17, Schritt 1). Die Authentifizierung und ggf. Autorisierung
des Nutzers gegenüber dem Provider ist jedoch schon geschehen und erfolgt daher
nur noch gegenüber der in der Datenbank hinterlegten Benutzerdaten. Das
Accounting erfolgt ebenso wie beim RADIUS-Roaming (Abbildung 17, Schritt 2).
Nach beendeter Verbindung werden die Verbindungsdaten durch die RoamingPlattform aufbereitet und unter Verwendung des ANIDs als Benutzernamens an die
Provider weitergeleitet. Diese Zuordnung zwischen Orginal-Benutzernamen und
ANID erfolgt durch den Provider vor der Abrechnung gegenüber dem Endkunden.
65
Abbildung 17: ANID-Roaming – Autorisierung und Accounting
Beispiel
Folgendes Beispiel verdeutlicht den Ablauf. Der Nutzer ruft eine beliebige Internetseite auf und wird auf das Portal des Hotspotbetreibers geleitet. Dort klickt er auf
einen Button, über den er zur T-Systems Verteilerseite gelangt. Hier wählt er aus den
für diesen Hotspot möglichen aufgelisteten Providern T-Online aus. Er wird auf den
Server von T-Online weitergeleitet, wo er seine T-Online Zugangsdaten eingibt.
Nach Authentifizierung gegenüber T-Online werden ANID und Kennwort erzeugt. Als
ANID wird ein zusammengesetzter Wert aus Session ID und Providerkennung
erstellt, beispielsweise 4v123p342lk334lg@t-online.de. Das zufällig gewählte
Kennwort lautet w4x9nl2m. Diese Werte werden unter Verwendung der in Tabelle 9
genannten Beispielwerte für die Zusammensetzung der Weiterleitungsadresse
verwendet, welche daher wie folgt aussieht:
https://10.0.0.6/login.php?username=4v123p342lk334lg@tonline.de&password=w4x9nl2m
Zusätzlich werden die Daten an die Roaming-Plattform gesendet. Hierzu werden die
in Tabelle 10 genannten Werte genutzt:
https://www.crossroam.com/addanid.aspx?anid=4v123p342lk334lg@t
-online.de&password=w4x9nl2m&service=internet
Die Benutzerdaten werden nun vom WISP-System als RADIUS-Request umgesetzt.
Der RADIUS-Server des WISP-Systems erkennt an der Endung @t-online.de,
66
dass es sich um einen externen Benutzer handelt und sendet einen Access-Request
an die T-Systems Roaming-Plattform. Dort wird in der lokalen Datenbank überprüft,
ob die Benutzerdaten korrekt sind und ein Access-Accept an die WISP-Plattform
zurückgesendet. Ebenso erfolgt das Accounting. Die Roaming-Plattform verarbeitet
die Accounting-Daten zu Verbindungsdaten und sendet sie an den Provider. Eine
Zuordnung der ANID zu dem echten Benutzernamen erfolgt erst wieder dort.
Implementierungsaufwand
Die Implementierung des Roaming mit ANID ist für den WISP, bzw. für den StandortBetreiber kaum aufwendiger als die Implementierung des RADIUS-Roaming. Je nach
verwendetem System sind meist nur geringe Änderungen am Design nötig. Es ist
jedoch dafür zu sorgen, dass die Roaming-Plattform und die Anmeldeseiten der
zulässigen Provider vom Hotspot aus erreichbar sind, obwohl der Benutzer noch
nicht angemeldet ist. Diese Funktionalität ist meist mit „Walled Garden“ bezeichnet.
Beim Provider sind je nach vorhandenem System etwas umfangreichere Änderungen
notwendig. Es muss eine Portalseite erstellt werden, welche die übermittelten Parameter auslesen kann, den Nutzer authentifiziert und an das WISP-System weiterleitet
sowie die anonymisierten Daten an die Roaming-Plattform sendet.
Der größte Vorteil des ANID-Roamings ist – neben dem größeren zur Verfügung
stehenden potentiellen Kundenkreis – vor allem die Sicherheit. Große Provider legen
besonderes Augenmerk auf die durch Einmalbenutzernamen und SSL-Verschlüsselung sicherere Authentifizierung. Bei dem beschriebenen ANID-Verfahren erhält
weder der WISP noch der Vermittler T-Systems die Authentifizierungsdaten des
Nutzers.
67
8 Abrechnungsschnittstelle zwischen den
Roamingpartnern
Die Abrechnungsschnittstelle soll die vom Clearinghouse empfangenen und verpreisten Verbindungsdaten an die V-WISPs übermitteln, welche die Verbindungen
dann ihren Kunden in Rechnung stellen. Weiterhin wird hier spezifiziert, wie die
Daten durch das Clearinghouse empfangen werden.
Die Rechnungsstellung von T-Systems an die Roamingpartner erfolgt nicht auf
elektronischer Basis, sondern per monatlicher Sammelrechnung in Papierform,
welche durch das hauseigene ERP-System generiert wird. Die für die Rechnung
erforderlichen Daten werden vom Clearinghouse direkt ins ERP-System übertragen.
Eine dafür erforderliche Schnittstelle ist bereits für andere Systeme innerhalb von TSystems vorhanden, weshalb die Spezifikation im Rahmen dieser Arbeit nicht notwendig ist.
8.1 Standards zur Abrechnung von Verbindungsdaten
In diesem Kapitel werden Standards analysiert, welche für die Abrechnung von
Wireless LAN Verbindungen in Frage kommen. Eine Vorauswahl wurde anhand der
Verbreitung der einzelnen Standards getroffen, da auch hier nur Standards sinnvoll
sind, die auch in Nutzung sind.
8.1.1 IPDR
IPDR ist ein Konsortium von Providern, Hardware-Herstellern, Integrationshäusern,
und Softwareherstellern, die gemeinsam einen Standard zur Abrechnung von
Verbindungsdaten erschaffen wollen. Hierzu hat das Konsortium ein Dokument
veröffentlicht, dass neben der Struktur des IPDR-Formats auch die Übertragung
spezifiziert. Die aktuelle Version nennt sich „Network Data Management - Usage
68
(NDM-U) for IP-Based Services“, trägt die Versionsnummer 3.1.1 und ist auf deren
Homepage verfügbar59.
Das IPDR-Format ist in zwei Unterformate untergliedert. Das einfache XML-Format
und das komprimierte Datenformat unterscheiden sich jedoch nicht in den Attributen.
Das neuere, komprimierte Format basiert auf XDR (RFC183260) und wurde entwickelt, um die Datenübertragung zu beschleunigen.
XML
Die Spezifikation beschreibt ein Master-Schema, welches den Aufbau einer XMLDatei definiert, in dem allgemeine Informationen zum Dokument enthalten sind. Dazu
gehören beispielsweise eine eindeutige Nummer der Datei, die Versionsnummer,
durch die die Struktur definiert ist, die Erstellungszeit und die Anzahl der Datensätze.
Aufgrund der in XML möglichen hierarchischen Struktur ist es möglich, mehrere
Datensätze in einer XML-Datei abzubilden. Zu jedem Datensatz kann laut MasterSchema eine Erstellungszeit und eine Sequenznummer angegeben werden.61
Für die verschiedenen Einsatzgebiete für IPDRs gibt es jeweils ein separates Dokument, welches zusätzliche Attribute für jeden Datensatz definiert. Die dort beschriebenen Attribute erben vom Master-Schema, d.h. alle dort definierten Attribute können
auch hier verwendet werden.
Zurzeit gibt es Spezifikationen für folgende Dienste:
•
Application Service Providing
•
Email
•
Commerce
•
Internet access
•
Streaming Media
•
Video on Demand
•
Voice over IP
59
IPDR-NDM-U (2002)
60
RFC1832 (1995)
61
vgl. IPDR-NDM-U (2002), S. 35
69
Das für diese Arbeit relevante Dokument definiert die Abrechnung von Internetzugang und trägt den Titel „Internet Access and Content, Including Wireless“. Auch
dieses Dokument ist über die IPDR-Homepage erreichbar62.
Zusätzlich zu den Attributen des Master-Schemas werden hier die für den Internetzugang relevanten definiert. Hierzu gehören das Transportprotokoll (z.B. TCP),
Verbindungsart (DSL, Netzwerk, Wireless LAN), Bandbreite, Volumen, Startzeit,
Endzeit, Dauer, IP-Adressen vom Endkunden und vom Access Gateway,
Benutzername und noch einige andere.
Es ist jedoch nicht genau spezifiziert, welche Inhalte diese Felder haben können. Es
werden zwar Beispiele angegeben, eine vollständige Liste ist jedoch nicht verfügbar.
XDR
Das komprimierte IPDR-Format63 baut auf den gleichen Schemata wie XML auf.
Lediglich die Codierung ist unterschiedlich. Während XML-Dateien einfache Textdateien sind, erfolgt die Speicherung von XDR in Binärform. So werden Zahlen nicht
als ASCII dargestellt (für jede Ziffer wird ein Byte benutzt) sondern binär. So kann
beispielsweise statt den Zahlen -9 bis 99 (zwei Byte im ASCII-Format) die Zahlen
von 0 bis 65535 dargestellt werden.
Die weitaus größere Komprimierung wird allerdings dadurch erreicht, dass die
Attribute nicht durch die Attributnamen eingeschlossen sind, sondern die Struktur im
Kopf der Datei definiert wird. So genügt zwischen den einzelnen Attributen nur ein
Byte, welches den Attributnamen und den Datentyp beschreibt. Daraus folgt allerdings, dass sich dieses Format nur rentiert, wenn eine große Menge an Datensätzen
in einer einzelnen Datei übertragen werden, da der Overhead in einer Datei relativ
groß ist.
Die Struktur ist so aufgebaut, dass ein Codieren und Decodieren schon während der
Übertragung möglich ist. Dies erhöht die Performance zusätzlich.
62
IPDR-IA (2001)
63
vgl. IPDR-NDM-U (2002), S. 43ff
70
Datenübertragung
Zusätzlich zum Aufbau wird auch die Datenübertragung zwischen einem IPDR
Sender und einem Abrechnungssystem (BSS) angesprochen. Die Übertragung wird
jedoch nicht für ein Protokoll beschrieben sondern allgemein definiert, um die
Verwendung von verschiedenen Protokollen zu ermöglichen.
Grundsätzlich gibt es für den Datenaustausch drei Möglichkeiten64.
•
Der IPDR Sender schickt Daten zum BSS, sobald neue verfügbar sind.
•
Das BSS ruft in Eigeninitiative die Daten vom IPDR Sender ab.
•
Der IPDR Sender informiert das BSS über die Verfügbarkeit von neuen
Daten, woraufhin es die Daten abrufen kann.
Die Zuordnung der Dokumente zu den Abrechnungssystemen erfolgt anhand von
Gruppen. Ein BSS kann eine Gruppe abbonieren. Innerhalb dieser Gruppe werden
die Dokumente fortlaufend nummeriert, sodass ein anforderndes BSS anhand der
Nummer erkennen kann, ob neue Dokumente verfügbar sind. Neben diesen Gruppen und Sequenznummern hat jedes Dokument zusätzlich eine eindeutige ID.
Das Unterkapitel „Protocol Primitives and Parameters“65 beschreibt die Funktionen,
die für den Datenaustausch benötigt werden. Hier werden jedoch nur Funktionsnamen, Parameter und Sinn der jeweiligen Funktion beschrieben, nicht die Verarbeitung selbst. Es gibt Funktionen für Auflistung von Gruppen und Dokumenten, für
das Abbonieren und Abbestellen einer Gruppe, für das Senden und Abrufen von
Dokumenten sowie für die Anforderung der unterstützten Protokollversion.
Es werden zwei Beispiele angegeben, wie die Datenübertragung erfolgen kann. Die
eine Möglichkeit ist die Verwendung des SOAP-Protokolls, wobei die IPDR XMLDokumente hierbei in die XML-Struktur des SOAP-Protokolls eingebettet werden. Es
wird ausdrücklich darauf hingewiesen, dass diese Methode noch nicht in der Praxis
eingesetzt wurde und die Spezifikation sich noch in der Entwicklung befindet. Eine
64
vgl. IPDR-NDM-U (2002), S. 60
65
71
zweite Möglichkeit ist die Nutzung des sogenannten „File Sharing Protocols“66,
welches aber nur den direkten Austausch der Dokumente beschreibt, nicht jedoch
die anderen Funktionen wie Abbonieren, Dokumente und Gruppen auflisten usw.
ermöglicht.
8.1.2 TAP3
Der TAP3-Standard wird von Mobilfunkanbietern für die Abrechnung von Roamingleistungen genutzt. Herausgegeben wird dieser Standard von der GSM Association.
In der aktuellen Version TAP3.11 können u.a. Telefongespräche, SMS-Versand,
Datenübertragung (GPRS) und Mehrwertdienste (Bezahlung für bestimmte Services)
abgerechnet werden. Seit der Version 3.10.01 ist die Abrechnung von Wireless LAN
Services über das TAP3-Format möglich67.
Struktur
Das TAP3-Format wird, so wie das IPDR-Format, ebenfalls als Baumstruktur dargestellt, jedoch ist diese erheblich komplexer68. Das oberste Element heißt Data
Interchange, welches sich in Notification und Transfer Batch verzweigt. Pro Datei
kann nur eines der beiden Objekte übertragen werden.
Unter Notification befinden sich Objekte wie Sender, Empfänger, Erstellungszeit und
Version. Es beinhaltet aber keine Nutzdaten.
Transfer Batch verzweigt sich in Batch Control Information (Sender, Empfänger,
Erstellungszeit und Version), Accounting Information (Steuern, Rabatte, Währung,
Wechselkurs), Network Information, VAS Information, Message Description, Call
Event Details und Audit Control Information (Rechnungsdaten). VAS Information,
Message Description Information und Call Event Details können mehrfach erscheinen, es ist also möglich, mehrere Datensätze in einer Datei abzubilden.
66
67
vgl. GSM-TAP3.10.01 (2002), S. 3
68
vgl. GSM-TAP3.11 (2003), S. 12ff
72
Am stärksten untergliedert sind die Call Event Details. Jeder Abrechnungsdatensatz
wird durch eines der folgenden Objekte beschrieben: Mobile Originated Call, Mobile
Terminated Call, Supplementary Service Event, Service Center Usage, Value Added
Service, GPRS Call, Content Transaction und Location Service.
Für Wireless LAN werden die gleichen Attribute genutzt wie für GPRS, d.h. die des
Objektes GPRS Call. Ob WLAN oder GPRS genutzt wurde, wird im Attribut Type Of
Controlling Node angegeben. Weitere Objekte, die gefüllt werden müssen, sind
GPRS Basic Call Information (Nutzerinformationen, Zugangsinformationen), GPRS
Location Information (Daten zum GPRS Netzwerk, Daten des eigenen Netzwerkes
und geografische Angaben), Equipment Information, GPRS Services Used (Datenvolumen, Datum und Zeit, Dauer und Gebühren), CAMEL Service Used, Value
Added Service Used und Operator Specific Information.
Codierung
Die oben beschriebene Struktur des TAP-Formates ist in ASN.1 definiert. ASN.1 ist
eine Beschreibungssprache, aus der mit Hilfe von Basic Encoding Rules (BER)
binärer Code generiert werden kann69. Der generierte Code kann decodiert werden,
ohne die verwendete Struktur zu kennen. Für die Umwandlung in Binärdaten können
verschiedene Compiler verwendet werden, welche als Standardprodukte erhältlich
sind.
Datenübertragung
Mit welchem Protokoll die generierten TAP-Dateien übertragen werden ist nicht
spezifiziert. Lediglich das Format der Dateinamen ist angegeben.
Fehlerbehandlung
Es kann passieren, dass sich in einer übertragenen Datei ein Fehler befindet. Dies
kann ein Syntaxfehler (kein gültiges TAP3-Format) oder aber auch ein inhaltlicher
Fehler sein, beispielsweise wenn eine Vertragsbedingung nicht eingehalten wurde.
69
vgl. Shamos (2002), Folie 24ff
73
Aus diesem Grund hat die GSM Association im April 2001 den Standard „Returned
Accounts Procedure“ (RAP) eingeführt70, eine automatisierte Fehlerbehandlung. Die
Partei, an welche die TAP-Datei geschickt wird, überprüft diese nach syntaktischen
und inhaltlichen Gesichtspunkten. Falls ein fehlerhafter Datensatz (Call Event
Details) enthalten ist, wird dieser abgelehnt. Der sendende Partner muss diesen
Datensatz korrigieren und in einer späteren TAP-Datei erneut senden.
8.1.3 Weitere Formate
Am weitesten verbreitet dürften proprietäre Formate sein, welche sich also nicht oder
nur teilweise an einem Standard orientieren.
CSV (Comma Separated Values)
Die einfachste Form Datensätze zu übermitteln ist das CSV-Format. Die Daten
werden in eine Textdatei geschrieben. Nach jedem Datensatz erfolgt ein Zeilenumbruch. Zwischen den Werten steht ein Trennzeichen, beispielsweise ein Komma
oder ein Semikolon. Es ist hierbei darauf zu achten, dass in den Werten nicht dieses
Trennzeichen und kein Zeilenumbruch vorhanden ist, da sonst die Datei nicht richtig
decodiert werden kann.
XML (Extensible Markup Language)
In den letzten Jahren wird immer mehr das XML-Format für den Datenaustausch
genutzt. Hier können die Daten hierarchisch angeordnet werden. Ähnlich wie bei
HTML werden die Werte zu Attributen zugeordnet, indem man sie in Tags
einschließt: <attributname>Wert</attributname>. Die Werte werden in HTML
Standard codiert, ein > wird also als > geschrieben.
70
vgl. Gullstrand (2001)
74
Codierung und Datenübertragung
Bei beiden Formaten ist auf die Codierung, also den verwendeten Zeichensatz der
Textdatei zu achten. Um möglichst alle Schriftzeichen abzudecken empfiehlt sich die
Verwendung von UTF8.
Die Übertragung ist bei beiden Formaten nicht spezifiziert. Die Dateien können per
Datenträger, Dateisystem, Mail, Netzwerk oder auf jede andere Art übermittelt
werden.
8.1.4 Fazit
Ziel ist es, eine flexible und einfache Form des Datenaustausches zu implementieren, die eine möglichst hohe Akzeptanz findet. Die Marktanalyse hat gezeigt, dass
für die Wireless LAN Abrechnung das IPDR-Format am meisten unterstützt wird,
aber auch proprietäre auf CSV basierende Formate sind vorhanden. Es scheint sich
aber für alle Formate keine klare Definition anzufinden. Daher soll für die erste
Version der Roaming-Plattform jede Art von Textaustausch ermöglicht werden. Das
IPDR-Format wird zunächst nur in der XML-Form unterstützt, die komplexen
Funktionen zum Abbonieren und Auflisten von Gruppen sind zunächst nicht notwendig.
Ein Protokoll für den Datenaustausch ist bei allen Formaten nicht festgelegt, weshalb
in den folgenden zwei Abschnitten auch ein Übertragungsmechanismus definiert
werden muss.
In einer späteren Version sollte GSM-Standard TAP3.11 unterstützt werden, falls
Anfragen von potenziellen Kunden diesbezüglich kommen. Insbesondere für die
Anbindung von GSM-Mobilfunkanbietern könnte diese Abrechnungsart zukünftig
interessant sein. Jedoch haben erste Gespräche gezeigt, dass auch hier proprietäre
CSV-Formate genutzt werden.
75
8.2 Empfang der Daten von WISPs
Dieses Kapitel beschreibt den Empfang von Verbindungsdaten von der RoamingPlattform oder von WISP-Systemen anderer Hersteller, die an das Clearinghouse
gesendet werden. Die Verbindungsdaten enthalten genaue Informationen zu WLANRoamingverbindungen, wie z.B. Start- und Endzeit sowie Volumen, die von den
angeschlossenen WISPs über das RADIUS-Protokoll empfangen und durch die
Roaming-Plattform aufbereitet wurden.
8.2.1 Funktionalität
Empfang der Abrechnungsdaten
Die Daten werden in Form von IPDRs über FTP empfangen. Angeschlossene Systeme bauen eine FTP-Verbindung auf, welche über IPsec verschlüsselt wird. Die
IPDRs werden in Form von Textdateien in einem Eingangsordner abgelegt. Dabei ist
darauf zu achten, dass die Dateien eine eindeutige Bezeichnung haben. Das Format
für den Dateinamen lautet wie folgt:
partnerid_yymmtt_hhss_id.ipdr
partnerid:
Eindeutige Nummer des Partners (wird durch das Clearinghouse
vergeben)
yymmtt:
Datum (Jahr, die letzten 2 Stellen / Monat, 2 Stellen / Tag, 2 Stellen)
hhmmss:
Uhrzeit (Stunden, 2 Stellen / Minuten, 2 Stellen / Sekunden, 2 Stellen)
id:
Fortlaufende Zahl
Angeschlossene Systeme können die Dateien nur in das Verzeichnis hinein kopieren, nicht aber Dateien ändern oder überschreiben.
Einlesen und Prüfen der Daten
In regelmäßigen Abständen wird der Eingangsordner vom FTP Server auf neue
Dateien überprüft. Jede neue Datei wird geöffnet und auf formelle Richtigkeit
76
(korrekte XML-Struktur, vgl. Kapitel 8.2.2) untersucht. Dabei muss darauf geachtet
werden, dass die zu öffnende Datei vollständig übertragen wurde.
Als nächstes wird überprüft, ob die Daten bereits einmal übertragen wurden. Dateiinformationen (Dateigröße, Anzahl der CDRs, Datum des ersten CDRs, Datum des
letzten CDRs, Partner ID) werden hierzu mit bereits gespeicherten in der Datenbank
verglichen. Stimmen alle Attribute überein kann davon ausgegangen werden, dass
die CDRs aus dieser Datei bereits einmal übertragen wurden.
Sind die Daten vollständig werden sie nach inhaltlichen Gesichtspunkten analysiert.
Es wird geprüft, ob die Pflichtfelder gefüllt, alle Werte positiv, die angegebenen Einheiten ($, €, kB, MB, …) bekannt und ob keine widersprüchlichen Angaben enthalten
sind (Endzeit – Startzeit = Dauer ?). Wenn die Endzeit nicht enthalten ist, wird sie
aus der Dauer berechnet.
Speichern der Daten
Sind keine Fehler gefunden worden, werden die Daten in die Datenbank gespeichert.
Dazu werden die mit Einheiten versehenen Attribute aber zunächst auf die Grundeinheiten umgerechnet.
Es gelten die folgenden Grundeinheiten:
•
Traffic-Volumen wird in Byte umgerechnet
•
Bandbreite wird in kBit/s umgerechnet
•
Zeit wird in Sekunden umgerechnet
Nach der Umrechnung werden die Daten laut Transformationstabelle (Kapitel 8.2.2)
in die Datenbank geschrieben. Sind keine Fehler aufgetreten wird die IPDR-Datei in
das Archiv-Verzeichnis verschoben und bei der nächsten Sicherung archiviert. Es
erfolgt ein Eintrag ins Logfile, in dem der Dateiname, die Bearbeitungszeit und der
Status „import ok“ enthalten sind.
Datenabgleich
Um mit einem WISP den korrekten Versand der Daten abzugleichen werden ihm
Reports zur Verfügung gestellt, in der alle von ihm erhaltenen und nicht zurückge77
wiesenen Dateien mit den Dateiinformationen aufgelistet werden. Hierzu werden die
Dateiinformationen aus der Datenbank verwendet.
Error Handling
Das Fehlermanagement ist abhängig von dem Zeitpunkt, an dem ein Fehler auftritt.
Ist die Datei nach dem Einlesen nicht vollständig und der letzte Änderungszeitpunkt
liegt nicht länger als 1 Stunde zurück wird der Fehler ignoriert und die Datei beim
nächsten Durchlauf erneut eingelesen. In diesem Fall kann davon ausgegangen
werden, dass die Datenübertragung noch nicht abgeschlossen ist.
Falls der letzte Änderungszeitpunkt länger als 1 Stunde zurück liegt und die XMLStruktur fehlerhaft ist, wird sie in ein Fehler-Verzeichnis verschoben und ein Eintrag
in das Logfile mit dem Dateinamen, der Bearbeitungszeit und dem Status „import
failed: unrecognized xml format“ geschrieben.
Wird eine Datei als doppelt gesendete Datei identifiziert wird diese in das Fehlerverzeichnis verschoben und ein Eintrag in das Logfile vorgenommen. Eingetragen
wird Dateiname, Bearbeitungszeit und dem Status „import
failed:
CDRs
already send“.
Ebenfalls in das Fehler-Verzeichnis verschoben werden die Dateien, wenn inhaltliche
Fehler festgestellt wurden. In diesem Fall wird ebenfalls ein Eintrag in das Logfile
vorgenommen. Eingetragen wird Dateiname, Bearbeitungszeit und Status. Status ist
immer „import
failed:
“ gefolgt von dem Grund („mandatory
value
missing - attribute“, „value should be positive - attribute“,
„unit unrecognized - attribute”, „wrong calculation – startTime,
endTime, duration”), wobei attribute der Name des fehlerhaften Attributes
ist.
Für jeden Fehler wird ein Eintrag ins Logfile geschrieben, auch wenn es sich noch
um die gleiche Datei handelt. Erfolgt ein Fehler, weshalb die Datei zurückgewiesen
wird, müssen auch die Dateiinformationen zu dieser Datei in der Datenbank gelöscht
werden.
78
8.2.2 Datenstruktur
IPDR-Format
Die folgende Tabelle zeigt die Attribute, welche für den Empfang verwendet werden.
Diese Attribute richten sich nach dem von IPDR.org herausgegebenen Vorgaben, die
allerdings noch nicht offizieller Standard sind (vgl. 8.1.1).
Category
Attribute
Type
Nomads
Comment for
Clearinghouse
Clearinghouse
What
transportProtocol
String
Required
Should be TCP
What
connectionType
String
Optional
Fixed Wire Dialup,
DSL, Wireless LAN,
…
What
upBandwidth
Value/Unit Optional
Upstream bandwidth
provided
What
downBandwidth
Value/Unit Optional
Downstream
bandwidth provided
What
upVolume
Value/Unit Optional/
Conditional
What
downVolume
Required when the
tariff is volume based
Required when the
Conditional
tariff is volume based
What
qosRequested
Number
Optional
For future use
What
qosDelivered
Number
Optional
For future use
When
startTime
Datetime
Required
ISO8601 time when
access started
When
endTime
Datetime
Optional/
ISO8601 time when
Conditional
access stopped. If
duration is not given
then this is required.
79
Category
When
Attribute
duration
Type
Nomads
Comment for
Clearinghouse
Clearinghouse
Conditional
Duration of access. If
endTime is not given
then this is required.
Where
accessPoint
String
Required
IP address of the
Access-Cube
Who
subscriberId
String
Required
User-Name
Where
serviceElement
String
Optional???
Access-Points (MAC
Address)
Who
serviceProviderId
String
Required
V-WISP, the provider
with whom the
subscriber has a
business relationship.
Where
locationArea
String
Required
ID of the Location
(Hotspot) where the
End User is using the
service
Where
cellId
String
MAC address of the
access-cube??
What
serviceBearer
String
WISP, hotspot
location owner
What
ipServiceId
String
Required
service name
What
amount
Value/
Required
Amount to be charged
Type
for service, required
from the WISP but not
sent to V-WISP;
Currency of value
(ISO format)
80
Category
Who
Attribute
userIpAddress
Type
String
Nomads
Comment for
Clearinghouse
Clearinghouse
Required
IP-Address of the End
User
Who
userMacAddress
String
Required
MAC-Address of the
End User
Why
terminationCause
number
optional
Reason for the
termination
Tabelle 11: IPDR-Attribute für den Versand der Verbindungsdaten
Beispiel
Nachfolgendes XML-Dokument dient als Beispiel für die Struktur einer XML-Datei.
Grundlage ist das XML-Schema von IPDR.org71, dass die Struktur jedes Dokumentes definiert, sowie das Schema72, das die Erweiterung um die zusätzlich benötigten
Attribute beschreibt.
71
IPDR-NDM-U (2002), S. 37ff
72
IPDR-IA (2001), S. 12ff
81
<?xml version="1.0" encoding="UTF-8"?>
<IPDRDoc xmlns="http://www.ipdr.org/namespaces/ipdr"
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:schemaLocation="http://www.ipdr.org/namespaces/ipdr/Ipdr
IAC2.5-A.0.xsd"
docId="f9c0ca84-1111-11b2-a222-90ef-fd73546596bb"
version="2.5">
<IPDRRec info="www.crossroam.com" />
<IPDR seqNum="1" time="2003-10-30T22:30:04Z">
<SS id="ses10" service="rstp">
<SC xsi:type="SC-WCS-Type">
<subscriberId>max@t-online.de</subscriberId>
<cellId>3E-32-2D-91-29</cellId>
</SC>
<SE xsi:type="SE-WCS-Type">
<serviceElement>192.168.1.242</serviceElement>
<serviceProviderId>toi</serviceProviderId>
<serviceBearer>dmag</serviceBearer>
</SE>
</SS>
<UE xsi:type="UE-WCS-Type" type="Start-Stop">
<connectionType>Wireless LAN</connectionType>
<transportProtocol>TCP</transportProtocol>
<upBandwidth unit="Kbps">128</upBandwidth>
<downBandwidth unit="Kbps">128</downBandwidth>
<upVolume unit="KB">1074</upVolume>
<downVolume unit="KB">8275</downVolume>
<startTime>2003-10-30T22:30:04Z</startTime>
<endTime>2003-10-30T22:30:08Z</endTime>
<accessPoint>10.0.1.161</accessPoint>
<ipServiceId>internet</ipServiceId>
<amount unit="EUR">10.50</amount>
<locationArea>dmag001</locationArea>
82
<userIpAddress>10.0.2.65</userIpAddress>
<userMacAddress>1F-3B-23-98-2C</userMacAddress>
</UE>
</IPDR>
</IPDRDoc>
Transformation von IPDR in die Datenbankstruktur
Die folgende Tabelle zeigt die Transformationslogik von IPDR in die Datenbankstruktur:
IPDR-Attribut
Datenbank-Attribut
subscriberId
UserID
ipServiceId
ContentID
upVolume
VolumeUp
downVolume
VolumeDown
locationId
LocationID
userMacAddress
MacAddress
amount
Price
currency
CurrencyID
amount
UnitID
startTime
EnterTime
endTime
ExitTime
sessionId
SessionID
Bemerkungen
Wird aus amount berechnet
Wird aus amount berechnet
Tabelle 12: Transformationslogik von IPDR in die Datenbankstruktur
83
8.3 Versand der Daten an V-WISPs
Dieses Kapitel beschreibt den Versandprozess von Verbindungsdaten von der
Roaming-Plattform bzw. dem Clearinghaus an die V-WISPs und das Format der
übermittelten Daten. Die Verbindungsdaten enthalten genaue Informationen zu
WLAN-Roamingverbindungen, wie z.B. Start- und Endzeit sowie Volumen, die von
den angeschlossenen WISPs über das RADIUS-Protokoll empfangen und durch die
Roaming-Plattform aufbereitet wurden. Je nach Partner können verschiedene Übermittlungsformate definiert werden.
8.3.1 Funktionalität
Funktionsaufruf
Das Senden von Daten an angeschlossene Provider (V-WISPs) wird durch ein
externes Modul der Roaming-Plattform angestoßen. Hierzu muss eine Funktion
aufgerufen werden, die als Parameter den Zeitraum (von, bis), die Provider ID und
die Status ID erwartet. Die Datensätze werden nach diesen Kriterien gefiltert. Alternativ kann ein Array von Datensatz IDs übergeben werden (SessionID aus der
Tabelle tbl_CDR), welches die zu sendenden Datensätze definiert. Die Provider ID
muss zur Fehlervermeidung trotzdem übergeben werden.
Rückgabewert ist die Anzahl der generierten Dateien. Bei Konfigurationsfehlern (z.B.
fehlende Vorlage oder Zielverzeichnis nicht vorhanden) wird eine negative Fehlernummer zurückgegeben.
Dateigenerierung
Aufgrund der Vielzahl der erwarteten angeschlossenen Provider wird ein einheitliches Datenformat nicht in der Praxis umzusetzen sein. Aus diesem Grund wird
versucht, das Format der zu verschickenden Daten möglichst variabel zu halten.
Für das Erstellen der zu übermittelnden Dateien werden Vorlagen verwendet. Diese
beinhalten eine Struktur (z.B. XML oder CSV) sowie Platzhalter für die möglichen
Attribute (Attributsliste vgl. Abschnitt 8.3.2). Die Platzhalter haben das Format
84
##attribute##, attribute ist das Datenbankfeld aus der Tabelle tbl_CDR,
durch das der Platzhalter ersetzt werden soll. Es können auch mehrere Datensätze
in einer Datei übermittelt werden, indem die sich wiederholende Struktur durch ##repeat-start-## und ##-repeat-end-## eingeschlossen wird. Beispiele für
mögliche Strukturen werden in Abschnitt 8.3.2 beschrieben.
Je Provider kann eine Vorlage erstellt werden. Abgelegt werden die Vorlagen in
einem Vorlagen-Verzeichnis, der Dateiname lautet template_ProviderId_
dispatch.tld, wobei ProviderId die in der Roamingbroker-Datenbank verwendete ID für einen V-WISP und tld die Dateierweiterung der Vorlage (z.B. txt oder
xml) darstellt. Die Dateierweiterung wird während des gesamten Prozesses nicht
geändert.
Die Generierung der zu versendenden Daten erfolgt mittels dieser Vorlage. Die zu
versendenden Datensätze werden anhand der Parameter aus dem Funktionsaufruf
aus der Datenbank ermittelt und die zugehörige Vorlage geöffnet. Für jeden Datensatz wird der Abschnitt zwischen den Platzhaltern ##-repeat-start-## und ##repeat-end-## wiederholt, die Platzhalter ##attribute## werden durch die
Inhalte aus den Datenbankfeldern ersetzt. Die überflüssigen Wiederholungsplatzhalter werden gelöscht. Falls die Wiederholungsplatzhalter nicht vorhanden sind,
wird für jeden Datensatz eine separate Datei angelegt.
Ist keine Vorlage für den Provider vorhanden, wird eine Standardvorlage verwendet,
die im Vorlagen-Verzeichnis unter template_default_dispatch.tld abgelegt
ist. Falls mehrere Dateierweiterungen vorhanden sind, wird xml bevorzugt, falls
diese nicht vorhanden ist die im Alphabet erste.
Die generierten Dateien werden in einem Ausgangsverzeichnis sowie in einem
Archivverzeichnis gespeichert. Als Dateiname wird out_ProviderId_id.tld
verwendet. ProviderId ist die in der Datenbank verwendete ID des Providers, id
eine fortlaufende Zahl und tld die Dateierweiterung der Vorlage. Sobald die Datei
geschrieben ist, wird in der Tabelle tbl_CDR für jeden ermittelten Datensatz das
Attribut Filename mit dem Dateinamen gefüllt und der Status in der Datenbank auf
1 gesetzt.
85
Datenaustausch
Für jeden Provider gibt es ein Ausgangsverzeichnis unterhalb des FTP-RootVerzeichnisses (z.B. ProviderID), auf das der Provider mit einem Passwort
zugreifen kann. Nach erfolgreicher Übertragung muss die Datei als Empfangsbestätigung durch den Provider aus dem Ausgangsverzeichnis gelöscht werden. In regelmäßigen Abständen wird überprüft, ob die Datei noch vorhanden ist und ggf. der
Status auf 2 geändert.
Alternativ kann der Datenaustausch auch durch die Roaming-Plattform gestartet
werden. Hierzu müssen für den Provider ein FTP-Server sowie das Verzeichnis auf
dem FTP Server festgelegt sein, in das die Dateien gespeichert werden sollen.
Weiterhin sollte der Server kennwortgeschützt sein, d.h. es müssen ein Benutzername und ein Passwort hinterlegt sein. Nach erfolgreicher Übertragung wird die
Datei aus dem Ausgangsverzeichnis gelöscht und der Status auf 2 geändert.
Die Verbindung zwischen den beteiligten Servern sollte in beiden Fällen zusätzlich
zur Sicherung durch Kennwort auch auf Netzwerkebene verschlüsselt sein.
Statusangabe
Damit eine korrekte Verarbeitung erfolgen kann, ist für jeden Datensatz der Tabelle
tbl_CDR eine Status ID (Attribut StatusID) vorhanden. Diese beschreibt den
aktuellen Status des Datensatzes.
0
Die Daten wurden vom Settlement Modul in die Datenbank geschrieben
1
Für den Datensatz wurde eine Datei erzeugt und für den Provider
bereitgestellt
2
Der Provider hat die Datei erhalten
3
Der Provider hat die Datei reklamiert
Tabelle 13: Werte für den Status beim Versand von Verbindungsdaten
86
Error Handling
Ist eine Generierung der Datei nicht möglich, weil keine Vorlage vorhanden ist, wird
der aufrufenden Komponente die Fehlernummer -1 zurückgegeben. Ist das Zielverzeichnis nicht vorhanden wird die Fehlernummer -2 zurückgegeben. Übertragungsfehler werden nicht an den Aufrufenden zurückgegeben, aber in ein Logfile geschrieben. Fehlernummer für einen Übertragungsfehler ist -3. Die Datei wird in diesem Fall
nicht aus dem Ausgangsverzeichnis gelöscht.
Generell wird jeder Fehler in ein Logfile geschrieben. Dazu werden aktuelles Datum
und aktuelle Zeit, Fehlernummer und Aufrufparameter gespeichert.
Sicherheit
Um nicht autorisierte Zugriffe und ein Abhören der Daten zu unterbinden sollte die
Verbindung zwischen Provider und der Roaming-Plattform durch IPsec verschlüsselt
werden.
Statistik
Der Provider kann jederzeit über eine HTTPS-Verbindung die zu ihm gehörenden
Daten einsehen. In der Statistik erscheinen alle Datensätze der Tabelle tbl_CDR,
die einen Status größer oder gleich 1 besitzen und deren Provider ID mit derjenigen
des Providers übereinstimmt. Die Statistik wird durch ein Kennwort geschützt.
8.3.2 Datenstruktur
Attributsliste
Als Variablen für das Feld ##attribute## können alle Spaltennamen aus der
Datenbanktabelle tbl_CDR verwendet werden. Dazu gehören:
##attribute##
Format
Remarks
SessionID
Varchar(50)
Nomads Primary Key
ContentID
Int
Nomads specific
87
UserId
Int
Nomads id of user
UserName
Varchar(50)
e.g. donald@duck.org
LocationID
Varchar(50)
Nomads id of location
LocationName
Varchar(50)
Location name
WispID
Varchar(50)
Nomads id of WISP
WispName
Varchar(50)
WISP name
VWispID
Varchar(50)
Nomads id of V-WISP
VWispName
Varchar(50)
V-WISP name
GatewayMacAdress
Varchar(12)
MAC address of PAC
GatewayIpAdress
Varchar(50)
IP address of PAC
MacAdress
Varchar(12)
MAC address of subscriber
IpAdress
Varchar(50)
IP address of subscriber
Entertime
Datetime
YYYY-MM-DDThh:mm:ssTZD (ISO 8601)
ExitTime
Datetime
Duration
int
In seconds
VolumeUp
Bigint
Volume upstream in byte
VolumeDown
Bigint
Volume downstream in byte
Price
Money
Price per unit
Currecy
Varchar(3)
ISO format (EUR, USD, GBP, …)
Unit
Varchar(10)
e.g. s, h, kb, MB
calculatedSessionPrice
Float
Price per session
State
Varchar(50)
Created
Datetime
e.g. 1997-07-16T19:20:30+01:00
YYYY-MM-DDThh:mm:ssTZD (ISO 8601)
e.g. 1997-07-16T19:20:30+01:00
Tabelle 14: Verfügbare Attribute für den Versand von Verbindungsdaten
88
Beispiele
Die folgenden Beispiele zeigen Möglichkeiten, wie eine Vorlage strukturiert werden
kann.
CSV-Datei
So könnte eine Vorlage für einen Provider mit der ID 1234 aussehen, der die Daten
als CSV-Datei (Comma Separated Values) erhalten möchte.
User;Location;WISP;Entertime;ExitTime;Timestamp
##-repeat-start-##
##UserName##;##LocationName##;##WispName##;##Entertime##;##Exi
tTime##;##Created##
##-repeat-end-##
Dateiname: template_1234_dispatch.csv
XML-Datei (Mehrere Datensätze pro Datei)
So könnte eine Vorlage für einen Provider mit der ID 89 aussehen, der alle Datensätze in einer einzelnen XML-Datei erhalten möchte.
<xml>
<service>WLAN</service>
<partner>Nomads</partner>
<records>
##-repeat-start-##
<record id=“##SessionID##“>
<creation_timestamp>##Created##</creation_timestamp>
<user>##UserName##</user>
<location id=“##LocationID##“>##LocationName##</location>
<wisp id=“##WispID##“>##WispName##</wisp>
<session_start>##Entertime##</session_start>
<session_end>##ExitTime##</session_end>
<amount>##calculatedSessionPrice##</amount>
89
<currency>##currency##</currency>
<mac>## MacAdress##</mac>
<ip>## IpAdress##</ip>
</record>
##-repeat-end-##
</records>
</xml>
Dateiname: template_89_dispatch.xml
XML-Datei (Ein Datensatz pro Datei)
So könnte eine Vorlage für einen Provider mit der ID 543 aussehen, der für jeden
Datensatz eine separate XML-Datei erhalten möchte.
<xml>
<nomads_session_id>##SessionID##</nomads_session_id>
<creation_timestamp>##Created##</creation_timestamp>
<user>##UserName##</user>
<location>##LocationName##</location>
<service>WLAN</service>
<wisp>##WispName##</wisp>
<session_start>##Entertime##</session_start>
<session_end>##ExitTime##</session_end>
<session_price>##calculatedSessionPrice##
##currency##</session_price>
</xml>
Dateiname: template_543_dispatch.xml
90
9 Zusammenfassung und Schlussbetrachtungen
Die Verbreitung von Public Wireless LAN und die Akzeptanz beim Endkunden sind
zurzeit noch gering. Das liegt vor allem an nicht ausreichenden Marketingmaßnahmen, den verbraucherunfreundlichen Zugangsmöglichkeiten und den hohen
Nutzungspreisen. Viele Endkunden wissen nicht, dass an dem aktuellen Standort
Public WLAN verfügbar ist oder wollen nicht an jedem Ort neue Voucher des
aktuellen Hotspot-Betreibers kaufen.
Die T-Systems Plattformen beseitigen die technischen Probleme. Durch die WISPPlattform kann ein Investor schnell Hotspots aufbauen, ohne eine Verwaltungssoftware programmieren zu müssen. Die Roaming-Plattform ermöglicht Besuchern,
über eine vorhandene Vertragsbeziehung mit einem anderen Provider Dienste in
seinem Hotspot in Anspruch zu nehmen. Das Clearinghouse dient der finanziellen
Abrechnung von weiteren Providern.
Die Plattformen – und nicht zuletzt diese Arbeit – tragen also dazu bei, den Public
Wireless LAN Markt so verbraucherfreundlich wie möglich zu machen und ihn
dadurch zum Wachsen zu bringen. Durch die weitere Verbreitung werden dann auch
die Preise sinken, wodurch das Medium auch wieder mehr genutzt wird.
Es wird sich jedoch zeigen, ob UMTS der Verbreitung entgegenwirkt oder sich
parallel zu Public Wireless LAN durchsetzen kann.
91
Literaturverzeichnis
Ahlers (2003)
Richtig vernetzen, Anschluss mit und ohne Kabel; Ernst Ahlers; veröffentlicht in: c’t
6/2003, Heise Verlag, Hannover
BSI (2002)
Sicherheit im Funk-LAN (WLAN, IEEE 802.11); Bundesamt für Sicherheit in der
Informationstechnik, Stand 17.07.2002; online am 20.05.2003 unter:
http://www.bsi.de/fachthem/funk_lan/wlaninfo.pdf
Cisco (2002)
BBSM for Hotspots; Cisco Systems; 2002; online am 12.08.2003 unter:
http://www.cisco.com/application/pdf/en/us/guest/products/ps4950/c1650/ccmigration
_09186a0080132900.pdf
Calhoun / Loughney / Guttman / Zorn / Arkko (2002)
Diameter Base Protocol; Pat R. Calhoun, John Loughney, Erik Guttman, Glen Zorn,
Jari Arkko; Dezember 2002; online am 05.08.2003 unter:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-17.txt
Calhoun / Mitton / Spence / Zorn (2003)
Diameter Network Access Server Application; Pat R. Calhoun, David Mitton, David
Spence, Glen Zorn; Juni 2003; online am 05.08.2003 unter:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-12.txt
Delbrouck / Wilcox (2003)
Microsoft verpasst Windows XP mehr WLAN-Sicherheit; Dirk Delbrouck und Joe
Wilcox; ZDNet; 01.04.2003; online am 28.05.2003 unter:
http://news.zdnet.de/story/0,,t533-s2132766,00.html
ECO (2003)
Greenspot WLAN-Roaming; eco, Verband der deutschen Internetwirtschaft e.V.;
04.04.2003; nicht öffentliches Dokument
X
Garderos (2003)
i250 Platform for Public and Enterprise WLAN; Garderos Software Innovations
GmbH; online am 08.10.2003 unter:
http://www.garderos.de/images/pdf/Garderos%20product%20brochure.pdf
Gebert (2003)
WISP Guide 08/2003; Michael Gebert; Marketing Society; 23.07.2003; online am
28.07.2003 unter:
http://www.marketingsociety.de/strategie/wispguide082003.pdf
GlobalAirNet AG (2003)
GANAG - highspeed wireless network; Homepage der GlobalAirNet AG; online am
12.08.2003 unter:
http://www.ganag.de/content/00hhomea.php
GLOSSAR.de (2003)
GLOSSAR.de - Zahlen und Zeichen; online am 28.05.2003 unter:
http://www.glossar.de/glossar/amglos_1.htm
Gullstrand (2001)
Tapping the Potential of Roaming; Christer Gullstrand; GSM Association; Mai 2001;
online am 10.04.2003 unter:
http://www.gsmworld.com/using/billing/potential.shtml
GSM-IR.61 (2003)
WLAN Roaming Guidelines; GSM Association; April 2003; online am 09.08.2003
unter:
http://www.gsmworld.com/documents/wlan/ir61.pdf
GSM-TAP3.10.01 (2002)
Transferred Account Procedure Data Record Format Specification; GSM Association;
Dezember 2002; online am 11.04.2003 unter:
http://www.gsmworld.com/using/billing/tap_files.zip
XI
GSM-TAP3.11 (2003)
Transferred Account Procedure Data Record Format Specification; GSM Association;
Juni 2003; online am 09.08.2003 unter:
http://www.gsmworld.com/using/billing/tap_files.zip
Heise (2003)
Standard für Power-over-Ethernet verabschiedet; Heise Online Newsticker,
24.06.2003; online am 24.06.2003 unter:
http://www.heise.de/newsticker/data/ola-24.06.03-003/
Holtrop (2003)
Rede anlässlich der Bilanzpressekonferenz am 13. März 2003 in Hannover; Thomas
Holtrop, Vorstandsvorsitzender T-Online International AG; online am 24.06.2003
unter:
http://download-dtag.t-online.de/deutsch/presse/7-reden-veroeffentlichungen/1reden-archiv/030313_holtrop.pdf
IPDR-IA (2001)
Internet Access and Content, Including Wireless, Version 2.5-A.0; IPDR
Organization; 13.04.2001; online am 07.08.2003 unter:
http://www.ipdr.org/public/Service_Specifications/2.X/IA/IAC2.5-A.0.pdf
IPDR-NDM-U (2002)
Network Data Management - Usage (NDM-U) for IP-Based Services, Version 3.1.1;
IPDR Organization; 09.10.2002; online am 07.08.2003 unter:
http://www.ipdr.org/documents/NDM-U_3.1.1.pdf
Kecman / Paolini / Pow (2003)
Public WLAN Access in Western Europe and the USA, market analysis and
forecasts; Maja Kecman, Monica Paolini, Ross Pow; Analysys Research Limited;
Februar 2003
Keene (2003a)
Das ABC der 802.11-Standards; Ian Keene; 03.03.2003; online am 26.10.2003 unter:
http://www.zdnet.de/mobile/print_this.htm?pid=20000721-20000107c
XII
Keene (2003b)
Public Wireless LAN Hot Spots: Worldwide, 2002-2008; Ian Keene; Gartner, Inc.;
15.05.2003
Lancom (2003)
Wireless-LANs an öffentlichen Plätzen; Lancom Systems; 16.01.2003; online am
16.04.2003 unter:
http://www.comdis.ch/WP_Public_Spot_030116.pdf
Mallenius (2000)
The COPS (Common Open Policy Service) Protocol; Seppo Mallenius; 08.11.2000;
http://www.cs.helsinki.fi/u/kraatika/Courses/QoS00a/mallenius.pdf
Microsoft (2003)
Windows XP-Supportpatch für Wireless Protected Access; Microsoft; 31.03.2003;
http://www.microsoft.com/downloads/details.aspx?FamilyID=009d8425-ce2b-47a4abec-274845dc9e91&displaylang=de
Mobileaccess.de (2003)
802.11g - Entwurf jetzt mit 20 statt 54 Mbit/s; in: WLAN_weekly Nachrichten,
Ausgabe 0320; online am 30.05.2003 unter:
http://www.mobileaccess.de/wlan/?go=newsletter&sid=
Netcheckin (2003)
Pressemeldung: E-Plus und NetCheckIn vereinbaren Kooperation; 05.05.2003;
http://www.netcheckin.biz/Presse/PM%20E-Plus%20050503.pdf
Wireless-LAN 802.11 und Port-basierte Authentifizierung 802.1x, 802.1x schwächelt;
Network Computing; 21.03.2002; online am 21.10.2003 unter:
http://www.networkcomputing.de/news_00/news_2002/news_0502/news_0502e.html
XIII
Gespann aus 802.1x und EAP authentifiziert auf Port-Ebene, Torwächter an jedem
Port; Network Computing; 21.10.2003; online am 21.10.2003 unter:
http://www.networkcomputing.de/heft/solutions/sl-2002/sl_1902234.htm
O2 (2003)
WLAN AG und Swisscom; Homepage von O2 Deutschland; online am 12.08.2003
unter:
http://www.o2online.de/o2/business/datenloesungen/wlan/partner/eurospot/
Plate (2003)
Einführung in Betriebssysteme, Benutzerverwaltung; Prof. Jürgen Plate; online am
29.07.2003 unter:
http://www.netzmafia.de/skripten/bs/bs5.html
RegTP (1999)
Teil 3, technische Anforderungen an Entgeltermittlungssysteme zur Sicherstellung
der richtigen Verbindungspreisberechnung nach § 5 der TelekommunikationsKundenschutz-Verordnung (TKV); Vfg. 168/1999 im Amtsblatt 23/99;
Regulierungsbehörde für Telekommunikation und Post; 22.12.1999; online am
23.10.2003 unter:
http://www.regtp.de/imperia/md/content/tech_reg_t/tkv/5.pdf
RegTP (2001)
Mitteilung zur Nachweiserstellung gemäß § 5 TelekommunikationsKundenschutzverordnung (TKV); Mitteilung Nr. 367/2001 im Amtsblatt Nr. 12/2001
der Regulierungsbehörde für Telekommunikation und Post; 27.06.2001; online am
23.10.2003 unter:
http://www.regtp.de/imperia/md/content/tech_reg_t/tkv/mit367_01.pdf
RegTP (2003)
Informationen zur Technischen Umsetzung von Überwachungsmaßnahmen;
Regulierungsbehörde für Telekommunikation und Post; online am 22.10.2003 unter:
http://www.regtp.de/tech_reg_tele/start/in_06-09-00-00-00_m/index.html
XIV
RFC1832 (1995)
XDR: External Data Representation Standard; IEEE Internet Engineering Task
Force; August 1995; online am 08.08.2003 unter:
http://www.ietf.org/rfc/rfc1832.txt
RFC1492 (1993)
An Access Control Protocol, Sometimes Called TACACS; IEEE Network Working
Group; Juli 1993; online am 26.10.2003 unter:
RFC2138 (1997)
Remote Authentication Dial In User Service (RADIUS); IEEE Network Working
Group; April 1997; online am 23.10.2003 unter:
RFC2865 (2000)
Remote Authentication Dial In User Service (RADIUS); IEEE Network Working
Group; Juni 2000; online am 09.04.2003 unter:
RFC2866 (2000)
RADIUS Accounting; IEEE Network Working Group; Juni 2000; online am
09.04.2003 unter:
RFC2869 (2003)
RADIUS Extensions; IEEE Network Working Group; Juni 2000; online am
28.10.2003 unter:
RFC3162 (2001)
RADIUS and IPv6; IEEE Network Working Group; August 2001; online am
28.10.2003 unter:
XV
RFC3576 (2003)
Dynamic Authorization Extensions to Remote Authentication Dial In User Service
(RADIUS); IEEE Network Working Group; Juli 2003; online am 27.10.2003 unter:
ServiceFactory (2003)
Products; ServiceFactory; online am 08.10.2003 unter:
http://www.servicefactory.com/main.jsp?menuPK=11&htmlPagePK=14
Shamos (2002)
eCommerce Technology, Data Interchange; Michael I. Shamos; Sommer 2002;
online am 09.08.2003 unter: http://www.stuart.iit.edu/courses/ecom540/summer00/
week3/eCommerce%20overview%5B1%5D%20-%20Shamos.ppt
Siering (2001)
WLAN-Wegweiser, Was man zum Aufbau eines 802.11b-Funknetzes braucht; Peter
Siering; veröffentlicht in: c’t 18/2001, Heise Verlag, Hannover
Starbucks (2003)
High-speed wireless internet access; Starbucks-Homepage; online am 12.08.2003
unter:
http://www.starbucks.com/retail/wireless.asp
TDSV (2000)
Telekommunikations-Datenschutzverordnung (TDSV); Bundesregierung; 18.12.2000;
http://www.bfd.bund.de/information/TDSV_neu.pdf
TKÜV (2002)
Verordnung über die technische und organisatorische Umsetzung von Maßnahmen
zur Überwachung der Telekommunikation (TelekommunikationsÜberwachungsverordnung - TKÜV); Bundesregierung; 22.01.2002; online am
06.10.2003 unter:
http://www.bmwi.de/Redaktion/Inhalte/Downloads/TKUEV1,property=pdf.pdf
XVI
TKV (1997)
Telekommunikations-Kundenschutzverordnung; Bundesregierung; 11.12.1997;
http://bundesrecht.juris.de/bundesrecht/tkv_1998/gesamt.pdf
USR (2003)
Pressemitteilung: U.S. Robotics launcht weltweit erste WLAN Netzwerkgeräte mit
100 Mbps; 22.05.2003; online am 30.05.2003 unter:
http://www.usr-presse.de/uploads/pdf/PM_100mbps_Productlaunch_210503_
FinalP030526.pdf
Wi-Fi (2002)
Wi-Fi Protected Access; Wi-Fi Alliance; 31.10.2002; online am 28.05.2003 unter:
http://www.wi-fi.org/OpenSection/pdf/Wi-Fi_Protected_Access_Overview.pdf
Wi-Fi (2003)
Wireless ISP Roaming (WISPr); Wi-Fi Alliance; 02/2003; online am 25.03.2003 unter:
http://www.wi-fi.org/opensection/downloads/wispr_v1.0.pdf
Wificom (2003a)
Wificom SAB Gateway; Wificom Technologies; online am 11.10.2003 unter:
http://www.wificom.com/content/index.shtml?Products_and_Services/SAB_Gateway/
Intro.inc
Wificom (2003b)
Wificom SAB Server; Wificom Technologies; online am 11.10.2003 unter:
http://www.wificom.com/content/index.shtml?Products_and_Services/SAB_Server/Int
ro.inc
WirelessCreation (2003)
WPS - General Features; WirelessCreation; online am 08.10.2003 unter:
http://www.wirelesscreation.biz/de/21_wps/features.htm
XVII
Glossar
Hotspot:
Gelände oder Gebäude, auf dem das Wireless LAN installiert ist
Hotspot-Besitzer:
Der Eigentümer bzw. Mieter des Geländes oder Gebäudes, auf
dem das Wireless LAN installiert ist
Hotspot-Betreiber: Der Betreiber des WLANs auf dem Gelände des HotspotBesitzers
WISP-Plattform:
Die Instanz, welche verschiedene Hotspots zusammenfasst, für
die korrekte Abrechnung der Nutzungsdaten sorgt und ggf. die
Voucherdaten verwaltet
Roaming-Plattform: Die Vermittlungsstelle zwischen der WISP-Plattform und eines
Roaming-Partners (ein Provider)
Clearinghouse:
Plattform zur gegenseitigen Abrechung von Roamingverbindungen zwischen Providern und WISPs
Provider:
Derjenige, der in direkter Beziehung zum Endkunden steht, also
das Geld vom Endkunden einnimmt. Dies kann entweder
Prepaid
geschehen,
d.h.
der
Endkunde
kauft
eine
Guthabenkarte (Voucher) oder Postpaid, d.h. der Endkunde hat
eine Vertragsbeziehung mit einem Provider, von dem er nach
Benutzung eine Rechnung bekommt (z.B. T-Online)
XVIII
CD-Rom zur Arbeit
Auf der beiliegenden CD befinden sich die als PDF verfügbaren Dokumente des
Literaturverzeichnisses, die Internetquellen sowie die Arbeit im PDF-Format. Zum
Anzeigen ist ggf. der auf der CD enthaltene Adobe Acrobat Reader bzw. ein
Internetbrowser notwendig.
Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Die Arbeit hat
keiner anderen Prüfungsbehörde vorgelegen.
Berlin, 17. November 2003
Gandolf Holler
XIX

Abrechnung von Wireless LAN Roamingverträgen

Transcription

Similar documents

gesunde ernährung, gesunde knochen

Zigarettenwerbung in Deutschland – Marketing für ein

LevelOne Wireless 11g AP Router WBR-3405TX - IT

Link zum Report - C-Lab

Jahresbericht 2011 - Bundespatentgericht

Medienkompass

INTERNATIONAL ROAMING INTERNATIONAL

Zusammenfassung - auf ThomasKaelin.ch