Aller au contenu principal

RFC 9401 - L'ajout du drapeau de mort (DTH) à TCP

  • Statut: Informational
  • Publié: April 2023
  • Stream: INDEPENDENT
  • Errata: Pas d'errata

Résumé (Abstract)​

Ce mémo spécifie l'incorporation du drapeau de mort (Death, DTH) à TCP, y compris l'utilisation d'un bit par DTH dans l'en-tête TCP. Le drapeau est conçu pour rendre les récits de session TCP fluides et attrayants.

Statut de ce mémo (Status of This Memo)​

Ce document n'est pas une spécification de piste de normes Internet ; il est publié à des fins d'information.

Il s'agit d'une contribution à la série RFC, indépendamment de tout autre flux RFC. L'éditeur RFC a choisi de publier ce document à sa discrétion et ne fait aucune déclaration sur sa valeur pour la mise en œuvre ou le déploiement. Les documents approuvés pour publication par l'éditeur RFC ne sont pas des candidats pour aucun niveau de norme Internet ; voir la section 2 de la RFC 7841.

Les informations sur le statut actuel de ce document, les errata éventuels et la manière de fournir des commentaires peuvent être obtenues à l'adresse https://www.rfc-editor.org/info/rfc9401.

Copyright (c) 2023 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Ce document est soumis au BCP 78 et aux dispositions légales de l'IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner ces documents attentivement, car ils décrivent vos droits et restrictions concernant ce document.

Sommaire (Contents)​

Note importante​

Cette RFC est publiée sur le flux de soumission indépendant (Independent Submission stream). Cette RFC n'est pas approuvée par l'IETF et n'a aucune position formelle dans le processus de normalisation de l'IETF.

Note : Ce document est une RFC du poisson d'avril publiée le 1er avril 2023, avec un contenu humoristique faisant référence aux concepts de « drapeaux de mort » (Death Flag) issus des anime, manga et light novels.

1. Introduction​

Le drapeau de mort proposé, ou DTH en abrégé, utilise le quatrième bit de drapeau dans l'en-tête TCP pour indiquer la terminaison probable de la session TCP.

Le drapeau permet aux applications de se préparer à des terminaisons de session abruptes. Les ingénieurs réseau trouvent cette fonctionnalité utile pour identifier une ou plusieurs causes racines des RST TCP. Les utilisateurs finaux critiques peuvent utiliser ces informations pour mieux comprendre les récits TCP.

Le nom du drapeau est adapté de la coutume des anime, manga ou light novels [NOVEL]. Les « drapeaux de mort » (Death Flags) font référence aux indices qu'un personnage mourra bientôt [CBR-FLAG].

Par exemple, le drapeau DTH d'un scientifique maléfique est défini lorsqu'il exprime trop de confiance dans son invention mortelle. Le scientifique est souvent tué par sa propre invention. Ce type de récit est également courant dans les films conventionnels. Un exemple notable est un soldat dans une tranchée. Le drapeau du soldat est défini sur 1 immédiatement après qu'il partage une photographie de sa fiancée et parle du mariage à venir qui aura lieu après son retour de la bataille. Un autre exemple consiste à définir le drapeau pour un couple s'échappant d'une cabane isolée pour une excursion nocturne. Généralement, l'excursion est violemment terminée par un individu avec une tronçonneuse.

Références​

2. Langage des exigences (Requirements Language)​

Les mots-clés « MUST » (DOIT), « MUST NOT » (NE DOIT PAS), « REQUIRED » (REQUIS), « SHALL » (DEVRA), « SHALL NOT » (NE DEVRA PAS), « SHOULD » (DEVRAIT), « SHOULD NOT » (NE DEVRAIT PAS), « RECOMMENDED » (RECOMMANDÉ), « NOT RECOMMENDED » (NON RECOMMANDÉ), « MAY » (PEUT) et « OPTIONAL » (OPTIONNEL) dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Références​

  • [RFC2119] : Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, mars 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. 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

