B3. Handling Loss of Synchronization

Se si verifica una perdita di pacchetti 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, cioè le equazioni nell'Appendice B2.2. non riusciranno a produrre il valore corretto. A meno che questo problema non venga rilevato e affrontato, 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 supporti l'opzione ESN.

Si noti che questo tipo di perdita di traffico estesa sembra improbabile che si verifichi se una frazione significativa del traffico sulla SA in questione è TCP, perché la sorgente non riuscirebbe a ricevere 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, un'interruzione così estesa probabilmente risulterebbe nell'attivazione di 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.

La soluzione che abbiamo scelto è stata selezionata per:

• minimizzare l'impatto sull'elaborazione del traffico normale.
• evitare di creare un'opportunità per un nuovo attacco 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 perché l'anti-replay è un servizio solo per il ricevitore, e il trasmettitore generalmente non è consapevole se il ricevitore sta utilizzando i numeri di sequenza a supporto di questo servizio opzionale. È preferibile che i meccanismi di recupero siano locali al ricevitore. Ciò consente anche la compatibilità con le versioni precedenti.

B3.1. Triggering Re-synchronization

Per ogni SA, il ricevitore registra il numero di pacchetti consecutivi che falliscono l'autenticazione. Questo conteggio viene utilizzato per attivare il processo di ri-sincronizzazione, che dovrebbe essere eseguito in background o utilizzando un processore separato. La ricezione di un pacchetto valido sulla SA reimposta il contatore a zero. Il valore utilizzato per attivare il processo di ri-sincronizzazione è un parametro locale. Non vi è alcun requisito di supportare valori di trigger distinti per diverse SA, sebbene un implementatore possa scegliere di farlo.

B3.2. Re-synchronization Process

Quando viene raggiunto il punto di trigger sopra indicato, viene selezionato un pacchetto "cattivo" per il quale l'autenticazione viene ritentata utilizzando valori successivamente più grandi per la metà superiore del numero di sequenza (Seqh). Questi valori vengono generati incrementando di uno per ogni tentativo. Il numero di tentativi dovrebbe essere limitato, nel caso in cui questo sia un pacchetto del "passato" o un pacchetto fasullo. Il valore limite è un parametro locale. (Poiché il valore Seqh è implicitamente posizionato dopo il payload AH (o ESP), potrebbe essere possibile ottimizzare questa procedura eseguendo l'algoritmo di integrità sul pacchetto fino all'endpoint del payload, quindi calcolare diversi ICV candidati variando il valore di Seqh.) L'autenticazione riuscita di un pacchetto tramite questa procedura reimposta il conteggio dei fallimenti consecutivi e imposta il valore di T su quello del pacchetto ricevuto.

Questa soluzione richiede supporto solo da parte del ricevitore, consentendo così la compatibilità con le versioni precedenti. Inoltre, poiché gli sforzi di ri-sincronizzazione si verificherebbero in background o utilizzerebbero un processore aggiuntivo, questa soluzione non ha impatto sull'elaborazione del traffico e un attacco denial of service non può deviare risorse dall'elaborazione del traffico.