- II -

Inhaltsverzeichnis

Inhaltsverzeichnis   IV

Abbildungsverzeichnis   V

Tabellenverzeichnis VII   

Abk  ürzungsverzeichnis  IX

1  Vorwort  1

2  IP Security (IPSec)  3

2.1  Einführung  3

2.1.1  Internet  4

2.1.2  ISO/OSI - Referenzmodell  5

2.1.3  TCP/IP  7

2.2  Protokolle und Modi  19

2.2.1  Transportmode  19

2.2.2  Tunnelmode  20

2.2.3  Encapsulating Security Payload (ESP)  22

2.2.4  Authentication Header (AH)  26

2.2.5  Security Association (SA)  27

2.2.6  Security Policy Database (SPD)  28

2.2.7  Security Association Database (SAD)  28

2.3  Internet Key Exchange (IKE)  29

2.3.1  Domain of Interpretation (DOI)  29

2.3.2  Internet Security Association and Key Management Protocol  

  (ISAKMP)  29

3  Sicherheitsaspekte  43

3.1  Bundesamt für Sicherheit in der Informationsverarbeitung (BSI) Empfeh-  

lungen   43

3.2  Sicherheitspolitik  44

- III - 3.2.1Sicherheitspolitik für VPN . . . . . . . . . . . . . . . . . . . . . 44 3.2.2 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.3 IP Adressbereiche RFC 1918 . . . . . . . . . . . . . . . . . . . . 47 3.3 Internet Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.1 Mehrere Beteiligte Provider . . . . . . . . . . . . . . . . . . . . 49 3.3.2 Ein Beteiligter Provider . . . . . . . . . . . . . . . . . . . . . . 49 3.4 Aufbau der Einrichtungen . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.5 Risikoabschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Ausgangssituation 52

4.1 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.3 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4 Erwartungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Produktübersicht 58

5.1 Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2 Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.1 Software Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.2 Hardware Lösungen . . . . . . . . . . . . . . . . . . . . . . . . 61 5.3 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Kosten 67

6.1 Einrichtungs- und Anschaffungskosten . . . . . . . . . . . . . . . . . . . 67 6.1.1 Allgemeine Kosten . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.1.2 DDV-Anbindungen . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.1.3 VPN-Anbindungen . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.2 Laufende Kosten (Betrieb) . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.2.1 Allgemeine laufende Kosten . . . . . . . . . . . . . . . . . . . . 70 6.2.2 DDV-Anbindungen . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.2.3 VPN-Anbindungen . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.3 Vergleich der Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7 Zusammenfassung 74

Quellenverzeichnis A

Glossar E

Index M

- IV - AAnhang i

A.1 Auflistung der verwendeten Header Kodierungen (RFC 2408) . . . . . . i

A.2 Payload Formate (RFC 2408) . . . . . . . . . . . . . . . . . . . . . . . . i

A.2.1 Security Association Payload Format . . . . . . . . . . . . . . . ii

A.2.2 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . . iii A.2.3 Transform Payload Format . . . . . . . . . . . . . . . . . . . . . iv A.2.4 Key Exchange Payload Format . . . . . . . . . . . . . . . . . . . vi A.2.5 Identification Payload Format . . . . . . . . . . . . . . . . . . . vi A.2.6 Certificate Payload Format . . . . . . . . . . . . . . . . . . . . . vii A.2.7 Certificate Request Payload Format . . . . . . . . . . . . . . . . vii A.2.8 Hash Payload Format . . . . . . . . . . . . . . . . . . . . . . . . viii A.2.9 Signature Payload Format . . . . . . . . . . . . . . . . . . . . . ix A.2.10 Nonce Payload Format . . . . . . . . . . . . . . . . . . . . . . . ix A.2.11 Notification Payload Format . . . . . . . . . . . . . . . . . . . . ix A.2.12 Delete Payload Format . . . . . . . . . . . . . . . . . . . . . . . x

A.2.13 Vendor ID Payload Format . . . . . . . . . . . . . . . . . . . . . xi A.3 Beispielkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv A.3.1 Netscreen 5XP . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv A.3.2 FortiGate 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii A.3.3 CISCO IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

- V - Abbildungsverzeichnis

2.1 ISO/OSI-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Schichten im TCP/IP-Protokollstapel . . . . . . . . . . . . . . . . . . . . 7

2.3 IP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 TCP Protokollkopf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5 UDP Protokollkopf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.6 ICMP Protokollkopf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.7 Einordnung der Protokolle nach Ebenen . . . . . . . . . . . . . . . . . . 13 2.8 IP-Adresse 192.168.1.1 binär und dezimal . . . . . . . . . . . . . . . . . 14 2.9 IP-Adresse, Subnetzmaske und Netzwerk . . . . . . . . . . . . . . . . . 15 2.10 Aufbau eines TCP Paketes, für den Versand im Ethernet . . . . . . . . . . 18 2.11 IP Sec. Transportmodus . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.12 Protokoll-Köpfe im Transportmode . . . . . . . . . . . . . . . . . . . . . 20 2.13 IPSec Tunnelmodus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.14 Protokoll-Köpfe im Tunnelmode . . . . . . . . . . . . . . . . . . . . . . 22 2.15 IPSec. Verschachtelte Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 22 2.16 ESP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.17 Minimum Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.18 Optionale Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.19 Authentication-Header (AH) . . . . . . . . . . . . . . . . . . . . . . . . 26 2.20 ISAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.21 Generische ISAKMP Header . . . . . . . . . . . . . . . . . . . . . . . . 32 2.22 Data Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.23 ISAKMP Beispiel Nachricht . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Netzwerk Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1 Magisches Dreieck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1 Netzwerk “Ist Zustand“ . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.1 Security Association Payload Format . . . . . . . . . . . . . . . . . . . . iii A.2 Proposal Payload Format . . . . . . . . . . . . . . . . . . . . . . . . . . iii

