2.21. Error Handling (Gestione degli errori)

Durante l'elaborazione IKE possono verificarsi molti tipi di errore. Regola generale: se una richiesta è malformata o inaccettabile per policy (nessun algoritmo compatibile), la risposta contiene un payload Notify di errore. Inviare o meno dipende dall'esistenza di un'IKE SA autenticata.

In caso di errore nell'analisi o nell'elaborazione di un pacchetto di risposta, in genere non si invia errore in quanto le risposte non devono generare nuove richieste. Tali errori devono comunque indurre il destinatario a ripulire lo stato IKE (es. Delete per SA errata).

Solo fallimenti di autenticazione (AUTHENTICATION_FAILED ed errore EAP) e messaggi malformati (INVALID_SYNTAX) causano eliminazione dell'IKE SA senza scambio INFORMATIONAL esplicito con Delete. Altri errori POSSONO richiedere tale scambio se la policy lo impone. Con terminazione EAP Failure non si invia AUTHENTICATION_FAILED.

2.21.1. Error Handling in IKE_SA_INIT

Gli errori prima di un'IKE SA protetta crittograficamente richiedono cautela. Bilanciamento tra aiutare il peer a diagnosticare ed evitare DoS con messaggi falsi.

In IKE_SA_INIT ogni notifica di errore fa fallire lo scambio. Alcune (COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION) possono portare a uno scambio successivo riuscito. Tutte le notifiche sono non autenticate; il destinatario dovrebbe continuare a tentare per un po' prima di arrendersi. Non agire subito sulla notifica salvo azioni correttive definite qui.

2.21.2. Error Handling in IKE_AUTH

Tutti gli errori in IKE_AUTH che fanno fallire l'autenticazione (segreto condiviso non valido, ID non valido, emittente certificato non attendibile, certificato revocato/scaduto, ecc.) DOVREBBERO produrre AUTHENTICATION_FAILED. Se l'errore è sul rispondente, la notifica è nella risposta protetta, spesso unica payload. Anche cifrata, il peer che non ha ancora autenticato l'altro deve essere cauto.

Se l'errore è sull'iniziatore, la notifica PUÒ essere in uno scambio INFORMATIONAL separato, spesso senza altri payload. Eccezione alla regola di non avviare scambi per errori nelle risposte.

Richieste con payload critico non supportato o messaggio interamente malformato DEVONO essere rifiutate per intero e DEVONO produrre solo UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX. Non verificare in tal caso i payload di autenticazione.

Se l'autenticazione IKE_AUTH è riuscita, l'IKE SA è stabilita; la Child SA o la configurazione possono ancora fallire. Ciò non elimina automaticamente l'IKE SA. Il rispondente può includere IDr, CERT, AUTH con notifiche di errore per scambi accoppiati (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, ecc.); l'iniziatore NON DEVE considerare fallita l'autenticazione per questo.

In IKE_AUTH o nell'INFORMATIONAL immediatamente successivo, solo UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX e AUTHENTICATION_FAILED eliminano o impediscono l'IKE SA senza Delete. I documenti di estensione POSSONO definire altre notifiche con la stessa semantica ma NON DEVONO usarle senza prova che il peer le capisca (es. Vendor ID).

2.21.3. Error Handling after IKE SA is Authenticated

Dopo autenticazione IKE SA, ogni richiesta con errori DEVE produrre una risposta che notifichi l'estremità opposta.

Normalmente una risposta valida non dovrebbe creare errore nell'altro peer; non si dovrebbero inviare messaggi di erroro come INFORMATIONAL non di risposta (rischio loop). Errori di stato incoerente possono giustificare eliminazione dell'IKE SA.

Se un peer che analizza una richiesta la trova malformata (dopo MAC e controlli finestra) e restituisce INVALID_SYNTAX, tale notifica è fatale per entrambi: IKE SA eliminata senza Delete esplicito.

2.21.4. Error Handling Outside IKE SA

Un nodo deve limitare la frequenza di risposte a messaggi non protetti.

Messaggi su UDP 500 o 4500 fuori contesto di IKE SA nota (e non richiesta di avvio IKE): possibile crash recente. Se marcati come risposta: audit ma NON rispondere. Se richiesta: audit e si PUÒ rispondere. Risposta: stesso IP/porta sorgente, stessi SPI IKE, Message ID copiato, non protetta crittograficamente, Notify INVALID_IKE_SPI.

Il peer che riceve tale Notify non protetta NON DEVE rispondere né cambiare stato SA. Trattare come suggerimento di possibili problemi SA verso quell'IP e avviare controllo di vitalità; limitare frequenza (DoS).

Errori fuori contesto richiesta IKE (es. ESP su SPI inesistente): avviare INFORMATIONAL con Notify.

Messaggio sospetto da IP/porta (con NAT-T) con cui esiste IKE SA: inviare Notify IKE in INFORMATIONAL su quella SA. Il destinatario NON DEVE cambiare stato SA; può registrare per diagnostica.