Zum Hauptinhalt springen

3. Spezifikation (Specification)

3.1. TCP-Paketformat (TCP Packet Format)​

Das DTH-Flag verwendet das vierte Bit im Control-Bits-Feld im TCP-Header, wie in Abbildung 1 [RFC9293] dargestellt. Das vierte Bit wurde absichtlich ausgewählt, weil „vier" auf Chinesisch Sì ist; es klingt ähnlich wie Sǐ, was „sterben" bedeutet.

 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 |D|     |C|E|U|A|P|R|S|F|                               |
| Offset|T| Rsr |W|C|R|C|S|S|Y|I|            Window             |
|       |H| vd  |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           [Options]                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               :
:                             Data                              :
:                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Hinweis: Eine Strichmarkierung repräsentiert eine Bitposition.

Abbildung 1: TCP-Header mit DTH-Flag-Bit

Ein TCP-Sitzungs-Peer SOLLTE ein DTH-Segment übertragen, wenn die TCP-Sitzung wahrscheinlich bald beendet wird. Es kann sowohl vom Server als auch vom Client gesendet werden. Die Anwendung oder der TCP-Stack KANN sich entscheiden, keine DTH-Segmente zu senden, auch wenn bekannt ist, dass die Sitzung beendet wird. Dies führt zu einer dramatischen Überraschung für den Peer; die Endbenutzer könnten das Ende jedoch als zu bequem oder übermäßig vereinfacht empfinden. Die Verwendung des DTH-Segments, das nicht mit der Sitzungsbeendigung verbunden ist, wird nicht empfohlen, ist aber erlaubt. (Dies wird oft als „Necken" oder falsch-positives DTH-Flag bezeichnet.)

Das DTH-Flag ist informativ. TCP-Software, die diese Funktion nicht implementiert, kann dieses Flag sicher ignorieren. Um die Sitzung jedoch vollständig zu würdigen, sollten Benutzer sich der subtilen Zeichen der Sitzungsnarrative bewusst sein.

Das DTH-Flag selbst ändert nicht die Sequenz- oder Bestätigungsnummer. Es erfordert keine Bestätigung.

Der Empfänger des Flags muss beim Empfang nicht anders handeln; es wird jedoch EMPFOHLEN, dass Informationen an die Anwendungsschicht weitergeleitet werden, damit der Endbenutzer über den Vorfall informiert werden kann. Der Empfänger eines DTH-Segments SOLLTE NICHT den Socket sofort beim Empfang schließen; er SOLLTE auf ein RST- oder FIN-Segment warten.

Diese Spezifikation legt nicht die maximale Anzahl von DTH-Segmenten fest, die in einer TCP-Sitzung zulässig sind; es wird jedoch EMPFOHLEN, sie auf einige wenige zu beschränken, um den dramatischen Effekt zu maximieren.

3.2. Wann senden (When to Send)​

DTH kann jederzeit verwendet werden, wenn der Absender es für wichtig hält, sein unvermeidliches Ende dem TCP-Peer zu signalisieren. Die folgenden Beispielszenarien veranschaulichen, wann DTH-Segmente gesendet werden sollten.

Ein böswilliger Akteur kann das Flag senden, wenn er plötzlich bereut; zum Beispiel, wenn ein Absender plötzlich seine Beteiligung an einem DDoS-Angriff bereut und den Angriff unerwartet einstellt. Der Erzschurke beendet den Absender normalerweise grausam und erbarmungslos kurz nach der Verhaltensänderung (oder wird getötet, weil er den Helden schützt). Das Timing der DTH-Übertragung ist implementierungsabhängig. Es kann jederzeit von den frühen Anzeichen des Verrats bis kurz vor der Verhaltensänderung gesendet werden.

Das Flag kann gesendet werden, wenn der Absender aufhört, kryptografische Schutzmechanismen zu verwenden, und seinen Klartext-Inhalt offenlegt, zum Beispiel ein mysteriöser Charakter mit einer Maske, der oft stirbt, nachdem er sein Gesicht enthüllt hat. In diesem Beispiel würde das DTH-Segment kurz vor dem Senden der Umleitung (30x) von HTTPS zu HTTP [RFC9110] gesendet werden. Ebenso kann das Flag gesetzt werden, wenn das gefälschte User-Agent- oder Server-HTTP-Header-Feld auf den tatsächlichen Wert geändert wird, wenn ihre wahre Identität offenbart würde (zum Beispiel „Ich bin dein lange verlorener Zwilling", „Ich bin ein Spion" usw.). Dies führt gelegentlich zum Tod des Charakters.

Dem TCP-Peer wird EMPFOHLEN, das Flag zu senden, wenn er Ressourcenprobleme bemerkt, z. B. abnehmender Speicherplatz oder Bandbreite. Ein KI-Bot, Cyborg, Zauberer-Anwendung mit verbotenen Protokollen usw. SOLLTE in Betracht ziehen, das Flag zu senden, wenn er beginnt, stark Fehlermeldungen zu husten.

Eine Anwendung, die ihre Aufgabe weniger gut erfüllen kann, KANN das Flag von Zeit zu Zeit senden. Sie wird früher oder später aufgrund ihrer Ineffizienz vom Betriebssystem (dem Erzschurken) oder CTRL-C (dem Endbenutzer) getötet werden. Dasselbe gilt wahrscheinlich für eine speicherfressende Anwendung, zum Beispiel ein skrupelloser Charakter, der versucht, den gesamten Schatz zu nehmen, stirbt oft zufällig (z. B. fällt von einer Klippe).

Eine Anwendung SOLLTE wirklich zweimal nachdenken, bevor sie auf einen „Honeypot" oder Spuk-Server zugreift. Wenn Ihre Möglichkeiten begrenzt sind (z. B. fällt Ihr Lieblingsserver mitten im Nirgendwo aus und der dunkle Server, der nicht im DNS ist, ist der einzige Ort, an dem Sie Schutz finden können), ist es eine gute Idee, das Flag regelmäßig zu senden. Die Sitzung ist höchstwahrscheinlich verflucht.

3.3. Wann nicht senden (When Not to Send)​

Das DTH-Flag SOLLTE NICHT auf dem FIN-Flag huckepack genommen werden. Falls vorhanden, SOLLTE der Empfänger das DTH-Flag stillschweigend ignorieren. Die einzige Ausnahme ist, wenn der Empfänger ein Experte für Hokuto-Shinken („Big Dipper Divine Fist") [WIKI-FNS] ist. In diesem Fall ist der Absender bereits tot, bleibt aber einige Sekunden aktiv (was inoffiziell als „Halb-Zombie-Offen"-Zustand bezeichnet wird).

Das DTH-Flag SOLLTE NICHT mit dem URG-Flag [RFC6093] gesendet werden. Die Verwendung des URG-Flags wird in neuen Implementierungen nicht empfohlen [RFC9293].

Die Verwendung des Flags im frühen Stadium einer TCP-Sitzung wird NICHT EMPFOHLEN. Charaktere, die im frühen Stadium sterben, werden als unwesentlich betrachtet, daher trägt ihr Tod nicht zur Qualität der Sitzung bei. (Offensichtlich gibt es Ausnahmen.)

3.4. Verwendung mit dem IP Evil Bit​

Einige experimentelle Implementierungen verwenden das Evil Bit [RFC3514] des IP-Headers, um anzuzeigen, ob die Sitzung einen bösen Charakter darstellt. Das DTH-Flag ist nicht dazu gedacht, eine TCP-Sitzung zu charakterisieren. Es soll das Schicksal der Sitzung zeigen, unabhängig von der Natur der Sitzung. Wenn sowohl das Evil Bit als auch das DTH-Flag vorhanden sind, MÜSSEN sie unabhängig interpretiert werden.

Referenzen​

  • [RFC3514]: Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 2003
  • [RFC6093]: Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, Januar 2011
  • [RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, Juni 2022
  • [RFC9293]: Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022
  • [WIKI-FNS]: Wikipedia, "List of Fist of the North Star characters", März 2023
Letztes Update am