2.3.3 Auf- und Abbau von Verbindungen

Der Aufbau einer TCP-Verbindung erfolgt in drei Schritten. Man spricht daher auch von einem Three-way Handshake:

Nach dem Bild hier nun die verbale Beschreibung:

  1. Der typischerweise als Klient bezeichnete Initiator einer Kommunikation sendet ein Segment mit gesetztem SYN-Flag an einen ausgewählten Server, dessen Portnummer natürlich bekannt sein muß. Aus diesem ersten Paket erfährt der Server u.a. die ISN (Initial Sequence Number) des Klienten.

  2. Der Server antwortet mit einem eigenen SYN-Segment. Darin teilt er dem Klienten seine ISN mit und bestätigt außerdem den Erhalt des SYN-Segments aus Schritt 1. Dies geschieht durch Setzen des ACK-Flags sowie der Angabe der um eins erhöhten ISN des Klienten als Bestätigungsnummer. Wir hatten bereits darauf hingewiesen, daß ein gesetztes SYN-Flag wie ein Byte im Datenstrom behandelt wird.

  3. Der Klient bestätigt dem Server anschließend dessen SYN-Segment, ebenfalls durch ACK-Flag und Server-ISN plus eins.

Die gezeigten drei Schritte sind für eine korrekte Synchronization der Sequenznummern beider Enden einer Verbindung und somit für deren Aufbau sowohl notwendig als auch hinreichend. Nach dem Aufbau einer Verbindung kann diese für den bidirektionalen Datenaustausch genutzt werden. Die Partner sind dabei gleichberechtigt. Es handelt sich also nicht um eine Master-Slave-Beziehung.

Oft wird auch gesagt, daß der Klient, also derjenige, der eine Verbindung durch das erste SYN-Segment initiiert, ein sog. Active Open ausführt. Entsprechend spricht man bei seinem Partner, dem Server, vom Passive Open. Jeder Partner ist berechtigt, den Verbindungsaufbau einzuleiten. Deshalb wurde der Three-way Handshake auch so konzipiert, daß kein Problem entsteht, wenn beide Seiten gleichzeitig versuchen, eine Verbindung zueinander herzustellen. Diese Situation, in der beide Partner ein Active Open ausführen, bezeichnet man auch als Simultaneous Open.

Die jeweils gewählte ISN sollte sich im Laufe der Zeit ändern, so daß jede Verbindung ihre eigene, spezifische ISN erhält. Im RFC 793 wird vorgeschlagen, zur Generierung dieser Zahl einen 32-Bit-Zähler zu verwenden, der ca. alle 4 Mikrosekunden um eins zu erhöhen ist. Die Implementierungen in den einzelnen Systemen weichen allerdings oft davon ab.

