Vorlesung Rechnernetze II Teil 7

Transkript

1 Vorlesung Rechnernetze II Teil 7 Sommersemester 2009 Christian Grimm Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze

2 Übersicht TCP 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 Nutzdatenrate und Framerate über Gigabit Ethernet Socket-Buffer und MTU Internet2 Land Speed Records Christian Grimm 20. Mai 2009 Seite 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 Christian Grimm 20. Mai 2009 Seite 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 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) Christian Grimm 20. Mai 2009 Seite 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) 32 Bit Source Port Destination Port Sequence Number Acknowledgment Number head not U A P R S F length used Checksum Receive Window Urgent data pointer Options (variable Länge) Nutzdaten sechs Flags URG Urgent data Pointer ist gültig ACK Acknowledgment Number ist gültig PSH (Push) Nutzdaten werden unmittelbar an Anwendung geleitet RST (Reset) Rücksetzen einer Verbindung SYN und FIN Signalisierung i von Verbindungsauf- bzw. -abbau Christian Grimm 20. Mai 2009 Seite 5

6 Nagle Algorithm Problem TCP erhält den Datenstrom d. h. die Nutzdaten einer Anwendung byteweise es werden z. B. durch schlechte ht Programmierung die Zeichen eines Strings einzeln übergebenb 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 idein kleines TCP-Segment gesendet, dtmuss zunächst ähtauf fdas ACK gewartet tt werden, bevor ein weiteres kleines TCP-Segment gesendet werden darf große TCP-Segmente dürfen jedoch sofort gesendet werden während der Wartezeit kann TCP-Stack weitere Daten der Anwendung annehmen, 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, so dass sich eher große TCP-Segmente ergeben Christian Grimm 20. Mai 2009 Seite 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 für spezifisch über Socket Option TCP_NODELAY deaktiviert werden Frage: Wie groß ist ein kleines TCP-Segment? Antwort: siehe Silly Window Syndrome Christian Grimm 20. Mai 2009 Seite 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 Christian Grimm 20. Mai 2009 Seite 8

9 Silly Window Syndrome Lösung Empfänger sendet erst dann ein ACK, wenn damit mindestens Daten der Größe 1MSS 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 Christian Grimm 20. Mai 2009 Seite 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 Christian Grimm 20. Mai 2009 Seite 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 f von TELNET und Fehlermeldung ld 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 Christian Grimm 20. Mai 2009 Seite 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 (z. B. ACKs) mit RecvWindow 0 gehen verloren d. h. Sender wartet unendlich lange auf TCP-Segment mit RecvWindow 0, darf gem. Spezifikation während dieser Zeit aber keine neuen Nutzdaten senden Lösung Sender sendet nach Erhalt von RecvWindow = 0 Probes 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 oft wiederholt Christian Grimm 20. Mai 2009 Seite 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 t die Ressourcen auf Client und Server bleiben belegt Spezifikation von 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 "The keepalive timer is a controversial feature. Many feel that this polling of the other end has no place in TCP and should be done by the application, if desired. This is one of the religious issues, because of the fervor expressed by some on the topic. W. Richard Stevens Christian Grimm 20. Mai 2009 Seite 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 Christian Grimm 20. Mai 2009 Seite 14

15 FIN_WAIT_2 Timer und TIME_WAIT Timer Sender Empfänger ESTABLISHED ESTABLISHED FIN_WAIT_1 close () CLOSE_WAIT FIN_WAIT_2 close () LAST_ACK TIME_WAIT TIME_WAIT Timer FIN_WAIT_2 Timer CLOSED CLOSED CLOSED t t Christian Grimm 20. Mai 2009 Seite 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 timeout send: RST LISTEN passive open 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 appl: close send: FIN FIN_WAIT_1 recv: FIN send: ACK recv: SYN send: SYN, ACK simultaneous open ESTABLISHED data transfer simultaneous close CLOSING 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: ACK send: <nothing> passive close recv: FIN FIN_ WAIT_ 2 TIME_WAIT send: ACK 2MSL timeout Christian Grimm 20. Mai 2009 Seite 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 t implementiert t Christian Grimm 20. Mai 2009 Seite 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 h 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 bessere Variante (2): Empfänger sendet Cumulative Acknowledgment für Segment 1 nicht: SACK für 1,3 und 5 Selective Acknowledgments für Segmente 3, 5 und 7 und Cumulative ACK für 7 Christian Grimm 20. Mai 2009 Seite 18