- VI -

A.3  Transform Payload Format  iv

A.4  Key Exchange Payload Format  vi

A.5  Identification Payload Format  vii

A.6  Certificate Payload Format  vii

A.7  Certificate Request Payload Format  viii

A.8  Hash Payload Format  ix

A.9  Signature Payload Format  ix

A.10  Nonce Payload Format  x

A.11  Notification Payload Format  xi

A.12  Delete Payload Format  xi

A  13 Vendor ID Payload Format  xii

- VII - Tabellenverzeichnis

2.1 Adressklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2 Beispiel mögliche Klasse-C-Subnetze des Netzwerkes. . . . . . . . . . . 17 2.3 Einsatz von Verschlüsselungsverfahren . . . . . . . . . . . . . . . . . . . 25 2.4 Phase 1 Main Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.5 Phase 1 Aggressive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.6 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.7 Vordefinierte DH-Gruppen . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1 Zugänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2 IT Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.3 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.4 Laufende Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.6 Einmalige Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1 Übersicht allgemeine Kosten . . . . . . . . . . . . . . . . . . . . . . . . 68 6.2 Übersicht DDV-Anbindung . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.3 Übersicht VPN-Anbindung . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.4 Laufende Kosten allgemein . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.5 Laufende Kosten DDV-Anbindung . . . . . . . . . . . . . . . . . . . . . 72 6.6 Laufende Kosten VPN-Anbindungen . . . . . . . . . . . . . . . . . . . . 73 6.7 Kosten DDV zu VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.1 VPN-Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A.1 Exchange Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

A.2 Next Payload Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii

A.3 Situationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii A.4 IPSEC Security Protocol Identifier . . . . . . . . . . . . . . . . . . . . . iv A.5 IPSEC ESP Transform Identifier . . . . . . . . . . . . . . . . . . . . . . v

A.6 IPSEC AH Transform Identifier . . . . . . . . . . . . . . . . . . . . . . v

A.7 IPSEC ISAKMP Transform Identifier . . . . . . . . . . . . . . . . . . . v

A.8 IPSec IPCOMP Transform Identifier . . . . . . . . . . . . . . . . . . . . v

- VIII -

A.9  Attribute Types  vi

A.10  Zertifikat Typen  viii

A  11 Message Types  xiii

- IX - Abkürzungsverzeichnis

3DES Triple - Data Encryption Standard

a.a.O am angeführten Ort

ACT Anti Clogging Token

AES Advanced Encryption Standard

AH Authentication Header

ARPANET Advanced Research Project Agency Network

ADSL Asynchronous Digital Subscriber Line

BDSG Bundesdatenschutzgesetz

BITS Bump in the Stack

BITW Bump in the Wire

BSI Bundesamt für Sicherheit in der Informationsverarbeitung

CA Certificate Authority

CBC Cipher-Block-Chaining

CD Compact Disc

CIDR Classless Inter-Domain Routing

CLI Command Line Interface

CPU Central Processing Unit

DCE Data Communications Equipment

DDoS Distributed Denial of Service

DDV Datendirektverbindungen

DE-CIX Deutscher Commercial Internet Exchange

DES Data Encryption Standard

- X - DES40 Data Encryption Standard 40 Bit

DFV Datenfernverbindungen

DFÜ Datenfernübertragung

DH Diffie-Hellmann

DHCP Dynamic Host Configuration Protokoll

DMZ Demilitarized Zone

DOI Domain of Interpretation

DoS Denial of Service

DSL Digital Subscriber Line

DTAG Deutsche Telekom AG

DTE Data Terminal Equipment

EDI Electronic Data Interchange

E2E End to End

ESP Encapsulating Security Payload

FAQ Frequently Ask Questions

FTP File Transfer Protocol

GSHB Grundschutzhandbuch

HA High Availability

HMAC Keyed-Hashing for Message Authentication

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

HWC Handwerker Client

IANA Internet Assigned Numbers Authority

ICMP Internet Control Message Protocol

IDS Intrusion Detection System

- XI - IKE Internet Key Exchange

IP Internet Protocol

IPv4 Internet Protocol Version 4

IPv6 Internet Protocol Version 6

IPSec IP Security

IETF Internet Engineering Task Force

IOS Internetworking Operating System

ISAKMP Internet Security Association and Key Management Protocol

ISDN Integrated Services Digital Network

ISO International Organization for Standardization

ISP Internet Service Provider

IT Information Technologie

IV Initialisierungsvektor

KE Key Exchange

L2L LAN to LAN

L2TP Layer 2 Tunneling Protocol

LAN Local Area Network

LDAP Lightweight Directory Access Protocol

LED Light Emitting Diode

MAC Message Authentication Code

MAE Metropolitan Area Exchange

MD Message Digest

MS Microsoft Corporation

MTU Maximum Transmission Unit

NAT Network Address Translation

- XII - NIST National Institute of Standards and Technology

NPG Network Protection Gateway

NSA National Security Agency

NNTP Network News Transfer Protocol

OEM Original Equipment Manufacture

OSI Open Systems Interconnection

PC Personal Computer

PFS Perfect Forward Secrecy

PK preshared keys

PKI Public key Infrastructure

PMTU Path Maximum Transmission Unit

POP Point of Presens

