Vorlesung. Rechnernetze II Teil 10. Sommersemester 2006

Transkript

1 Vorlesung Rechnernetze II Teil 10 Sommersemester 2006 Christian Grimm Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze C. Grimm 28. Juni 2006

2 Übersicht TCP Rückblick auf Rechnernetze I weitere Eigenschaften von TCP Nagle Algorithm, Silly Window Syndrome Timer in TCP Selective Acknowledgment Option (SACK) Sequence Numbers Wahl der Initial Sequence Number (ISN) Spoofing Experiment: Prüfung der ISN in aktuellen Betriebssystemen Protection against Wrapped Sequence Numbers (PAWS) Performance von TCP Transmission Delay und Propagation Delay Bandwidth Delay Product und Sendefenster Window Scale Option C. Grimm 28. Juni 2006 Folie 2

3 Eigenschaften von TCP Punkt-zu-Punkt genau ein Sender und genau ein Empfänger nehmen an dem Datentransfer teil verbindungsorientiert vor der Übertragung von Nutzdaten Verbindungsaufbau durch three-way-handshake three-way-handshake dient auch dem Austausch initialer Übertragungsparameter gesicherte Übertragung die Daten werden bei Fehlern im Netz durch Retransmits ggf. mehrfach übertragen Scheitern auch Retransmits, wird eine Fehlermeldung an die Anwendung übergeben Full Duplex Nutzdaten und Kontrollinformationen können in beide Richtungen der Verbindung ausgetauscht werden Piggybacking (engl.: Huckepack) Nutzdaten und Acknowledgments können innerhalb desselben TCP-Segments übertragen werden C. Grimm 28. Juni 2006 Folie 3

4 Eigenschaften von TCP Ende-zu-Ende die Verbindung zwischen zwei Hosts über TCP wird nicht von Netzwerkkomponenten wie Routern oder Switches unterbrochen d. h. TCP-Header werden während der Übertragung nicht verändert Buffering das Betriebssystem verwaltet Sende- und Empfangspuffer für die Zwischenspeicherung und Bestätigung von out-of-order data Byte-orientiert die Einheit für Sequence und Acknowledgment Numbers ist 1 Byte nicht z. B. die Nummer des TCP-Segments Flow Control (Flusskontrolle) Überfluten des Empfängers wird verhindert (Receive Window im TCP-Header) Congestion Control (Staukontrolle) Überfluten des Netzes wird verhindert (Congestion Window auf Sender) C. Grimm 28. Juni 2006 Folie 4

5 Aufbau TCP-Segment Felder im Header 16-Bit Source und Destination Port 32-Bit Sequence und Acknowledgment Number Länge des Headers in 32-Bit Worten (4 Bit) 12 Bit für Flags, davon 6 nicht genutzt 16-Bit Receive Window 16-Bit Prüfsumme Zeiger auf eilige Daten außerhalb der Nutzdaten (z. B. Break bei TELNET) Optionen (Vielfaches von 32 Bit) head not length used Source Port 32 Bit Sequence Number Nutzdaten Destination Port Acknowledgment Number U A P Checksum R S F Receive Window Urgent data pointer Options (variable Länge) sechs Flags URG ACK PSH (Push) RST (Reset) SYN und FIN Urgent data Pointer ist gültig Acknowledgment Number ist gültig Nutzdaten werden unmittelbar an Anwendung geleitet Rücksetzen einer Verbindung Signalisierung von Verbindungsauf- bzw. -abbau C. Grimm 28. Juni 2006 Folie 5

6 Nagle Algorithm Problem TCP erhält den Datenstrom d. h. die Nutzdaten einer Anwendung byteweise es werden z. B. durch schlechte Programmierung die Zeichen eines Strings einzeln übergeben es werden viele kleine TCP-Segmente mit jeweils wenigen Nutzdaten gesendet geringer Durchsatz durch hohen Overhead, führt ggf. sogar zu Congestion Lösung durch Nagle Algorithm J. Nagle, Congestion Avoidance in IP/TCP Networks, IETF RFC 896, Januar 1984 wird ein kleines TCP-Segment gesendet, muss zunächst auf das ACK gewartet werden, bevor ein weiteres kleines TCP-Segment gesendet werden darf große TCP-Segmente dürfen jedoch sofort gesendet werden während der Wartezeit können weitere Daten der Anwendung angenommen werden so dass das nächste TCP-Segment größer wird und sofort gesendet werden darf der Nagle Algorithm ist selbstregulierend im LAN treffen ACKs schnell ein, so dass auch häufiger kleine TCP-Segmente gesendet werden können im WAN treffen ACKs langsamer ein, es wird eher auf große TCP-Segmente gewartet C. Grimm 28. Juni 2006 Folie 6

