Passa al contenuto principale

RFC 9401 - L'aggiunta del flag di morte (DTH) a TCP

  • Stato: Informational
  • Pubblicato: April 2023
  • Stream: INDEPENDENT
  • Errata: Nessun errata

Sommario (Abstract)​

Questo memo specifica l'incorporazione del flag di morte (Death, DTH) in TCP, incluso l'uso di un bit nell'header TCP da parte di DTH. Il flag è progettato per rendere le narrazioni di sessione TCP fluide e attraenti.

Stato di questo memo (Status of This Memo)​

Questo documento non è una specifica Internet Standards Track; è pubblicato a scopo informativo.

Questo è un contributo alla serie RFC, indipendentemente da qualsiasi altro flusso RFC. L'RFC Editor ha scelto di pubblicare questo documento a sua discrezione e non fa alcuna dichiarazione sul suo valore per l'implementazione o il deployment. I documenti approvati per la pubblicazione dall'RFC Editor non sono candidati per alcun livello di Standard Internet; vedere la Sezione 2 di RFC 7841.

Le informazioni sullo stato attuale di questo documento, eventuali errata e come fornire feedback possono essere ottenute presso https://www.rfc-editor.org/info/rfc9401.

Copyright (c) 2023 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

Questo documento è soggetto a BCP 78 e alle Disposizioni Legali dell'IETF Trust relative ai Documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i vostri diritti e le restrizioni rispetto a questo documento.

Sommario (Contents)​

Nota importante​

Questa RFC è pubblicata sul flusso di sottomissione indipendente (Independent Submission stream). Questa RFC non è approvata dall'IETF e non ha posizione formale nel processo di standardizzazione IETF.

Nota: Questo documento è un RFC del pesce d'aprile pubblicato il 1° aprile 2023, con contenuti umoristici che fanno riferimento ai concetti di "flag di morte" (Death Flag) da anime, manga e light novel.

1. Introduzione (Introduction)​

Il flag di morte proposto, o DTH in breve, utilizza il quarto bit di flag nell'header TCP per indicare la probabile terminazione della sessione TCP.

Il flag consente alle applicazioni di prepararsi per terminazioni di sessione brusche. Gli ingegneri di rete trovano questa funzionalità utile per identificare una o più cause radice dei RST TCP. Gli utenti finali critici possono utilizzare queste informazioni per comprendere meglio le narrazioni TCP.

Il nome del flag è adattato dalla consuetudine di anime, manga o light novel [NOVEL]. I "flag di morte" (Death Flags) si riferiscono a indizi che un personaggio morirà presto [CBR-FLAG].

Ad esempio, il flag DTH di uno scienziato malvagio viene impostato quando esprime troppa fiducia nella sua invenzione mortale. Lo scienziato viene spesso ucciso dalla propria invenzione. Questo tipo di narrativa è comune anche nei film convenzionali. Un esempio notevole è un soldato in una trincea. Il flag del soldato viene impostato su 1 immediatamente dopo che condivide una fotografia della sua fidanzata e racconta del matrimonio imminente che avrà luogo dopo il ritorno dalla battaglia. Un altro esempio è l'impostazione del flag per una coppia che sgattaiola fuori da una cabina isolata per un'escursione notturna. Comunemente, l'escursione viene terminata violentemente da un individuo con una motosega.

Riferimenti​

2. Linguaggio dei requisiti (Requirements Language)​

Le parole chiave "MUST" (DEVE), "MUST NOT" (NON DEVE), "REQUIRED" (RICHIESTO), "SHALL" (DOVRÀ), "SHALL NOT" (NON DOVRÀ), "SHOULD" (DOVREBBE), "SHOULD NOT" (NON DOVREBBE), "RECOMMENDED" (RACCOMANDATO), "NOT RECOMMENDED" (NON RACCOMANDATO), "MAY" (PUÒ) e "OPTIONAL" (OPZIONALE) in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

Riferimenti​

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

3. Specifica (Specification)​

3.1. Formato del pacchetto TCP (TCP Packet Format)​

Il flag DTH utilizza il quarto bit nel campo dei bit di controllo nell'header TCP come illustrato nella Figura 1 [RFC9293]. Il quarto bit è stato selezionato intenzionalmente perché "quattro" in cinese è Sì; ha un suono simile a Sǐ, che significa "morire".

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