POP3 Post Office Protocol Version 3

PPTP Point to Point Tunneling Protocol

PS Protection Suite

PVC Permanent Virtual Connection

RADIUS Remote Authentication Dial-In User Service

RFC Request for Comments

RIPE Reseaux IP Europeens

RZ Rechenzentrum

SA Security Association

SAD Security Association Database

SAP Service Access Points

SDSL Synchronus Digital Subscriber Line

SHA Secure Hash Algorithm

- XIII - SLA Service Level Agreement

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

SOHO Small-Office/Home-Office

SPD Security Policy Database

SPI Security Parameter Index

SSH Secure Shell

SSL Secure Socket Layer

TCP Transmission Control Protocol

TCP/IP Transmission Control Protocol / Internet Protocol

TCO Total Cost of Ownership

UDP User Datagram Protocol

UI User Interface

USV Unterbrechnungsfreie Stromversorgung

VLSM Variable Length Subnet Masks

VPN Virtual Private Networks

WAN Wide Area Network

WU Wohnungsbauunternehmen

Widmung

Als erstes möchte ich meiner lieben Frau Petra und meiner Tochter Annie, die in den letzten Jahren unter meinem Studium “leiden“ mussten, wenn ihr Mann (Vater) mal wieder für sein Studium “nebenbei“ die Zeit opferte, anstatt mit ihnen die Freizeit zu genießen. Euch möchte ich besonders für eure Geduld, Unterstützung und so manches liebe Wort danken, ohne all dieses wäre es vielleicht gar nicht zu diesem Ende gebracht worden. Außerdem möchte ich mich bei Herrn Professor Dr. Thomas Wilmes für die freundliche und engagierte Unterstützung bei der Ausarbeitung dieser Diplomarbeit und der vorhergehenden Projektarbeit bedanken.

- 1 - 1Vorwort

Unternehmungen, die verteilt über verschiedene Standorte evtl. sogar bundesweit oder international arbeiten, müssen mit immensen laufenden Kosten für die benötigten Kommunikationsverbindungen rechnen. Alternativ können durch komplizierte Replikationsverfahren die Daten zu günstigen Zeiten abgeglichen werden, wodurch diese den Anwendungssystemen nicht zeitnah zur Verfügung stehen. Heutige Unternehmen erreichen ihren Erfolg gegenüber dem Mitbewerb zu einem nicht unbeachtlichen Teil dadurch, dass sie Informationen schneller verfügbar haben als der Mitbewerb. Die erwarteten Preissenkungen durch die Öffnung des Telekommunikationsmarkt haben für die Unternehmen keinen Durchbruch gebracht. Neue preisgünstige Kommunikationslösungen für Unternehmen bergen daher ein beachtliches monatliches Einsparungspotential. So werden durch sog. Internet Service Provider (ISP), Standleitungen ins Internet mit verschiedenen Anschlußtechniken und Bitraten zu günstigen Preisen angeboten. Für die technische Realisierung sollen sog. Virtual Private Networks (VPN) verwendet werden. Diese Lösungen senden Daten in einen sog. “IP-Tunnel“ ¹ , dieser “Tunnel“, der von einem Standort zur Zentrale geführt wird, transportiert die Daten verschlüsselt und damit entsprechend vertraulich. Für den Aufbau und Betrieb dieses “Tunnels“ ist spez. Hard- oder Software notwendig.

Ein Unternehmen das Internetverbindungen als kostengünstige Lösung benutzen möchte, muss die daraus entstehenden Gefährdungen beachten und in die Kalkulation mit einbeziehen. Die bisher von einem Anwender bei einem Kommunikationsanbieter gebräuchlichen Merkmale bzgl. der Qualität, Sicherheit und der Verfügbarkeit sind durch einen ISP meist nicht zu garantieren, da ein ISP nur eingeschränkte Möglichkeiten hat, außerhalb seines eigenen Internet-Teils auf die oben genannten Merkmale Einfluss zu nehmen. Schon deshalb muss ein Unternehmen, das VPN’s betreiben möchte, den sog. Service Level Agreement (SLA)’s der ISP besondere Aufmerksamkeit widmen, und auch mögliche Ausfallszenarien in seinen Betrachtungen mit einfließen lassen. Ob der Einsatz von VPN für Unternehmen aus dem Bereich SOHO sicher und günstig gestaltet werden kann, soll in dieser Diplomarbeit exemplarisch an einem Beispiel ermittelt werden. Als Beispiel für ein Kleinunternehmen, dient uns hier eine real existierende Gesellschaft, die wir im weiteren mit Firma Electronic Data Interchange (EDI)

¹ Das Transportprotokol im Internet ist Transmission Control Protocol / Internet Protocol (TCP/IP)

- 2 - GmbH ² bezeichnen,dieses Unternehmen beschäftigt zur Zeit 18 Mitarbeiter verteilt an drei Standorten (Essen, Hamburg, Frankfurt). Die Mitarbeiter arbeiten stark teamorien-tiert. Daten werden ausschließlich elektronisch aufbereitet. Über sog. Microsoft - Ter-minalserver Clients arbeiten die Mitarbeiter auf einem zentralem Server in Essen. Die anfallenden Kommunikationsverbindungen wurden bisher mittels Datendirektverbindun-gen (DDV) der Deutsche Telekom AG (DTAG) realisiert.

