3. Spécification (Specification)
3.1. Format de paquet TCP (TCP Packet Format)
Le drapeau DTH utilise le quatrième bit dans le champ des bits de contrôle de l'en-tête TCP comme illustré dans la figure 1 [RFC9293]. Le quatrième bit a été intentionnellement sélectionné car « quatre » en chinois est Sì ; il a un son similaire à Sǐ, qui signifie « mourir ».
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 : une marque de graduation représente une position de bit.
Figure 1 : En-tête TCP avec le bit de drapeau DTH
Un pair de session TCP DEVRAIT transmettre un segment DTH lorsque la session TCP sera probablement terminée bientôt. Il peut être envoyé à la fois depuis le serveur et le client. L'application ou la pile TCP PEUT choisir de ne pas envoyer de segments DTH, même si elle sait que la session sera terminée. Cela entraîne une surprise dramatique pour le pair ; cependant, les utilisateurs finaux peuvent percevoir la fin trop commode ou trop simpliste. L'utilisation du segment DTH qui n'est pas associé à la terminaison de session n'est pas encouragée mais elle est permise. (Ceci est souvent appelé « taquinerie » ou un faux positif du drapeau DTH.)
Le drapeau DTH est informatif. Le logiciel TCP qui n'implémente pas cette fonctionnalité peut ignorer ce drapeau en toute sécurité. Cependant, pour apprécier pleinement la session, les utilisateurs doivent être conscients des signes subtils des récits de session.
Le drapeau DTH lui-même ne modifie pas le numéro de séquence ou d'accusé de réception. Il ne nécessite aucun accusé de réception.
Le destinataire du drapeau n'est pas tenu d'agir différemment à la réception ; cependant, il est RECOMMANDÉ que les informations soient transmises à la couche application, afin que l'utilisateur final puisse être informé de l'incident. Le destinataire d'un segment DTH NE DEVRAIT PAS fermer le socket immédiatement à la réception ; il DEVRAIT attendre un segment RST ou FIN.
Cette spécification ne stipule pas le nombre maximum de segments DTH autorisés dans une session TCP ; cependant, les limiter à quelques-uns est RECOMMANDÉ pour maximiser l'effet dramatique.
3.2. Quand envoyer (When to Send)
DTH peut être utilisé à tout moment où l'expéditeur considère qu'il est important de signaler sa fin inévitable au pair TCP. Les scénarios d'exemple ci-dessous illustrent quand envoyer des segments DTH.
Un acteur malveillant peut envoyer le drapeau lorsqu'il se repent soudainement ; par exemple, lorsqu'un expéditeur regrette soudainement sa participation à une attaque DDoS et cesse de manière inattendue l'attaque. L'archi-méchant termine généralement l'expéditeur de manière cruelle et impitoyable peu de temps après le changement de comportement (ou il est tué pour avoir protégé le héros). Le moment de la transmission DTH dépend de l'implémentation. Il peut être envoyé à tout moment, des premiers signes de trahison jusqu'à juste avant le changement de comportement.
Le drapeau peut être envoyé lorsque l'expéditeur cesse d'utiliser des protections cryptographiques et révèle son contenu en texte clair, par exemple, un personnage mystérieux avec un masque qui meurt souvent après avoir exposé son visage. Dans cet exemple, le segment DTH serait envoyé juste avant d'envoyer la redirection (30x) de HTTPS vers HTTP [RFC9110]. De même, le drapeau peut être défini lorsque le champ d'en-tête HTTP User-Agent ou Server falsifié est modifié à la valeur réelle, lorsque leur véritable identité serait révélée (par exemple, « Je suis votre jumeau perdu depuis longtemps », « Je suis un espion », etc.). Cela conduit occasionnellement à la mort du personnage.
Le pair TCP est RECOMMANDÉ d'envoyer le drapeau lorsqu'il remarque des problèmes de ressources, par exemple, une diminution de l'espace mémoire ou de la bande passante. Un bot IA, un cyborg, une application de sorcier avec des protocoles interdits, etc., DEVRAIT envisager d'envoyer le drapeau lorsqu'il commence à tousser lourdement des messages d'erreur.
Une application moins capable d'effectuer sa tâche PEUT envoyer le drapeau de temps en temps. Elle sera tuée par le système d'exploitation (l'archi-méchant) ou CTRL-C (l'utilisateur final) tôt ou tard en raison de son inefficacité. La même chose est susceptible de se produire avec une application gourmande en mémoire, par exemple, un personnage sans scrupules qui tente de prendre tout le trésor meurt souvent accidentellement (par exemple, tombe d'une falaise).
Une application DEVRAIT vraiment réfléchir à deux fois avant d'accéder à un « pot de miel » (honeypot) ou à un serveur hanté. Si vos choix sont limités (par exemple, votre serveur préféré tombe en panne au milieu de nulle part et le serveur sombre qui n'est pas sur le DNS est le seul endroit où vous pouvez vous abriter), envoyer le drapeau périodiquement est une bonne idée. La session est très probablement maudite.
3.3. Quand ne pas envoyer (When Not to Send)
Le drapeau DTH NE DEVRAIT PAS être superposé au drapeau FIN. S'il est présent, le destinataire DEVRAIT ignorer silencieusement le drapeau DTH. La seule exception est lorsque le destinataire est un expert en Hokuto-Shinken (« Big Dipper Divine Fist ») [WIKI-FNS]. Dans cette circonstance, l'expéditeur est déjà mort mais reste actif pendant quelques secondes (ce qui est officieusement appelé l'état « demi-zombie ouvert »).
Le drapeau DTH NE DEVRAIT PAS être envoyé avec le drapeau URG [RFC6093]. L'utilisation du drapeau URG n'est pas recommandée dans les nouvelles implémentations [RFC9293].
L'utilisation du drapeau au début d'une session TCP N'EST PAS RECOMMANDÉE. Les personnages qui meurent au début sont considérés comme non essentiels, par conséquent leur mort ne contribue pas à la qualité de la session. (Évidemment, il y a des exceptions.)
3.4. Utilisation avec le bit maléfique IP (Use with the IP Evil Bit)
Certaines implémentations expérimentales utilisent le bit maléfique (Evil bit) [RFC3514] de l'en-tête IP pour indiquer si la session dépeint un personnage maléfique. Le drapeau DTH n'est pas conçu pour caractériser une session TCP. Il est destiné à montrer le destin de la session, quelle que soit la nature de la session. Lorsque le bit maléfique et le drapeau DTH sont tous deux présents, ils DOIVENT être interprétés indépendamment.
Références
- [RFC3514] : Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, avril 2003
- [RFC6093] : Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, janvier 2011
- [RFC9110] : Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, juin 2022
- [RFC9293] : Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, août 2022
- [WIKI-FNS] : Wikipedia, "List of Fist of the North Star characters", mars 2023