Nota: un segno di spunta rappresenta una posizione di bit.

Figura 1: Header TCP con il bit del flag DTH

Un peer di sessione TCP DOVREBBE trasmettere un segmento DTH quando la sessione TCP probabilmente terminerà presto. Può essere inviato sia dal server che dal client. L'applicazione o lo stack TCP PUÒ scegliere di non inviare segmenti DTH, anche se sa che la sessione verrà terminata. Ciò comporta una sorpresa drammatica per il peer; tuttavia, gli utenti finali potrebbero percepire la fine troppo conveniente o eccessivamente semplicistica. L'uso del segmento DTH che non è associato alla terminazione della sessione non è incoraggiato ma è consentito. (Questo è spesso definito "presa in giro" o flag DTH falso positivo.)

Il flag DTH è informativo. Il software TCP che non implementa questa funzionalità può ignorare questo flag in sicurezza. Tuttavia, per apprezzare pienamente la sessione, gli utenti dovrebbero essere consapevoli dei segni sottili delle narrazioni di sessione.

Il flag DTH stesso non cambia il numero di sequenza o di riconoscimento. Non richiede alcun riconoscimento.

Il destinatario del flag non è tenuto ad agire diversamente al ricevimento; tuttavia, è RACCOMANDATO che le informazioni vengano trasmesse al livello applicativo, in modo che l'utente finale possa essere notificato dell'incidente. Il destinatario di un segmento DTH NON DOVREBBE chiudere il socket immediatamente al ricevimento; DOVREBBE attendere un segmento RST o FIN.

Questa specifica non stabilisce il numero massimo di segmenti DTH consentiti in una sessione TCP; tuttavia, limitarli a pochi è RACCOMANDATO per massimizzare l'effetto drammatico.

3.2. Quando inviare (When to Send)​

DTH può essere utilizzato ogni volta che il mittente ritiene importante segnalare la sua fine inevitabile al peer TCP. Gli scenari di esempio qui sotto illustrano quando inviare segmenti DTH.

Un attore malevolo può inviare il flag quando si pente improvvisamente; ad esempio, quando un mittente si pente improvvisamente della sua partecipazione a un attacco DDoS e interrompe inaspettatamente l'attacco. Il grande cattivo generalmente termina il mittente in modo crudele e spietato poco dopo il cambio di comportamento (o viene ucciso per aver protetto l'eroe). Il momento della trasmissione DTH dipende dall'implementazione. Può essere inviato in qualsiasi momento dai primi segni di tradimento fino a poco prima del cambio comportamentale.

Il flag può essere inviato quando il mittente smette di utilizzare protezioni crittografiche e rivela il suo contenuto in chiaro, ad esempio un personaggio misterioso con una maschera che spesso muore dopo aver esposto il suo volto. In questo esempio, il segmento DTH verrebbe inviato appena prima di inviare il reindirizzamento (30x) da HTTPS a HTTP [RFC9110]. Analogamente, il flag può essere impostato quando il campo di intestazione HTTP User-Agent o Server contraffatto viene modificato al valore effettivo, quando la loro vera identità verrebbe rivelata (ad esempio, "Sono il tuo gemello perduto da tempo", "Sono una spia", ecc.). Ciò porta occasionalmente alla morte del personaggio.

Al peer TCP è RACCOMANDATO di inviare il flag quando nota problemi di risorse, ad esempio diminuzione dello spazio di memoria o della larghezza di banda. Un bot AI, cyborg, applicazione stregone con protocolli proibiti, ecc., DOVREBBE considerare di inviare il flag quando inizia a tossire pesantemente messaggi di errore.

Un'applicazione meno capace di svolgere il suo compito PUÒ inviare il flag di tanto in tanto. Verrà uccisa dal sistema operativo (il grande cattivo) o CTRL-C (l'utente finale) prima o poi a causa della sua inefficienza. Lo stesso è probabile che accada con un'applicazione che consuma molta memoria, ad esempio un personaggio senza scrupoli che tenta di prendere tutto il tesoro spesso muore accidentalmente (ad es. cade da un precipizio).

Un'applicazione DOVREBBE davvero pensarci due volte prima di accedere a un "honeypot" o server infestato. Se le tue scelte sono limitate (ad es. il tuo server preferito si guasta in mezzo al nulla e il server oscuro che non è nel DNS è l'unico posto dove puoi rifugiarti), inviare periodicamente il flag è una buona idea. La sessione è molto probabilmente maledetta.