In diesem Dokument soll nach einer kurzen Einführung in die Technik der TCP/IP Netzwerke eine Vertiefung in das Thema IP Security (IPSec) gegeben werden. Ein Exkurs zum Thema Sicherheit einer solchen Lösung soll Auskunft über evtl. entstehende Gefährdungen geben. Ausgehend von der realen Gesellschaft EDI mit einer Problemstellung soll über eine Marktanalyse untersucht werden, ob die sich ergebenden Nutzen, Risiken und Möglichkeiten für VPN Lösungen in Unternehmen aus dem SOHO-Bereich wirtschaftlich zu betreiben sind.

² Da die Kenntnisse über die Strukturen und Sicherheitseinrichtungen des Netzwerkes einen potentiellen Angreifer helfen könnte, habe ich den Namen der realen Gesellschaft anonymisiert.

- 3 - 2 IPSecurity (IPSec)

VPN sollen dem Anwender eine sichere Kommunikation zwischen entfernten Computern über ein öffentliches Wide Area Network (WAN) ¹ , wie z. B. das Internet bieten. So können zwei Local Area Network (LAN)’s , oder ein Benutzer mit einer Wählverbindung in ein LAN ² mittels VPN verbunden werden. Bei diesen Verbindungen werden die Datenpakete ohne VPN meist im Klartext über verschiedene Koppelelemente wie Router, Switch und Sicherheitssysteme geführt. Dabei können die Daten von jeder beteiligten Institution (z. B. Nachrichtendienste, ISP, Austauschknoten, etc.) entlang des Weges unbemerkt vom Absender mitgeschnitten, evtl. können die Daten sogar verfälscht werden. Ebenso können die Verkehrsinformationen Rückschlüsse auf den Benutzer wie z. B. Nutzerverhalten, Neigungen, etc. zulassen. Authentizität des Absenders, Integrität und Vertraulichkeit der Daten können so nicht sichergestellt werden. Diese Schwächen sind schon länger bekannt, aber dem Nutzer des Internet meist nicht bewusst. Sicherlich gibt es auch schon länger Lösungen dafür, doch waren diese in der Vergangenheit meist proprietär und teuer. In den letzten Jahren wurde deshalb ein Standard entwickelt: “IPSec“. Dieser Standard soll ermöglichen, dass vertrauliche Verbindungen im Internet (und anderen WAN) vom Anwender etabliert werden können, bei denen der Anwender sicher sein kann, dass seine Daten von keinem mitgelesen oder manipuliert werden können. Durch die Standardisierung des Protokolls wird die Koppelung unterschiedlicher Netze vereinfacht. In den Implementierungen ergeben sich jedoch im einzelnen noch Kompatibilitätsprobleme. Meist sind nicht alle Funktionen in allen Geräten umgesetzt, so dass herstellerübergreifend oft nur eingeschränkte Funktionalitäten zur Verfügung stehen.

2.1 Einführung

Zu Beginn der technischen Erläuterungen soll kurz eine gemeinsame Basis geschaffen werden. Deshalb betrachten wir in einem kurzen Abriss die Entstehung des Internet und die Beschaffenheit der unterschiedlichen Protokolle in der TCP/IP-Protokollsuite.

¹ WAN engl. für Weitverkehrsnetze

² LAN engl. für Lokales Netzwerk

- 4 - 2.1.1Internet

Als das Internet 1969 entwickelt wurde bestand es gerade mal aus vier Rechnern, 1971 waren es 15 Computer und das Netz hieß damals noch Advanced Research Project Agency Network (ARPANET). Die Teilnehmer waren untereinander alle bekannt, so dass bei der Entwicklung der Protokolle für den Datenaustausch die Vertraulichkeit keine große Rolle gespielt hatte, wohl aber die Ausfallsicherheit ³ . Mit der Entwicklung des Hypertext Transfer Protocol (HTTP) explodierte die Anzahl der Teilnehmer am Internet. Die kommerziellen Möglichkeiten des Internet wurden erkannt. Zu diesem Zeitpunkt waren im Internet schon eine sehr große Anzahl von Rechnern verfügbar, bis heute sind es ca. 100 Millionen ⁴ , Tendenz weiter steigend. Das Internet besteht heute praktisch nur aus einem Zusammenschluss von sehr vielen einzelnen Netzwerken, die alle als gemeinsames Protokoll TCP/IP benutzen. Der Datenaustausch zwischen den einzelnen Netzen wird über die sog. “Peering-Agreements“ bestimmt ⁵ . Dies sind Vereinbarungen mit denen die Betreiber der Netzwerke bestimmen, welche Datenmengen von den Partnern durch ihre Netzwerke geleitet werden dürfen. Im Gegenzug erwarten sie vom Partner, dass sie ihre Datenkontingente durch die Partnernetzwerke leiten können. Während des Wachstums des Internet haben sich Konzentrationspunkte herausgebildet, an denen sich viele dieser Peering-Partner (in der Regel sog. ISP) treffen, diese Treffpunkte werden als “Peering-Points“ bezeichnet. Bekannte Austauschknoten in den USA sind Metropolitan Area Exchange (MAE)-EAST (Washington D.C), MAE-WEST (San Jose CA) und in Deutschland z. B. Deutscher Commercial Internet Exchange (DE-CIX) (Frankfurt am Main). Damit ein Firmennetzwerk oder ein Einzelcomputer am Internet teilnehmen kann, muss man einen ISP auswählen. Mit diesem schließt man einen Vertrag über eine bestimmte Laufzeit, Bandbreite und/oder Datenvolumen, oder eine sog. Flat-Rate. Alternativ kann man auch für Einzel-Computer oder kleinere Netzwerke einen Wählzugang (Call by Call) benutzen, der über die Telefongebührenabrechnung verrechnet wird. Doch bevor ein Computer als Teilnehmer in einem Netzwerk Datenpakete loswerden kann, muss in seinem Betriebssystem eine Unterstützung für das in diesem Netzwerk verwendete Protokoll vorhanden sein. Das Protokoll, das im Internet verwendet wird nennt sich TCP/IP-Protokoll. Dieses Protokoll oder genauer diese Sammlung von Protokollen (TCP/IP-Protokollsuite) wird für jeglichen Verkehr im Internet herangezogen. Deshalb