7 Nagle Algorithm Nachteile Behinderung interaktiver (Echtzeit-)Anwendungen, in denen kontinuierlich wenige Byte übertragen werden Beispiele Sondertasten über TELNET (zwei Byte Codes) Bewegungen der Maus im X Window System Aktivierung des Nagle Algorithm kann generell über Kernelparameter aktiviert bzw. deaktiviert werden sollte per default für jede TCP-Verbindung aktiviert sein kann über Socket Option TCP_NODELAY deaktiviert werden Frage: wie groß ist ein kleines TCP-Segment? Antwort: siehe Silly Window Syndrome C. Grimm 28. Juni 2006 Folie 7

8 Silly Window Syndrome Problem des Silly Window Syndrome schnelle Verarbeitung der TCP-Segmente auf Sender oder Empfänger führt dazu, dass lediglich kleine TCP-Segmente ausgetauscht werden wird durch zwei verschiedene Situationen in TCP-Schicht verursacht auf Sender Nutzdaten aus Anwendung werden unmittelbar gesendet d. h. es werden viele kleine TCP-Segmente gesendet auf Empfänger empfangene Nutzdaten werden unmittelbar an Anwendung übergeben und bestätigt d. h. RecvWindow vergrößert sich nur geringfügig C. Grimm 28. Juni 2006 Folie 8

9 Silly Window Syndrome Lösungen Empfänger sendet erst dann ein ACK, wenn damit mindestens Daten der Größe 1 MSS oder RecvBuffer / 2 bestätigt werden können (nicht RecvWindow, s. u.) Sender sendet erst dann Daten, wenn TCP-Segment mindestens 1 MSS Byte enthält oder RecvBuffer / 2 Byte enthält oder wenn auf kein ACK gewartet wird (vgl. Nagle Algorithm, s. o.) Anmerkungen damit wird auch Nagle Algorithm abgehandelt klein bedeutet also im Nagle Algorithm < 1 MSS d. h. Sender sendet mindestens TCP-Segment der Größe 1 MSS Sender kann RecvBuffer nur abschätzen, z. B. durch max. RecvWindow zur Erinnerung an RecvBuffer und RecvWindow RecvWindow Daten von IP-Schicht frei Daten Daten an Anwendung RecvBuffer C. Grimm 28. Juni 2006 Folie 9

10 Timer in TCP für jede Verbindung werden 7 Timer gesetzt Connection Establishment Timer Erkennung von Timeouts bei Verbindungsaufbau (Default in BSD-Unix: 75 s) Retransmission Timer Berechnung des TimeoutInterval aus EstimatedRTT und DevRTT s. Rechnernetze I Teil 6 Delayed ACK Timer Timer für das Senden verzögerter Acknowledgments ( ms) s. Rechnernetze I Teil 6 Persist Timer Prüfung des Empfängers, wenn RecvWindow = 0 TCP Exponential Backoff, s. u. Keepalive Timer Prüfung vermutlich abgebrochener Verbindungen (2 Stunden) FIN_WAIT_2 Timer und TIME_WAIT Timer (2MSL Timer) Timeouts bei Verbindungsabbau zur Freigabe von Ressourcen FIN_WAIT_2 ca. 10 Minuten, TIME_WAIT empfohlen lt. RFC Minuten initiale Werte der Timer können über Kernelparameter verändert werden C. Grimm 28. Juni 2006 Folie 10

