Zum Hauptinhalt springen

RFC 9401 - Die Hinzufügung des Tod (DTH) Flags zu TCP

  • Status: Informational
  • Veröffentlicht: April 2023
  • Stream: INDEPENDENT
  • Errata: Keine Errata

Zusammenfassung (Abstract)​

Dieses Memo spezifiziert die Einbindung des Tod (Death, DTH) Flags in TCP, einschließlich der Verwendung eines Bits im TCP-Header durch DTH. Das Flag ist so konzipiert, dass TCP-Sitzungsnarrative flüssig und attraktiv werden.

Status dieses Memos (Status of This Memo)​

Dieses Dokument ist keine Internet Standards Track-Spezifikation; es wird zu Informationszwecken veröffentlicht.

Dies ist ein Beitrag zur RFC-Serie, unabhängig von jedem anderen RFC-Stream. Der RFC-Editor hat sich entschieden, dieses Dokument nach eigenem Ermessen zu veröffentlichen und macht keine Aussage über seinen Wert für die Implementierung oder Bereitstellung. Dokumente, die vom RFC-Editor zur Veröffentlichung freigegeben wurden, sind keine Kandidaten für irgendeine Ebene eines Internetstandards; siehe Abschnitt 2 von RFC 7841.

Informationen über den aktuellen Status dieses Dokuments, etwaige Errata und wie man Feedback dazu geben kann, sind unter https://www.rfc-editor.org/info/rfc9401 erhältlich.

Copyright (c) 2023 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

