RFC 9401

The Addition of the Death (DTH) Flag to TCP

πŸ“… published April 2023, from ietf

RFC 9401: The Addition of the Death (DTH) Flag to TCP πŸ¦‹

Request for Comments: 9401 πŸ’– Author: S. Toyosawa, Independent ✨ Category: Informational πŸŽ€ Date: 1 April 2023 🌸 ISSN: 2070-1721 🫢 Obsoletes / Updates: the header doesn't list anything it obsoletes or updates πŸ™ˆ

Okay bestie, this is an Independent Submission, so it's not an official Internet Standard. It's published for info only, and the header lists no obsoletes or updates. πŸ’…

Abstract πŸ–€

okay so this memo adds the Death (DTH) flag to TCP 😭, and DTH uses one bit in the TCP header to do it. The whole point is to make TCP session narratives smooth and attractive. it's giving plot twist energy 🎬✨

Status of This Memo πŸ“œ

This document is not an Internet Standards Track specification. It's published for informational purposes, so it's not a formal standard, just a fun read with main character energy πŸ’œ

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard. (See Section 2 of RFC 7841 if you want the deets πŸ€“)

Info about the current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9401 πŸ”—

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they describe your rights and restrictions for this document. no skipping the legal stuff bestie πŸ™ˆ

Table of Contents πŸ—‚οΈ

   1.  Introduction
   2.  Requirements Language
   3.  Specification
     3.1.  TCP Packet Format
     3.2.  When to Send
     3.3.  When Not to Send
     3.4.  Use with the IP Evil Bit
   4.  Security Considerations
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Author's Address

1. Introduction ✨

okay so the proposed Death flag, or DTH for short, uses the fourth flag bit in the TCP header to signal that the TCP session will probably end soon πŸ’€

The flag lets applications get ready for abrupt session endings. Network engineers find it super helpful for figuring out the one or more root causes of TCP RSTs πŸ”. Critical end users can use it to better understand the TCP narratives too 🍿

The name comes from the anime, manga, and light novel custom [NOVEL]. "Death Flags" are hints that a character is going to die soon [CBR-FLAG]. iykyk πŸ™ˆ

For example, an evil scientist's DTH flag gets set when they're way too confident in their deadly invention. And then guess what? The invention kills them πŸ’€πŸ§ͺ. This kind of storyline is also a classic in movies. A notable one is a soldier in a trench. The soldier's flag gets set to 1 right after they show off a photo of their fiancΓ© and talk about the wedding that's happening once they get back from battle πŸ’. Another one is a couple sneaking out of an isolated cabin for a late-night adventure. Usually that adventure gets violently ended by somebody with a chainsaw πŸͺšπŸ˜­

2. Requirements Language πŸ’…

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, as shown here. ✨ the capitals are the whole vibe here πŸ“£

3. Specification πŸŽ€

3.1. TCP Packet Format πŸ“¦

The DTH flag uses the fourth bit in the Control bits field of the TCP header, as shown in Figure 1 [RFC9293]. The fourth bit was picked on purpose because "four" in Chinese is SΓ¬, which sounds a lot like Sǐ, meaning "die" πŸ§§πŸ’€. That's some serious wordplay energy πŸ‘‘

       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                              :
      :                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Note that one tick mark represents one bit position.

                 Figure 1: TCP Header with the DTH Flag Bit

A TCP session peer SHOULD send a DTH segment when the session will likely end soon 🫣. Both the server and the client can send one 🀝. The application or TCP stack MAY choose not to send DTH segments, even when it knows the session is ending. That gives the peer a dramatic surprise, though end users might find the ending too convenient or overly simple πŸ™„. Sending a DTH segment that isn't tied to the session ending isn't encouraged, but it's allowed. (This is often called "teasing," or a false-positive DTH flag 😜)

The DTH flag is informational. TCP software that doesn't implement this feature can safely ignore it. Still, to really appreciate the session, users should notice the subtle signs in the narrative πŸ‘€

The DTH flag doesn't change the sequence or acknowledgment number, and it doesn't require any acknowledgement πŸ™Œ

The recipient isn't required to act differently when it gets the flag. However, it is RECOMMENDED that the info gets passed up to the application layer, so the end user can be told about the incident πŸ“’. The recipient of a DTH segment SHOULD NOT close the socket right away when it arrives. Instead it SHOULD wait for a RST or FIN segment ⏳

This spec doesn't set a maximum number of DTH segments allowed in one TCP session. But limiting them to a few is RECOMMENDED to maximize the dramatic effect 🎭✨

3.2. When to Send πŸ’Œ

DTH can be used any time the sender thinks it's important to signal its inevitable end to the TCP peer 🫠. The example scenarios below show when to send DTH segments.