11 Connection Establishment Timer Experiment zur Bestimmung des Connection Establishment Timers TCP-Verbindungsaufbau (z. B. über TELNET) zu nicht existierendem Host einfache Messung der Zeit zwischen Aufruf von TELNET und Fehlermeldung Solaris 9: 224 Sekunden (3 75 Sekunden, d.h. größer als Default in BSD-UNIX) bash-2.05$ date; telnet xxx.xxx discard;date Tue May 24 12:47:46 CEST 2005 Trying xxx.xxx... telnet: Unable to connect to remote host: Connection timed out Tue May 24 12:51:30 CEST 2005 Linux : 189 Sekunden (2,5 75 Sekunden, d.h. größer als Default in BSD-UNIX) bash-2.05$ date; telnet xxx.xxx discard;date Die Mai 24 12:48:04 CEST 2005 Trying xxx.xxx... telnet: connect to address xxx.xxx: Connection timed out Die Mai 24 12:51:13 CEST 2005 Anmerkung zur Auswahl der Zieladresse TELNET nicht an Host in demselben LAN, da bereits ARP scheitern würde TELNET nicht an Host hinter einer Firewall, da Firewall Verbindung mit RST abbricht C. Grimm 28. Juni 2006 Folie 11

12 Persist Timer Problem mit Flow Control in TCP RecvBuffer ist gefüllt, d. h. Empfänger setzt RecvWindow = 0 danach werden keine weiteren TCP-Segmente zum Empfänger gesendet oder nachfolgende TCP-Segmente mit RecvWindow 0 gehen verloren d. h. wartet Sender unendlich lange auf TCP-Segment mit RecvWindow 0 und darf während dieser Zeit keine neuen Nutzdaten senden Lösung Sender sendet nach Erhalt von RecvWindow = 0 Probes mit 1 Byte Nutzdaten ACK des Empfängers enthält sehr wahrscheinlich irgendwann RecvWindow 0 Achtung: solange Empfänger das Probe -Segment nicht verarbeiten kann, enthält das ACK die Sequence Number des letzten angenommen Byte Zwischenaussendezeiten der Probe-Segmente: TCP Exponential Backoff Startwert ist 1,5 s, wird nach jedem ACK auf das Probe-Segment verdoppelt Persist Timer wird auf den Bereich [5;60] auf- bzw. abgerundet berechnete Folge: 1, gerundete Folge: wird theoretisch unendlich wiederholt C. Grimm 28. Juni 2006 Folie 12

13 Keepalive Timer Verbindungsaufbau zwischen Client und Server eine TCP-Verbindung zwischen Client und Server wird durch 3-way-handshake etabliert für die Verbindung werden Ressourcen auf Client und Server belegt Problem die Verbindung wird nicht ordnungsgemäß getrennt die Ressourcen auf Client und Server bleiben belegt TCP sieht keinen Timer vor, um Verbindungen zu prüfen bzw. um Ressourcen nicht genutzter Verbindungen freizugeben! Lösung Implementierung eines Keepalive Timers im TCP-Stack Aktivierung über Socket-Option SO_KEEPALIVE mit SO_KEEPALIVE prüft TCP-Stack eine ungenutzte Verbindung alle 2 Stunden C. Grimm 28. Juni 2006 Folie 13

14 FIN_WAIT_2 Timer und TIME_WAIT Timer Verbindungsabbau zwischen Client und Server Client setzt FIN-Bit im letzten TCP-Segment mit Nutzdaten Client ist im Zustand FIN_WAIT_1 (active close) Server bestätigt zunächst korrekten Empfang der Nutzdaten durch ACK Server ist im Zustand CLOSE_WAIT (passive close) Client ist nach Erhalt des ACK im Zustand FIN_WAIT_2 Achtung: Server kann aber weiterhin Nutzdaten an Client senden, Client sendet weiterhin ACKs Server sendet mit letzten Nutzdaten TCP-Segment mit gesetztem FIN-Bit Server ist im Zustand LAST_ACK Client bestätigt korrekten Empfang der Nutzdaten durch ACK Client ist danach im Zustand TIME_WAIT Client wartet ggf. auf Retransmit des letzten TCP-Segments, falls ACK verloren ging Aufgabe FIN_WAIT_2 Timer und TIME_WAIT Timer (2MSL Timer) Verbindung wird nach Ablauf der Timer direkt in Zustand CLOSED gesetzt z. B. bei Absturz des Servers fehlerhafter Implementierung des 4-way-close auf Kommunikationspartner (oder DOS-Attacke!) MSL: Maximum Segment Lifetime, angenommene maximale Lebensdauer eines IP- Paketes bzw. TCP-Segments im Internet eigentlich durch TTL von 255 im IP-Header C. Grimm 28. Juni 2006 Folie 14