Dieses Dokument unterliegt BCP 78 und den rechtlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (https://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments in Kraft sind. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben.

Inhaltsverzeichnis (Contents)​

Wichtiger Hinweis​

Dieses RFC wird im Independent Submission Stream veröffentlicht. Dieses RFC wird von der IETF nicht unterstützt und hat keine formale Stellung im IETF-Standardisierungsprozess.

Hinweis: Dieses Dokument ist ein April-Scherz-RFC, das am 1. April 2023 veröffentlicht wurde, mit humorvollem Inhalt, der sich auf „Death Flag"-Konzepte aus Anime, Manga und Light Novels bezieht.

1. Einführung (Introduction)​

Das vorgeschlagene Tod-Flag, kurz DTH, verwendet das vierte Flag-Bit im TCP-Header, um die wahrscheinliche Beendigung der TCP-Sitzung anzuzeigen.

Das Flag ermöglicht es Anwendungen, sich auf abrupte Sitzungsbeendigungen vorzubereiten. Netzwerkingenieure finden diese Funktion hilfreich bei der Identifizierung der einen oder mehreren Grundursachen von TCP-RSTs. Kritische Endbenutzer können diese Informationen verwenden, um TCP-Narrative besser zu verstehen.

Der Name des Flags ist von der Gewohnheit von Anime, Manga oder Light Novels [NOVEL] abgeleitet. „Death Flags" (Todesflags) beziehen sich auf Hinweise darauf, dass ein Charakter bald sterben wird [CBR-FLAG].

Zum Beispiel wird das DTH-Flag eines bösen Wissenschaftlers gesetzt, wenn er zu viel Vertrauen in seine tödliche Erfindung ausdrückt. Der Wissenschaftler wird oft von seiner eigenen Erfindung getötet. Diese Art von Narrativ ist auch in konventionellen Filmen üblich. Ein bemerkenswertes Beispiel ist ein Soldat in einem Schützengraben. Das Flag des Soldaten wird auf 1 gesetzt, unmittelbar nachdem er ein Foto seiner Verlobten teilt und über die bevorstehende Hochzeit spricht, die nach seiner Rückkehr aus der Schlacht stattfinden wird. Ein weiteres Beispiel ist das Setzen des Flags für ein Paar, das sich aus einer abgelegenen Hütte für einen nächtlichen Ausflug schleicht. Üblicherweise wird der Ausflug gewaltsam von einer Person mit einer Kettensäge beendet.

Referenzen​

2. Anforderungssprache (Requirements Language)​

Die Schlüsselwörter „MUST" (MUSS), „MUST NOT" (DARF NICHT), „REQUIRED" (ERFORDERLICH), „SHALL" (SOLL), „SHALL NOT" (SOLL NICHT), „SHOULD" (SOLLTE), „SHOULD NOT" (SOLLTE NICHT), „RECOMMENDED" (EMPFOHLEN), „NOT RECOMMENDED" (NICHT EMPFOHLEN), „MAY" (KANN) und „OPTIONAL" (OPTIONAL) in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Referenzen​

  • [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, März 1997
  • [RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Mai 2017

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

4. Sicherheitserwägungen (Security Considerations)​

Vorläufer des unvermeidlichen Todes (oft gewaltsam) einer TCP-Sitzung sind für Anwendungen auf höheren Ebenen und Endbenutzer nützlich; das Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit sollte jedoch auch berücksichtigt werden. Da DTH-Flags den internen Zustand der TCP-Sitzung offenlegen können, können sie von Angreifern ausgenutzt werden (z. B. den Mörder nennen, bevor der Detektiv auf den Verdächtigen zeigt). Spoiler sind eine böse Tat. Diejenigen, die die Geschichte geheim halten möchten, sollten das Flag sparsam verwenden.

Risikoanalyse​

  1. Informationsoffenlegung (Information Disclosure): DTH-Flags können Angreifern Informationen über die bevorstehende Beendigung der Sitzung offenlegen, die für Timing-Angriffe oder andere böswillige Zwecke verwendet werden könnten.

  2. Dienstblockierung (Denial of Service): Böswillige Akteure könnten DTH-Flags missbrauchen, um Empfänger irrezuführen, was zu unnötiger Ressourcenzuweisung oder Sitzungsverwaltungsproblemen führt.

  3. Datenschutzerwägungen (Privacy Considerations): Die übermäßige Verwendung von DTH-Flags kann Anwendungsverhaltensmuster preisgeben und damit die Privatsphäre der Benutzer beeinträchtigen.

  4. Spoiler-Effekt (Spoiler Effect): Die Vorab-Kenntnis der Sitzungsbeendigung kann die dramatischen und Überraschungselemente der Benutzererfahrung verringern.

Empfehlungen​

  • Implementierer sollten DTH-Flags vorsichtig verwenden und das Setzen des Flags vermeiden, wenn es nicht notwendig ist.
  • Netzwerkadministratoren sollten DTH-Flag-Verwendungsmuster überwachen, um potenzielle Sicherheitsbedrohungen zu identifizieren.
  • Anwendungsentwickler sollten die Sicherheitsauswirkungen von DTH-Flags berücksichtigen und geeignete Schutzmaßnahmen implementieren.

5. IANA-Erwägungen (IANA Considerations)​

Dieses Dokument definiert das Verhalten eines der derzeit reservierten (Rsrvd) Kontrollbits im TCP-Header. Es wird als informativer Indikator für das Schicksal einer TCP-Sitzung verwendet. Das vierte Bit (gezählt vom Beginn des dreizehnten Oktetts in einem TCP-Header) wurde absichtlich ausgewählt, um seine Bedeutung zu signalisieren; eine Änderung der Bitposition verursacht jedoch keine funktionale Verschlechterung.

Diese Funktion könnte bereits auf unterschiedliche Weise in Hollywood- und/oder japanischen Animationsstudio-Netzwerken implementiert sein; nach Kenntnis des Autors ist die Technologie jedoch noch nicht patentiert.

TCP-Header-Kontrollbit-Zuweisung​

Diese Spezifikation verwendet das vierte Bit im Kontrollbit-Feld des TCP-Headers, das zuvor in einem reservierten Zustand war.

Bitposition: Bit 4 (gezählt vom Beginn des Kontrollbit-Felds)
Flag-Name: DTH (Death)
Zweck: Informatives Flag, das anzeigt, dass die TCP-Sitzung bald enden könnte
Referenz: Dieses Dokument

Registrierungsanforderungen​

Obwohl dieses Dokument die Verwendung des DTH-Flags definiert, wird es als informatives RFC veröffentlicht und stellt keine formale Änderungsanforderung für die IANA-TCP-Parameter-Registry dar. Implementierer, die dieses Flag in Produktionsumgebungen verwenden möchten, sollten sich seiner nicht standardmäßigen Natur bewusst sein.

Implementierungshinweise​

  1. Abwärtskompatibilität (Backward Compatibility): TCP-Implementierungen, die das DTH-Flag nicht unterstützen, ignorieren dieses Bit einfach, da es als reserviertes Bit behandelt wird.

  2. Interoperabilität (Interoperability): Die Verwendung des DTH-Flags sollte die Interoperabilität mit Legacy-TCP-Implementierungen nicht beeinträchtigen.

  3. Patentstatus (Patent Status): Nach Kenntnis des Autors ist diese Technologie nicht patentgeschützt, obwohl Hollywood oder japanische Animationsstudios möglicherweise unabhängig ähnliche narrative Techniken entwickelt haben.

6. Referenzen (References)​

6.1. Normative Referenzen (Normative References)​

6.2. Informative Referenzen (Informative References)​

Beschreibung der Referenzen​

Normative Referenzen (Normative References)​

Normative Referenzen sind Dokumente, die für die Implementierung dieser Spezifikation erforderlich sind. Diese Dokumente definieren die kritischen Protokollelemente und Schlüsselwortinterpretationen, die für den Betrieb des DTH-Flags erforderlich sind.

Informative Referenzen (Informative References)​

Informative Referenzen liefern zusätzliche Informationen über die konzeptionellen Ursprünge und den relevanten Hintergrund des DTH-Flags. Diese Referenzen helfen, den kulturellen Kontext des „Death Flag"-Konzepts zu verstehen, sind aber nicht für die Implementierung dieser Spezifikation erforderlich.

Verwandte RFC-Dokumente​

  • RFC 793 - Transmission Control Protocol (ursprüngliche TCP-Spezifikation)
  • RFC 9293 - Transmission Control Protocol (neueste TCP-Aktualisierung)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit, ein weiteres April-Scherz-RFC)
  • RFC 2119 - Key words for use in RFCs (RFC-Schlüsselwortdefinitionen)
  • RFC 8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (RFC 2119 Schlüsselwort-Groß-/Kleinschreibung-Klarstellung)

Adresse des Autors (Author's Address)​

Satoshi Toyosawa
Unabhängig (Independent)
E-Mail (Email): [email protected]

Über den Autor​

Satoshi Toyosawa ist ein unabhängiger Forscher mit starkem Interesse an Netzwerkprotokollen und humorvoller technischer Dokumentation. RFC 9401 ist der Beitrag des Autors zur IETF-April-Scherz-RFC-Tradition, bei dem das „Death Flag"-Konzept aus Anime und Manga kreativ auf das TCP-Protokoll angewendet wird.

Kontaktinformationen​

Bei Fragen, Vorschlägen oder Kommentaren zu diesem RFC wenden Sie sich bitte über die oben genannte E-Mail-Adresse an den Autor.

Danksagungen​

Danke an alle, die Feedback und Vorschläge für dieses Dokument gegeben haben. Besonderer Dank geht an diejenigen, die den Humor an der Schnittstelle von Anime, Manga und Netzwerkprotokollen verstehen und schätzen.

Historischer Hintergrund​

Dieses Dokument wurde am 1. April 2023 veröffentlicht und setzt die IETF-April-Scherz-RFC-Tradition fort. Diese Tradition begann 1978 mit RFC 748 und hat im Laufe der Jahre viele kreative und humorvolle technische Dokumente hervorgebracht, darunter:

  • RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers (Übertragung von IP-Datagrammen über Brieftauben)
  • RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (Hypertext-Kaffeemaschinen-Steuerungsprotokoll)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit)
  • RFC 7511 - Scenic Routing for IPv6 (malerisches Routing für IPv6)
  • RFC 9401 - The Addition of the Death (DTH) Flag to TCP (dieses Dokument)

Obwohl diese April-Scherz-RFCs humorvoll sind, enthalten sie oft tiefe Einblicke in echte technische Probleme und demonstrieren die Kreativität und den Humor der technischen Gemeinschaft.