A malicious actor can send the flag when it suddenly repents 😳. For example, a sender might suddenly regret their part in a DDoS attack and abruptly stop the attack. The archvillain usually ends the sender cruelly and mercilessly soon after that change of heart (or they get killed for protecting the hero) 🦹. When the DTH gets sent is up to the implementation. It can go out anytime from the first signs of betrayal to right before the behavior changes βš”οΈ

The flag can also be sent when the sender stops using cryptographic protections and reveals its plain-text content 🎭. Think of a mysterious character in a mask who often dies right after they reveal their face. In this case, the DTH segment would be sent just before the redirect (30x) from HTTPS to HTTP [RFC9110]. Similarly, the flag can be set when a forged User-Agent or Server HTTP header field gets changed to the real value, which reveals their true identity (like "I am your long-lost twin," "I am a spy," and so on). This sometimes leads to the character's death 😭

The TCP peer is RECOMMENDED to send the flag when it notices resource issues, like shrinking memory or bandwidth πŸ“‰. An AI bot, a cyborg, or a sorcerer application running forbidden protocols (and so on) SHOULD consider sending the flag when it starts coughing up a lot of error messages πŸ€–πŸ§™β€β™€οΈ

An application that's less capable of doing its task MAY send the flag from time to time. Sooner or later it'll get killed by the OS (the archvillain) or by CTRL-C (the end user) because it's inefficient πŸ’…. The same thing is likely to happen to a memory-hogging application. For example, an unscrupulous character who tries to grab all the treasure often dies by accident (like falling off a cliff) πŸ”οΈ

An application SHOULD really think twice before accessing a "honeypot" or haunted server πŸ‘». If your options are limited (say your favorite server breaks down in the middle of nowhere, and the dark server not on DNS is the only shelter around), sending the flag periodically is a good idea. The session is most likely cursed πŸŒ‘πŸ«£

3.3. When Not to Send 🚫

The DTH flag SHOULD NOT be piggybacked on the FIN flag πŸ™…β€β™€οΈ. If it's present anyway, the recipient SHOULD silently ignore the DTH flag. The only exception is when the recipient is an expert in Hokuto-Shinken ("Big Dipper Divine Fist") [WIKI-FNS]. In that case the sender is already dead but stays active for a few seconds, which is unofficially called the "half-zombie open" state πŸ₯·πŸ’€

The DTH flag SHOULD NOT be sent with the URG flag [RFC6093]. The use of the URG flag is not recommended in new implementations [RFC9293].

Using the flag early in a TCP session is NOT RECOMMENDED πŸ™ˆ. Characters who die early are considered nonessential, so their death doesn't add to the quality of the session. (Obviously there are exceptions πŸ˜‰)

3.4. Use with the IP Evil Bit 😈

Some experimental implementations use the Evil bit [RFC3514] in the IP header to indicate whether the session portrays an evil character 😈. The DTH flag isn't meant to characterize a TCP session. It's meant to show the fate of the session no matter what kind of session it is. When both the Evil bit and the DTH flag are present, they MUST be interpreted independently πŸ’œ

4. Security Considerations 🚨

Precursors to the inevitable death (often violent) of a TCP session are useful for upper-layer applications and end users 🧠. However, the security vs. usability balance should also be considered βš–οΈ. Since DTH flags may expose the internal state of the TCP session, attackers can exploit them. Think naming the murderer before the detective points at the suspect πŸ•΅οΈβ€β™€οΈπŸ”ͺ. Spoilers are an act of evil 😀. Anyone who wants to keep the story secret should use the flag mildly 🀫

5. IANA Considerations 🌸

This document defines the behavior of the one of the currently reserved (Rsrvd) control bits in the TCP header πŸŽ€. It's used as an informative indicator of the fate of a TCP session. The fourth bit (counting from the beginning of the thirteenth octet in a TCP header) was intentionally chosen to signify its meaning. A change in the bit position doesn't cause any functional problems, though 🧩

This feature may already be implemented in different ways in Hollywood and/or Japanese animation studio networks πŸŽ¬πŸ‡―πŸ‡΅. To the author's knowledge, though, the technology isn't patented yet πŸ¦‹

✨ Part 1 ends here. Part 2 picks up with Section 6 (References) and Author's Address ✨

6. References ✨

6.1. Normative References πŸ“š

Okay bestie, these are the must-read receipts πŸ§ΎπŸ’… Each one comes with its own DOI and link so you can check the source yourself.

6.2. Informative References 🌸

These ones are just for fun and background, so no pressure to memorize them πŸ™ˆ but they're all here, I promise.

Author's Address πŸ¦‹

Satoshi Toyosawa Independent Email: s2.toyosawa@gmail.com

Thanks for reading all the way to the end, bestie πŸ’œ you're literally the best 🫢

πŸ“¦ where this page comes from