15 FIN_WAIT_2 Timer und TIME_WAIT Timer Sender Empfänger ESTABLISHED ESTABLISHED FIN_WAIT_1 close () FIN=1 FIN=0 ACK=1 CLOSE_WAIT FIN_WAIT_2 FIN=1 close () LAST_ACK TIME_WAIT FIN=0 ACK=1 TIME_WAIT Timer FIN_WAIT_2 Timer CLOSED CLOSED CLOSED t t C. Grimm 28. Juni 2006 Folie 15

16 TCP State Transition Diagram normal transition for server normal transition for client other possible transitions appl: passive open send: <nothing> starting point CLOSED appl: state transitions taken when application issues operation recv: state transitions taken when segment received send: what is sent for this transition Quellen G. R. Wright, W. Richard Stevens, TCP/IP Illustrated Volume 2 The Implementation. Addison Wesley, G. McKinney. resources/tcpip_state_transition_dia gram.pdf. November active close SYN_RCVD FIN_WAIT_1 timeout send: RST appl: close send: FIN recv: SYN send: SYN, ACK recv: RST recv: ACK send: <nothing> appl: close send: FIN recv: FIN send: ACK LISTEN passive open recv: SYN send: SYN, ACK simultaneous open ESTABLISHED data transfer simultaneous close CLOSING appl: active open send: SYN appl: send data send: SYN recv: SYN, ACK send: SYN recv: FIN send: ACK SYN_SENT active open CLOSE_WAIT appl: close send: FIN LAST_ACK appl: close or timeout recv: ACK send: <nothing> recv: ACK send: <nothing> recv: FIN, ACK send: ACK recv: ACK send: <nothing> passive close FIN_WAIT_2 recv: FIN send: ACK TIME_WAIT 2MSL timeout C. Grimm 28. Juni 2006 Folie 16

17 TCP Selective Acknowledgment Option (SACK) Spezifikation Vorschlag in RFC 1072, TCP Extensions for Long Delay Paths, Oktober 1988 keine Erwähnung in RFC 1323, TCP Extensions for High Performance, Mai 1992 Modifikation in RFC 2018, TCP Selective Acknowledgment Options, Oktober 1996 Problem geringe Performance von TCP Reno, wenn mehrere TCP-Segmente verloren gehen besonders bei Verlust von nicht aufeinander folgenden TCP-Segmenten durch Simulationen belegt Lösung gezielt Angabe von erfolgreich empfangenen Segmenten und dadurch auch von Lücken innerhalb eines Fensters durch Selective Acknowledgments Selective Acknowledgments werden als Option im TCP-Header übertragen in einem TCP-Header können bis zu drei Blöcke von oberer und unterer Sequence Number angegeben werden SACK ist in den meisten aktuellen Betriebssystemen implementiert C. Grimm 28. Juni 2006 Folie 17

18 TCP Selective Acknowledgment Option Szenario 1 Segmente 1 4 und 6 8 werden empfangen, Segment 5 nicht ohne SACK: Verlust des Segments 5 wird durch gewöhnliche Cumulative Acknowledgments auf Segment 4 signalisiert aber Sender weiß anhand der wiederholten ACKs auf Segment 4 nicht zuverlässig, ob Segmente 6 8 korrekt empfangen wurden mit SACK: Cumulative Acknowledgment auf 4, Selective Acknowledgement auf 6 8 Szenario 2 Segment 1 geht verloren, Segmente 2 8 nicht mit SACK: Cumulative Acknowledgment auf 0, Selective Acknowledgement auf 2 8 Szenario 3 Segmente 1,3,5 und 7 werden empfangen, Segmente 2, 4, 6 und 8 gehen verloren mit SACK (1): Empfänger sendet Selective Acknowledgment der Segmente 1, 3 und 5 besser Variante (2): Empfänger sendet Cumulative Acknowledgment für Segment 1 Selective Acknowledgments für Segmente 3, 5 und 7 nicht SACK für 1,3 und 5 und Cumulative ACK für 7 C. Grimm 28. Juni 2006 Folie 18

19 Sequence Numbers Erinnerung: eine Verbindung wird eindeutig definiert über Source-Port, Source-IP, Destination-Port, Destination-IP, Protocol Protocol kennzeichnet Transportprotokoll, d. h. TCP oder UDP Sequence Numbers zwei 32-Bit Werte (Sequence und Acknowledgment Number) im TCP-Header die Sequence Numbers werden innerhalb einer Verbindung byteweise inkrementiert zwischen verschiedenen Verbindungen sind identische Sequence Numbers unerheblich bei kurz aufeinander folgenden gleichen Verbindungen sind identische Sequence Numbers kritisch: Problem bei duplizierten und verzögerten IP-Paketen Richtlinien zur Bildung von Sequence Numbers Verbindung dürfen nicht mit gleichen Sequence Numbers beginnen Verbindung sollten nicht mit definierten Werten beginnen Attacken durch Spoofing möglich, s. u. Frage: wie wird also die Initial Sequence Number (ISN) gebildet? C. Grimm 28. Juni 2006 Folie 19