³ Das Netz sollte nach einem evtl. Atomschlag weiter funktionieren (man war ja noch im sog. “Kalten Krieg“).

⁴ Prof. Dr. Rainer Oechsle Rechnernetze, TCP/IP: Transport und Vermittlung im Internet. Trier: Fernstudium Allgemeine Informatik, Fachhoschule Trier, 1999, Lerneinheit Informations- und Kommunikati-

onstechniken, vgl. Seite 1.

⁵ Darauf werden wir in Kap. 3.3.1 auf Seite 49 noch zurückkommen.

- 5 - werdenwir uns im Weiteren nur mit diesem Protokoll auseinandersetzen.

2.1.2 ISO/OSI - Referenzmodell

Bevor ein Computer in einem Netzwerk Daten austauschen kann, muss sein Betriebssystem über die Verkehrssprache in diesem Netzwerk informiert sein. Er muss diese sog. Protokolle beherrschen. Sein Betriebssystem stellt einer Anwendung über Schnittstellen den gewünschten Netzwerkdienst zur Verfügung. Anfangs wurden solche Schnittstellentreiber in monolithischen Blöcken erstellt. Dies hatte z. B. bei der Änderung der Netzwerkkarte den Nachteil, dass der Treiber für das Betriebssystem neu erstellt werden musste. Weitere Überlegungen führten dazu, dass man diese Netzwerkfunktionen in einen sog. Protokollstapel mit einzelnen Funktionsblöcken und einzelnen Schnittstellen (sog. Service Access Points (SAP)) aufteilte. Somit ist jedes einzelne Element im Protokollstapel austauschbar, ohne dass die darüber oder darunterliegenden Funktionsblöcke Veränderungen unterliegen (z. B. ist es einer Anwendung egal, ob sie auf einem Token-Ring Netzwerk oder einem Ethernet Netzwerk ihre Daten versendet). In Abb. 2.1 ist das sog. International Organization for Standardization (ISO)/Open Systems Interconnection (OSI)- Referenzmodelldargestellt. Jede einzelne Schicht hat eine spezielle Funktion, die wir im Anschluss kurz anreißen wollen, entnommen sind diese Angaben: Dr. Holger Taday Grundlagen der Kommunikationstechnik. Hagen: Land Nordrhein-Westfalen, Ministerium für Schule, Wissenschaft und Forschung, IfV NRW, 2000, Lerneinheit Informations-und Kommunikationstechniken, vgl. Seite 15.

- 6 - PhysikalischeSchicht Diese Schicht beschreibt die mechanischen, funktionellen und elektrischen Eigenschaften. Sie koppelt das Systems mit der physikalischen Verbindungs-leitung. Sie sorgt für die Bitübertragung zwischen zwei Systemen. Wesentliche Aufgabe ist auch der Auf- und Abbau von ungesicherten Systemverbindungen.

Sicherungsschicht Aufgabe dieser Schicht ist es den ungesicherten Bitstrom aus der Bitübertragungsschicht in eine gesicherte Datenreihe zu verwandeln. Die ankommenden Daten in Datenblöcke sog. frames umwandeln und sequentiell übertragen. Den Nutzdaten werden Verwaltungsdaten wie Sender- und Empfängeradresse hinzugefügt. Die Sicherungsfunktion bezieht sich ausschließlich auf Bitübertragungsfehler. Weitere Leistungen sind Wahl des Netzzugriffverfahrens und Vermeidung von Überlastungen.

Vermittlungsschicht Aufbau einer Verbindung zwischen sendenden und empfangenden System. Sowie die Wegewahl, und der Wiederaufbau der Verbindung nach einer Störung.

Transportschicht In dieser Schicht wird die logische Verbindung zwischen Sender und Empfänger gesteuert und überwacht. Überwachung, ob die Pakete auch beim Empfänger ankommen.

Kommunikationssteuerungsschicht In der Kommunikationssteuerungsschicht werden die notwendigen Mittel bereitgestellt, um die Kommunikation zu organisieren, zu synchronisieren und den Datenaustausch zu regeln. Die Kommunikationssteuerungsschicht erstellt eine sitzungsbezogene Verbindung (session connection) zwischen den Teilnehmern. Bei mehreren gleichzeitigen Anfragen übernimmt sie das Multiplexing und steuert so die Zuordnung der einzelnen Verbindungen.

Darstellungsschicht Absprache der Kommunikationsteilnehmer über die Darstellung der auszutauschenden Daten. Festlegung der Transfersyntax einschließlich der Zeichen-codewandlung in den Zeichencode des Netzwerks, oder auch Datenkomprimierung und Verschlüsselung.

Anwendungsschicht Identifizierung des Kommunikationspartners, Synchronisierung der Anwenderanfragen aus den Anwendungsprozessen.

- 7 - 2.1.3 TCP/IP

Nach dem in Abb. 2.1 auf Seite 5 aufgeführten ISO/OSI Referenzmodell wenden wir uns nun dem TCP/IP-Stapel in Abb. 2.2 zu. Dieser differenziert nicht nach sieben sondern je nach Darstellung in der Literatur zwischen vier oder fünf Schichten ⁶ .

