Passa al contenuto principale

2.21. Gestione degli errori

2.21. Gestione degli errori​

Ci sono molti tipi di errori che possono verificarsi durante l'elaborazione IKE. La regola generale è che se una richiesta ricevuta è male formattata, o inaccettabile per ragioni di policy (come nessun algoritmo crittografico corrispondente), la risposta contiene un payload Notify che indica l'errore. La decisione se inviare o meno tale risposta dipende dal fatto che esista una IKE SA autenticata.

Se c'è un errore nell'analisi o nell'elaborazione di un pacchetto di risposta, la regola generale è di non rispedire alcun messaggio di errore perché le risposte non dovrebbero generare nuove richieste (e una nuova richiesta sarebbe l'unico modo per rispedire un messaggio di errore). Tali errori nell'analisi o nell'elaborazione dei pacchetti di risposta dovrebbero comunque causare al destinatario di pulire lo stato IKE (per esempio, inviando un Delete per una SA errata).

Solo i fallimenti di autenticazione (AUTHENTICATION_FAILED e fallimento EAP) e i messaggi malformati (INVALID_SYNTAX) portano alla cancellazione della IKE SA senza richiedere uno scambio INFORMATIONAL esplicito che trasporti un payload Delete. Altre condizioni di errore POSSONO richiedere tale scambio se la policy lo impone. Se lo scambio è terminato con EAP Failure, non viene inviata una notifica AUTHENTICATION_FAILED.

2.21.1. Gestione degli errori in IKE_SA_INIT​

Gli errori che si verificano prima che una IKE SA crittograficamente protetta sia stabilita devono essere gestiti con molta cautela. C'è un compromesso tra il desiderio di aiutare il peer a diagnosticare un problema e quindi rispondere all'errore, e il desiderio di evitare di fare parte di un attacco DoS basato su messaggi falsificati.

In uno scambio IKE_SA_INIT, qualsiasi notifica di errore causa il fallimento dello scambio. Notare che alcune notifiche di errore come COOKIE, INVALID_KE_PAYLOAD o INVALID_MAJOR_VERSION possono portare a uno scambio successivo riuscito. Poiché tutte le notifiche di errore sono completamente non autenticate, il destinatario dovrebbe continuare a provare per un certo tempo prima di abbandonare. Il destinatario non dovrebbe agire immediatamente sulla base della notifica di errore a meno che azioni correttive non siano definite in questa specifica, come per COOKIE, INVALID_KE_PAYLOAD, e INVALID_MAJOR_VERSION.

2.21.2. Gestione degli errori in IKE_AUTH​

Tutti gli errori che si verificano in uno scambio IKE_AUTH, causando il fallimento dell'autenticazione per qualsiasi ragione (segreto condiviso non valido, ID non valido, emittente certificato non attendibile, certificato revocato o scaduto, ecc.) DOVREBBERO risultare in una notifica AUTHENTICATION_FAILED. Se l'errore si è verificato sul risponditore, la notifica è restituita nella risposta protetta, ed è di solito l'unico payload in quella risposta. Sebbene i messaggi IKE_AUTH siano cifrati e protetti da integrità, se il peer che riceve questa notifica non ha ancora autenticato l'altra estremità, quel peer deve trattare l'informazione con cautela.

Se l'errore si verifica sull'iniziatore, la notifica PUÒ essere restituita in uno scambio INFORMATIONAL separato, di solito senza altri payload. Questa è un'eccezione alla regola generale di non avviare nuovi scambi basati su errori nelle risposte.

Notare però che i messaggi di richiesta che contengono un payload critico non supportato, o dove l'intero messaggio è malformato (piuttosto che solo un cattivo contenuto di payload), DEVONO essere rifiutati nella loro interezza, e DEVONO portare solo a una notifica UNSUPPORTED_CRITICAL_PAYLOAD o INVALID_SYNTAX inviata come risposta. Il ricevitore non dovrebbe verificare i payload relativi all'autenticazione in questo caso.

Se l'autenticazione ha successo nello scambio IKE_AUTH, la IKE SA è stabilita; tuttavia, stabilire la Child SA o richiedere informazioni di configurazione può ancora fallire. Questo fallimento non causa automaticamente la cancellazione della IKE SA. Specificamente, un risponditore PUÒ includere tutti i payload associati all'autenticazione (IDr, CERT, e AUTH) mentre invia notifiche di errore per gli scambi piggybacked (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, ecc.), e l'iniziatore NON DEVE far fallire l'autenticazione a causa di ciò. L'iniziatore PUÒ, certamente, per ragioni di policy in seguito cancellare tale IKE SA.