20 Sequence Numbers nach RFC 793, Transmission Control Protocol (TCP), 1981 TCP-Stack enthält 32-Bit Initial Sequence Number (ISN) Generator Generator wird alle 4 µs um den Wert 1 erhöht Überlauf nach , s 4 Stunden 46 Minuten 20 Sekunden Gefahr durch duplizierte IP-Pakete ist annähernd ausgeschlossen nach RFC 1948, Defending Against Sequence Number Attacks, 1996 ISN new = ISN old + f (Source-Port, Source-IP, Destination-Port, Destination-IP,...) ISN old ist ISN nach RFC 793 f () ist z. B. MD5 Hash Anmerkung zum Verbindungsaufbau / Synchronisation während des Verbindungsaufbaus in TCP (3-way-handshake) synchronisieren sich Sender und Empfänger auf gegenseitige ISN 1. A an B: SYN my sequence number is X 2a. B an A: ACK your sequence number is X ein TCP-Segment! 2b. B an A: SYN my sequence number is Y 3. A an B: ACK your sequence number is Y C. Grimm 28. Juni 2006 Folie 20

21 Spoofing mit TCP Sequence Numbers typischer Verbindungsaufbau über TCP zwischen A und B three way handshake: SYN, SYN-ACK, ACK SYN(ISN A ) A SYN(ISN B ) ACK(ISN A ) ACK(ISN B ) B C. Grimm 28. Juni 2006 Folie 21

22 Spoofing mit TCP Sequence Numbers Schritt 1: X erkundet auf offiziellem Weg die aktuelle ISN B Ziel: danach kann X die nächste ISN B' raten und mit gefälschter Adresse von A unentdeckt Daten an B senden A B SYN(ISN X ) SYN(ISN B ) ACK(ISN X ) ACK(ISN B ) X, A X C. Grimm 28. Juni 2006 Folie 22

23 Spoofing mit TCP Sequence Numbers Schritt 2: X sendet unter der IP von A (d. h. als A X ) SYN mit ISN X' an B Schritt 3: Opfer B sendet SYN-ACK an A mit seiner ISN B' A SYN(ISN B' ) ACK(ISN X' ) B Anmerkung eigentlich schickt A Reset (RST) an B, da A das TCP-Segment keiner Verbindung zuordnen kann nach Erhalt des RST würde B die Verbindung schließen, der Angriff durch X wäre nicht möglich X kann aber durch vorheriges Fluten A dazu bringen, nicht zuordnenbare TCP-Segment zu ignorieren! SYN(ISN X' ) X, A X C. Grimm 28. Juni 2006 Folie 23

24 Spoofing mit TCP Sequence Numbers Schritt 4: X bzw. A X sendet ACK mit geratener ISN B' an B Ergebnis wenn ISN B' stimmt, hat X als A X Verbindung zu B aufgebaut wenn ISN B' nicht stimmt, verweigert B die Annahme und schickt Reset (RST) an A A B ACK(ISN B' ) X, A X C. Grimm 28. Juni 2006 Folie 24

25 Spoofing mit TCP Sequence Numbers Schritt 5: X bzw. A X sendet Daten an B mit aufeinander folgenden SNs Schritt 6: B sendet weiterhin alle ACKs an A d. h. zwischen A X und B besteht lediglich eine unidirektionale Verbindung A ACK(SN X... ) B Data SN X... X, A X Aus Sicht von X genügt unidirektionale Verbindung, um unentdeckt Aktionen auf B durchzuführen. Es fehlt nur eine direkte Kontrolle der Ergebnisse. C. Grimm 28. Juni 2006 Folie 25