Datenübertragungsschicht . . . ist verantwortlich für die Übertragung des Paketes über die physikalischen Medien, also für die Übertragung zwischen zwei Geräten, zwischen denen eine physikalische Verbindung besteht z. B. Ethernet, Token Ring. 7

Netzwerkschicht . . . leistet verbindungslose Dienste. Die Netzwerkschicht ist dafür ver-antwortlich, Pakete zu routen 8 . Sie befördert die Pakete zu dem bestimmten Ziel und sorgt für die entsprechende Wegewahl. Die Entscheidungen zur Wegewahl müssen nicht von der Datenquelle alleine getroffen werden. Aktive Netzwerkkomponenten wie z. B. Router unterstützen die Datenquelle auf ihrem Weg zur Datensenke. Die Netzwerkschicht muss über eine Adressierung zur eindeutigen Identifizierung der Netzteilnehmer verfügen. Diese Adressierungsmechanismen sind abhängig vom gewählten Netzwerktyp, im Falle eines TCP/IP basierenden Netzwerk muss die Adressierung wie in Kap. 2.1.3.8 auf Seite 14 erläutert, aufgebaut sein.

Transportschicht . . . in der TCP/IP-Protokollsuite verfügt über verschiedene Grund-formen der Datenübertragung. Es sind verbindungsorientierte, verbindungslose oder zu-

⁶ NaganadDoraswamy und Dan Harkins IPSEC, Der neue Sicherheitsstandard für das Internet, Intranets und virtuelle private Netze. 1. Auflage. München: Addison-Wesley Verlag, 2000, vgl. Abb 2.1 auf Seite

36.

⁷ Doraswamy und Harkins, a. a. O., vgl. Seite 38.

⁸ Doraswamy und Harkins, a. a. O., vgl. Seite 38

- 8 - verlässigeund unzuverlässige Datenübertragungen möglich. Diese Eigenschaften der Transportschicht, können von der Anwendungsschicht in Kombination angefordert wer-den. Näheres zu den einzelnen Protokollarten über das Transmission Control Pro-tocol (TCP) in Kap. 2.1.3.4 auf Seite 11 bzw. User Datagram Protocol (UDP) in Kap. 2.1.3.5 auf Seite 12 und über Internet Control Message Protocol (ICMP) in Kap. 2.1.3.6 auf Seite 12. Jedoch machen einige Kombinationen keinen Sinn, wie z. B. die Kombination verbindungslos und zuverlässig ⁹ .

Anwendungsschicht . . . hat die Aufgabe für die Anwendungen auf einem System die Daten über das Netzwerk zu versenden. Die Anwendungsschicht hat auch die Aufgabe, die Schnittstelle zur Transportschicht zu definieren. Diese Schnittstelle ist Betriebssystem abhängig. Die bekannteste ist das Socket-Interface auf UNIX Betriebsystemen 10 .Im Vergleich sieht die Aufteilung nach dem ISO/OSI Referenzmodell detaillierter aus als bei der Darstellung des TCP/IP-Protokollstapels. Dies hat in der Praxis aber keine Konsequenz, da die Funktionalitäten der entfallenen Schichten in den dargestellten Schichten mit aufgenommen wurden.

2.1.3.1 TCP/IP-Protokollsuite

Wie im Kap. 2.1.3 auf der vorherigen Seite aufgeführt, bietet die Protokollsuite einige Basis-Funktionalitäten, die für eine Netzwerkdatenübertragung benötigt werden. Diese sollen im folgenden näher erläutert werden.

2.1.3.2 Internet Protocol (IP)

Das Internet Protocol (IP)-Protokoll bildet die Basis der Datenübertragung in der TCP/IP- Protokollsuiteund ist definiert in Request for Comments (RFC) 791 ¹¹ . Es bietet einen verbindungslosen Datenübertragungsdienst in der Netzwerkschicht. Der Einfachheit halber wollen wir hier nur die Internet Protocol Version 4 (IPv4) betrachten, da die zusätzliche Betrachtung der Internet Protocol Version 6 (IPv6) den Umfang der Arbeit verdoppeln würde. Da aber zu diesem Zeitpunkt der Einsatz von IPv6 noch eher selten ist, sollte diese Einschränkung den Nutzen für den Leser nicht schmälern. Der Aufbau des IP-Datenpaket ist in Abb. 2.3 auf der nächsten Seite zu sehen. Da bei der Übertragung von Daten in den IP-Datagrammen Bitfolgen in Bytes und Wortgrößen vorkommen, musste eine Festlegung über die Reihenfolge der Bytes getroffen werden. Die Darstellung in TCP/IP wurde

⁹ Doraswamy und Harkins, a. a. O., vgl. Seite 38

¹⁰ Doraswamy und Harkins, a. a. O., vgl. Seite 37.

¹¹ Jon Postel RFC 791: Internet Protocol. ftp://ftp.isi.edu/in-notes/rfc791.txt - besucht am 20.02.2003.