4. Considérations de sécurité (Security Considerations)​

Les précurseurs de la mort inévitable (souvent violente) d'une session TCP sont utiles pour les applications de couche supérieure et les utilisateurs finaux ; cependant, l'équilibre entre la sécurité et l'utilisabilité doit également être pris en compte. Étant donné que les drapeaux DTH peuvent exposer l'état interne de la session TCP, ils peuvent être exploités par des attaquants (par exemple, nommer le meurtrier avant que le détective ne désigne le suspect). Les spoilers sont un acte de mal. Ceux qui souhaitent garder l'histoire secrète devraient utiliser le drapeau avec modération.

Analyse des risques​

  1. Divulgation d'informations (Information Disclosure) : Les drapeaux DTH peuvent révéler aux attaquants des informations sur la terminaison imminente de la session, ce qui pourrait être utilisé pour des attaques de timing ou d'autres objectifs malveillants.

  2. Déni de service (Denial of Service) : Les acteurs malveillants peuvent abuser des drapeaux DTH pour tromper les destinataires, provoquant une allocation de ressources inutile ou des problèmes de gestion de session.

  3. Considérations de confidentialité (Privacy Considerations) : L'utilisation excessive de drapeaux DTH peut divulguer des modèles de comportement d'application, affectant ainsi la confidentialité des utilisateurs.

  4. Effet spoiler (Spoiler Effect) : La connaissance préalable de la terminaison de la session peut réduire les éléments dramatiques et de surprise de l'expérience utilisateur.

Recommandations​

  • Les implémenteurs doivent utiliser les drapeaux DTH avec prudence, en évitant de définir le drapeau lorsque cela n'est pas nécessaire.
  • Les administrateurs réseau doivent surveiller les modèles d'utilisation des drapeaux DTH pour identifier les menaces de sécurité potentielles.
  • Les développeurs d'applications doivent prendre en compte les implications de sécurité des drapeaux DTH et mettre en œuvre des mesures de protection appropriées.

5. Considérations IANA (IANA Considerations)​

Ce document définit le comportement de l'un des bits de contrôle actuellement réservés (Reserved, Rsrvd) dans l'en-tête TCP. Il est utilisé comme indicateur informatif du destin d'une session TCP. Le quatrième bit (à compter du début du treizième octet dans un en-tête TCP) est intentionnellement sélectionné pour signifier sa signification ; cependant, un changement de position de bit ne provoque aucune détérioration fonctionnelle.

Cette fonctionnalité peut déjà être implémentée de différentes manières dans les réseaux de studios d'animation hollywoodiens et/ou japonais ; cependant, à la connaissance de l'auteur, la technologie n'est pas encore brevetée.

Attribution des bits de contrôle de l'en-tête TCP​

Cette spécification utilise le quatrième bit dans le champ des bits de contrôle de l'en-tête TCP, qui était auparavant dans un état réservé.

Position du bit : Bit 4 (à compter du début du champ des bits de contrôle)
Nom du drapeau : DTH (Death)
Objectif : Drapeau informatif indiquant que la session TCP peut se terminer bientôt
Référence : Ce document

Exigences d'enregistrement​

Bien que ce document définisse l'utilisation du drapeau DTH, il est publié en tant que RFC informatif et ne constitue pas une demande de modification formelle du registre des paramètres TCP de l'IANA. Les implémenteurs souhaitant utiliser ce drapeau dans des environnements de production doivent être conscients de sa nature non standard.

Notes d'implémentation​

  1. Rétrocompatibilité (Backward Compatibility) : Les implémentations TCP qui ne prennent pas en charge le drapeau DTH ignoreront simplement ce bit, car il est traité comme un bit réservé.

  2. Interopérabilité (Interoperability) : L'utilisation du drapeau DTH ne devrait pas affecter l'interopérabilité avec les implémentations TCP héritées.

  3. Statut des brevets (Patent Status) : À la connaissance de l'auteur, cette technologie n'est pas protégée par des brevets, bien que Hollywood ou les studios d'animation japonais aient pu développer indépendamment des techniques narratives similaires.

