lehrstuhl für kommunikationssysteme – systeme ii1 systeme ii – 4te vorlesung lehrstuhl für...

Lehrstuhl für Kommunikationssysteme – Systeme II 1

Systeme II – 4te Vorlesung

Lehrstuhl für KommunikationssystemeInstitut für Informatik / Technische Fakultät

Universität Freiburg2009


Übungszettel abgeben (nach vorne durchreichen, vorne ablegen)

Praktische Übungen Erste Übung war am 29. April, nächste am 6. Mai (Mittwoch)

Besprechung des ersten Übungsblattes

Übungszettel ebenso wie theoretische auch immer Online verfügbar (z.B. für Arbeit Zuhause)

Mailingliste Jetzt eingerichtet

Adresse: systemeII-SS09@rz (geändert wegen organisatorischer Probleme)

Jede(r) sollte die Begrüßungs-Email erhalten haben

Vorlesung Systeme II – Organisatorisches

mailto:systemeII-SS09@rz


Inhalt der Vorlesung

Kurze Wiederholung IP-Paketzustellung in lokalen Netzen Prinzip des IP-Routings DHCP

Theorie der Vermittlungsschicht Paketstau und Stauvermeidung Mittel, Orte und Maße

ICMP Hilfsprotokoll des IP ICMP Messages


Letzte Vorlesung

‣ Prinzip des IP Routings

‣ Routing-Tabelle

‣ Prinzip der Paketzustellung• Beispiel einer Routing-Tabelle auf der Linux-Plattform

• Lokale und Zustellung über Router

• Rekursion des Matchings der Zieladresse (Ziel AND Netzmaske – Vergleich mit Netzadresse)


Letzte Vorlesung

‣ Automatische Verteilung von IP-Adressen: DHCP


Letzte Vorlesung

‣ DHCP als Protokoll in der Applikationsschicht für die Vermittlungsschicht (Client-Server-Kommunikation)


Aufgaben der Vermittlungsschicht

‣ IP in erster Linie als Vermittlungsschichtprotokoll anzusehen

‣ Vermittlungsschicht hat im theoretischen Modell weitere Aufgaben zu übernehmen

‣ Reine Weiterleitung der Datagramme anhand der Vermitt-lungsschichtadressen genügt nicht

‣ Was passiert bei Leitungsüberlastung (auch von Teilstücken), wer Sender/Empfänger wird wie informiert?

8

Congestion Control – Stauvermeidung

‣ Jedes Netzwerk hat eine eingeschränkte Übertragungs-Bandbreite

‣ Wenn mehr Daten in das Netzwerk eingeleitet werden, führt das zum • Datenstau (congestion)

oder gar• Netzwerkzusammenbru

ch (congestive collapse)

‣ Folge: Datenpakete werden nicht ausgeliefert

9

Schneeballeffekt

‣ Congestion control soll Schneeballeffekte vermeiden• Netzwerküberlast führt zu Paketverlust

(Pufferüberlauf, ...)

• Paketverlust führt zu Neuversand

• Neuversand erhöht Netzwerklast

• Höherer Paketverlust

• Mehr neu versandte Pakete

• ...

10

Anforderungen an Congestion Control

‣ Effizienz• Verzögerung klein

• Durchsatz hoch

‣ Fairness

• Jeder Fluss bekommt einen fairen Anteil

• Priorisierung möglich- gemäß Anwendung

- und Bedarf

11

Mittel der Stauvermeidung

‣ Erhöhung der Kapazität• Aktivierung weiterer Verbindungen, Router• Benötigt Zeit und in der Regel den Eingriff der

Systemadministration

‣ Reservierung und Zugangskontrolle• Verhinderung neuen Verkehrs an der Kapazitätsgrenze• Typisch für (Virtual) Circuit Switching

‣ Verringerung und Steuerung der Last• (Dezentrale) Verringerung der angeforderten Last bestehender

Verbindungen• Benötigt Feedback aus dem Netzwerk• Typisch für Packet Switching

- wird in TCP verwendet


Orte und Maße von Paketstaus

‣ Router- oder Host-orientiert• Messpunkt (wo wird der Stau bemerkt)

• Steuerung (wo werden die Entscheidungen gefällt)

• Aktion (wo werden Maßnahmen ergriffen)

‣ Fenster-basiert oder Raten-basiert• Rate: x Bytes pro Sekunde

• Fenster: siehe Fenstermechanismen in der Sicherungsschicht

• wird im Internet verwendet

13

Routeraktion: Paket löschen

‣ Bei Pufferüberlauf im Router

• muss (mindestens) ein Paket gelöscht werden