festgelegt als big-endian. Für die weitere Betrachtung sollen die Felder im IP-Header ¹² kurz erläutert werden, genaue Details können dem RFC 791 ¹³ entnommen werden. Das Feld Version ist bei IPv4 immer mit einer vier vorbelegt. Die Länge enthält bei einem IP-Datagramm die Headerlänge, ohne IP-Optionsfeld ist dies der Wert fünf (5 mal 4 Byte-Worte ergibt eine Länge von 20 Byte ). Die Gesamtlänge enthält die Gesamtlänge des IP-Paketes in Bytes. Identifikation: Mit diesem Feld wird bei der Fragmentierung eines IP-Datagramms die Zuordnung der Datenpakte zum IP-Datagramm hergestellt. Die sog. Flags sind wichtig für die Fragmentierung, durch Setzen des ersten Bit wird signalisiert, dass nicht fragmentiert werden darf. Das zweite Bit dient der Erkennung des letzten fragmentierten Paket. Das dritte Bit ist unbenutzt. Wird ein Paket zerstückelt (fragmentiert), dient der Fragmentierungs-Offset dazu die Stückelungsstelle bekannt zugeben. Der Verfallszähler TTL Time to live wird vom Sender auf einen Wert gesetzt, anschließend wird er von jedem Router auf dem Weg zum Ziel um einen verringert. Erreicht das Feld TTL den Wert Null, wird das Paket verworfen. Das Protokoll-Feld dient zur Kennzeichnung der einzelnen Protokolle aus der TCP/IP-Protokollsuite, und bestimmt damit was für ein Header dem IP-Header folgt. In der Header-Prüfsumme ist die berechnete Prüfsumme des Headers enthalten. Zur Identifikation des sendenden Host wird hier die Quell IP-Adresse transportiert. Damit das Datenpaket sein Ziel erreicht, muss die Ziel IP-Adresse selbstverständlich auch vorhanden sein. Das Feld IP-Optionen hat für diese Betrachtung keine Relevanz und kommt in der Praxis auch selten vor.

¹² Header = gemeint sind hier Kopfinformation eines Datenpaketes

¹³ Postel, a. a. O.

- 10 - 2.1.3.3Fragmentierung

Der Versand von Daten über ein Netzwerk erfolgt nicht als kontinuierlicher Datenstrom, sondern in Datenpaketen einer bestimmten Größe. Diese Größe wird bestimmt durch die physikalische Netzwerkschicht. So hat z. B. Ethernet eine maximale Größe eines Datenpaket von 1526 Bytes. Dies schließt die in der Netzwerkschicht zusätzlich notwendige Adressen-Information mit ein. Daraus folgt, das einem IP-Paket maximal 1480 Bytes für Nutzdaten zur Verfügung stehen. Denn der IP-Kopf hat eine Größe von 20 Bytes und die notwendigen Ethernet-Informationen benötigen weitere 26 Bytes. In einem anderen physikalischen Netzwerk z. B. Token-Ring ist die maximale Größe eines Pakets 4096 Bytes. Sollen nun Pakete von einen Token-Ring in ein Ethernet übertragen werden, muss das Gerät ¹⁴ die Daten vor dem Versand ins Ethernet in Stücke zerlegen. Dies nennt man Fragmentierung. Das empfangende Gerät muss diese Datenpakte anschließend wieder zu einem Paket zusammensetzen und zwar bevor es an die Netzwerkschicht weitergegeben werden kann. Dabei können die Daten zusätzlich noch in der falschen Reihenfolge eintreffen, da das IP-Protokoll eine verbindungslose (stateless) Übertragung ist.

Maximum Transmission Unit (MTU) Um die Bandbreite der vorhandenen Netzwerke optimal nutzen zu können, hat in einem System jedes Netzwerkinterface eine Eigenschaft, die eine Fragmentierung verhindern soll, diese Eigenschaft nennt sich Maximum Transmission Unit (MTU). Sie wird bei der Erzeugung der Datenpakete zur Vermeidung der Fragmentierung herangezogen.

Path Maximum Transmission Unit (PMTU) Auf dem Weg von einem aussendenden Rechner zu einem empfangenden Rechner können die Pakete unterschiedliche Netzwerke passieren, diese Netzwerke können alle verschiedener Art sein, und unterschiedlich grosse Datenpakete voraussetzen. Dann würde es auf dem Weg zum Ziel trotzdem zu einer Fragmentierung kommen. Deshalb gibt es eine Möglichkeit die sog. Path Maximum Transmission Unit (PMTU) festzustellen, dies geschieht mit der Unterstützung des Internet Control Message Protocol (ICMP)-Protokolls (siehe Kap. 2.1.3.6 auf Seite 12). Die so für den Weg festgestellte Größe muss nun vom Protokollstapel (hier dem IP-Protokoll, Netzwerkschicht) dafür sorgen, dass das ausgesendete Paket diese Größe (incl. aller notwendigen Netzwerkinformationen) nicht überschreitet, so können die Datenpakete optimal bis ans Ziel gebracht werden. Leider wird oft durch falsch eingestellte Firewalls 15

¹⁴ Die Kopplung zweier unterschiedlicher Netzwerke wird im allgemeinen über einen Router erfolgen, dieser übernimmt dabei die Arbeit der Fragmentierung.

¹⁵ Firewalls = engl. Brandmauern. Sind Sicherheitssysteme die den Zugriff auf Netzwerke durch Regelwer- ke einschränken.

- 11 - dieErmittlung der PMTU verhindert. Dies führt manchmal sogar dazu das zwischen den Geräten dann keine Kommunikation stattfinden kann. Bezogen auf IPSec und die Behand-lung der PMTU ist RFC 2401 ¹⁶ zu lesen.

2.1.3.4 Transmission Control Protocol (TCP)