19 Sequence Numbers Erinnerung: eine Verbindung wird eindeutig definiert über Source-Port, Source-IP, Destination-Port, Destination-IP, Protocol Protocol kennzeichnet Transportprotokoll, t 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 i 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? Christian Grimm 20. Mai 2009 Seite 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 aber nicht Spoofing 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 2b. B an A: SYN my sequence number is Y 3. A an B: ACK your sequence number is Y ein TCP-Segment! Christian Grimm 20. Mai 2009 Seite 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 Christian Grimm 20. Mai 2009 Seite 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 X Christian Grimm 20. Mai 2009 Seite 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! X, A X Christian Grimm 20. Mai 2009 Seite 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, t 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 X, A X Christian Grimm 20. Mai 2009 Seite 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 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. Christian Grimm 20. Mai 2009 Seite 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 2 SequenceNumber 1 ΔISN = t 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 Christian Grimm 20. Mai 2009 Seite 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 t Christian Grimm 20. Mai 2009 Seite 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 bis 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 Christian Grimm 20. Mai 2009 Seite 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 dtransmission i Delay d trans (s. unten) Verlust von Paketen führt zu Retransmits Last auf Netzkomponenten führt zu Verzögerungen (insgesamt d queue ) 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? Christian Grimm 20. Mai 2009 Seite 29

30 Sättigung eines Links mit TCP-Segmenten Rechnernetze I Teil 8 Segmente t=0 ACKs Link 1 2 t=8 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! Christian Grimm 20. Mai 2009 Seite 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 Christian Grimm 20. Mai 2009 Seite 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 l Simultaneous Connections? Antwort: nein, S Sendefenster bzw. RecvWindow lässt sich wesentlich vergrößern, s. u. 100, , ,4 kbit/s 64 kbit/s 128 kbit/s 1,0000 RTT [s] 0,1000 0, kbit/s 1,544 MBit/s (T1) 10 MBit/s S Sendefenster Byte 45 MBit/s (T3) Fast Ethernet 0, MBit/s (STM-3) Gigabit Ethernet 0, E+3 100E+3 1E+6 10E+6 100E+6 1E+9 R [Bit/s] Christian Grimm 20. Mai 2009 Seite 32

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 wscale = 4 wscale = 7 RecvWindow = = RecvWindow = = Christian Grimm 20. Mai 2009 Seite 33