In uno scambio IKE_AUTH, o nello scambio INFORMATIONAL immediatamente seguente (nel caso in cui si sia verificato un errore durante l'elaborazione di una risposta a IKE_AUTH), le notifiche UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, e AUTHENTICATION_FAILED sono le sole a causare la cancellazione o la non creazione della IKE SA, senza un payload Delete. I documenti di estensione POSSONO definire nuove notifiche di errore con queste semantiche, ma NON DEVONO usarle a meno che non sia stato mostrato che il peer le comprende, come usando il payload Vendor ID.

2.21.3. Gestione degli errori dopo l'autenticazione della IKE SA​

Dopo che la IKE SA è autenticata, tutte le richieste che hanno errori DEVONO risultare in una risposta che notifica l'errore.

In situazioni normali, non ci dovrebbero essere casi in cui una risposta valida da un peer risulta in una situazione di errore nell'altro peer, quindi non ci dovrebbe essere alcuna ragione per un peer di inviare messaggi di errore all'altra estremità se non come risposta. Poiché inviare tali messaggi di errore come scambio INFORMATIONAL potrebbe portare a ulteriori errori che potrebbero causare loop, tali errori NON DOVREBBERO essere inviati. Se si vedono errori che indicano che i peer non hanno lo stesso stato, potrebbe essere bene cancellare la IKE SA per pulire lo stato e ricominciare.

Se un peer che analizza una richiesta nota che è male formattata (dopo che ha superato i controlli del codice di autenticazione del messaggio e i controlli della finestra) e restituisce una notifica INVALID_SYNTAX, allora questa notifica di errore è considerata fatale in entrambi i peer, il che significa che la IKE SA è cancellata senza bisogno di un payload Delete esplicito.

2.21.4. Gestione degli errori al di fuori della IKE SA​

Un nodo deve limitare la frequenza con cui invierà messaggi in risposta a messaggi non protetti.

Se un nodo riceve un messaggio sulla porta UDP 500 o 4500 al di fuori del contesto di una IKE SA a esso nota (e il messaggio non è una richiesta di avvio di una IKE SA), questo può essere il risultato di un recente crash del nodo. Se il messaggio è marcato come risposta, il nodo può auditare l'evento sospetto ma NON DEVE rispondere. Se il messaggio è marcato come richiesta, il nodo può auditare l'evento sospetto e PUÒ inviare una risposta. Se viene inviata una risposta, la risposta DEVE essere inviata all'indirizzo IP e alla porta da cui proviene con gli stessi SPI IKE e l'ID di messaggio copiato. La risposta NON DEVE essere protetta crittograficamente e DEVE contenere un payload Notify INVALID_IKE_SPI. La notifica INVALID_IKE_SPI indica che è stato ricevuto un messaggio IKE con un SPI di destinazione non riconosciuto; ciò indica di solito che il destinatario è riavviato e ha dimenticato l'esistenza di una IKE SA.

Un peer che riceve tale payload Notify non protetto NON DEVE rispondere e NON DEVE cambiare lo stato di alcuna SA esistente. Il messaggio potrebbe essere una contraffazione o potrebbe essere una risposta che un corrispondente genuino è stato indotto a inviare. Un nodo dovrebbe trattare tale messaggio (e anche un messaggio di rete come ICMP destination unreachable) come un indizio che potrebbero esserci problemi con le SA verso quell'indirizzo IP e dovrebbe iniziare un controllo di liveness per tali IKE SA. Un'implementazione DOVREBBE limitare la frequenza di tali test per evitare di essere indotta a partecipare a un attacco DoS.

Se si verifica un errore al di fuori del contesto di una richiesta IKE (es., il nodo riceve messaggi ESP su uno SPI inesistente), il nodo DOVREBBE iniziare uno scambio INFORMATIONAL con un payload Notify che descrive il problema.

Un nodo che riceve un messaggio sospetto da un indirizzo IP (e porta, se è usato il NAT traversal) con cui ha una IKE SA DOVREBBE inviare un payload Notify IKE in uno scambio IKE INFORMATIONAL su quella SA. Il destinatario NON DEVE cambiare lo stato di alcuna SA in conseguenza di ciò, ma può auditare l'evento per aiutare a diagnosticare malfunzionamenti.