Il protocollo TCP è stato progettato per supportare connessioni end-to-end, ovvero la comunicazione diretta tra due host. Certo, tra di essi erano presenti bridge e router, ma questi dispositivi non modificavano l'intestazione TCP né il payload. Oggi, però, le cose sono cambiate. Ora abbiamo dispositivi come traduttori di indirizzi di rete, firewall, sistemi di prevenzione delle intrusioni e acceleratori di rete. Tutti questi dispositivi possono modificare l'intestazione TCP, inviare conferme o reset o semplicemente eliminare il pacchetto nel bit bucket. A peggiorare le cose, questi dispositivi si trovano alle due estremità della rete e talvolta anche nel mezzo.
Immaginiamo il caso di un host A sulla rete B con una connessione all'host Y sulla rete Z. Davanti alla rete B c'è un acceleratore WAN che aumenta il throughput falsificando i riconoscimenti dall'host Y. Ciò consente all'host A di inviare dati alla massima velocità possibile. L'acceleratore si occuperà di tutto il buffering e delle ritrasmissioni. Sfortunatamente, il sistema di prevenzione delle intrusioni davanti alla rete Z sta eliminando un pacchetto innocente ma dall'aspetto sospetto proveniente dall'host A. L'host Y non lo vede mai, quindi non lo riconosce. L'acceleratore WAN davanti alla rete B lo ritrasmette, ma ovviamente il pacchetto viene nuovamente eliminato. L'acceleratore alla fine va in timeout e invia un reset all'host A e all'host Y.
Cosa vede l'amministratore di sistema dell'host A quando cerca di capire cosa sta succedendo dopo che un utente ha segnalato un problema? Vede che i pacchetti in uscita dall'host A vengono riconosciuti dall'host Y, ma non riceve alcuna risposta a livello di applicazione dall'host Y, che quindi resetta la connessione senza che vi sia alcun indicatore di un problema o del motivo per cui l'host Y ha resettato la connessione. Cosa vede l'amministratore di sistema dell'host Y? Vede che l'host A ha semplicemente smesso di inviare pacchetti e poi ha inviato un ripristino, ancora una volta senza alcun indizio che indichi un problema o il motivo per cui l'host A ha ripristinato la connessione.
L'ipotesi che l'host A stia comunicando direttamente con l'host Y è errata e porta ciascun amministratore ad attribuire la responsabilità del fallimento della connessione all'altro sistema.
Per capire cosa sta succedendo, è necessario prestare attenzione ai valori dei campi "non interessanti" nei dati di tracciamento dell'intestazione IP, campi come "Tipo di servizio", ID, Flag e "Time to Live" (TTL). Le modifiche in questi campi, ad esempio i pacchetti con dati hanno un TTL di 47 e i pacchetti senza dati hanno un TTL di 127, possono indicare che i pacchetti provengono da due fonti diverse.
Il confronto delle tracce provenienti dall'host A e dall'host Y può mettere in luce il problema. Non solo è possibile vedere i pacchetti presenti in una traccia che non sono presenti nell'altra, ma anche le modifiche in tutti quei campi dell'intestazione IP non interessanti o nella porta TCP o nei numeri di sequenza indicheranno con certezza al 100% che questi host non stanno comunicando direttamente tra loro.
Potrebbe non essere possibile disattivare l'acceleratore di rete o il sistema di prevenzione delle intrusioni (e potrebbe anche non essere una buona idea), ma sapere che sono presenti e conoscere il loro funzionamento offre maggiori possibilità di comprendere e correggere i problemi quando si verificano.