26 Prüfung der ISN in aktuellen Betriebssystemen Ansatz: Aufbau von zwei TCP-Verbindungen nach Zeit t einfache Lösung z. B. über telnet Protokollieren von Sequence Numbers und t über Packet Sniffer, z. B. Ethereal Berechnung ISN: SequenceNumber SequenceNumber1 ISN = t 2 Berechnung für Windows XP Time [s] Src-IP Dest-IP Src-Port Dest-Port TCP-Header [SYN] Seq= Ack=0 Win=64240 Len= [RST, ACK] Seq=0 Ack= Win=0 Len= [SYN] Seq= Ack=0 Win=64240 Len= [RST, ACK] Seq=0 Ack= Win=0 Len=0 ISN = , s = 252,13 1ms 1 4 µs RFC 1948 ist in Windows XP offenbar nicht implementiert Aktualisierung: gilt nicht mehr für Windows XP SP2 C. Grimm 28. Juni 2006 Folie 26

27 Prüfung der ISN in aktuellen Betriebssystemen Berechnung für Solaris 9 Time [s] Src-IP Dest-IP Src-Port Dest-Port TCP-Header [SYN] Seq= Ack=0 Win=64240 Len= [RST, ACK] Seq=0 Ack= Win=0 Len= [SYN] Seq= Ack=0 Win=64240 Len= [RST, ACK] Seq=0 Ack= Win=0 Len=0 ISN = , s = 249,57 1ms 1 4 µs RFC 1948 ist in Solaris 9 offenbar nicht implementiert Berechnung für Linux (Kernel , SuSE 8.2) Time [s] Src-IP Dest-IP Src-Port Dest-Port TCP-Header [SYN] Seq= Ack=0 Win=64240 Len= [RST, ACK] Seq=0 Ack= Win=0 Len= [SYN] Seq= Ack=0 Win=64240 Len= [RST, ACK] Seq=0 Ack= Win=0 Len=0 ISN = , s = 1515,07 1ms 1 4 µs RFC 1948 ist in Linux offenbar implementiert C. Grimm 28. Juni 2006 Folie 27

28 Überlauf von Sequence Numbers Sequence Number ist 32-Bit Wert d. h. mit Sequence Numbers können 4 GByte eindeutig adressiert werden die Übertragung einer Datei von 4 GByte dauert über Gigabit Ethernet ca. 35 s 10 Gigabit Ethernet ca. 3,5 s spätestens bei 10 Gigabit Ethernet ist die Gefahr duplizierter Sequence oder Acknowledgment Numbers auch praktisch gegeben PAWS: Protection Against Wrapped Sequence Numbers in RFC 1323, TCP Extensions for High Performance, Mai 1992 Option im TCP-Header enthält Timestamp des Senders (32 Bit) Zähler für Timestamp wird innerhalb 1 ms 1 s um Wert 1 erhöht (also keine Uhr!) Sequence Number kann überlaufen, Timestamp steigt monoton! anhand Timestamp können empfangene TCP-Segmente zeitlich geordnet werden d. h. TCP-Segmente mit identischen Sequence Numbers lassen sich zuverlässig unterscheiden Anmerkung: Timestamp war ursprünglich Erweiterung zur Berechung der RTT Empfänger kopiert Timestamp des Senders in ACK (Timestamp Echo) Sender erhält dadurch zusätzliche Information zur Berechnung der RTT C. Grimm 28. Juni 2006 Folie 28

29 Performance von TCP Rechnernetze I Teil 8 Frage: welche Faktoren beeinflussen den Datendurchsatz bzw. die Performance? allgemein Faktoren Propagation Delay d prop und Transmission Delay d trans (s. Rechnernetze II Teil 11) Verlust von Paketen führt zu Retransmits Last auf Netzkomponenten führt zu Verzögerungen und Retransmits Dauer von Timeouts beeinflussen den Start von Retransmits Overhead Verhältnis von Summe der übertragenen Daten zu Nutzdaten spezielle Faktoren in TCP Warten auf Acknowledgments Verzögerungen durch Delayed Acknowledgments Größe des Sendefensters (beachte Congestion Window: Slow Start, Fast Recovery) Frage: wann wird maximale Performance in TCP auf idealem Link erreicht? Annahme: ideale Sender und Empfänger, fehlerfreier Link die maximale Performance wird genau dann erreicht, wenn ununterbrochen TCP-Segmente vom Sender zum Empfänger übertragen werden können Frage: welche Größe hat das Sendefenster bei maximaler Performance? C. Grimm 28. Juni 2006 Folie 29

