TCP / IP impedisce la riproduzione dei pacchetti?

Question

TCP / IP impedisce a più copie dello stesso pacchetto di raggiungere la destinazione? Oppure dipende dall'endpoint sovrapporre la logica dell'idempotenza sopra di essa?

Se possibile, fare riferimento a paragrafi specifici dalle specifiche TCP / IP.

Answer 1

È compito dello stack TCP recuperare da pacchetti duplicati:

  

Il TCP deve recuperare dai dati   danneggiato, perso, duplicato o       consegnato fuori servizio dal sistema di comunicazione Internet. Questo       si ottiene assegnando un numero progressivo a ciascun ottetto       trasmesso e che richiede un riconoscimento positivo (ACK) dal       ricezione TCP. Se l'ACK non viene ricevuto entro un timeout       intervallo, i dati vengono ritrasmessi. Al ricevitore, il   sequenza       i numeri vengono utilizzati per ordinare correttamente i segmenti che possono essere ricevuti       fuori servizio e per eliminare i duplicati. Il danno è gestito da       aggiungendo un checksum a ciascun segmento trasmesso, verificandolo su       ricevitore e scartare segmenti danneggiati.

- RFC 793 - Protocollo di controllo della trasmissione, Sezione 1.5

Tuttavia, se sono gli stessi pacchetti con nuovi numeri di sequenza, allora no.

Answer 2

TCP utilizza i numeri di sequenza per rilevare la duplicazione in caso di ritrasmissione, che impedirà anche attacchi di replay banali.

Da RFC 793, Sezione 3.3 - Numeri di sequenza:

  

Una nozione fondamentale nel design   è che ogni ottetto di dati inviati   su una connessione TCP ha una sequenza   numero. Dal momento che ogni ottetto è   in sequenza, ciascuno di essi può essere   riconosciuto. Il riconoscimento   il meccanismo impiegato è cumulativo quindi   che un riconoscimento di sequenza   il numero X indica che tutti gli ottetti sono in alto   ma non includendo X sono stati   ricevuto. Questo meccanismo consente   rilevamento diretto dei duplicati   in presenza di ritrasmissione.   Numerazione degli ottetti all'interno di un segmento   è quel primo ottetto di dati   immediatamente dopo l'intestazione è   il numero più basso e il seguente   gli ottetti sono numerati consecutivamente.

Il rilevamento duplicato garantirà che lo stesso pacchetto non possa essere banalmente ritrasmesso. I numeri di sequenza garantiranno inoltre che si noterà l'inserimento (anziché la sostituzione) di dati nel flusso di dati, poiché ulteriori pacchetti legittimi a seguito di pacchetti contraffatti avranno numeri di sequenza duplicati, che interromperanno il flusso di dati. Ciò probabilmente farà sì che quei pacchetti vengano eliminati come duplicati, il che probabilmente interromperà il protocollo in uso.

Ulteriori informazioni sulla specifica TCP / IP originale (1981) sono disponibili in RFC 793 e le molte altre RFC che coinvolgono estensioni o modifiche al protocollo TCP / IP.

Answer 3

Sì, il livello TCP impedisce pacchetti duplicati. Il livello IP sottostante non lo fa.

Dettagli in RFC 1122 .

Answer 4

Sembri preoccupato per due cose diverse:

1. Quali garanzie fornisce la consegna affidabile TCP
2. Un utente malintenzionato può influire sul processo del mio server con un attacco di riproduzione

Rispondi a 1:

TCP garantisce la consegna affidabile e in ordine di una sequenza di byte. Qualunque sia il dato che l'applicazione client invia a TCP tramite write () uscirà esattamente lo stesso durante la chiamata read () del server.

Rispondi a 2:

Gli attacchi di riproduzione non funzionano bene con TCP, poiché ogni connessione dipende da due numeri casuali a 32 bit generati rispettivamente dal client e dal server. Affinché un attacco di replay funzioni, l'attaccante deve indovinare il numero di sequenza generato dal server per la falsa connessione che sta iniziando (teoricamente, l'attaccante ha una probabilità 1/232 ** di indovinare correttamente). Se l'attaccante indovina in modo errato, nel peggiore dei casi causerà un buffering dei dati nel tuo sistema operativo.

Nota che solo perché un attacco di replay non funziona, nulla impedisce a un utente malintenzionato di stabilire una connessione legittima con il tuo server e di trasmettere qualunque flusso di dati desideri alla tua applicazione. Questo è il motivo per cui è importante convalidare sempre l'input .

Answer 5

I livelli sotto TCP possono presentare più pacchetti o pacchetti rilasciati. I livelli sopra TCP non presentano ripetizioni o pacchetti rilasciati.

Answer 6

