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