30 Sättigung eines Links mit TCP-Segmenten Rechnernetze I Teil 8 Segmente t=0 ACKs 1 Link t=8 2 t= t= t=1 1 t=9 3 2 t= t= t=2 1 t= t= t= t=3 1 t= t= t= t=4 1 t= t= t= t=5 1 t= t= t= t=6 1 t= t= t= t=7 1 t= t= t= Sättigung! C. Grimm 28. Juni 2006 Folie 30

31 Bandwidth Delay Product und Sendefenster Rechnernetze I Teil 8 Betrachtung zum Zeitpunkt t=31 das Sendefenster enthält die 8 nicht bestätigten Segmente 8 15 weiterer Ablauf t=32: mit Ankunft von ACK 8 kann Segment 16 unmittelbar gesendet werden t=33: mit Ankunft von ACK 9 kann Segment 17 unmittelbar gesendet werden t=34: usw. daraus folgt als Bedingung für einen kontinuierlich maximal gefüllten Link das Sendefenster muss mindestens doppelt so groß sein (hier 8 TCP-Segmente) wie das Datenvolumen, das den Link füllt (hier 4 TCP-Segmente) mit der Datenrate R, Propagation Delay d Prop und Round Trip Time RTT (2 d Prop ) folgt S Sendefenster 2 R d Prop = R RTT Anmerkung: die maximale Größe des Sendefensters wird durch das Receive Window des Empfängers bzw. das Feld im TCP-Header bestimmt und beträgt Byte das Bandwidth Delay Product BDP = R RTT kennzeichnet die Kapazität eines Links bei Kenntnis von S Sendefenster und RTT ergibt sich folgende Abschätzung für die maximal erreichbare Datenrate R max : aus R S Sendefenster / RTT R max = S Sendefenster / RTT C. Grimm 28. Juni 2006 Folie 31

32 Bandwidth Delay Product und Sendefenster Rechnernetze I Teil 8 Links mit hohem BDP können bei S Sendefenster Byte nicht gesättigt werden! Einschränkung: jedenfalls nicht mit einer einzelnen TCP-Verbindung Frage: ist das ein neuer Grund für Methoden à la Multiple Simultaneous Connections? Antwort: nein, S Sendefenster bzw. RecvWindow lässt sich wesentlich vergrößern, s. u. 100, ,4 kbit/s 10, kbit/s 128 kbit/s RTT [s] 1,0000 0, kbit/s 1,544 MBit/s (T1) 10 MBit/s 0,0100 S Sendefenster Byte 45 MBit/s (T3) Fast Ethernet 0,0010 0, E+3 100E+3 1E+6 10E+6 100E+6 1E+9 C. Grimm 28. Juni 2006 Folie MBit/s (STM-3) Gigabit Ethernet R [Bit/s]

33 Window Scale Option Ziel: Erweiterung des RecvWindow von 16 auf 32 Bit (genau ca. 30 Bit) V. Jacobson et. al., RFC 1323, TCP Extensions for High Performance, Mai 1992 Implementierung durch Option im TCP-Header die Window Scale Option gibt an, wie oft das angegebene RecvWindow mit dem Faktor 2 multipliziert werden muss, um die tatsächliche Fenstergröße zu erhalten gestattete Werte für Window Scale Option sind 0 bis 14 hierdurch lassen sich Fenster von bis GByte adressieren Window Scale Option darf nur während des Verbindungsaufbaus, d. h. in SYN- bzw. SYN-ACK Segmenten, ausgetauscht werden Beispiel RecvWindow = wscale = 4 RecvWindow = wscale = 7 RecvWindow = = wscale = 4 RecvWindow = = wscale = 7 C. Grimm 28. Juni 2006 Folie 33

34 TCP-Performance über Long Fat Networks (LFNs) LFNs = El-ef-an(t)s Links mit hohem Bandwidth Delay Product werden als LFNs bezeichnet eine TCP-Verbindung über ein LFN wird entsprechend als Long Fat Pipe bezeichnet Verbesserung der Performance von TCP über Long Fat Pipes Problem: keine Sättigung des Links durch geringes RecvWindow ( Byte) Lösung: Vergrößerung des RecvWindow durch Window Scale Option Problem: Überlauf von Sequence und Acknowledgment Numbers Lösung: Protection Against Wrapped Sequence Numbers (PAWS) Problem: Unterbrechung durch Retransmits bei mehreren Paketverlusten Lösung: TCP Selective Acknowledgment Options (SACK) Problem: Berechnung der RTT zu ungenau Lösung: Timestamps in Optionen des TCP-Headers (hier nicht dargestellt) weitere Verbesserung Vergrößerung der MTU durch Jumbo Frames in Ethernet (s. Rechnernetze II Teil 11) C. Grimm 28. Juni 2006 Folie 34