Non conosco la ripetizione dei pacchetti, ma non l'ho mai incontrato usando TCP / IP e so che garantisce che tutti i pacchetti arrivano e nell'ordine corretto, quindi non riesco a capire perché non dovrebbe 't.

Answer 7

Dipende molto da come stai ricevendo i tuoi dati - anche se tecnicamente il protocollo non dovrebbe fornirti duplicati (cioè pacchetti con lo stesso checksum tcp), altri fattori potrebbero farti vedere duplicati - ad esempio, l'hardware di rete che stai utilizzando; anche se stai usando gli sniffer per guardare i flussi tcp, piuttosto che leggere un socket aperto nella tua applicazione, è possibile ottenere pacchetti duplici dagli sniffer anche se i flussi tcp reali che stavano monitorando non avevano pacchetti dup.

Per fare un esempio del mondo reale - Al momento sto lavorando ad alcune analisi tcp delle reti interne per un'importante borsa valori, ei dati che sto guardando provengono da più sniffer e vengono ricuciti insieme. Quindi, inserendo i dati, ho scoperto che devo eseguire una serie di passaggi di pre-elaborazione, tra cui la ricerca e la rimozione di duplicati. Ad esempio, in uno stream che ho appena letto, di circa 60.000 pacchetti di dati, ho individuato e rimosso 95 pacchetti duplicati.

La strategia che prendo qui è di mantenere una finestra mobile dei 10 checksum tcp più recenti e di ignorare i pacchetti che corrispondono a quei checksum. Nota che funziona bene per i pacchetti PSH, ma non così bene per i pacchetti ACK, ma sono comunque meno preoccupato per questi.

Ho scritto una raccolta speciale allo scopo di tracciare questa finestra mobile di checksum tcp, che potrebbe essere utile per gli altri:

/// <summary>
/// Combination of a double-linked-list and a hashset with a max bound; 
/// Works like a bounded queue where new incoming items force old items to be dequeued; 
/// Re-uses item containers to avoid GC'ing;
/// Public Add() and Contains() methods are fully thread safe through a ReaderWriterLockSlim;
/// </summary>
public class BoundedHashQueue<T>
{
    private readonly int _maxSize = 100;
    private readonly HashSet<T> _hashSet = new HashSet<T>();
    private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
    private readonly Item _head;
    private readonly Item _tail;
    private int _currentCount = 0;

    public BoundedHashQueue(int maxSize)
    {
        _maxSize = maxSize;
        _head = _tail = new Item();
    }

    private class Item
    {
        internal T Value;
        internal Item Next;
        internal Item Previous;
    }

    public void Add(T value)
    {
        _lock.Write(() =>
            {
                if (_currentCount == 0)
                {
                    Item item = new Item();
                    item.Value = value;
                    _head.Next = item;
                    item.Previous = _head;
                    item.Next = _tail;
                    _tail.Previous = item;
                    _currentCount++;
                }
                else
                {
                    Item item;
                    if (_currentCount >= _maxSize)
                    {
                        item = _tail.Previous;
                        _tail.Previous = item.Previous;
                        _tail.Previous.Next = _tail;
                        _hashSet.Remove(item.Value);
                    }
                    else
                    {
                        item = new Item();
                        _currentCount++;
                    }
                    item.Value = value;
                    item.Next = _head.Next;
                    item.Next.Previous = item;
                    item.Previous = _head;
                    _head.Next = item;
                    _hashSet.Add(value);
                }
            });
    }

    public bool Contains(T value)
    {
        return _lock.Read(() => _hashSet.Contains(value));
    }
}}

Answer 8

Non capisci completamente il problema. Vedi questo link: http://en.wikipedia.org/wiki/Transmission_Control_Protocol

In questa pagina è scrivere:

" I timestamp TCP, definiti in RFC 1323, aiutano TCP a calcolare il tempo di andata e ritorno tra il mittente e il destinatario. Le opzioni di data / ora includono un valore di data / ora a 4 byte, in cui il mittente inserisce il valore corrente del suo orologio di data e ora, e un valore di data / ora di risposta dell'eco a 4 byte, in cui il ricevitore inserisce generalmente il valore di data / ora più recente che ha ricevuto. Il mittente utilizza il timestamp di risposta dell'eco in un riconoscimento per calcolare il tempo totale trascorso dall'invio del segmento riconosciuto. [2]

I timestamp TCP sono anche usati per aiutare nel caso in cui i numeri di sequenza TCP incontrino il loro limite di 2 ^ 32 e "circolino". lo spazio numerico della sequenza. Questo schema è noto come numeri di Protect Against Wrapped Sequence o PAWS (vedi RFC 1323 per i dettagli). & Quot;

Saluti, Joint (Polonia)