Ebenso wichtig in der TCP/IP-Protokollsuite ist das Transmission Control Protocol, es stellt verbindungsorientierte und gesicherte Verbindungen zur Verfügung. Definiert ist das Transmission Control Protocol (TCP)-Protokoll im RFC 793 ¹⁷ . TCP-Pakete werden im IP-Header im Protokoll-Feld mit dem Wert ≫ 6 ≪ gekennzeichnet. Die Verbindung ist fullduplexfähig, transparent (aus Sicht des Benutzer sieht die Verbindung wie ein Datenstrom aus), Sicherung der Daten mit Sequenznummern, Prüfsumme und Quittungen. Durch 16 Bit Breite sog. Portnummern, kann ein Rechner bis zu 65.535 verschiedene Verbindungen aufbauen ¹⁸ . Die Verbindung wird mit einem sog. three-way-Handshake aufgebaut. Der Verbindungsaufbau und die verschiedenen Stati einer Verbindung des TCP-Protokolls sind für den interessierten Leser im RFC793 ¹⁹ , oder anderer Literatur nachzulesen, für das weitere Verständnis, jedoch nicht ganz so wichtig. Deshalb wurde auf eine detaillierte Darstellung verzichtet.

¹⁶ Randall Atkinson RFC 2401: Security Architecture for the Internet Protocol. ftp://ftp.isi.edu/in-notes/ rfc2401.txt - besucht am 20.02.2003, Kap. 6.1.2 Path MTU Discovery.

¹⁷ Jon Postel RFC 793: Transmission Control Protocol. ftp://ftp.isi.edu/in-notes/rfc793.txt - besucht am 20.02.2003.

¹⁸ Diese Verbindungen (Sessions) werden unterschieden durch die ausgehandelten Portnummern.

¹⁹ Postel, a. a. O.

- 12 - 2.1.3.5 UserDatagram Protocol (UDP)

Verbindungslose und ungesicherte Verbindungen werden mittels des User Datagram Protocol (UDP)-Protokolls zur Verfügung gestellt. Der UDP-Protokollkopf besteht nur aus der Sender- und Empfänger Portnummer, der Datagrammlänge und einer Prüfsumme. Dies macht das UDP-Protokoll zu einem Leichtgewicht, das ohne großen Protokoll-Overhead auskommt. Das UDP-Protokoll verzichtet bewusst auf eine Sicherungsschicht, um im LAN hohe Transferraten zu erreichen. Da die Paketverluste sich in LAN’s gewöhnlich in Grenzen halten, ist dies auch weiter kein Problem. Einige Multimediadatendienste wie z. B. Realaudio benutzen das UDP-Protokoll. Die Sender- und Empfänger-Portnummern haben eine Länge von 16 Bit. Im IP-Header wird im Protokoll-Feld für UDP eine ≫ 17 ≪ eingetragen. Spezifiziert wird das UDP-Protokoll im RFC 768 ²⁰ . Der Aufbau des UDP Protokollkopfs ist in Abb. 2.5 zusehen.

2.1.3.6 Internet Control Message Protocol (ICMP)

Das ICMP-Protokoll wird von allen aktiven Netzwerkkomponenten benutzt, um Funktionen in TCP/IP-Netzwerk zu steuern, Fehler zu melden und zu beheben. Dies wird dadurch erreicht, dass Geräte ICMP-Nachrichten aussenden, wie z. B. “Host not reachable“, das von einen Router ausgesendet wird, falls er das adressierte Ziel nicht erreichen kann. Aber auch einfachere Aufgaben werden mit diesem Protokoll realisiert, wie z. B. eine Überprüfung der Erreichbarkeit, die mit dem Befehl “Ping“ ²¹ durchgeführt werden kann. Dabei werden ICMP-Echo request Nachrichten ausgesandt. Das Zielsystem antwortet mit einer ICMP-Echo replay Nachricht. Das ICMP-Protokoll gehört zu den wichtigsten Grundfunktionen der TCP/IP-Protokollsuite. Der Aufbau eines ICMP-Protokollkopfs

²⁰ Jon Postel RFC 768: User Datagram Protocol. ftp://ftp.isi.edu/in-notes/rfc768.txt - besucht am 20.02.2003.

²¹ Michael-John Muuss The Story of the PING Program. http://ftp.arl.army.mil/ ^∼ mike/ping.html - be- sucht am 22.01.2003.

- 13 - istder Abb. 2.6 zu entnehmen. Es ist im RFC 792 ²² definiert und im IP-Header ist ein ICMP-Paket durch eine ≫ 1 ≪ im Protokoll-Feld zu erkennen. Das Feld Type dient der

Benachrichtigung der Geräte, die im RFC 1700 ²³ spezifiziert sind. Eine weiter Spezifizierung der Nachricht kann mit dem Feld Kode erfolgen, das ebenfalls im RFC 1700 ²⁴ erläutert wird.

2.1.3.7 Übersicht

Um nun einen Überblick zu bekommen, auf welchen der Schichten die einzelnen Protokolle angeordnet sind, ist die Zuordnung der Protokolle zu den einzelnen Schichten des Protokollstapels in Abb. 2.7 dargestellt. Die Darstellung in Abb. 2.7 ist bzgl. des

²² Jon Postel RFC 792: Internet Control Message Protocol. ftp://ftp.isi.edu/in-notes/rfc792.txt - besucht am 20.02.2003.

²³ Jon Postel und Joyce K. Reynolds RFC 1700: Assigned Numbers. ftp://ftp.isi.edu/in-notes/rfc1700. txt - besucht am 20.02.2003, In RFC 3232 wurde die Auflistung des RFC 1700 durch eine Online

Datenbank ersetzt. Die Auflistung der ICMP-Types und Kode’s ist soweit vollständig..

²⁴ Postel und Reynolds, a. a. O.