35 Optionen im TCP-Header Eigenschaften nach RFC 793 drei Optionen: End of List, No Operation, Maximum Segment Size nach RFC 1323 weitere Optionen, u. a. Window Scale Factor und Timestamp Optionen umfassen 1 10 fache von 4 Byte (daher No Operation) Format: Kind (1 Byte), Length (1Byte), Value (0 38 Byte) End of Option List No Operation MSS (2 Byte) Window Scale (1 Byte) kind=0 kind=1 kind=2 len=4 MSS kind=3 len=3 Shift SACK-permitted kind=4 len=2 SACK-Option Timestamp kind=5 len=x max. 3 2 Blöcke à 4 Byte kind=8 len=10 Timestamp Value Timestamp Echo Reply Nutzung der Optionen ist Betriebssystem überlassen häufig sind deutliche Unterschiede zu erkennen, s. TCP Fingerprinting C. Grimm 28. Juni 2006 Folie 35

36 Tinygram und Nastygram Tinygram eigentlich kleines IP- oder UDP-Paket häufig auch kleines TCP-Segment (s. Nagle Algorithm, Silly Window Syndrome) Nastygram auch kamikaze packet, christmas tree packet, lamp test segment J. Postel, RFC 1025, TCP and IP Bake Off, September 1987 Test verschiedener TCP-Implementierungen Beschreibung von Testverfahren und Bewertung A nastygram is a segment with e. g. SYN, Push, URG, and FIN on with options and data. Nastygram ist also ein illegales TCP-Segment, d. h. es enthält unsinnige Optionen Annmerkung die Bezeichnung Bake Off für einen Wettbewerb ist inzwischen für Koch-Wettbewerbe von The Pillsbury Company geschützt und darf nicht anderweitig verwendet werden C. Grimm 28. Juni 2006 Folie 36

37 TCP Fingerprinting die Implementierung eines TCP-Stack bietet viele Freiheiten Timer Optionen initiale Größen Verhalten bei unerwarteten TCP-Segmenten jeder TCP-Stack hat seinen eigenen Fingerabdruck anhand der vielfältigen Möglichkeiten, auf beliebige TCP-Segmente zu reagieren, kann das Betriebssystem eine Rechners ermittelt werden siehe Sequence Numbers! die Identifizierung des Betriebssystem ist häufig der erste Schritt eines gezielten Angriffs typisches Tool zum Prüfen von TCP Fingerprints: Nmap Gegenmaßnahme in vielen TCP-Stacks wird inzwischen gezielt versucht, den Fingerprint zu verwischen s. ISN in Windows XP SP2, Linux C. Grimm 28. Juni 2006 Folie 37

38 The Matrix Reloaded Trinity Nmap Version 2.54BETA25 sshnuke Hardware? zeitliche Einordnung dargestellte Version: Nmap version 2.54BETA25, released 4. Juni 2001 nächste Version: Nmap version 2.54BETA26, released 9. Juli 2001 dargestellter Exploit: SSH1 CRC32 (sshnuke), released 8. Februar 2001 Quellen C. Grimm 28. Juni 2006 Folie 38

39 Literatur W. R. Stevens. TCP/IP Illustrated, Volume 1 3. Addison Wesley D. E. Comer, Internetworking with TCP/IP, Volume 1 2. Prentice Hall W. R. Stevens. UNIX Network Programming. Addison Wesley. C. Grimm 28. Juni 2006 Folie 39

40 Übersicht TCP Rückblick auf Rechnernetze I weitere Eigenschaften von TCP Nagle Algorithm, Silly Window Syndrome Timer in TCP Selective Acknowledgment Option (SACK) Sequence Numbers Wahl der Initial Sequence Number (ISN) Spoofing Experiment: Prüfung der ISN in aktuellen Betriebssystemen Protection against Wrapped Sequence Numbers (PAWS) Performance von TCP Transmission Delay und Propagation Delay Bandwidth Delay Product und Sendefenster Window Scale Option C. Grimm 28. Juni 2006 Folie 40