2.21. Error Handling (Gestion des erreurs)

De nombreuses erreurs peuvent survenir pendant le traitement IKE. Règle générale: si une requête est mal formée ou inacceptable par politique (par exemple aucun algorithme cryptographique compatible), la réponse contient une charge Notify d'erreur. L'envoi dépend de l'existence d'une IKE SA authentifiée.

En cas d'erreur d'analyse ou de traitement d'une réponse, on n'envoie généralement pas d'erreur en retour, car les réponses ne doivent pas générer de nouvelles requêtes. Ces erreurs doivent néanmoins amener le destinataire à nettoyer l'état IKE (par exemple envoyer un Delete pour une mauvaise SA).

Seuls les échecs d'authentification (AUTHENTICATION_FAILED et échec EAP) et les messages mal formés (INVALID_SYNTAX) entraînent la suppression de l'IKE SA sans échange INFORMATIONAL explicite avec Delete. D'autres erreurs PEUVENT exiger un tel échange si la politique l'exige. Si l'échange se termine par EAP Failure, AUTHENTICATION_FAILED n'est pas envoyé.

2.21.1. Error Handling in IKE_SA_INIT (Erreurs dans IKE_SA_INIT)

Les erreurs avant l'établissement d'une IKE SA protégée cryptographiquement exigent une grande prudence. Il faut arbitrer entre aider le pair à diagnostiquer et éviter de participer à une attaque DoS par messages forgés.

Dans IKE_SA_INIT, toute notification d'erreur fait échouer l'échange. Certaines (COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION) peuvent mener à un échange ultérieur réussi. Comme toutes les notifications sont non authentifiées, le destinataire devrait continuer à essayer un certain temps avant d'abandonner. Il ne devrait pas agir immédiatement sur la notification sauf si des actions correctives sont définies ici (COOKIE, INVALID_KE_PAYLOAD, INVALID_MAJOR_VERSION).

2.21.2. Error Handling in IKE_AUTH (Erreurs dans IKE_AUTH)

Toutes les erreurs IKE_AUTH menant à l'échec d'authentification (secret partagé invalide, ID invalide, émetteur de certificat non fiable, certificat révoqué ou expiré, etc.) DEVRAIENT produire AUTHENTICATION_FAILED. Si l'erreur est côté répondant, la notification est dans la réponse protégée, souvent seule charge. Même chiffré, le pair qui n'a pas encore authentifié l'autre doit rester prudent.

Si l'erreur est côté initiateur, la notification PEUT être dans un échange INFORMATIONAL séparé, souvent seule. Exception à la règle de ne pas démarrer d'échanges sur erreur de réponse.

Cependant, les requêtes avec charge critique non supportée ou message entièrement mal formé (pas seulement le contenu d'une charge) DOIVENT être rejetées entièrement et NE DOIVENT produire qu'une notification UNSUPPORTED_CRITICAL_PAYLOAD ou INVALID_SYNTAX. Le récepteur ne devrait pas vérifier les charges d'authentification dans ce cas.

Si l'authentification IKE_AUTH a réussi, l'IKE SA est établie; la Child SA ou la configuration peut encore échouer. Cet échec ne supprime pas automatiquement l'IKE SA. Le répondant peut inclure IDr, CERT, AUTH tout en envoyant des erreurs pour les échanges parallèles (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, etc.), et l'initiateur NE DOIT PAS considérer l'authentification comme échouée pour autant. L'initiateur PEUT plus tard supprimer l'IKE SA pour politique.

Dans IKE_AUTH ou l'INFORMATIONAL qui suit immédiatement (erreur lors du traitement de la réponse à IKE_AUTH), seules UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX et AUTHENTICATION_FAILED suppriment ou empêchent l'IKE SA sans Delete. Les extensions peuvent définir d'autres notifications avec la même sémantique mais NE DOIVENT PAS les utiliser sans preuve que le pair les comprend (par ex. Vendor ID).

2.21.3. Error Handling after IKE SA is Authenticated (Après authentification IKE SA)

Après authentification de l'IKE SA, toute requête en erreur DOIT produire une réponse notifiant l'autre extrémité.

Normalement une réponse valide d'un pair ne devrait pas créer d'erreur chez l'autre; il ne devrait pas y avoir de raison d'envoyer des erreurs autrement que en réponse. Envoyer des erreurs en INFORMATIONAL peut provoquer des boucles; on ne DEVRAIT PAS le faire. Des erreurs d'état incohérent peuvent justifier de supprimer l'IKE SA.

Si un pair analysant une requête la trouve mal formée (après MAC et fenêtre) et renvoie INVALID_SYNTAX, cette notification est fatale pour les deux: l'IKE SA est supprimée sans Delete explicite.

2.21.4. Error Handling Outside IKE SA (Hors IKE SA)

Un nœud doit limiter le débit de réponses aux messages non protégés.

Si un message arrive sur UDP 500 ou 4500 hors contexte d'une IKE SA connue (et ce n'est pas une demande d'ouverture), cela peut suivre un crash. S'il est marqué réponse, audit possible mais NE PAS répondre. S'il est marqué requête, audit possible et réponse possible. Si réponse: même adresse IP et port source, mêmes SPI IKE, Message ID copié; pas de protection cryptographique; charge INVALID_IKE_SPI. Cela indique un SPI de destination IKE non reconnu (souvent reboot).

Le pair recevant une telle Notify non protégée NE DOIT PAS répondre ni modifier l'état des SA. Message forgé ou réponse d'un correspondant trompé. Traiter comme indice de problème possible avec les SA vers cette IP et lancer une vérification de vivacité pour chaque IKE SA concernée. L'implémentation DEVRAIT limiter la fréquence pour éviter la participation à un DoS.

Hors contexte de requête IKE (par ex. ESP sur SPI inexistant), le nœud DEVRAIT lancer un INFORMATIONAL avec Notify décrivant le problème.

Un message suspect depuis une adresse IP (et port si NAT-T) avec laquelle une IKE SA existe DEVRAIT recevoir une réponse Notify en INFORMATIONAL sur cette SA. Le destinataire NE DOIT PAS changer l'état des SA mais peut auditer.