‣ Das zuletzt angekommene Paket löschen (drop-tail queue)

• Intuition: “Alte” Pakete sind wichtiger als neue (Wein)- z.B. für go-back-n-Strategie

‣ Ein älteres Paket im Puffer löschen

• Intuition: Für Multimedia-Verkehr sind neue Pakete wichtiger als alte (Milch)

14

Paketverlust erzeugt implizites Feedback

‣ Paketverlust durch Pufferüberlauf im Router erzeugt Feedback in der Transportschicht beim Sender durch ausstehende Bestätigungen• Internet

‣ Annahme: • Paketverlust wird hauptsächlich durch Stau ausgelöst

‣ Maßnahme:• Transport-Protokoll passt Senderate an die neue Situation

an

15

Proaktive Methoden

‣ Pufferüberlauf deutet auf Netzwerküberlast hin

‣ Idee: Proaktives Feedback = Stauvermeidung (Congestion avoidance)• Aktion bereits bei kritischen

Anzeigewerten• z.B. bei Überschreitung einer

Puffergröße• z.B. wenn kontinuirlich mehr

Verkehr eingeht als ausgeliefert werden kann

• ...• Router ist dann in einem Warn-

Zustand


Paket drosseln (Choke packets)

‣ Wenn der Router in dem Warnzustand ist:• Sendet er Choke-Pakete (Drossel-Pakete) zum Sender

‣ Choke-Pakete fordern den Sender auf die Sende-Rate zu verringern

‣ Problem:• Im kritischen Zustand werden noch mehr Pakete erzeugt

• Bis zur Reaktion beim Sender vergrößert sich das Problem

• wird im Internet verwendet

17

Proaktive Aktion: Warnbits

‣ Wenn der Router in dem Warnzustand ist:• Sendet er Warn-Bits in allen Paketen zum Ziel-Host

‣ Ziel-Host sendet diese Warn-Bits in den Bestätigungs-Bits zurück zum Sender• Quelle erhält Warnung und reduziert Sende-Rate

18

Proaktive Aktion: Random Early Detection

‣ Random Early Detection (RED)

‣ Verlorene Pakete werden als Indiz aufgefasst

‣ Router löschen Pakete willkürlich im Warnzustand

‣ Löschrate kann mit der Puffergröße steigen

P(drop)

1.0

MaxP

MinTh MaxTh AvgLen

19

Reaktion des Senders

‣ Raten-basierte Protokolle

• Reduzierung der Sende-Rate

• Problem: Um wieviel?

‣ Fenster-basierte Protokolle:

• Verringerung des Congestion-Fensters

• z.B. mit AIMD (additive increase, multiplicative decrease)


Aufgaben der Vermittlungsschicht

‣ Probleme nur teilweise durch IP behandelt• Schichtenmodell nicht in Reinform umgesetzt – andere Schichten

übernehmen Aufgaben oder Aufgaben auch doppelt implementiert (spätere Vorlesungen)

• In TCP/IP wird feine Flusskontrolle von TCP übernommen

‣ IP selbst wenig Möglichkeiten diese Vermittlungsschichtauf-gaben zu implementieren

‣ TOS (Type of Service – 2te Vorlesung) Feld als Entscheidungshilfe zur Paketklassifizierung

‣ ICMP übernimmt Teile der IP-Aufgaben


IP – Internet Control Message Protocol

‣ IP paket-orientiertes, verbindungsloses Protokoll• Hat keine eingebauten, direkten Mechanismen der

Paketverfolgung

• Prinzip: Verschicken & Vergessen

• Pakete können zu lange verzögert oder auch verloren gehen

• Zielmaschine kann unerreichbar sein (temporär, für länger)

- Maschine selbst (abgeschaltet, abgestürzt, ...)

- Routing schlägt fehl (Netzwerkfehlkonfiguration, Netzwerkkomponenten, ...)

- Protokoll auf höherem Level existiert nicht oder schlägt fehl



‣ Typischerweise kümmert sich Protokoll auf höherer Schicht (TCP) oder Applikation implementiert Time-Outs, ...

‣ Alternatve: Einführung eines Hilfsprotokolls der Vermittlungs-schicht, da nicht alle Aufgaben sinnvoll an höhere Schichten delegierbar

‣ Einführung eines IP-nahen Mechanismus für Fehlermeldun-gen und speziellen Informationsaustausch – ICMP

‣ ICMP definiert Erweiterungen zum unsicheren IP• Diese logisch als Teil des IP-Moduls angelegt, aber in IP-

Datagramme eingepackt

• Damit können IP-Module von Systemen sich Informationen zustellen