3.3. Quando non inviare (When Not to Send)​

Il flag DTH NON DOVREBBE essere trasportato sul flag FIN. Se presente, il destinatario DOVREBBE ignorare silenziosamente il flag DTH. L'unica eccezione è quando il destinatario è un esperto di Hokuto-Shinken ("Big Dipper Divine Fist") [WIKI-FNS]. In quella circostanza, il mittente è già morto ma rimane attivo per alcuni secondi (che è ufficiosamente chiamato lo stato "mezzo-zombie aperto").

Il flag DTH NON DOVREBBE essere inviato con il flag URG [RFC6093]. L'uso del flag URG non è raccomandato nelle nuove implementazioni [RFC9293].

L'uso del flag nella fase iniziale di una sessione TCP NON È RACCOMANDATO. I personaggi che muoiono nella fase iniziale sono considerati non essenziali, quindi la loro morte non contribuisce alla qualità della sessione. (Ovviamente, ci sono eccezioni.)

3.4. Uso con l'IP Evil Bit​

Alcune implementazioni sperimentali utilizzano l'Evil bit [RFC3514] dell'header IP per indicare se la sessione ritrae un personaggio malvagio. Il flag DTH non è progettato per caratterizzare una sessione TCP. È destinato a mostrare il destino della sessione indipendentemente dalla natura della sessione. Quando sia l'Evil bit che il flag DTH sono presenti, DEVONO essere interpretati indipendentemente.

Riferimenti​

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

4. Considerazioni sulla sicurezza (Security Considerations)​

I precursori della morte inevitabile (spesso violenta) di una sessione TCP sono utili per le applicazioni di livello superiore e gli utenti finali; tuttavia, dovrebbe essere considerato anche l'equilibrio tra sicurezza e usabilità. Poiché i flag DTH possono esporre lo stato interno della sessione TCP, possono essere sfruttati dagli aggressori (ad es. nominare l'assassino prima che il detective indichi il sospetto). Gli spoiler sono un atto di male. Coloro che desiderano mantenere segreta la storia dovrebbero usare il flag con moderazione.

Analisi dei rischi​

  1. Divulgazione di informazioni (Information Disclosure): I flag DTH possono rivelare agli aggressori informazioni sulla terminazione imminente della sessione, che potrebbero essere utilizzate per attacchi temporali o altri scopi malevoli.

  2. Negazione del servizio (Denial of Service): Gli attori malevoli potrebbero abusare dei flag DTH per fuorviare i destinatari, causando allocazione di risorse non necessaria o problemi di gestione della sessione.

  3. Considerazioni sulla privacy (Privacy Considerations): L'uso eccessivo di flag DTH può rivelare modelli di comportamento delle applicazioni, influenzando così la privacy degli utenti.

  4. Effetto spoiler (Spoiler Effect): La conoscenza anticipata della terminazione della sessione può ridurre gli elementi drammatici e di sorpresa dell'esperienza utente.

Raccomandazioni​

  • Gli implementatori dovrebbero utilizzare i flag DTH con cautela, evitando di impostare il flag quando non è necessario.
  • Gli amministratori di rete dovrebbero monitorare i modelli di utilizzo dei flag DTH per identificare potenziali minacce alla sicurezza.
  • Gli sviluppatori di applicazioni dovrebbero considerare le implicazioni di sicurezza dei flag DTH e implementare misure di protezione appropriate.

5. Considerazioni IANA (IANA Considerations)​

Questo documento definisce il comportamento di uno dei bit di controllo attualmente riservati (Reserved, Rsrvd) nell'header TCP. È utilizzato come indicatore informativo del destino di una sessione TCP. Il quarto bit (contando dall'inizio del tredicesimo ottetto in un header TCP) è stato selezionato intenzionalmente per significare il suo significato; tuttavia, un cambiamento nella posizione del bit non causa alcun deterioramento funzionale.

Questa funzionalità potrebbe essere già implementata in modi diversi nelle reti degli studi di animazione di Hollywood e/o giapponesi; tuttavia, per quanto a conoscenza dell'autore, la tecnologia non è ancora brevettata.