6. Références (References)​

6.1. Références normatives (Normative References)​

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, mars 1997, <https://www.rfc-editor.org/info/rfc2119>

  • [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, DOI 10.17487/RFC3514, avril 2003, <https://www.rfc-editor.org/info/rfc3514>

  • [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, janvier 2011, <https://www.rfc-editor.org/info/rfc6093>

  • [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, mai 2017, <https://www.rfc-editor.org/info/rfc8174>

  • [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, août 2022, <https://www.rfc-editor.org/info/rfc9293>

6.2. Références informatives (Informative References)​

  • [CBR-FLAG] Stalberg, A., "10 Death Flags That Mean An Anime Character is Probably Going To Die", 2023, <https://www.cbr.com/anime-death-hints-signs/>

  • [NOVEL] Wikipedia, "Light novel", février 2023, <https://en.wikipedia.org/w/index.php?title=Light_novel&oldid=1136814877>

  • [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, juin 2022, <https://www.rfc-editor.org/info/rfc9110>

  • [WIKI-FNS] Wikipedia, "List of Fist of the North Star characters", mars 2023, <https://en.wikipedia.org/w/index.php?title=List_of_Fist_of_the_North_Star_characters&oldid=1145633265>

Description des références​

Références normatives (Normative References)​

Les références normatives sont des documents nécessaires pour implémenter cette spécification. Ces documents définissent les éléments de protocole critiques et les interprétations de mots-clés requis pour le fonctionnement du drapeau DTH.

Références informatives (Informative References)​

Les références informatives fournissent des informations supplémentaires sur les origines conceptuelles et le contexte pertinent du drapeau DTH. Ces références aident à comprendre le contexte culturel du concept de « drapeau de mort », mais ne sont pas nécessaires pour implémenter cette spécification.

Documents RFC connexes​

  • RFC 793 - Transmission Control Protocol (spécification TCP originale)
  • RFC 9293 - Transmission Control Protocol (mise à jour TCP la plus récente)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit, une autre RFC du poisson d'avril)
  • RFC 2119 - Key words for use in RFCs (définitions des mots-clés RFC)
  • RFC 8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (clarification de la casse des mots-clés RFC 2119)

Adresse de l'auteur (Author's Address)​

Satoshi Toyosawa
Indépendant (Independent)
E-mail (Email) : [email protected]

À propos de l'auteur​

Satoshi Toyosawa est un chercheur indépendant avec un vif intérêt pour les protocoles réseau et la documentation technique humoristique. RFC 9401 est la contribution de l'auteur à la tradition des RFC du poisson d'avril de l'IETF, appliquant de manière créative le concept de « drapeau de mort » des anime et manga au protocole TCP.

Coordonnées​

Pour toute question, suggestion ou commentaire concernant cette RFC, veuillez contacter l'auteur à l'adresse e-mail ci-dessus.

Remerciements​

Merci à tous ceux qui ont fourni des commentaires et des suggestions pour ce document. Un merci particulier à ceux qui comprennent et apprécient l'humour à l'intersection des anime, des manga et des protocoles réseau.

Contexte historique​

Ce document a été publié le 1er avril 2023, poursuivant la tradition des RFC du poisson d'avril de l'IETF. Cette tradition a commencé en 1978 avec la RFC 748 et a produit au fil des ans de nombreux documents techniques créatifs et humoristiques, notamment :

  • RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers (transmission de datagrammes IP par pigeons voyageurs)
  • RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (protocole de contrôle de cafetière hypertexte)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit)
  • RFC 7511 - Scenic Routing for IPv6 (routage panoramique pour IPv6)
  • RFC 9401 - The Addition of the Death (DTH) Flag to TCP (ce document)

Bien que ces RFC du poisson d'avril soient de nature humoristique, elles contiennent souvent des aperçus profonds sur de véritables problèmes techniques et démontrent la créativité et le sens de l'humour de la communauté technique.