A3. Handling Loss of Synchronization due to Significant Packet Loss (Gestione della perdita di sincronizzazione dovuta a significativa perdita di pacchetti)

A3. Handling Loss of Synchronization due to Significant Packet Loss (Gestione della perdita di sincronizzazione dovuta a significativa perdita di pacchetti)

Se si verifica una perdita non rilevata di 2^32 o più pacchetti consecutivi su una singola SA, allora il trasmettitore e il ricevitore perderanno la sincronizzazione dei bit di ordine superiore, ovvero le equazioni nella Sezione A2.2. non riusciranno a produrre il valore corretto. A meno che questo problema non venga rilevato e risolto, i pacchetti successivi su questa SA falliranno i controlli di autenticazione e verranno scartati. La seguente procedura DOVREBBE essere implementata da qualsiasi implementazione IPsec (ESP o AH) che supporta l'opzione ESN.

Si noti che questo tipo di perdita di traffico estesa è probabile che venga rilevata a livelli superiori nella maggior parte dei casi, prima che IPsec debba invocare il tipo di meccanismo di ri-sincronizzazione descritto in A3.1 e A3.2. Se una frazione significativa del traffico sulla SA in questione è TCP, la sorgente non riuscirebbe a ricevere gli ACK e smetterebbe di inviare molto prima che 2^32 pacchetti fossero stati persi. Inoltre, per qualsiasi applicazione bidirezionale, anche quelle che operano sopra UDP, tale interruzione prolungata probabilmente risulterebbe nell'attivazione di una qualche forma di timeout. Tuttavia, un'applicazione unidirezionale, che opera su UDP, potrebbe mancare di feedback che causerebbe il rilevamento automatico di una perdita di questa entità, da cui la motivazione per sviluppare un metodo di recupero per questo caso. Si noti che le osservazioni di cui sopra si applicano alle SA tra gateway di sicurezza, o tra host, o tra host e gateway di sicurezza.

La soluzione che abbiamo scelto è stata selezionata per:

• minimizzare l'impatto sull'elaborazione normale del traffico

• evitare di creare un'opportunità per un nuovo attacco di denial of service come potrebbe verificarsi consentendo a un attaccante di forzare la deviazione di risorse verso un processo di ri-sincronizzazione

• limitare il meccanismo di recupero al ricevitore -- poiché l'anti-replay è un servizio solo per il ricevitore, e il trasmettitore generalmente non è a conoscenza se il ricevitore stia utilizzando numeri di sequenza a supporto di questo servizio opzionale, è preferibile che i meccanismi di recupero siano locali al ricevitore. Questo consente anche la compatibilità all'indietro.