Algorithmische Grundlagen des Internets

Algorithmische Grundlagen des Internets
Vorlesungsskript
Sommersemester 2003
Christian Schindelhauer
Heinz Nixdorf Institut
Fakultät EIM, Institut für Informatik
Universität Paderborn
Sommersemester 2003
Kapitel 1
Organisation
Web-site
Zu dieser Veranstaltung ist eine Webseite unter der Adresse:
http://www.upb.de/cs/ag-madh/vorl/AlGInt03/
eingerichtet worden. Hier findet man aktuelle Informationen sowie das Skript, Vorlesungsfolien und Übungsblätter.
Termine
Die Vorlesung findet montags, 14:15–15:45 Uhr in Raum F0.530 statt. Es werden zwei Übungsgruppen
angeboten. Die erste ist montags, 16:00 – 16:45 Uhr, Raum F0.530, die zweite montags, 17:00 – 16:45 Uhr,
ebenfalls F0.530. Die Zuordnung der Übungsteilnehmer ist in der ersten Vorlesung erfolgt. Eine detaillierte
Aufstellung der geplanten Veranstaltungen findet man auf den Webseiten.
Übungen
Es werden zwei Sorten von Übungsaufgaben angeboten.
1. Die Wochenübungszettel werden eine Woche vor demÜbungstermin hier veröffentlicht und können
am Freitag vor dem Übungstermin bei mir in Raum F1.203 abgegeben werden (oder auch per EMail
an mich verschickt werden).
Die Bearbeitung ist freiwillig, aber prüfungsrelevant. Werden diese Aufgaben bearbeitet, so werden
sie zum Übungstermin besprochen.
2. Wenn kein Bedarf besteht die Wochenübungszettel zu besprechen (z.B. zum ersten Übungstermin,
wegen allgemein guter Bearbeitung oder auch mangels irgendwelcher studentischer Beiträge), werden Präsenzübungszettel während derÜbung verteilt. Diese werden dann im Rahmen der Übung
in Gruppenarbeit Übungszettel werden zwei Wochen vor dem Übungstermin hier veröffentlicht und
können am Donnerstag vor demÜbungstermin in Raum F1.203 abgegeben werden. Die Bearbeitung
ist freiwillig.
Daneben ist die Übung ein Forum, um detaillierte Fragen zur Vorlesung zu stellen und zu diskutieren.
Inhalt der Veranstaltung
Im Rahmen dieser Veranstaltung werden Algorithmen und Probleme vorgestellt, die typisch für das Internet sind. Die Struktur des Internets ist historisch gewachsen. Angefangen mit einer handvoll vernetzter
1
1. Vorlesung
28.04.2003
KAPITEL 1. ORGANISATION
2
Rechner sind mittlerweile Hundertausende von Servern, Millionen von Rechnern und Milliarden von Webseiten vorhanden. Das Internet vernetzt heterogene lokale Netzwerke (LAN), deren Nutzer unterschiedliche
Motivation und Absichten haben.
Dieses Wachstum und die sich ständig verändernde Nutzung des Internets hat immer wieder zu Krisen
geführt, die von den Gestaltern des Internets nicht vorherzusehen waren. Dadurch ergaben sich interessante
algorithmische Problemstellungen und entsprechend originelle Lösungen.
Ziel dieser Veranstaltung ist es die theoretischen Hintergründe hinter diesen Problemstellungen und
algorithmischen Lösungen vorzustellen und zu diskutieren.
Nach einer knapp gehaltenen Übersicht über Struktur und Aufbau des Internets werden unter anderem
folgende Themenstellungen behandelt:
1. Kurzübersicht TCP/IP
2. IP: Der Kampf gegen DoS-Angriffe (denial of service)
3. TCP: Verteilte faire und effiziente Durchsatzoptimierung
4. Der Webgraph: Struktur und Aufbau
Struktur und Aufbau
Suchalgorithmen für das Internet
5. P2P (Peer to Peer-Netzwerke): Effizientes File-sharing
6. Web-Caching: Surfen ohne Engpässe
Diese Vorlesung konzentriert sich auf Algorithmen und mathematische Modelle. Wir werden nicht
im einzelnen die technischen Besonderheiten und Implementationsdetails der Internetprotokolle vorstellen
(allein schon aus zeitlichen Gründen). Vielmehr werden die Grundproblemstellungen mit Internetbezug
herausgearbeitet und algorithmische Modelle und Lösungen diskutiert. Wir interessieren uns für die eingesetzten und konzipierten Algorithmen und die prinzipielle Lösbarkeit von Problemstellungen, also unteren
Schranken. Hierfür werden wir neben graphtheoretischen Methoden, effizienten Datenstrukturen auch eine
Reihe wahrscheinlichkeitstheoretischer Analysen durchführen.
Voraussetzungen
Vorausgesetzt wird ein abgeschlossenes Vordiplom im Studiengang Informatik. Kenntnisse aus der Veranstaltung Kommunikation in Parallelen Rechenmodellen sind in dieser Veranstaltung sehr hilfreich, werden
aber nicht vorausgesetzt.
Prüfung
Diese Veranstaltung ist eingeordnet in den Bereich Modelle und Algorithmen (MUA). Wer nach der DPO
4 oder der neuen Lehramtsstudienordnung studiert, kann im Anschluss an dieser Veranstaltung eine benotete, mündliche, ca. 30-minütige Prüfung bei Christian Schindelhauer ablegen. Termine für diese Prüfung
können mit ihm vereinbart werden.
An dieser Stelle erscheint eine Liste von möglichen Prüfungsfragen. Daneben können auchÜbungsaufgaben in der Prüfung gestellt werden.
Literatur
An dieser Stelle werden Hinweise auf empfehlenswerte Bücher und gute Übersichtsartikel und ihre Einordnung in die Vorlesung aufgeführt.
3
W. Richard Stevens, TCP/IP Illustrated, Volume I, Addison-Wesley, 1996 [Ste95].
In diesem Buch findet man eine Einführung undÜbersicht in die beiden wichtigsten Protokolle des
Internets, TCP und IP. Wenn wir in Rahmen dieser Veranstaltung die reale Umsetzung der Protokolle
beschreiben, werden wir uns auf dieses Buch beziehen. Die theoretischen und analytischen Überlegungen, die der Kern dieser Veranstaltung sind, werden dort aber höchstens am Rande erwähnt.
Computer Networks, Tanenbaum, Prentice-Hall, 1996, [Tan96].
Tanenbaums Rundumschlag zum Thema Rechnernetzwerke liegt mittlerweile in der vierten Auflage
vor. Er gibt eine kompakte (und humorvolle) Einführung in das Gebiet. Wir werden uns auf dieses
Buch beziehen, um die Besonderheiten des Internets im Vergleich zu alternativen Entwurfsmethoden
aufzuzeigen.
Practical Network Support for IP Traceback, Savage, Wetherall, Karlin and Anderson, ACM SIGCOMM, 2000 [SWKA00].
Im dritten Kapitel stellen wir das Verfahren von Savage et al. zur Routenrückverfolgung von Paketen
vor. Der Originalartikel ist sehr gut lesbar und gibt einen fundierten Einblick in weitere Details des
vorgeschlagenen Markierungsverfahrens als auch in alternative Lösungen.
Prüfungsfragen
Neben den folgenden inhaltlichen Fragen, können auch Übungsaufgabe als Prüfungsfragen auftauchen.
Natürlich wird sich kein Prüfung stringent an solch einen Fragenkatalog halten. Gleichwohl soll dieser
Katalog dem Prüfling bei der Vorbereitung der Prüfung behilflich sein, indem er das Augenmerk auf die
wesentlichen Sachverhalte lenken soll1 .
1. Vorlesung — TCP/IP, Kurzübersicht
(a) Was ist das Internet?
(b) Nennen und beschreiben Sie die vier Schichten des Internets.
(c) Beschreiben Sie die Eigenschaften der Anwendungsschicht.
(d) Vergleichen Sie TCP und UDP.
(e) Was leistet TCP im Detail?
(f) Was ist IP?
(g) Wie funktioniert prinzipiell das Routing im Internet?
(h) Zeigen Sie anhand einer Kommunikationsverbindung das Zusammenspiel der Protokolle auf.
(i) Beschreiben Sie Verbindungsaufbau und Verbindungsende von TCP.
(j) Was leistet der Algorithmus von Nagle.
2. Vorlesung — Das Internet Protokoll und DoS-Angriffe (I)
(a) Vergleichen Sie IP und VC (Virtual Circuits)
(b) Was ist ein Denial-of-Service-Angriff?
(c) Warum ist IP besonders anfällig gegenüber DoS-Angriffen?
(d) Warum ist die Quellensuche für die Abwehr von DoS-Angriffen so wichtig und im Internet so
schwierig?
(e) Welche Strategien zur Quellbestimmung von IP-Paketen oder zur Abwehr von DoS-Angriffen
kennen Sie?
(f) Charakterisieren Sie verschiedene Methoden gegen DoS-Angriffe hinsichtlich Verwaltungsaufwand, Netzwerklast, Routeraufwand und Post-Mortem-fähigkeit.
1 Ein
Antwortkatalog wird nicht herausgegeben
KAPITEL 1. ORGANISATION
4
(g) Wie funktioniert ICMP-Traceback?
(h) Wie viele Pakete sind notwendig um mit ICMP-Traceback eine Route zurückzuverfolgen?
3. Vorlesung — Das Internet Protokoll und DoS-Angriffe (II)
(a) Vergleichen Sie die Qualtität der Chernoff-Schranke mit der Markov- und TschebyscheffUngleichung anhand eines Beispiels.
(b) Beweisen Sie, dass mit Wahrscheinlichkeit
DoS-Pakete genügen.
im ICMP Traceback Verfahren
(c) Welche Annahmen liegen den Markierungsstrategien gegen DoS-Angriffen zu Grunde?
(d) Warum kann der exakte DoS-Angriffspfad mit Markierungsstrategien nicht bestimmt werden?
(e) Was sind die Vor- und Nachteile von Node Append?
(f) Was ist Node Sampling?
4. Vorlesung — Das Internet Protokoll und DoS-Angriffe (III)
(a) Wie kann man die Konvergenzzeit von Node Sampling abschätzen?
(b) Wie funktioniert Edge Sampling?
(c) Wie kann die Konvergenzzeit von Edge Sampling abschätzen?
(d) Vergleichen Sie Node und Edge-Sampling?
Kapitel 2
Das Internet-Protokoll IP
2.1 Eine Kurz ¨ubersicht von TCP/IP
Wir werden hier (vorerst) nur einen kurzen Überblick über das Zusammenspiel der verschiedenen Protokolle geben. Eine gute Beschreibung der TCP/IP-Protokolle im einzelnen findet man in [Ste95].
Die Protokolle von TCP/IP erlauben Computer unterschiedlicher Leistungsfähigkeit, aller Hersteller
und verschiedener Betriebssysteme miteinander zu kommunizieren. Der jetzige Aufbau dieser Protokolle
ist weitestgehend das gewachsene Ergebnis eines historischen Prozess, der durch den enormen Zuwachs
an Rechenkapazitäten, Datendurchsatz und Anzahl verbundener Rechner geprägt wurde. Ein historischer
Überblick ist in [Lyn93] dargestellt.
In Tabelle 2.1 und Abbildung 2.1 sind die einzelnen Schichten von TCP/IP in der Übersicht dargestellt.
2.1.1 Anwendungsschicht (application layer)
Durch Anwendungen, wie z.B. EMail, WWW (HTTP), Telnet oder FTP (File Transfer Protocol), werden
Datenströme zwischen zwei Rechnern erzeugt.
Verbindungen sind immer bidirektional. Oft handelt es sich um Client-Server-Strukturen.
Die Datenmenge kann beträchtlich variieren. Im Falle von FTP kann zum Beispiel von Host A nach
B nur wenige Bytes in der einen Richtung und dagegen 100 MBytes in der Gegenrichtung transferiert
werden. Die gegenläufigen Datenströme sind insbesondere nicht unabhängig.
Datenströme müssen absolut fehlerfrei übermittelt werden.
Verbindungspausen dürfen nicht zum Abbruch führen.
Die eigentliche Kommunikation wird delegiert auf die Transportschicht.
2.1.2 Transportschicht (transport layer)
Hier existieren zwei äußerst unterschiedliche Protokolle:
Anwendung
Transport
Netzwerk
Link
z.B. Telnet, FTP, HTTP, Email, . . .
TCP,UDP
IP +ICMP,+IGMP
Gerätetreiber (z.B. Ethernet, token ring
driver)
Tabelle 2.1: Die Schichten von TCP/IP
5
KAPITEL 2. DAS INTERNET-PROTOKOLL IP
6
Abbildung 2.1: Verschiedene Protokolle in den Schichten von TCP/IP (aus [Ste95])
TCP (Transmission Control Protocol)
TCP erzeugt einen zuverlässigen Datenfluss zwischen zwei Rechnern. Die ursprüngliche Spezifikation von TCP steht in RFC 793 [Pos81b]1 .
Hierfür werden die Datenströme aus der Anwendungsschicht in Pakete angemessener Länge unterteilt. Diese Pakete, als auch Bestätigungsnachrichten (acknowledgments) für erhaltene Pakete,
werden dann mittels der Netzwerkschicht versandt.
UDP (User Datagram Protocol)
UDP ist eine einfacher Dienst, der Päckchen von einem Rechner zu einem anderen Rechner ohne
Erfolgsgarantie verschickt. Im Gegensatz zu TCP muss die Anwendungsschicht die Päckchengröße
vorgeben. Aus diesem Päckchen wird ein Datagramm (Analogbildung zu Telegramm) gebildet und
durch die Netzwerkschicht verschickt.
Man beachte: Die Transportschicht ist am Routing nicht beteiligt! Dieses wird durch die Netzwerkschicht erledigt. Sowohl Anwendungsschicht als auch Transportschicht sind end-to-end-Protokolle.
2.1.3 Netzwerkschicht (Network layer)
Die Netzwerkschicht von TCP/IP ist IP (Internet Protocol) mit den angegliederten Hilfsprotokollen ICMP
(Internet Control Management Protocol) und IGMP (Internet Group Management Protocol). Die offizielle
Spezifikation von IP findet sich in RFC 791 [Pos81a].
1 Alle offiziellen Standards des Internets sind veröffentlicht als Request for Comment (RFC). Jede wird durch eine Nummer identifiziert (hier RFC793), welche die Chronologie dieser Dokumente wiedergibt. Ein Index und (fast) alle RFCs erh¨alt man auf der
Webseite www.ietf.org der Internet Engineering Task Force (IETF).
2.1. EINE KURZÜBERSICHT VON TCP/IP
7
IP IST EIN UNZUVERL ÄSSIGES VERBINDUNGSLOSER DATAGRAMMAUSLIEFERUNGSDIENST.
Diese Aussage ist essentiell zum Verständnis der Schwierigkeiten, die TCP bei der Lösung seiner Aufgaben zu bewältigen hat:
IP ist ein Datagrammauslieferungsdienst
Ein Datagramm besteht im wesentlichen nur aus dem Datenpaket, Sender- und Empfängeradresse.
Die Aufgabe von IP ist, dieses Datagramm unverändert vom Sender zum Empfänger zu befördern.
Ist keine direkte Verbindung zwischen Sender und Zielrechner vorhanden, werden als Zwischenstationen Rechner benutzt. Diese Rechner werden Router genannt.
IP ist unzuverl¨
assig
Die Fehlerbehandlung von IP ist: Tritt ein Problem bei der Auslieferung auf, löscht es das Datagramm und versucht eine ICMP-Nachricht (Internet Control Management Protocol) zum Sender zu
schicken. Tritt ein Problem mit der Auslieferung einer ICMP-Nachricht auf, löscht es diese auch
(erzeugt hierbei insbesondere keine neue ICMP-Nachricht).
Es werden insbesondere keine Kopien von Datagrammen erzeugt. Das heißt unter anderem, stürzt
ein Router ab, so verschwinden mit ihm alle Datagramme.
IP ist verbindungslos
Die Weitergabe der Datagramme geschieht ausschließlich durch Weitergabe von Router zu Router,
als hop-to-hop-Protokoll. Jedes Datagramm wird unabhängig behandelt. Deswegen können Datagramme in veränderter zeitlicher Reihenfolge am Zielrechner eintreffen.
Auch die Datagramme tragen keinerlei Routing-Information. Die einzigen routing-verwandte Informationen neben Absender und Zieladressen in einem Datagramm sind
– das TOS-Feld (type of service)
Hier wird binär kodiert, welche der vier Kriterien Zeit (delay), Datendurchsatz (throughput),
Zuverlässigkeit (reliability) und finanzielle Kosten (monetary cost) optimiert werden sollten.
– das TTL-Feld (time to live)
Dieses 8-bit Feld enthält eine Zahl, die vom Sender initialisiert wird (typischerweise 32 oder
64) und von jedem Router um eins verringert wird. Ist diese Zahl 0 wird das Paket weggeworfen
und eine ICMP-Nachricht an den Sender erzeugt.
Der Weg eines Datagramms ergibt sich aus einer Folge von lokalen Entscheidungen der Router.
IP-Adressen und Host-Namen
Jedes Interface in einem Rechnernetzwerk muss eine eindeutige Internet-Adresse (IP-Adresse) besitzen.
Diese 32-Bit-Adressen, byteweise beispielsweise notiert als 65.114.4.69, gliedern sich in eine RechnerID (Host ID) und eine Netzwerk-Adresse (netid)2 . Netzwerkadressen werden vom Internet Network Information Center vergeben, Host IDs von der jeweiligen Netzwerkadministration.
Der IP-Header
Der mindestens 20-Byte-Header eines IP-Pakets besteht unter anderen aus den folgenden Teilen.
1. Version
Hier steht die Versionsnummer von IP. Momentan findet ein Übergang von IPv4 zu IPv6 statt, um
eine Reihe von historisch bedingten Einschränkungen zu lösen. IPv4 und IPv6 werden aber sehr
lange noch parallel existieren. Wir beziehen uns hier auf IPv4. D.h. wir schreiben in dieses Feld eine
4.
2 und
einer Klassenbeschreibung A, B oder C, die festlegen welche Adressl¨angen Net ID und Host ID haben.
KAPITEL 2. DAS INTERNET-PROTOKOLL IP
8
IP Header Format
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service|
Total Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|Flags|
Fragment Offset
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
Protocol
|
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Header Format
Note that one tick mark represents one bit position.
Abbildung 2.2: IP-Header-Definition aus RFC 791 [Pos81a]
2. IHL (IP Header Length)
Dieses Feld bezeichnet die Länge des IP-Headers in 4-Byte-Wörter. Der Mindesteintrag ist 5.
3. TOS (Type of Service)
Von diesem 8-Bit-Feld werden nur vier verwendet, um zu charakterisieren, ob delay, throughput,
reliability, oder monetary cost optimiert werden sollen. Drei Bits sind ungenutzt. Das letzt Bit muss
auf Null gesetzt werden3 . Tatsächlich wird dieses Feld von den meisten Routern ignoriert.
4. Total Length
Hier wird die Größe des IP-Pakets in Bytes angegeben. Damit beschränkt IPv6 die maximale Paketgröße auf 64 kBytes. Tatsächlich werden hier in der Regel höchstens einige kBytes eingetragen (Das
Network File System (NFS) erlaubt nur 8 kByte).
5. Identification
Dieses Feld definiert das Paket (= Datagramm)eindeutig. Normalerweise wird es in jedem Schritt
um eins erhöhtl. Dieses Vorgehen ist aber nicht vorgeschrieben.
6. TTL (time to live)
Dieses Feld bezeichnet die maximale Anzahl von Routern, die dieses Paket passieren darf. Jeder
Router verringert diesen Eintrag. Ist es Null und ist es noch nicht angekommen, wird eine ICMPNachricht an den Sender geschickt und das IP-Paket verworfen.
7. Protocol
Dieses Feld wird zur Verteilung der Pakete im Rahmen des Demultiplexing an TCP, UDP, ICMP, etc.
benutzt. Hier steht an welchen Diest ddas Datagramm übergeben werden soll.
8. Checksum
Diese Prüfsumme bezieht sich nur auf den IP-Header.
9. Source/Destination Address
Hier stehen die IP-Adressen von Quell und Ziel-knoten.
3 Warum
nur?
2.1. EINE KURZÜBERSICHT VON TCP/IP
9
10. Options
Momentan kann hier beispielsweise folgendes eingetragen werden.
Sicherheits und Handhabungseinschränkungen für militärische Zwecke
Routeninformation (record route)
Zeitstempel (z.B. für traceroute)
Zwischenstationen, die dieses Datagramm pasieren darf (loose source routing)
Zwischenstationen, die dieses Datagramm pasieren muss (strict source routing)
Domain Name System
In der Praxis benutzt man selten IP-Adressen direkt. Z.B. statt 131.234.22.29 benutzt man stargate.unipaderborn.de. Im Internet sorgt das Domain Name System (DNS) dafür, dass Rechnernamen wie
mx.icsi.berkeley.edu in IP-Adressen wie 192.150.186.11 umgewandelt werden.
Das DNS ist eine robuste verteilte Datenbank, die diese Umwandlung realisiert (in Unix-Systemen
abrufbar mit dem Befehl host).
Routing im Internet
Vereinfacht dargestellt wird ein Datagramm wird in einem Router wie folgt behandelt:
1. Ist die Ziel-IP gleich der Rechner-IP, wird es an die höhere Protokollschicht (Transportschicht) weitergegeben.
2. Ist ansonsten die (Sub-)netz-ID gleich der Netz-ID des Routers, wird das Datagramm direkt an den
entsprechenden Rechner übergeben.
3. Ansonsten wird der zuständige Router anhand einer lokalen Routingtabelle gemäß der IP-Adresse
oder nur der Netz-ID bestimmt und das Datagramm entsprechend an das in der Routingtabelle angegebene Interface weitergegeben.
4. Findet sich kein passender Eintrag, wird das Paket an einen in der Routingtabelle spezifizierten
Default-Router weitergeleitet.
Für lokale Netzwerke reichen oftmals feste Routingtabellen. In der Regel werden diese aber automatisch erzeugt durch Algorithmen wie z.B. RIP (Routing Information Protocol), OSPF (Open Shortest Path
First). Hierbei ergeben sich eine Reihe interessanter Fragestellungen, die wir leider im Rahmen dieser
Veranstaltung aus Zeitgründen nicht vorstellen können.
2.1.4 Verbindungsschicht (link layer)
Da jedes Interface eines Rechner eine andere IP-Adresse haben muss, muss ein Rechner, der in mehreren
lokale Netzwerken residiert, mehrere IP-Adressen besitzen (multi-homed). Dies betrifft insbesondere Router. In einem lokalen Netzwerk, z.B. Ethernet oder Token-Ring-Netzwerk, übergibt IP den entsprechenden
Kommunikationsprozeduren das Datagramm. Hierbei kann es auch passieren, dass ein Datagramm wiederum in kleinere Pakete zerlegt wird.
Außerdem müssen IP-Adressen in Adressen übersetzt werden, die vom lokalen Netzwerkprotokoll verstanden werden. Diese Aufgabe wird vom Address Resolution Protocol (ARP) und vom Reverse Address
Resolution Protocol (RARP) erledigt [Plu82].
Zusammenspiel der Schichten
In Abbildung 2.4 ist dargestellt, wie jede dieser vier Schichten den Benutzerdaten Zusatzinformation in
Header, oder auch Trailer, hinzufügt.
10
KAPITEL 2. DAS INTERNET-PROTOKOLL IP
Abbildung 2.3: Kapselung der Daten durch die verschiedenen Schichten von TCP/IP (aus [Ste95]).
Abbildung 2.4: Zusammenwirken der Schichten (aus [Ste95]).
2.2. DIE WIRKUNGSWEISE VON TCP
11
2.2 Die Wirkungsweise von TCP
Wie bereits erwähnt wurde TCP (Transmission Control Protocol) in [Pos81b] spezifiziert (Fehlerkorrekturen zu dieser Spezifikation finden sich in späteren RFCs). Die Zielsetzung von TCP wird durch folgenden
Satz beschrieben.
TCP
NALE
IST EIN VERBINDUNGSORIENTIERTER , ZUVERL ÄSSIGER
D IENST
F ÜR BIDIREKTIO -
B YTESTR ÖME .
TCP ist verbindungsorientiert
TCP-Verbindungen werden immer zwischen zwei Parteien hergestellt, d.h. TCP realisert insbesondere weder Broadcast noch Multicast. Bevor Daten übertragen werden, wird die Verbindung aufgebaut.
Während des Verbindungsaufbaus wird sichergestellt, dass die Parteien sich gegenseitig erreichen
können. Außerdem werden elementare Verbindungsparameter ausgetauscht. Solange die Verbindung
nicht ordentlich beendet wird, bleibt sie bestehen.
TCP ist zuverl¨
assig
Für die Bereitstellung einer zuverlässigen Verbinung wirken in TCP die folgenden Mechanismen.
Wie wir bereits erwähnt haben, werden von TCP Anwendungsdaten werden in Teilabschnitte unterteilt, welche Segmente oder auch TCP-Pakete genannt werden.
– Empfängt TCP ein Segment, sendet es dafür ein Bestätigungssegment (acknowledgement) (evtl.
kombiniert mit einem Datensegment). Wird die Bestätigung eines TCP-Pakets nicht empfangen, wird das Paket erneut versendet.
– TCP erstellt für Daten- und Headerbereich des Segments eine Prüfsumme (checksum). Stellt
der Empfänger Unstimmigkeiten zwischen Segment und mitgelieferter Prüfsumme fest, wird
das TCP-Paket ersatzlos und ohne weitere Aktion verworfen.
– TCP-Pakete werden als IP-Datagramme versandt. Da IP nicht immer Pakete in der richtigen
Reihenfolge ausliefert, stellt TCP die richtige Reihenfolge der TCP-Pakete wieder her.
– TCP löscht automatisch Pakete, die doppelt auftauchen. Solche Kopien können durch IP entstehen.
TCP ist ein Dienst f ür bidirektionale Bytestro¨me
Zwischen den beiden TCP-Anwendungen werden Daten auf 8-bit-Basis (Bytes) scheinbar kontinuierlich ausgetauscht. Es gibt keine Übertragungsmarker, die TCP veranlassen, Daten an bestimmten
Stellen zusammenzufassen oder zu trennen. Es findet grundsätzlich keine Interpretation der Anwendungsdaten statt.
Auch das Zeitverhalten wird durch TCP nicht weitergegeben. Sendet die Anwendungsschicht zuerst
10 Bytes und später 70 Bytes, so können auf der Empfangsseite beispielsweise alle 80 Bytes auf
einmal ankommmen oder als vier 20-Byte Stückchen.
TCP ermöglicht einen full-duplex-Dienst für die Anwendungsschicht. Das heißt, die Daten in beiden
Richtungen fließen völlig unabhängig, als ob sie durch zwei völlig unabhängige Verbindungen realisiert werden würden. Wir werden sehen, dass die hin- und rückfließende Pakete tatsächlich gleichzeitig für beide Kommunikationsrichtungen benutzt werden.
2.2.1 TCP-Header
Der (mind.) 20-Byte-Header eines TCP-Pakets (Segments) besteht, wie in Abbildung 2.5 gezeigt, aus folgenden Teilen.
16 Bit Absender-Port-Nummer (source port)
KAPITEL 2. DAS INTERNET-PROTOKOLL IP
12
TCP Header Format
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Port
|
Destination Port
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Acknowledgment Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data |
|U|A|P|R|S|F|
|
| Offset| Reserved |R|C|S|S|Y|I|
Window
|
|
|
|G|K|H|T|N|N|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
Urgent Pointer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
data
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
Note that one tick mark represents one bit position.
Abbildung 2.5: TCP-Header-Definition aus RFC 793 [Pos81b]
Diese Port-Nummern sind notwendig, um über eine IP-Adresse gleichzeitig verschiedene TCPVerbindungen aufrecht zu halten. Entsprechend dieser Portnummmer werden die IP-Datagrammen
den Anwendungen auf einem Rechner zugeordnet.
Die eigentliche Absender-IP-Adresse findet sich im IP-Header. Die Kombination aus Port und IPAdresses wird Socket genannt.
16 Bit Ziel-Port-Nummer (destination port)
Deren Aufgabe entspricht der Absender-Port-Nummer. Ziel- und Quell-Socket bilden zusammen das
Socket-Paar. Dieses Paar beschreibt eindeutig die TCP-Verbindung.
32 Bit Sequenznummer (sequence number)
Anhand dieser Zahl wird die Reihenfolge der TCP-Pakete wiederhergestellt. In jeder Kommunikationsrichtung wird jedes Byte durchnummeriert (mit Umbruch bei auf ) und das erste Byte
des Segments bestimmt die Sequenznummer des gesamten TCP-Pakets.
32 Bit Bestätigungsnummer (acknowledgement number)
Hier wird dem Sender einer Flußrichtung die Nummer des als nächstes erwarteten Datenbytes vom
Empfänger mitgeteilt. In anderen Worten ist es die Sequenznummer des letzten Bytes des zuletzt
erhaltenen Pakets plus eins. Dieses Feld wird erst mit gesetzten Acknowledgment-Flag gültig.
Wird eine Bestätigungsnummer eines TCP-Pakets (d.h. Sequenznummer+Paketlänge) empfangen, so
belegt das auch, dass alle Datenbytes mit kleinerer Sequenznummer ordentlich empfangen worden
sind. Durch diesen Mechanismus ist es insbesondere nicht (unmittelbar) möglich, einzelne Pakete
zu bestätigen, die nach einem fehlenden Paket empfangen worden sind. Erscheint also ein Paket
in einem Strom nicht, so müssten eigentlich alle Pakete die danach noch übermittelt worden sind,
mit dem fehlenden Paket (das durch die Bestätigungsnummer beschrieben wird) erneut verschickt
werden (Der fast retransmit-Algorithmus umgeht dieses Problem).
2.2. DIE WIRKUNGSWEISE VON TCP
13
6 Flag-Bits
Die folgenden 6 Flag-Bits können (weitestgehend4) unabhängig voneinander gesetzt werden.
– URG: urgent pointer
Dieses Flag aktiviert den urgent pointer. Mit diesem Mechanismus wird der Empfänger über
Dringlichkeit von Daten informiert. Dies wird zumeist in Telnet und Rlogin-Verbindungen benutzt5 .
– ACK: acknowledgement number
Dieses Flag aktiviert die Bestätigungsnummer.
– PSH: push
Ein gesetztes Push-Flag zeigt dem Empfänger an, dass die Daten so schnell als möglich an die
Anwendungsschicht weitergeben soll.
– RST: reset
Das Reset-Flag wird gesendet, um anzuzeigen, dass ein empfangenes Segment nicht einer TCPVerbindung korrekt zugeordnet werden kann. Dies geschieht beispielsweise, wenn ein UDPPaket an einem TCP-Port ankommt oder ein Port an einem Rechner nicht verwendet wird.
– SYN: synchronize
Damit werden Sequenznummern beim Verbindungsaufbau synchronisiert.
– FIN: finished
Damit wird angezeigt, dass der Sender einer Flußrichtung aufhört, Daten zu senden. In der
Gegenrichtung kann weiter übertragen werden.
4 Bit Headerlänge
Durch ein Optionsfeld ist die Länge des Headers variabel. Deswegen ist es notwendig, die Headerlänge mitzuteilen.
16 Bit Prüfsumme (checksum)
Diese Prüfsumme bezieht sich auf TCP-Header und TCP-Daten.
16 Bit Fenstergröße (window)
Diese Zahl gibt an, wieviel Bytes mit noch nicht eingegangener Bestätigung maximal in einer Flußrichtung noch versandt werden dürfen. Die variierende Fenstergröße ist die Methode von TCP der
Datenratenanpassung. Es ist klar, dass eine geringe Fenstergröße ein geringe Datenrate verursacht
und eine große Fenster hohen Datendurchsatz erst ermöglichen kann.
16 Bit urgent pointer wird hier nur der Vollständigkeit halber erwähnt und nicht weiter vorgestellt.
Variables Optionsfeld
Die am häufigsten verwendete Option ist die der maximalen Segmentgröße. Hier teilt der Empfänger
dem Sender die gewünschte maximale Segmentlänge (MSS: Maximum Segment Size) bei Verbindungsaufbau mit.
Variables Datenfeld
Hier stehen die Anwendungsdaten. Dieses Feld ist optional und tatsächlich gibt es bei Verbindungsaufbau, Beendigung und gelegentlich bei Bestätigung TCP-Pakete ohne dieses Datenfeld (Die Länge
dieses Datenfelds ergibt sich aus der Gesamtlänge des Segments, das im Header des umgebenden IPDatagramms mitgeteilt wird).
KAPITEL 2. DAS INTERNET-PROTOKOLL IP
14
Client
Server
SYN : Seq.nr.:j
SYN : Seq.nr.:k
ACK: Best.nr. j+1
ACK: Best.nr. k+1
Abbildung 2.6: Schematischer Verbindungsaufbau einer Client-Server TCP-Verbindung
2.2.2 Verbindungsaufbau
Zumeist handelt es sich bei TCP-Verbindungen um eine Client-Server-Beziehung. In diesem Fall wird eine
TCP-Verbindung durch drei Segmente aufgebaut, wie in Abbildung 2.6 gezeigt.
1. Im ersten Segment sendet der Client ein SYN-Segment mit der initialen Sequenznummer (und
natürlich mit dem gewünschten Ziel-Port).
2. Der Server antworte mit einem SYN-Segment mit seiner initialen Sequenznummer und bestätigt mit
diesem Segment durch ACK-Flag und Bestätigungsnummer (Sequenznummer des Client +1) das
erste Segment des Client.
3. Der Client bestätigt das SYN-Segment des Servers durch ein ACK-Segment mit Bestätigungsnummer (= Sequenznummer des Servers +1).
TCP legt hierbei auch mit dem SYN-Segment die maximale Segmentgröße (MSS) fest. Dies geschieht
dadurch, dass jeder Empfänger dem Sender die Segmentgröße, die er empfangen möchte, mitteilt. Problematisch bei diesem einfachen Protokoll ist, dass nicht getestet wird, ob diese Paketgröße auch tatsächlich
übermittelt werden kann (Beispielsweise kann ein Router oder eine dazwischen genutztes Netzwerk hierbei gewissen Einschränkungen unterliegen). Es sei hier erwähnt, dass IP Datagramme deren Länge die
maximale Übertragungseinheit einer Rechner zu Rechnerverbindung (MTU: Maximum Transmission Unit)
überschreiten, zerlegt (fragmentiert) und am Zielrechner wieder zusammensetzt. So ein Vorgang verringert
natürlich den Datendurchsatz und erhöht die Fehleranfälligkeit.
Neben dieser Art des Client-Server-Verbindungsaufbaus erlaubt TCP auch andere Varianten des Verbindungsaufbaus [Ste95].
2.2.3 Verbindungsende
TCP erlaubt einen so genannten half-close, d.h. die gegenläufigen Datenströme können unabhängig voneinander beendet werden. Ist ein Datenstrom beendet durch ein half-close, können noch Daten in der Gegenrichtung übermittelt werden.
Für ein half-close werden zwei Segmente benötigt (Abbildung 2.7):
1. Der Sender (einer Datenrichtung) verschickt ein FIN-Segment.
2. Der Empfänger bestätigt dies durch ein ACK-Segment.
Für das vollständige Schließen einer TCP-Verbindung werden daher 4 Segmente benötigt wegen zweier
Half-Close-Operationen (Abbildung 2.8).
4 Alle Flags zu setzen, ist zum Beispiel unsinnig. So ein so beflaggtes Segment wird laut [Pos87] kamikaze packet genannt. Weitere
Spitznamen dafür sind nastygram, christmas tree packet und lamp test.
5 Dieses Flag kann beschleunigt nicht etwa den Datenfluß. Es spielt eine Rolle im interaktiven Zusammenspiel der gegenl¨
aufigen
Datenflüsse.
2.2. DIE WIRKUNGSWEISE VON TCP
15
Sender
Empfänger
FIN : Seq.nr.:m
ACK: Best.nr. m+1
Abbildung 2.7: Half-Close einer TCP-Verbindung
A
B
FIN : Seq.nr.:m
ACK: Best.nr. m+1
FIN : Seq.nr.:n
ACK: Best.nr. n+1
Abbildung 2.8: Zwei entgegengesetzte Half-Close beenden eine TCP-Verbindung
2.2.4 Bestätigungen
Wie schon bei der Beschreibung des TCP-Headers erwähnt wurde, werden die Anwendungsdaten durch die
Sequenznummern durchnummeriert. Jedes TCP-Paket mit Daten muss bestätigt werden. Pakete, die keine
Daten tragen und nur aus Bestätigungen bestehen, werden nicht bestätigt. Diese verursachen natürlich auch
keine Erhöhung der Sequenznummer.
TCP nutzt nun die gegenläufigen Datenströme, um Bestätigungen in einer Richtung per Huckepack
mit Daten aus der Gegenrichtung zu befördern. Ferner müssen Segmente nicht einzeln bestätigt werden.
Sind alle Segmente bis zum Datenbyte mit Sequenznummer korrekt eingetroffen, wird lediglich eine
Bestätigungsnummer
zurückgeschickt, unabhängig davon, wie viele Pakete seit der letzten Bestätigung
eingetroffen sind. Tatsächlich wird bei jedem Segment (außer bei Verbindungsaufbau und Ende) das ACKFlag gesetzt und mit der Bestätigungsnummer das als nächstes erwartete Datenbyte mitgeteilt.
Um weiter Segmente einzusparen, arbeitet TCP mit verzögerten Bestätigungen (delayed acknowledgements). Hat die eine Seite keine Daten zu senden, wartet sie zwischen den reinen Bestätigungspaketen eine
Mindestzeit (z.B. 200 ms), um einkommende Segmente zu sammeln.
Eine weitere Technik, um die Paketanzahl auf Verbindungen mit geringen Datenfluß (wie z.B. in TelnetSitzungen) zu verringern, ist der Algorithmus von Nagle. Der Algorithmus verhindet den Versand von zu
kleinen TCP-Paketen (kleiner als die Segmentgröße), solange noch Bestätigungen von verschickten TCPPaketen ausstehen. Diese Daten werden gesammelt bis sie die vereinbarte Segmentgröße erreichen oder bis
die ausstehenden Bestätigungen eingetroffen sind.
Der Vorteil von Nagles Algorithmus ist die Selbsttaktung. Für schnelle Verbindungen werden mehr kleinere TCP-Pakete verschickt, während für langsame Verbindungen die Paketanzahl verringert wird. Nagles
Algorithmus lässt sich deaktiveren, was in bestimmten Situationen Sinn ergibt (wenn z.B. ein X Windows
Client die Bewegungen einer Maus übertragen muss).
KAPITEL 2. DAS INTERNET-PROTOKOLL IP
16
Eigenschaft
Verbindungsaufbau
Zustandsinformation
Wegewahl der Pakete
einer Verbindung
Routerausfall
Congestion control
(Staukontrolle)
IP
Ja
keine
Verschiedene Wege möglich
VC
Nein
Ja, für etablierte Routen
Route ist fest
kein Effekt, nur Pakete auf
ausgefallenen Router verloren
schwierig (durch TCP)
Alle Routen durch defekten
Router sind verloren
Einfach
Tabelle 2.2: Vergleich des Internetprotokolls mit Virtual Circuits
2.2.5 Unterschiede zwischen IP und Virtual Circuits
2. Vorlesung
Ein Grundprinzip des Internets ist, dass Router unabhängig als sogenannte autonome Systeme (AS) arbei- 5.05.2003
ten. Das heisst, dass die Wegewahl der Router unabhängig ist, und dass so Router ihre Routingtabellen mit
unterschiedlichen Verfahren aktualisieren können. Damit implementiert das Internet Protokoll (IP) keinen
Virtual Circuit (VC).
Beim Routing gemäß des Virtual-Circuit-Konzepts werden zuerst zwischen Quelle und Ziel Ressourcen
für eine Route bereitgestellt und nach Beendigung der Kommunikation wieder freigegeben. Als anschauliches Beispiel können die elektromechanischen Schaltanlagen des analogen Telefonsystems dienen. Hier
wird eine direkte Drahtverbindung zwischen Anrufer und Empfänger geschaltet. Gemäß dieses Konzepts
definieren die existerenden Routen einen Zustand des Kommunikationsnetzwerks.
Das Routing im Internet ist dagegen zustandslos und verbindungslos. Für einen Vergleich dieser Konzepte siehe Tabelle 2.2.
Kapitel 3
Dienstverweigerungsangriffe
Wir befassen uns hier mit einem Ereignis im Internet, in welchem Rechner oder Teilnetzwerke mit Paketen
von bösartigen Angreifern überschwemmt werden. Beim Versuch diese Pakete zu bearbeiten, muss das
Opfer seinge eigentlichen Aufgaben vernachlässigen. Dieses Ereignis bezeichnen wir als Dienstverweigerungsangriff (Denial of Service — DoS). Formal definieren wir solche Angriffe wie folgt.
Bei einem Denial of Service (DoS)-Angriff werden die Ressourcen eines Rechners oder Netzwerks ausschliesslich zu dem Zweck verwendet, um deren Verfügbarkeit zu verringern oder
auszuschalten.
Wir unterscheiden folgende Angriffsziele:
Einzelne Rechner
Ein Beispiel stellen sogenannte SYN-Angriffe dar. Hier werden eine Reihe von sogenannten halfopen TCP-Verbindungen angefordert duch SYN-Pakete (Der Begriff half-open bezeichnet hier keinen langfristig beabsichtigten Zustand einer TCP-Verbindung im Gegensatz zu einer half-closeVerbindung, an welchen sich half-open anlehnt). Da diese Anfragen ununterscheidbar von regulären
Anfragen sind, muss der TCP-Server einen Port reservieren, SYN/ACK-Pakete senden und auf Reaktion warten. Selbst mit einer Time-out-Regelung kann so ein Angriff relativ leicht die Anzahl
verfügbarer Ports aufbrauchen.
Dennoch können solche spezifischen Angriffe relativ gut lokal abgewehrt werden.
Netzwerk, wie z.B. SMurf-Angriff oder distributed DoS (DDoS) Angriff
Diese Angriffe richten sich gegen Internet-Service Provider (ISP). Hier wird ein großer Datenstrom
auf das lokalen Netzwerk gerichtet. An den kritischen Routern werden wegen Überlastung durch
das Internet Protokoll gelöscht. Hiervon sind mit gleicher relativen Häufigkeit sowohl gültige Pakete als auch DoS-Pakete betroffen. Dadurch wird die Anzahl eingehender gültiger Pakete erheblich
reduziert.
Solche Netzwerkangriffe sind schwieriger als Rechnerangriffe zu bekämpfen.
Die DoS-Anf¨
alligkeit von IP Das Hauptproblem bei der Bekämpfung von DoS-Angriffe ist, dass die
eingehenden Datenströme auf IP-Ebene meist nicht zurückverfolgt werden können. Hierzu erzeugt der
Angreifer Datagramme mit falscher Quell-IP-Adresse. Dieses Problem ist schon seit 1985 bekannt [Mor85]
und trotzdem gibt es seit dieser Zeit noch kein Verfahren zur Lösung dieses Problems (Vielleicht weil seiner
Zeit DoS-Angriffe noch nicht durchgeführt worden sind). Hätte das Internet eher dem Konzept des Virtual
Circuit entsprochen, so wäre die Routenrückverfolgung unproblematisch gewesen.
Außerdem stehen dem Empfänger der Datagramme der Routenverlauf der Pakete nicht zur Verfügung.
Es sei denn, alle Router kooperieren bei der Suche während einer Attacke bei der Rückverfolgung.
Solche DoS-Datagramme können von legitimen Datatgrammen nicht unterschieden werden. Dies kann
nur implizit und aus dem Kontext geschehen. Beispielsweise werden oft Universitätsrechner benutzt, um
17
KAPITEL 3. DIENSTVERWEIGERUNGSANGRIFFE
18
DoS-Attacken mit korrekter Quellinformation zu führen, ohne dass dies heißt, dass solche Attacken von
legitimen Benutzern durchgeführt werden.
Daneben können bestimmte Ereignisse, wie z.B. der Terroranschlag des 11. September 2001 ein Datenaufkommen erzeugen, das weit höher liegt als das eines DoS-Angriffs. Damals brachen sämtliche Nachrichtensites unter völlig legitimer Last zusammen.
Wir werden uns bei der Untersuchung von Verfahren zur Bekämpfung von Denial-of-Service-Angriffen
mit folgender Frage beschäftigen:
Wie kann man die Quelle(n) einer eingehenden Datagrammflut trotz gefälschter Quell-IPAdressen bestimmen?
Als Motivation bei dieser Aufgabe dient die naheliegende Vermutung, dass die Quelle der Nachrichtenmenge identisch ist mit der Ursprung des Angriffs. Wenn dem nicht so ist, so kann wenigsten durch
Abschalten instrumentalisierter Rechner (vorerst) der Angriff beendet werden.
Letzter Fall kommt insbesondere beim sogenannten Reflektorangriff vor. Hier schickt der Angreifer Datagramme mit der Opfer-IP-Adresse als falscher Quellinformation an unbeteiligte Netzteilnehmer (Rechner oder Netzwerkdrucker). Diese unbeteiligten Netzteilnehmer beantwortet die Anfrage an mutmaßliche
Quelle und so erhält das Opfer erhält eine DoS-Attacke von diesen instrumentalisierten Netzteilnehmern.
Die Suche nach dem Angreifer muss hier von den instrumentalisierten Netzteilnehmer aus ausgeführt werden.
3.1 Strategien zur DoS-Abwehr
Folgende Strategien sind in diesem Zusammenhang schon diskutiert, oder auch angewendet worden.
1. Eingangsfilter (Ingress filtering) [FS98]
Hier blockieren Router Pakete mit fehlerhafter Quellinformation und verhindern so den Angriff
schon im Vorfeld. Solch ein Filter macht natürlich nur solange Sinn, wenn gefälsche Quellinformationen erkennbar sind. Dies ist inbesondere der Fall, wenn die Pakete im Zuständigkeitsbereichs
eines Internet-Service-Provider (ISP) erzeugt werden. Somit ist dieser Eingangsfilter besonders sinnvoll an den Schnittstellenroutern von Internet-Service-Provider.
Einen effektiven Schutz durch diese Methode kann man wohl nur nur bei universellen Einsatz erreichen. Leider wird aber dieses Verfahren nicht bei der Mehrheit der ISP eingesetzt.
2. Rückwärtsverfolgung durch Eingangsanalyse (Link testing by input debugging)
Hierbei wird die Route der DoS-Pakete stromaufwärts zurückverfolgt. Das Opfer muss ein allgemeines Merkmal der DoS-Datagramme (attack signature) erkennen und dieses Merkmal an die Netzwerkbetreiber kommuniziert, deren Router als Durchgangsstationen in Betracht kommen. So wird
der Angriffspfad der eingehenden Datagramme immer weiter bis bestenfalls zur Quelle zurückverfolgt. Dies ist bisher die einzige Methode gewesen, um einen bestehenden Angriff zurückzuverfolgen, weswegen einige ISP dieses Verfahren auch automatisiert haben [Sto00].
3. Linktest durch kontrollierten Überlauf (link testing by controlled flooding) [BC00]
Hier geht man davon aus, dass das Opfer über eine aktuelle Routingkarte des Internets verfügt.
Während eines DoS-Angriffs konstruiert das Opfer die Angriffsrouten stromaufwärts, indem es alle
Möglichkeiten der letzten unbekannten Station selber kurzfristig mit einem DoS-Angriff belegt. Läßt
die Datenmenge kurzfristig nach, ist eine Station gefunden und der Vorgang wird per Tiefensuche
fortgesetzt.
Der Hauptnachteil ist, dass das Opfer selbst zum Angreifer wird. Kaum geeignet ist diese Verfahren
für verteilte DoS-Angriffe (DDoS), da hier verschiedene Pfade verwendet werden. Ist diese Methode
dem Angreifer bekannt, so kann er sie leicht überlisten, indem er Fluktuationen in den Datenstrom
einbaut.
3.1. STRATEGIEN ZUR DOS-ABWEHR
Ingress filtering
Link testing by input
debugging
Link testing by flooding
Logging
ICMP Traceback
Markieren
19
Verwaltungsaufwand
moderat
hoch
Netzwerklast
niedrig
niedrig
Routeraufwand
moderat
hoch
Post mortem
fähig
Nein
schlecht
Präventiv/
reaktiv
präventiv
reaktiv
niedrig
hoch
niedrig
schlecht
reaktiv
hoch
niedrig
niedrig
niedrig
niedrig
niedrig
hoch
niedrig
niedrig
ausgezeichnet
ausgezeichnet
ausgezeichnet
reaktiv
reaktiv
reaktiv
Tabelle 3.1: Verschiedene DoS-Abwehrstrategien im Vergleich
4. Protokollierung (Logging)
Hier zeichnet jeder Router zeichnet alle IP-Header auf. Durch Data-Mining-Techniken kann dann
der Angreifer bestimmt werden. Neben dem Problem des Datenschutzes ist der Hauptnachteil der
enorme Aufwand zum Unterhalt dieser Listen.
5. ICMP Traceback
Mit geringer Wahrscheinlichkeit (z.B. 1/20.000) wird in einem Router ein ICMP-Traceback-Datagramm an den Zielknoten geschickt. Dieser Packettyp ist im Hilfprotokoll Internet Control Management Protocol (ICMP) vorgesehen um Routen aufzuzeichnen. Der Zielknoten kann dann den
Weg rekonstruieren. Ein Nachteil ist, dass bei Pufferüberlauf ICMP-Pakete anders behandelt werden
können als IP-Pakete und ebenso wie oder gar häufiger als IP-Datagramme gelöscht werden können.
6. Markierung (Marking) [SWKA00]
Bei diesem Verfahren werden ungenutzte Felder des IP-Header verwendet, damit jeder Router auf
den Weg eines IP-Datagramms seine IP-Adresse mit gewisser Wahrscheinlichkeit protokolliert. Ein
Nachteil bei diesem Verfahren, das wir noch ausführlicher darstellen werden, ist, dass DDoS-Pfade
nur schwer rekonstruierbar sind.
In Tabelle 3.1 wird ein Überblick über die verschiedenen Vor- und Nachteile dieser Verfahren dargestellt.
Theorem 1
DoS und ).
diesen Pfad zu bestimmen, genügen DoS Pakete.
1. Wird mit Wahrscheinlichkeit ein ICMP-Paket erzeugt, dann sind erwartet
Pakete ausreichend zur Bestimmung eines DoS Pfades aus Routern (falls
2. Um mit Wahrscheinlichkeit
!)( +*
Beweis: Sei die Anzahl der DoS-Pakete. Bezeichne
die Zufallsvariable der Anzahl der Pakete, die
, dass Router kein
Router nach DoS-Paketen erzeugt. Dann ist die Wahrscheinlichkeit P
ICMP-Paket erzeugt, gegeben durch
!#"%$
'& Nun gilt folgendes Lemma.
Lemma 1 Für alle
,.-
gilt:
/
/
,10324 .4
,105276
*
KAPITEL 3. DIENSTVERWEIGERUNGSANGRIFFE
20
Wir fahren im Beweis des Theorems fort, indem wir dieses Lemma für
& ( 4 * 2
6
!
anwenden. Damit ist also
Die Wahrscheinlichkeit, dass einer der Router kein Paket schickt, ist gegeben durch
4 6 6
Die Wahrscheinlichkeit, dass einer der d Router kein Paket schickt, soll kleiner als sein. Hierfür setzen
wir folgende Ungleichung an.
4 6
/
/
Aufgelöst nach erhalten wir somit
0 0
was die die zweite Hälfte des Theorems beweist.
Für die erste Hälfte sei die Zufallsvariable, die beschreibt, wieviele Runden notwendig sind, bis jeder
der Router ein Paket verschickt hat. Es gilt
- % 3. Vorlesung
12.05.2003
Der Erwartungswert von E
% *
4 6
%
ist nur wenig größer als ! " ! ! !
"
!
In diesem Schritt haben wir die Summe nur aufgeteilt. Im nächsten werden wir den additiven Term aus der rechten Summe herausnehmen und zu der ersten hinzufügen, während wir den Term der linken
Summe mit abschätzen.
E
#
% $
'
%
" ! ! ( )
%
-
*
&
+
(
%
*#*#*
Die Summe aller Wahrscheinlichkeiten ergibt . Währenddessen haben wir im rechten Summenabgeschätzt und die Wahrscheinlichkeit -,/. + (
term mit
(0
3.2. MARKIERUNG
-
21
#
durch nach oben abgeschätzt. Als nächsten werden wir diese Wahrscheinlichkeit aus der
+
obigen Abschätzung einsetzen und substituieren.
E
Nun gilt
5
(
6
(
"
" "
6
6
%
. Und wir erhalten folgendes:
" 6
6
6
In der vorletzten Zeile haben wir und verwendet. Für *#*#* gilt für die Summe 4
" . In unserem Fall ergibt das für : "
6
6
*#* *
E
3.2 Markierung
Diese Lösung berücksichtigt die Ansprüche von Opfer und Netzwerkbetreiber. Es nutzt geschickt die Tatsache aus, dass DoS-Angriffe mit einer großen Anzahl von Paket geschehen, indem es die Routeninformation
proabilistisch auf die Pakete verteilt.
Voraussetzungen und Annahmen Die hier diskutierten Markierungsverfahren beruhen auf den folgenden Voraussetzungen.
Ein Angreifer kann alle Pakettypen erzeugen.
Verschiedene Angreifer können konspirieren.
Angreifer wissen, dass die Pakete zurückverfolgt werden.
Pakete können verloren gehen oder ihre Reihenfolge kann vertauscht werden.
Angreifer senden zahlreiche Pakete.
Die Route zwischen Angreifer und Opfer ist relativ stabil.
Die Router habe beschränkte Rechen- und Speicherressourcen.
Die Router arbeiten im wesentlichen ordnungsgemäß.
22
KAPITEL 3. DIENSTVERWEIGERUNGSANGRIFFE
Abbildung 3.1: Angriffspfad bei DoS-Angriffen in IP
Abbildung 3.2: Verfälschter DoS-Angriffspfade
3.2. MARKIERUNG
23
Problemstellungen
Wir gehen hier davon aus, dass alle DoS-Pakete auf einem Pfad vom Angreifer zum Opfer verschickt
werden. Die perfekte Lösung der Routenrückverfolgung wäre eine vollständige Angabe aller Router auf
dem Angriffspfad von Angreifer zum Opfer , siehe Abbildung 3.1. Die Auffindung dieses Pfades
heisst Exact Traceback.
Definition 1
Exact Traceback: Berechne den exakten
Angriffspfad
Approximate Traceback: Finde Pfad , der den Angriffspfad
als Suffix beinhaltet.
Wenn dem Angreifer die Methoden zur Routenrückverfolgung bekannt sind, kann er den Pfad möglicherweise verfälschen, indem er die Markierungen von Routern imitiert. Leider ist es nicht möglich dies
ganz ohne kryptographische Methoden1 zu unterbinden. Zumindestens kann man erwarten, dass die Route
zwischen dem Angreifer und dem Opfer nicht verfälscht wird. Dies wird durch das Approximate TracebackProblem beschrieben.
Wir versuchen in diesem Abschnitt Lösungen für das letztere Problem anzugeben. Hat also das Opfer
den Angriffspfad entschlüsselt, so muss er jeden der aufgefundenen Router stromaufwärts Anfragen, ob
der Angreifer sich in unmittelbarer Nähe befindet.
Das Markierungskonzept beruht immer auf zwei Algorithmen:
1. Der Markierungsalgorithmus im Router kodiert die Pfadinformation geeignet in den IP-Header
durchlaufender Datagramme.
2. Die Pfadrekonstruktion erfolgt durch das Opfer. Geschieht ein Angriff, liefern nun die IP-Header
die notwendige Information um das approximate traceback-Problem zu lösen.
Die Qualtitätsmerkmale solcher Markierungsalgorithmen sind
Konvergenzzeit: Das ist Anzahl notwendiger DoS-Pakete zur Lösung des Traceback-Problems
Speicherbedarf in IP-Header: Hier wird gemessen, wie viele Bits zusätzlich im Datagramm vom
Markierungsalgorithmus verwendet werden.
Berechnungsaufwand: Hier untersucht man sowohl den Berechnungsaufwand der im Router als
auch im Opfer notwendig ist.
Nun stellen wir drei unterschiedliche Markierungsalgorithmen vor: Node-Append, Node-Sampling und
Edge-Sampling.
3.2.1 Node Append
Beim Pfadprotokoll (node append) wird im IP-Header die gesamte Pfadinformation gespeichert. Hierzu
hängt jeder Router seine IP-Adresse an, wie durch die Algorithmen in Abbildung 3.3 beschrieben.
Die Konvergenzzeit ist mit einem Paket optimal. Die Nachteile bei diesem Verfahren überwiegen jedoch. Denn zum einen müssen Informationen in den Header geschreiben werden, wenn die Angriffspfadlänge ist. Da die Pfadlänge den Routern nicht bekannt ist, müssen also Mechanismen zur Pfadbeschränkung eingeführt werden, die wieder potenzielle Schwachstellen eröffnen. Ausserdem entsteht für den
regulären Datenverkehr ein erheblicher Zusatzaufwand. Man bedenke, dass z.B. in Telnet-Verbindungen
mitunter nur ein Zeichen übertragen.
3.2.2 Node Sampling
-
Bei der Knotenprobenmarkierungsstrategie (node sampling) schreibt immer nur ein Router seine IP-Adresse
in den IP-Header eines IP-Pakets. Hierfür ersetzt jeder Router mit Wahrscheinlichkeit
ein eventuell bestehenden Eintrag mit seiner eigenen Adresse. Somit trägt jedes Paket höchstens eine IP-Adresse
eines Routers. In Abbildung 3.4 findet sich die vollständige Beschreibung der Algorithmen.
1 Vor
kryptographschen Signaturschemata schreckt man aufgrund wegen des zus¨atzlichen Kommunikationsaufwands zurück.
KAPITEL 3. DIENSTVERWEIGERUNGSANGRIFFE
24
Node Append Pfadrekonstruktion durch Opfer begin
for a packets do
Extrahiere Pfad aus
od
return end.
Node Append Markierung bei Router
begin
for all packets do
Füge zu hinzu
od
end.
Abbildung 3.3: Node Append Markierungsstrategie
Node Sample Markierung bei Router
begin
for all packets do
uniforme Zufallszahl aus if
then
router
od
end.
*
4
Node Sample Pfadrekonstruktion durch Opfer begin
for all packets do
router
router
od
Sortierte Liste aller
vorgekommenden Router gemäß
return end.
*
*
Abbildung 3.4: Node Sampling Markierungsstrategie
Konvergenz Node Sampling
Lemma 2 Die Wahrscheinlichkeit bei der Pfadrekonstruktion von Node-sampling ein Paket mit Router-IP
, der Entfernung zum Opfer hat, zu finden ist mindestens
und höchstens
, wobei die Entfernung des Angreifers ist.
6
6
Beweis:
1. Fall: Der Angreifer sendet keine Pakete mit Routereintrag . Damit wird die Anzahl der Paket mit
Eintrag minimiert. Die Wahrscheinlichkeit, dass
Router zwischen Opfer und unabhängig
mit Wahrscheinlichkeit jeweils
keine eigenen Adressen hineinschreiben ist
. Die
Wahrscheinlichkeit, dass die Adresse hineinschreibt ist .
6
2. Fall: Um die Wahrscheinlichkeit, dass vorkommt, zu maximieren nehmen wir an, dass der Angreifer ausschliesslich Pakete mit dem Eintrag produziert. Die Wahrscheinlichkeit, dass Router
diese Information nicht überschrieben ist
. Man beachte, dass das Ereignis eines regulären
Eintrags von disjunkt von diesem Fall ist. Damit kann man die Wahrscheinlichkeit des ersten Falls
mit dieser addieren, um die gesuchte Wahrscheinlichkeit zu erhalten.
,
Für die Laufzeitabschätzung benötigen wir folgendes fundamentale Resultat zur Abschätzung des Summe von unabhängigen binären Zufallsvariablen.
*#* *
2
Theorem 2 Chernoff-Schranke
unabhängige binäre Zufallsvariablen. Wir bezeichnen die Summe mit
Seien
wobei E
, dann gilt
,
2
2
* $ 6 $ für P 2 6
2
Mit Hilfe dieses Theorems und des nun folgenden
Lemmas bestimmen wir eine obere Schranke der
für
4. Vorlesung
19.05.2003
P
erwarteten Konvergenzzweit von Node-Sampling.
3.2. MARKIERUNG
25
,
Lemma 3 Das selbe unabhängige Zufallsexperiment werde an Bällen durchgeführt. Mit Wahrscheinlichkeit
wird es rot gefärbt, mit Wahrscheinlichkeit
die Anzahl roter Bälle und
die
blau. Sei
Anzahl blauer. Dann gilt
2
2
- 4 " $ " $ 6
6
wobei 6 und 2 6 . 2
, . Nun sind und so gewählt worden, dass gilt
Beweis: Sei E , und E *
2
2 Sei . Es gilt nun - - 4 . Daraus folgt
- 2 2 P -2 4 2 P
P 2 4 2 2 PP 2 -
2 - 2 P 4 * 2 " $ "2 $
6
6 der Chernoff-Schranke.
Die letzte Zeile ergibt sich durch Anwenden
Lemma 4 Die Wahrscheinlichkeit, dass nicht mehr
Pakete von
einem Router der Tiefe als von einem der
Tiefe erscheinen, ist höchstens " #" .
6 6 Lemma
6 anwenden.
2
Beweis: Hier werden wir das zuletzt bewiesene
Wir können für die Abschätzung
P
dieser Wahrscheinlichkeit annehmen, dass der Angreifer versucht die normale Reihenfolge durcheinander
zu bringen, indem er Pakete des Routers in Tiefe
erzeugt. Diese Pakete färben wir rot und schätzen
die Wahrscheinlichkeit nach oben durch
ab, denn es gilt
Wir färben die Pakete des Routers in Tiefe blau und erhalten
*
6 Nun wenden wir obiges Lemma an für
6
gegeben durch
*
/
6 - ist - und somit ist die6 Fehlerwahrscheinlichkeit höchstens
Da ,
,
,
0
Für
erhalten wir
*
/
/ 0
0
,
/
0
*
,
6
,
, *
KAPITEL 3. DIENSTVERWEIGERUNGSANGRIFFE
26
/ von Node Sampling bei Wahrscheinlichkeit - Theorem 3 Die erwartete Konvergenzzeit E bei einer Angriffspfadlänge von .
ist
0
, " "
, DoS-Paketen
2
6 6 P P Bei , Paketen wird Router mit vertauscht
2
"
6 6 6 2
& ( 6 #"
6 6 2
Wir werden , so wählen, dass 4 und wir substitutieren . Um den Term abzuschätzen,
gilt
benutzen wir, dass für 5*
6 für . Sei das Zufallsereignis, welches bei
Beweis: Sei *
eintritt, wenn die Häufigkeit der Pakete nicht der Pfadordnung entspricht. Nun gilt
Damit erhalten wir
2
#" ( &
6
6 6 !" !" 6 6
6 6
P Nun setzen wir wieder und ein und erhalten
#" #" 6 6 2 6
6 bedeutet
6
was für die gesuchte Wahrscheinlichkeit
) *
P 6 6 2
Für die erwartete Anzahl von DoS-Paketen
erhalten
6 wir also 6
, P genau , Pakete reichen
E ,2 , P 2 , , 6 6
, 6 6
$
, *
3.2. MARKIERUNG
27
Edge Sample Markierung bei Router
begin
for all packets do
uniforme Zufallszahl aus if
then
start
distance
else
if distance then
end
fi
distance
distance
fi
od
end.
*
4 *
*
* *
*
Edge Sample Pfadrekonstruktion durch Opfer : Menge aller DoS-Pakete
begin
leerer Baum mit Wurzel
.
for
to
distance 0 do
for all mit distance
do
if end ist in mit Tiefe
then
Falls noch nicht vorhanden, füge Knoten
Falls noch nicht vorhanden, füge Kante
fi
od
od
return
end.
*
* * *
* start ein*
start end
hinzu
Abbildung 3.5: Edge Sampling Markierungsstrategie
& " #" ( stellen wir fest, dass für jede zulässige Wahl
sie mindestens so schnell wächst wie6 . Für
6 kurze Angriffspfade kann man vielleicht noch so
viele DoS-Pakete erwarten spätestens für längere Angriffspfade wir man wohl kaum so viele DoS-Pakete
Betrachten wir diese Konvergenzzeit
,
tolerieren können.
3.2.3 Edge Sampling
Bei der Kantenproben-Markierung (edge sampling) versucht man die Konvergenzzeit erheblich zu reduzieren. Hierfür speichert man statt Knoten Kanten des Angriffspfads ab. Zusätzlich führt man einen Zähler
ein, der die Entfernung der Kante vom Opfer angibt. Dieser wird bei dem weiter entfernteren Knoten der
Kante auf gesetzt und von jedem Router, der nicht die Kanteninformation überschreibt um eins erhöht.
Zur Pfadrekonstruktion wird der Angriffspfad/baum von der Wurzel mit Hilfe dieser Tiefeninformation rekonstruiert, siehe Abbildung 3.5 Analysiert man die Laufzeit, erscheint sie auf den ersten Blick nicht besser
als die von Node Samplling. Der wesentliche Unterschied hierbei ist aber, dass die Wahrscheinlichkeit
frei gewählt werden kann.
KAPITEL 3. DIENSTVERWEIGERUNGSANGRIFFE
28
von Edge Sampling bei Wahrscheinlichkeit Theorem 4 Die erwartete Konvergenzzeit E wenn 6
die Distanz des Angreifers ist.
ist
, 2
4
, , *
P 6
2 , wobei gilt also 2
Für , #"
*
6
P 6
2
Somit gilt für die Misserfolgswahrscheinlichkeit
*
P
6
6 2
6
Damit gilt für den Erwartungswert
, , , % *
E , 6 6
6 6
6
Eine günstige Wahl für ist , wenn die maximale Pfadlänge beträgt. Die erwartete Konver
Beweis: Bezeichne
die Anzahl der DoS-Pakete mit der Kanteninformation der Kante in Entfernung
dieses Paket nicht gefälscht werden kann,
zum Opfer, wobei DoS-Pakete erhältlich sind. Da für
berechnet sich die Wahrscheinlichkeit, dass keines dieser Pakete beim Opfer ankommt durch:
genzzeit ist dann
.
Literaturverzeichnis
[BC00]
Hal Burch and Bill Cheswick. Tracing anonymous packets to their approximate source. In
Proceedings of the Fourteenth Systems Administration Conference (LISA-00), pages 319–328,
Berkeley, CA, December 3–8 2000. The USENIX Association.
[FS98]
P. Ferguson and D. Senie. RFC 2267: Network ingress filtering: Defeating denial of service
attacks which employ IP source address spoofing, January 1998. Status: INFORMATIONAL.
[Lyn93]
Danial C. Lynch. Historical Evolution. In Internet System Handbook,. Daniel C. Lynch and
Marshall T. Rose, eds., Addison Wesley, Reading, 1993.
[Mor85]
Robert T. Morris. A weakness in the 4.2BSD unix TCP/IP software. Technical report, AT&T
Bell Laboratories, February 1985.
[Plu82]
DC Plummer. An ethernet address resolution protocol. RFC 826, November 1982.
[Pos81a]
J. Postel. Internet Protocol. Network Information Center RFC 791, pages 1–45, September
1981.
[Pos81b]
J. Postel. Transmission Control Protocol. Network Information Center RFC 793, pages 1–85,
September 1981.
[Pos87]
J. Postel. Internet Protocol. TCP and IP Bake Off, pages 1–6, 1987.
[Ste95]
W. R. Stevens. TCP/IP Illustrated, Volume 1; The Protocols. Addison Wesley, Reading, 1995.
[Sto00]
Robert Stone. CenterTrack: An IP overlay network for tracking DoS floods. In Proceedings of
the 9th USENIX Security Symposium (SECURITY-00), pages 199–212, Berkeley, CA, August
14–17 2000. The USENIX Association.
[SWKA00] Stefan Savage, David Wetherall, Anna Karlin, and Tom Anderson. Practical network support
for IP traceback. In Proceedings of the 2000 ACM SIGCOMM Conference, August 2000. An
early version of the paper appeared as techreport UW-CSE-00-02-01 available at: tt.
[Tan96]
Andrew S. Tanenbaum. Computer Networks. Prentice-Hall International, Inc., 1996. ISBN:
0-13-394248-1.
29