2.25. Collisioni di scambio

Poiché gli scambi IKEv2 possono essere iniziati da entrambi i peer, è possibile che due scambi che interessano la stessa SA si sovrappongano parzialmente. Ciò può portare a una situazione in cui le informazioni di stato della SA non sono temporaneamente sincronizzate e un peer può ricevere una richiesta che non può essere elaborata normalmente.

È evidente che l'uso di una dimensione della finestra maggiore di 1 porta a situazioni più complesse, specialmente se le richieste vengono elaborate fuori ordine. Questa sezione si concentra sui problemi che possono sorgere anche con una dimensione della finestra di 1 e ne raccomanda le soluzioni.

Una notifica TEMPORARY_FAILURE DOVREBBE essere inviata quando un peer riceve una richiesta che non può essere completata a causa di una condizione temporanea come un'operazione di rekeying. Quando un peer riceve una notifica TEMPORARY_FAILURE, NON DEVE ritentare immediatamente l'operazione; DEVE attendere così che il mittente possa completare l'operazione che ha causato la condizione temporanea. Il destinatario PUÒ ritentare la richiesta una o più volte nell'arco di alcuni minuti. Se un peer continua a ricevere TEMPORARY_FAILURE sullo stesso IKE SA dopo alcuni minuti, DOVREBBE concludere che le informazioni di stato non sono sincronizzate e chiudere lo IKE SA.

Una notifica CHILD_SA_NOT_FOUND DOVREBBE essere inviata quando un peer riceve una richiesta di rekeying di una Child SA inesistente. La SA che l'iniziatore ha tentato di rekeyare è indicata dal campo SPI nel payload Notify, copiato dal campo SPI nella notifica REKEY_SA. Un peer che riceve una notifica CHILD_SA_NOT_FOUND DOVREBBE eliminare silenziosamente la Child SA (se esiste ancora) e inviare una richiesta per creare una nuova Child SA da zero (se la Child SA non esiste ancora).

2.25.1. Collisioni durante il rekeying o la chiusura di Child SA

Se un peer riceve una richiesta di rekeying di una Child SA che sta cercando di chiudere, DOVREBBE rispondere con TEMPORARY_FAILURE. Se un peer riceve una richiesta di rekeying di una Child SA che sta rekeyando, DOVREBBE rispondere come al solito e DOVREBBE prepararsi a chiudere le SA ridondanti in seguito in base ai nonce (vedere sezione 2.8.1). Se un peer riceve una richiesta di rekeying di una Child SA inesistente, DOVREBBE rispondere con CHILD_SA_NOT_FOUND.

Se un peer riceve una richiesta di chiusura di una Child SA che sta cercando di chiudere, DOVREBBE rispondere senza payload Delete (vedere sezione 1.4.1). Se un peer riceve una richiesta di chiusura di una Child SA che sta rekeyando, DOVREBBE rispondere come al solito, con un payload Delete. Se un peer riceve una richiesta di chiusura di una Child SA inesistente, DOVREBBE rispondere senza payload Delete.

Se un peer riceve una richiesta di rekeying dello IKE SA mentre sta creando, rekeyando o chiudendo una Child SA di quel IKE SA, DOVREBBE rispondere con TEMPORARY_FAILURE.

2.25.2. Collisioni durante il rekeying o la chiusura di IKE SA

Se un peer riceve una richiesta di rekeying di uno IKE SA che sta rekeyando, DOVREBBE rispondere come al solito e DOVREBBE prepararsi a chiudere le SA ridondanti e a spostare le Child SA ereditate in seguito in base ai nonce (vedere sezione 2.8.2). Se un peer riceve una richiesta di rekeying di uno IKE SA che sta cercando di chiudere, DOVREBBE rispondere con TEMPORARY_FAILURE.

Se un peer riceve una richiesta di chiusura di uno IKE SA che sta rekeyando, DOVREBBE rispondere come al solito e dimenticare la propria richiesta di rekeying. Se un peer riceve una richiesta di chiusura di uno IKE SA che sta cercando di chiudere, DOVREBBE rispondere come al solito e dimenticare la propria richiesta di chiusura.

Se un peer riceve una richiesta di creazione o rekeying di una Child SA mentre sta rekeyando lo IKE SA, DOVREBBE rispondere con TEMPORARY_FAILURE. Se un peer riceve una richiesta di eliminazione di una Child SA mentre sta rekeyando lo IKE SA, DOVREBBE rispondere come al solito, con un payload Delete.