Die konkrete Art der Auswahl einer ISN ist prinzipiell sicherheitsrelevant. So beschreibt Steve Bellovin in seinem Paper Security Problems in the TCP/IP Protocol Suite [http://www.research.att.com/~smb/papers/ipext.ps] einen Angriff, der auf einer Vorherbestimmung der ISN eines Servers basiert. Dadurch kann es einem Außenstehenden gelingen, dem Server einen beliebigen anderen Rechner als Kommunikationspartner vorzutäuschen. Da bei bestimmten Diensten (z.B. rsh und rlogin) die Zugangskontrolle häufig auf der IP-Adresse des Klienten beruht, ergibt sich daraus die Möglichkeit des widerrechtlichen Eindringens in eine fremde Maschine, da man sich als jemand ausgibt, dem der Server vertraut (Trusted Host).

Im Anschluß an die Theorie wollen wir uns nun die beschriebenen Abläufe auch wieder praktisch ansehen, konkret am Beispiel des Aufbaus einer TCP-Verbindung vom Rechner ultra zum DISCARD-Server des Rechners yang. Die einzige Aufgabe des DISCARD-Servers besteht, wie sein Name schon vermuten läßt, im Vernichten aller ihm zugesandten Daten. Der Monitor snoop lieferte folgenden Mitschnitt:

________________________________
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      ETHER Type=0800 (IP), size = 58 bytes
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      IP  D=134.109.192.215 S=134.109.192.89 LEN=44, ID=26132
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      TCP D=9 S=36026 Syn Seq=2222652227 Len=0 Win=8760
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      DISCARD C port=36026 
________________________________
  2   0.00148 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      ETHER Type=0800 (IP), size = 60 bytes
  2   0.00148 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      IP  D=134.109.192.89 S=134.109.192.215 LEN=44, ID=52131
  2   0.00148 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      TCP D=36026 S=9 Syn Ack=2222652228 Seq=2581070522 Len=0 Win=64240
  2   0.00148 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      DISCARD R port=36026 
________________________________
  3   0.00004 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      ETHER Type=0800 (IP), size = 54 bytes
  3   0.00004 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      IP  D=134.109.192.215 S=134.109.192.89 LEN=40, ID=26133
  3   0.00004 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      TCP D=9 S=36026     Ack=2581070523 Seq=2222652228 Len=0 Win=8760
  3   0.00004 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      DISCARD C port=36026 
Genau wie in Abschnitt 2.2.4 erhalten wir pro Ethernet-Rahmen wieder getrennte Aussagen zu den verschiedenen Schichten. Neben Subnetz, Internet und Transport erkennen wir diesmal zusätzlich noch eine vierte Schicht: die Anwendung.

Eine Analyse der Anwendungsschicht erfolgt allerdings nicht in jedem Fall. In unserem obigen Beispiel wird sie durchgeführt, weil snoop den DISCARD-Dienst als Standard-Dienst (s. Abschnitt 2.3.11) kennt, dem von der IANA (Internet Assigned Numbers Authority) die feste (well-known) Portnummer 9 zugewiesen wurde. Hätten wir dagegen z.B. eine TCP-Verbindung zu einem Server der Secure Shell (SSH) beobachtet, der standardmäßig den Port 22 nutzt, dann hätte snoop keine Analyse der Anwendungsschicht vorgenommen, da ihm der Dienst SSH unbekannt ist (diese Aussage gilt für alle uns zur Verfügung stehenden snoop-Versionen bis einschließlich Solaris 2.6).

Auf der Anwendungsebene geben die beiden Buchstaben C und R die Richtung des Transfers an. Deren genaue Bedeutung ist leider im Online-Manual von snoop nicht beschrieben. Als sinnvolle Deutung bieten sich Call und Reply an. C beschreibt immer den Datenfluß vom Klienten zum Server, R denjenigen vom Server zum Klienten.

Es existiert auch hiervon eine detaillierte Ausgabe [tcpopen.txt].

Das Schließen einer TCP-Verbindung erfolgt in der Regel mittels eines vier Schritte umfassenden Protokolls, das man als modifizierten Three-way Handshake auffassen kann. Auf Grund des Vollduplex-Charakters von TCP werden beide Richtungen separat geschlossen. Ein Datenverlust tritt bei fehlerfreiem Ablauf nicht ein.

Will eine Seite ihrem Partner mitteilen, daß von ihr keine weiteren Daten zu erwarten sind, so schickt sie ihm ein Segment mit gesetztem FIN-Flag. Der Empfänger antwortet mit einer normalen Bestätigung und informiert außerdem die betreffende Anwendung, daß die andere Seite ihre Hälfte der Verbindung geschlossen hat:

Beim Abbau der im obigen Experiment aufgebauten Verbindung stellen sich die vier Schritte so dar:

________________________________
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      ETHER Type=0800 (IP), size = 54 bytes
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      IP  D=134.109.192.215 S=134.109.192.89 LEN=40, ID=26134
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      TCP D=9 S=36026 Fin Ack=2581070523 Seq=2222652228 Len=0 Win=8760
  1   0.00000 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      DISCARD C port=36026 
________________________________
  2   0.00070 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      ETHER Type=0800 (IP), size = 60 bytes
  2   0.00070 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      IP  D=134.109.192.89 S=134.109.192.215 LEN=40, ID=52132
  2   0.00070 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      TCP D=36026 S=9     Ack=2222652229 Seq=2581070523 Len=0 Win=64240
  2   0.00070 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      DISCARD R port=36026 
________________________________
  3   0.00489 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      ETHER Type=0800 (IP), size = 60 bytes
  3   0.00489 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      IP  D=134.109.192.89 S=134.109.192.215 LEN=40, ID=52133
  3   0.00489 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      TCP D=36026 S=9 Fin Ack=2222652229 Seq=2581070523 Len=0 Win=64240
  3   0.00489 yang.informatik.tu-chemnitz.de -> ultra.informatik.tu-chemnitz.de
      DISCARD R port=36026 
________________________________
  4   0.00008 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      ETHER Type=0800 (IP), size = 54 bytes
  4   0.00008 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      IP  D=134.109.192.215 S=134.109.192.89 LEN=40, ID=26135
  4   0.00008 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      TCP D=9 S=36026     Ack=2581070524 Seq=2222652229 Len=0 Win=8760
  4   0.00008 ultra.informatik.tu-chemnitz.de -> yang.informatik.tu-chemnitz.de
      DISCARD C port=36026 

Natürlich steht auch wieder der detaillierte Mitschnitt [tcpclose.txt] zur Verfügung.

Richard Stevens bezeichnet in seinem Buch TCP/IP Illustrated, Volume 1 in Analogie zur Terminologie beim Verbindungsaufbau das Schließen der ersten Hälfte als Active Close und nennt die Reaktion der Gegenseite entsprechend Passive Close. Es entstehen wiederum keine Probleme, wenn beide Seiten simultan ein Active Close ausführen. Diese Situation wird auch als Simultaneous Close bezeichnet.

Die in obiger Abbildung gestrichelt dargestellte Linie zwischen Active und Passive Close soll andeuten, daß das Schließen der beiden Richtungen nicht notwendigerweise unmittelbar nacheinander erfolgen muß. Es ist zulässig, die halboffene Verbindung weiterhin zum Datentransport zu verwenden. In der bereits geschlossenen Richtung werden dann allerdings nur noch Bestätigungen, aber keine Nutzdaten mehr verschickt. Die meisten praktischen Anwendungen machen jedoch von dieser Möglichkeit keinen Gebrauch, sondern beenden den Sendebetrieb, sobald die Gegenseite ihre "Hälfte" geschlossen hat.

Das bisher diskutierte Protokoll stellt den normalen Weg zum Schließen einer TCP-Verbindung dar, weswegen manchmal auch vom orderly Release gesprochen wird. Es gibt allerdings Fälle, in denen eine Anwendung oder die TCP-Software selbst einen mitunter als abortive Release bezeichneten abrupten Abbruch der gesamten Kommunikation durch Versenden eines Segments mit gesetztem RST-Flag veranlaßt, bei dem alle evtl. noch in internen Puffern gehaltenen Daten weggeworfen werden. Die Gegenseite reagiert auf RST nicht mit einer Quittung, sondern mit dem sofortigen Beenden der Verbindung, wovon der betroffene Anwendungsprozeß natürlich Kenntnis erhält.

Die folgende Liste beschreibt typische Situationen, in denen RST-Segmente zum Einsatz kommen:


© Holger Trapp, 26.5.1998