34 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 d(1b Byte), Length th(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 Vl Value Timestamp Echo Reply Nutzung der Optionen ist Betriebssystem überlassen häufig sind deutliche Unterschiede zu erkennen, s. TCP Fingerprinting Christian Grimm 20. Mai 2009 Seite 34

35 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 (s. PAWS) weitere Verbesserung auf Ebene des Data Link Layers Vergrößerung der MTU durch Jumbo Frames in Ethernet (s. u.) Christian Grimm 20. Mai 2009 Seite 35

36 Transmission Delay und Propagation Delay Dateitransfer über zwei verschiedene Links Link 1 ist T1 Datenrate R = Bit/s = Byte/s Link k2i ist tgigabit bitethernett Datenrate t R = Bit/s = Byte/s One Way Delay d prop beträgt 30 ms = 0,03 s zu übertragene Datei umfasst Volumen V von 1 MByte = Byte T1 Gigabit Ethernet 1 MByte 30 ms Berechnung der gesamten Übertragungsdauer D (ohne Slow Start, ACKs, Router) Propagation Delay d prop : Laufzeit des Signals auf dem Link Transmission Delay d trans: Übertragung der Datei D = d + d = d prop trans prop + V R d. h. d prop ist in beiden Fällen gleich, lediglich d trans ist veränderlich Christian Grimm 20. Mai 2009 Seite 36

37 Transmission und Propagation Delay Ergebnisse D T1 = 5,211 s D Gigabit Ethernet = 38 ms anschauliche Darstellung betrachtet wird Zeitpunkt t 0 = 30 ms, d. h. an dem das 1. Bit den Empfänger erreicht Byte noch in Datei 30 ms Byte im Link erzielbarer Gewinn durch Verdoppelung der Datenrate R T1 Gigabit Ethernet 8 ms Byte im Link lediglich d trans wird halbiert, d prop bleibt konstant D 2 T1 2T1 = 2,621 s, d. h. Übertragungsdauer g wird um Faktor 1,98 reduziert D 2 Gigabit Ethernet = 34 ms, d. h. Übertragungsdauer wird um Faktor 1,12 reduziert Erkenntnis: die Erhöhung der Datenrate lohnt sich nur bei V/R >> d prop Christian Grimm 20. Mai 2009 Seite 37

38 Transmission und Propagation Delay grafische Darstellung der Übertragungsdauer in Abhängigkeit der Datenrate Volumen V von 1 MByte bei d prop = 30 ms und d prop = 300 ms 1.000,00 14,4 kbit/s Übe ertagungsd dauer [s] 100,00 10,0000 1,00 0,30 0,10 0,03 64 kbit/s 128 kbit/s 768 kbit/s 1,544 MBit/s (T1) 10 MBit/s 45 MBit/s (T3) Fast Ethernet 622 MBit/s (STM-3) Gigabit Ethernet 10 Gigabit Ethernet 0,01 1,E+04 1,E+05 1,E+06 1,E+07 1,E+08 1,E+09 1,E+10 1,E+11 d prop = 300 ms d prop = 30 ms Datenrate [Bit/s] Christian Grimm 20. Mai 2009 Seite 38

39 Hohe Datenraten über einzelne TCP-Verbindung Sättigung des Links Ziel ist optimales (kontinuierliches) Füllen der Verbindung mit TCP-Segmenten Kit Kriterium i hierfür: S Sendefenster Bandwidth Delay Product BDP = R RTT weitere Überlegungen Übertragung möglichst großer Einheiten (Segmente, Pakete oder Rahmen) geringer Overhead ggf. weniger Interrupts ggf. weniger Kopiervorgänge zwischen Netzwerk-Interface und Betriebssystem (Socket-Buffer) ggf. weniger Kopiervorgänge zwischen Betriebssystem (Socket-Buffer) und Anwendung kleine Einheiten : MSS gibt günstige maximale Größe der Payload in TCP an ein TCP-Segment sollten nicht in mehrere IP-Pakete Pakete aufgeteilt werden müssen d. h. Vermeidung von Fragmentierung MSS wird aus Path MTU Discovery ermittelt (s. Rechnernetze I Teil 11) MSS wird als Option im TCP-Header angegeben (s. oben) Fragen Wie bestimmen MTU bzw. MSS die Übertragungsrate? Welche weiteren Parameter sind zu beachten? Christian Grimm 20. Mai 2009 Seite 39

40 Nutzdatenrate von TCP über Gigabit Ethernet Eckdaten Gigabit Ethernet Bit-Dauer für Bit/s: 1 Bit dauert s = 1 ns, d. h. 1 Byte dauert 8 ns MTU Ethernet t Nutzdaten t in einem Ethernet-Framet nach DIX-Ethernet (IEEE 802.3): Minimum 46 (38) Byte, Maximum (1.492) Byte für nicht standardisierte Erweiterung Jumbo Frames : Maximum Byte daraus folgt für Nutzdaten innerhalb eines TCP-Segmentes nach Abzug der Header, d. h. 20 Byte IPv4-Header und 20 Byte TCP-Header Minimum 6 Byte, Maximum Byte, bei Jumbo Frames Maximum Byte zusätzlicher Overhead durch Header in Ethernet Header umfasst mindestens 14 Byte (DIX-Ethernet, t s. Rechnernetze II Teil 2) Frame Checksum (FCS) 4 Byte daraus ergeben sich Ethernet-Frames von 64 bis Byte zusätzlicher Overhead durch minimalen Abstand von aufeinander folgenden Frames zu beachten ist Präambel von 8 Byte und Interframe Gap von 12 Byte daraus ergeben sich Abstände von 84 bis Byte Christian Grimm 20. Mai 2009 Seite 40

41 Framerate von TCP über Gigabit Ethernet Rechnernetze I Teil 12 Frage: Wie viele Frames/s können über Gigabit Ethernet übertragen werden? Datenrate R: R = Bit/s, Nutzdaten N: 6 Byte/Fr. N Byte/Fr. Framerate F Bit = s Byte 8 Bit ( N ) Frame 1Byte = Frames N + 78 s ges. Protokoll- Overhead F [Frames/s s] F [Frames/s s] N[B [Byte] 0 N[B [Byte] Christian Grimm 20. Mai 2009 Seite 41

42 Nutzdatenrate von TCP über Gigabit Ethernet Rechnernetze I Teil 12 Frage: welche Nutzdatenrate R N kann über Gigabit Ethernet erreicht werden? Nutzdaten N: 6 Byte/Frame N Byte/Frame, Framerate F (s. o.) R N [MBit/s] Nutzdatenrate R N = N Byte Frame F Frames s 5% Overhead 8 Bit 1Byte R N [MBit/s] N = N + 78 Datenrate ges. Protokoll- Overhead Bit s 1% Overhead N [Byte] 0 N [Byte] Christian Grimm 20. Mai 2009 Seite 42

43 Socket-Buffer Eigenschaften der Socket-Buffer in TCP Client: Speicher für gesendete (warten auf ACK) und zu sendende TCP-Segmente Server: Speicher für empfangene und zu verarbeitende TCP-Segmente (RecvBuffer) B freier Speicher im Socket-Buffer entspricht Option RecvWindow im TCP-Header Eigenschaften der Socket-Buffer in UDP lediglich Weitergabe einzelner Datagramme von IP- zur Anwendungsschicht Achtung: falls Socket-Buffer auf Empfänger zu klein für ein UDP-Datagramm ist, wird das UDP-Datagramm Datagramm verworfen bzw. zurückgewiesen Einstellungen Größen der Socket-Buffer können durch die Funktion setsockopt() gesetzt werden Default Werte variieren stark zwischen verschiedenen Betriebssystemen Achtung setsockopt() muss aufgerufen werden, bevor Client und Server MSS aushandeln gilt entsprechend auch bei Verwendung der Window Scale Option Christian Grimm 20. Mai 2009 Seite 43

44 TCP-Durchsatz in Abhängigkeit der Socket-Buffer maximale Größen Ethernet: Default MTU beträgt Byte, bei Jumbo Frames Byte IP: IPv Byte inkl. 20 Byte Header, in IPv Byte zzgl. 40 Byte Header TCP: MSS beträgt maximale Größe eines IP-Paketes abzüglich 20 Byte TCP-Header Anwendung Betriebssystem Application Layer Göß Größe durch hdeklaration der Variablen read/write buffer bzw. bei Systemaufruf recv (..., nbyte) send (..., nbyte) TCP/UDP socket buffer Größe manipulieren durch setsockopt () MSS IP IP (re)assembly buffers Betriebssystem Netzwerk-Interface Data Link Layer input/output queue MTU MTU + Header/Trailer Christian Grimm 20. Mai 2009 Seite 44

45 Nutzdatenrate in Abhängigkeit der Socket-Buffer Messung mit netperf zwischen SGI Onyx 2 uns SGI Origin 200 (IRIX 6.3) MBit/sec Gigabit Ethernet, normal framesize, MTU Byte 64 KByte Socket Buffer 128 KByte Socket Buffer 256 KByte Socket Buffer 512 KByte Socket Buffer 1024 KByte Socket Buffer Read/Write Buffer Size [KByte] Christian Grimm 20. Mai 2009 Seite 45

46 Nutzdatenrate in Abhängigkeit der Socket-Buffer Messung mit netperf zwischen SGI Onyx 2 uns SGI Origin 200 (IRIX 6.3) MBit/sec Gigabit Ethernet, jumbo frames, MTU Byte KByte Socket Buffer 128 KByte Socket Buffer KByte Socket Buffer 512 KByte Socket Buffer 1024 KByte Socket Buffer Read/Write Buffer Size [KByte] Christian Grimm 20. Mai 2009 Seite 46

47 Internet2 Land Speed Records (hier aus Mai 2004) Wettbewerb um höchste Datenrate (10 Gigabit Ethernet) über weite Entfernungen Kriterium ist Produkt aus Datenrate und Entfernung in [TBit m/s] Beschreibung und Verzeichnis i der Rekorde: t t2 / IPv4 single Stream IPv4 multiple Stream IPv6 single / multiple Entfernung g[ [km] Volumen [GByte] 838, Dauer [s] Datenrate [GBit/s] 423 4, , ,73 Terabit-Meter / Sekunde Hardware Client / Server Dell 2650, single Xeon / Intel Quad Itanium2 / HP Dual Itanium2 / Dell 2650, single Xeon Intel Quad Itanium2 Dual Xeon Netzwerk-Interface Intel PRO 10 GE / Intel PRO 10 GE S2io Xframe 10 GE / Intel PRO 10 GE Intel PRO 10 GE / Intel PRO 10 GE Betriebssystem NetBSD Windows Server 2003, 64 Bit Linux Messtool ttcp NTttcp iperf MTU [Byte] TCP Buffer [Byte] (?) Christian Grimm 20. Mai 2009 Seite 47

48 Berechnung Bandwidth Delay Product am Beispiel IPv4 single Stream Entfernung: l = m nominelle Datenrate t des Links: R = Bit/s Ausbreitungsgeschwindigkeit im Lichtwellenleiter: 2/3 c 0 mit c 0 = m/s Berechnung d Prop und S Sendefenster l m d Prop = = = 0, s 2 2 m c s S Sendefenster 2 R d Prop = Bit/s 0, s = Byte Anmerkungen der Link speichert gemäß Berechnung R d Prop = 102 MByte die tatsächliche mit traceroute gemessene RTT mess beträgt jedoch 270 ms die berechnete RTT rech = 2 d Prop = 163,43 ms ist jedoch um den Faktor 1,65 geringer d. h. S Sendefenster sollte sogar 204 MByte 1,65 = 340 MByte umfassen Erklärung: der Pfad zwischen Sender und Empfänger umfasste 40(!) Router jeder Router wird zwei mal durchlaufen, d. h. jedes Router-Interface verzögert um 1,3 ms die Differenz von 170 MByte 102 MByte = 68 MByte wird also in den Routern gespeichert Christian Grimm 20. Mai 2009 Seite 48

49 Internet2 Land Speed Records Entwicklung der Rekorde Beginn der Aufzeichnung am 21. März 2000 letzter t Rekord vom 31. Dezember 2006 Angaben in TBit m/s sämtliche Daten von /IPv /IPv4 Datenrate [GBit/s] /IPv /IPv /IPv /IPv /IPv6 vor 2004 in 2004 in 2005 in Distanz [km] Christian Grimm 20. Mai 2009 Seite 49

50 Tokio Chicago Amsterdam New York Chicago Tokio mit 216,300 TBit m/s Christian Grimm 20. Mai 2009 Seite 50

51 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 l TCP-Segment, d. h. es enthält unsinnige i 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 Christian Grimm 20. Mai 2009 Seite 51

52 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 t 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 Christian Grimm 20. Mai 2009 Seite 52

53 The Matrix Reloaded Trinity Nmap Version 2.54BETA25 sshnuke zeitliche Einordnung Hardware? 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, released 8. Februar 2001 Anmerkung: das Programm/Skript sshnuke ist fiktiv Quellen hackers/2003/apr html Christian Grimm 20. Mai 2009 Seite 53

54 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. g Addison Wesley. Christian Grimm 20. Mai 2009 Seite 54

55 Übersicht TCP Eigenschaften von TCP Nagle Algorithm, Silly Window Syndrome Timer in TCP Selective Acknowledgment Option (SACK) Sequence Numbers Wahl der Initial Sequence Number (ISN) Spoofing cv cv f trttrrtrhhtrt: Prüfung der ISN in aktuellen Protection against Wrapped Sequence Numbers (PAWS) Performance von TCP Transmission Delay und Propagation Delay Bandwidth Delay Product und Sendefenster Window Scale Option Nutzdatenrate und Framerate über Gigabit Ethernet Socket-Buffer und MTU Internet2 Land Speed Records Christian Grimm 20. Mai 2009 Seite 55