‣ Beschränkt auf Fehlermeldungen und Reporting• Anfragen: Laufen nach dem Client/Server Info Request/Response

Verfahren

• Fehlermeldungen: Mitteilung über Reihe von definierten Fehlerzuständen

• Dabei: Reihe von Einschränkungen, um ICMP Message Kaskaden zu vermeiden

‣ Deshalb dürfen keine ICMP Messages als Antwort verschickt werden, wenn:

• Eine ICMP Fehlermeldung einen Fehler generiert (Antwort OK für spezielle ICMP-Anfragen, die Antwort erwarten)



‣ Deshalb keine ICMP Messages wenn:• Für IP-Datagramme, deren Header Fehler aufweisen (könnte ja

die Quelladresse von betroffen sein – Meldung an andere Maschine sinnlos)

• Für Broadcast (vorletzte Vorlesung) oder Multicast IP-Datagramme

• Link Layer Broadcast oder Multicast Frames

• Ungültige Quelladressen oder das Null-Netzwerkprefix

• Auf IP-Fragmente bis auf das erste (die Ausgangsmaschine schickt ja genau nur ein Paket los)



‣ ICMP als Standard-IP-Paket hat definierten Aufbau und einen Header der Form:

• Typfeld gibt einen der 15 möglichen Message Types an

• Codefeld spezifiziert Subtypen

• Check-Summe deckt die gesamte ICMP Message ab



‣ Nicht mehr adäquat angesichts der komplexeren IP-Anwendungen heutzutage

• Gekapselte IP-Pakete (GRE – General Routing Encapsulation für IP-over-IP Tunnel)

• IPsec Pakete und andere komplexere Protokoll-Header

• Probleme bei NAT

‣ Neuere Regeln definieren deshalb: Soviel wie möglich des Original-pakets ohne dabei die Gesamtpaket-Länge von 576 Byte (Art von Minimum Transfer Unit) zu überschreiten

‣ Zudem: Für bestimmte ICMP-Typen lassen sich Test-Pattern definieren, z.B. bei ping (Manpage aufrufen und nachsehen)

• Besseres Wiederfinden von Testpaketen bei großen Setups



‣ ICMP Messages vom Typ Fehler (erstes Header Feld):• 3 = Destination Unreachable

• 4 = Source Quench (Weg-Überlastung, Thema später noch vertieft behandelt)

• 5 = Redirect (IP Routing)

• 11 = Time Exceeded (TTL)

• 12 = Parameter Problem



‣ Bei Fehlermeldungen übermittelt ICMP den Header des fehlgeschlagenen IP-Pakets und weitere 8 Daten-Bytes (Start des nächsten Protokoll-Headers)



‣ ICMP Meldungen vom Typ Query• 0 = Echo Reply (z.B. bei der ping Antwort) und 8 = Echo

Request ("ping Anfrage")



‣ ICMP Meldungen vom Typ Query• Sollte nicht in Firewalls gefiltert werden für einfaches

Netzwerk-Debugging, aber ... Sicherheitserwägungen, Verschleierung der Netzwerkstruktur ...

• Deshalb im Beispiel in der praktischen Übung beim traceroute * * * statt Router-IP

• 9 = Router Advertisement

• 10 = Router Solicitation(beide nicht mehr üblich, ersetzt beispielsweise durch DHCP)



‣ ICMP Meldungen vom Typ Query• 13 = Time Stamp Request

• 14 = Time Stamp Reply – überholt und durch andere Protokolle, wie RDate (TCP) oder Network Time Protocol (NTP – Applikationsschicht) übernommen

• 17 = Address Mask Request

• 18 = Address Mask Reply (überholt, ersetzt bspw. Durch DHCP – letzte Vorlesung)

• Deshalb werden die meisten dieser ICMP Messages einfach unterdrückt oder ignoriert – bieten zu einfache Einfallstore für Spoofing, Sniffing, Verfälschungen, ...



‣ ICMP Meldungen vom Typ Query• Ging auch etwas an der Idee von IP als einfaches Fire-Forget-

Protokoll vorbei

• ICMP zu unterkomplex, deshalb viele der genannten Aufgaben auf höhere Schichten verlagert

‣ Meldungen des Typs Destination Unreachable

• Arten von “Unreachable” Meldungen:

- 0: Network – keine Route in das Zielnetzwerk vorhanden, tritt typischerweise auf einen Wege-Router auf

- 1:host – Rechner im Zielnetz nicht erreichbar

- 2:protocol – Höherschichtige Protokoll nicht erreichbar, nicht implementiert



• Arten von “Unreachable” Meldungen:

- 3:port – Auf diesem Port reagiert kein Dienst/Applikation

- Generelles Problem bei der Erreichung eines Ziels:

- 4: frag needed – aber das Dont Fragment Bit im IP Header war gesetzt (genutzt für bestimmte Protokolle oder MTU Path Discovery)

- Neuere Implementierungen ersetzen das zweite Wort des ICMP Header (üblicherweise undefiniert) mit der MTU des nächsten Hops

- 5: source route failed – eher selten, da IP-Option (beim IP-Header nicht näher besprochen) Source-Route eingetragen war, diese aber nicht realisiert werden konnte



‣ ICMP Source Quench: Ursprüngliche Idee war, dass Routers “Staumeldungen” generieren konnten (Idee der Bandbreiten-steuerung)

‣ Problem nur: Generieren von weiterem Traffic in Phasen der Überlastung nicht besonders clever und mögliche Interferenzen mit der TCP Fluss-Kontrolle

‣ Deshalb sollten Router keine solchen ICMP Messages erzeugen



‣ ICMP Time Exceeded (vom Typ 11)• Zeigt an, dass die Zustellungszeit für ein IP-Paket

abgelaufen ist (vgl. Diskussion in der Vorlesung zu IP Header)

• Inhalt des Code-Felds:

- 0: TTL exceeded in transit

- 1: fragment reassembly time exceeded

‣ Darüber hinaus Typ: Parameter problem (Typ 12) - Generelles Catch-All für Zustellungsfehler, die nicht durch andere ICMP-Typen abgedeckt sind



‣ ICMP Redirect (vom Typ 5)• Zeigt an, dass ein falscher First-Hop-Router vom sendenden

System benutzt wird

• Redirect zeigt den Router, der anstelle verwendet werden sollte

• Code-Feld Werte:

- 0:network, 1:host, 2:TOS & Network, 3:TOS & Host

• Meldung des ping Kommandos



‣ ICMP Redirect (vom Typ 5) als Wireshark-Mitschnitt• Noch aktives Relikt vergangener Tage, welches aber vielfach noch

funktioniert (zumindest im Sinne der Generierung solcher Pakete)



‣ ICMP Redirect (vom Typ 5)• Idee: Einsparen von überflüssigen Hops, Reduktion von Traffic im

gleichen Subnetz (Paket passiert dieses nur einmal statt doppelt)

• Prinzip: End-System schickt Paket zum Default-Router (nach eigener Routing-Tabelle)



‣ ICMP Redirect (vom Typ 5)• Empfangener Rechner (der nicht der Router ist) informiert die

andere Maschine über korrekten Default-Router (in der heilen Welt)

• Einfallstor für Angriffe durch Paketumleitung, für Denial-of-Service, ...



‣ ICMP Redirect (vom Typ 5)• Ursprünglicher Sender aktualisiert seine Routing-Tabelle auf den

korrekten Router

• War interessant in frühen (pre-DHCP und Böse-Buben) Zeiten, nun überholt

• Nun zurück zu allgemeineren (Weitverkehrs-)Routing-Prinzipien


Internet Protocol – dynamisches Routing

‣ Bisher betrachtet: Statisches Routing (auf dem Endsystem) – Routing-Einträge lagen vor

• Zahl der Router (Beispiel Campus-Netz mit ?? Routern und Layer-3-Switches) zwar deutlich kleiner als der Endsysteme (~18.000)

• Dieses schon in mittleren Organisationen wie Universität Freiburg schwierig

‣ Deshalb – automatische Ermittlung von Routen nach bestimmten Kriterien (Optimalität) durch geeignete Algorithmen

‣ Umsetzung in speziellen Routing-Protokollen, die Routing-Informationen austauschen und lokale Routing-Tabellen konfigurieren – nächste Vorlesung(en)


Ende der zweiten VorlesungEnde der zweiten Vorlesung

Nächste Vorlesung am Montag an diesem Ort, gleiche Zeit: Weiter zu IP/Routing

Jede(r) sollte spätestens jetzt ersten Übungszettel abgegeben haben

Praktische Übung am Mittwoch wieder im Rechenzentrum (Keller)

Alle relevanten Informationen auf der Webseite zur Vorlesung: http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

Mailingliste wird in der Zwischenzeit aufgesetzt und eine erste Info-Mail verschickt ...

Zu lesen: Kapitel zu IP, ICMP und Routing in der angegebenen Literatur!

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

http://www.ks.uni-freiburg.de/php_veranstaltungsdetail.php?id=28

lehrstuhl für kommunikationssysteme – systeme ii1 systeme ii – 4te vorlesung lehrstuhl für...

Documents