Assegnazione del bit di controllo dell'header TCP​

Questa specifica utilizza il quarto bit nel campo dei bit di controllo dell'header TCP, che era precedentemente in uno stato riservato.

Posizione del bit: Bit 4 (contando dall'inizio del campo dei bit di controllo)
Nome del flag: DTH (Death)
Scopo: Flag informativo che indica che la sessione TCP potrebbe terminare presto
Riferimento: Questo documento

Requisiti di registrazione​

Sebbene questo documento definisca l'uso del flag DTH, è pubblicato come RFC informativo e non costituisce una richiesta di modifica formale al registro dei parametri TCP dell'IANA. Gli implementatori che desiderano utilizzare questo flag in ambienti di produzione dovrebbero essere consapevoli della sua natura non standard.

Note di implementazione​

  1. Retrocompatibilità (Backward Compatibility): Le implementazioni TCP che non supportano il flag DTH semplicemente ignoreranno questo bit, poiché viene trattato come un bit riservato.

  2. Interoperabilità (Interoperability): L'uso del flag DTH non dovrebbe influenzare l'interoperabilità con le implementazioni TCP legacy.

  3. Stato del brevetto (Patent Status): Per quanto a conoscenza dell'autore, questa tecnologia non è protetta da brevetto, sebbene Hollywood o gli studi di animazione giapponesi possano aver sviluppato indipendentemente tecniche narrative simili.

6. Riferimenti (References)​

6.1. Riferimenti normativi (Normative References)​

6.2. Riferimenti informativi (Informative References)​

Descrizione dei riferimenti​

Riferimenti normativi (Normative References)​

I riferimenti normativi sono documenti necessari per implementare questa specifica. Questi documenti definiscono gli elementi di protocollo critici e le interpretazioni delle parole chiave richieste per il funzionamento del flag DTH.

Riferimenti informativi (Informative References)​

I riferimenti informativi forniscono informazioni aggiuntive sulle origini concettuali e il contesto pertinente del flag DTH. Questi riferimenti aiutano a comprendere il contesto culturale del concetto di "flag di morte", ma non sono necessari per implementare questa specifica.

Documenti RFC correlati​

  • RFC 793 - Transmission Control Protocol (specifica TCP originale)
  • RFC 9293 - Transmission Control Protocol (aggiornamento TCP più recente)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit, un'altra RFC del pesce d'aprile)
  • RFC 2119 - Key words for use in RFCs (definizioni delle parole chiave RFC)
  • RFC 8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (chiarimento maiuscole/minuscole delle parole chiave RFC 2119)

Indirizzo dell'autore (Author's Address)​

Satoshi Toyosawa
Indipendente (Independent)
Email: [email protected]

Informazioni sull'autore​

Satoshi Toyosawa è un ricercatore indipendente con forte interesse per i protocolli di rete e la documentazione tecnica umoristica. RFC 9401 è il contributo dell'autore alla tradizione delle RFC del pesce d'aprile dell'IETF, applicando creativamente il concetto di "flag di morte" da anime e manga al protocollo TCP.

Informazioni di contatto​

Per domande, suggerimenti o commenti su questa RFC, si prega di contattare l'autore all'indirizzo email sopra indicato.

Ringraziamenti​

Grazie a tutti coloro che hanno fornito feedback e suggerimenti per questo documento. Un ringraziamento speciale a coloro che comprendono e apprezzano l'umorismo all'intersezione di anime, manga e protocolli di rete.

Contesto storico​

Questo documento è stato pubblicato il 1° aprile 2023, continuando la tradizione delle RFC del pesce d'aprile dell'IETF. Questa tradizione è iniziata nel 1978 con RFC 748 e ha prodotto nel corso degli anni molti documenti tecnici creativi e umoristici, tra cui:

  • RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers (trasmissione di datagrammi IP tramite piccioni viaggiatori)
  • RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (protocollo di controllo della caffettiera ipertestuale)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit)
  • RFC 7511 - Scenic Routing for IPv6 (routing panoramico per IPv6)
  • RFC 9401 - The Addition of the Death (DTH) Flag to TCP (questo documento)

Sebbene queste RFC del pesce d'aprile siano di natura umoristica, spesso contengono intuizioni profonde su problemi tecnici reali e dimostrano la creatività e l'umorismo della comunità tecnica.