2.21. Gestion des erreurs

Il existe de nombreux types d'erreurs qui peuvent se produire pendant le traitement IKE. La règle générale est que si une demande reçue est mal formatée, ou inacceptable pour des raisons de politique (telle qu'aucun algorithme cryptographique correspondant), la réponse contient un payload Notify indiquant l'erreur. La décision d'envoyer ou non une telle réponse dépend de l'existence d'une IKE SA authentifiée.

S'il y a une erreur d'analyse ou de traitement d'un paquet de réponse, la règle générale est de ne renvoyer aucun message d'erreur parce que les réponses ne doivent pas générer de nouvelles demandes (et un nouveau message serait le seul moyen d'envoyer un message d'erreur). De telles erreurs dans l'analyse ou le traitement des paquets de réponse devraient tout de même amener le destinataire à nettoyer l'état IKE (par exemple, en envoyant un Delete pour une mauvaise SA).

Seuls les échecs d'authentification (AUTHENTICATION_FAILED et échec EAP) et les messages mal formés (INVALID_SYNTAX) mènent à une suppression de la IKE SA sans nécessiter un échange INFORMATIONAL explicite transportant un payload Delete. D'autres conditions d'erreur PEUVENT nécessiter un tel échange si la politique le dicte. Si l'échange est terminé par un EAP Failure, une notification AUTHENTICATION_FAILED n'est pas envoyée.

2.21.1. Gestion des erreurs dans IKE_SA_INIT

Les erreurs qui se produisent avant qu'une IKE SA cryptographiquement protégée soit établie doivent être gérées avec beaucoup de précaution. Il y a un compromis entre le désir d'aider le pair à diagnostiquer un problème et donc de répondre à l'erreur, et le désir d'éviter de faire partie d'une attaque DoS basée sur des messages falsifiés.

Dans un échange IKE_SA_INIT, toute notification d'erreur provoque l'échec de l'échange. Notez que certaines notifications d'erreur telles que COOKIE, INVALID_KE_PAYLOAD ou INVALID_MAJOR_VERSION peuvent mener à un échange ultérieur réussi. Parce que toutes les notifications d'erreur sont complètement non authentifiées, le destinataire devrait continuer d'essayer pendant un certain temps avant d'abandonner. Le destinataire ne devrait pas agir immédiatement sur la base de la notification d'erreur à moins que des actions correctives ne soient définies dans cette spécification, telles que pour COOKIE, INVALID_KE_PAYLOAD, et INVALID_MAJOR_VERSION.

2.21.2. Gestion des erreurs dans IKE_AUTH

Toutes les erreurs qui se produisent dans un échange IKE_AUTH, provoquant l'échec de l'authentification pour quelque raison que ce soit (secret partagé invalide, ID invalide, émetteur de certificat non fiable, certificat révoqué ou expiré, etc.) DEVRAIENT résulter en une notification AUTHENTICATION_FAILED. Si l'erreur s'est produite sur le répondeur, la notification est retournée dans la réponse protégée, et est habituellement le seul payload dans cette réponse. Bien que les messages IKE_AUTH soient chiffrés et protégés par intégrité, si le pair recevant cette notification n'a pas encore authentifié l'autre extrémité, ce pair a besoin de traiter l'information avec prudence.

Si l'erreur se produit sur l'initiateur, la notification PEUT être retournée dans un échange INFORMATIONAL séparé, habituellement sans autres payloads. Ceci est une exception à la règle générale de ne pas démarrer de nouveaux échanges basés sur des erreurs dans les réponses.

Notez cependant que les messages de demande qui contiennent un payload critique non supporté, ou où le message entier est mal formé (plutôt que seulement un mauvais contenu de payload), DOIVENT être rejetés dans leur intégralité, et NE DOIVENT mener qu'à une notification UNSUPPORTED_CRITICAL_PAYLOAD ou INVALID_SYNTAX envoyée comme réponse. Le récepteur ne devrait pas vérifier les payloads liés à l'authentification dans ce cas.

Si l'authentification a réussi dans l'échange IKE_AUTH, la IKE SA est établie ; cependant, l'établissement de la Child SA ou la demande d'informations de configuration peuvent toujours échouer. Cet échec ne provoque pas automatiquement la suppression de la IKE SA. Spécifiquement, un répondeur PEUT inclure tous les payloads associés à l'authentification (IDr, CERT, et AUTH) tout en envoyant des notifications d'erreur pour les échanges piggybacked (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, etc.), et l'initiateur NE DOIT PAS faire échouer l'authentification à cause de cela. L'initiateur PEUT, bien sûr, pour des raisons de politique supprimer plus tard une telle IKE SA.

Dans un échange IKE_AUTH, ou dans l'échange INFORMATIONAL immédiatement suivant (dans le cas où une erreur s'est produite lors du traitement d'une réponse à IKE_AUTH), les notifications UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, et AUTHENTICATION_FAILED sont les seules à provoquer la suppression ou la non-création de la IKE SA, sans un payload Delete. Les documents d'extension PEUVENT définir de nouvelles notifications d'erreur avec ces sémantiques, mais NE DOIVENT PAS les utiliser à moins qu'il n'ait été montré que le pair les comprend, tel qu'en utilisant le payload Vendor ID.

2.21.3. Gestion des erreurs après l'authentification de la IKE SA

Après que la IKE SA est authentifiée, toutes les demandes ayant des erreurs DOIVENT résulter en une réponse notifiant l'erreur.

Dans des situations normales, il ne devrait pas y avoir de cas où une réponse valide d'un pair résulte en une situation d'erreur dans l'autre pair, donc il ne devrait y avoir aucune raison pour qu'un pair envoie des messages d'erreur à l'autre extrémité sauf en tant que réponse. Parce que l'envoi de tels messages d'erreur en tant qu'échange INFORMATIONAL pourrait mener à d'autres erreurs qui pourraient causer des boucles, de tels messages NE DEVRAIENT PAS être envoyés. Si des erreurs sont vues indiquant que les pairs n'ont pas le même état, il pourrait être bon de supprimer la IKE SA pour nettoyer l'état et recommencer.

Si un pair analysant une demande remarque qu'elle est mal formatée (après qu'elle a passé les vérifications du code d'authentification de message et les vérifications de fenêtre) et retourne une notification INVALID_SYNTAX, alors cette notification d'erreur est considérée comme fatale dans les deux pairs, ce qui signifie que la IKE SA est supprimée sans avoir besoin d'un payload Delete explicite.

2.21.4. Gestion des erreurs en dehors de la IKE SA

Un nœud a besoin de limiter le taux auquel il enverra des messages en réponse à des messages non protégés.

Si un nœud reçoit un message sur le port UDP 500 ou 4500 en dehors du contexte d'une IKE SA qu'il connaît (et que le message n'est pas une demande de démarrage d'une IKE SA), cela peut être le résultat d'un crash récent du nœud. Si le message est marqué comme une réponse, le nœud peut auditer l'événement suspect mais NE DOIT PAS répondre. Si le message est marqué comme une demande, le nœud peut auditer l'événement suspect et PEUT envoyer une réponse. Si une réponse est envoyée, la réponse DOIT être envoyée à l'adresse IP et au port d'où elle vient avec les mêmes SPI IKE et l'ID de message copiés. La réponse NE DOIT PAS être protégée cryptographiquement et DOIT contenir un payload Notify INVALID_IKE_SPI. La notification INVALID_IKE_SPI indique qu'un message IKE a été reçu avec un SPI de destination non reconnu ; cela indique habituellement que le destinataire a redémarré et a oublié l'existence d'une IKE SA.

Un pair recevant un tel payload Notify non protégé NE DOIT PAS répondre et NE DOIT PAS modifier l'état de toute SA existante. Le message peut être une contrefaçon ou peut être une réponse qu'un correspondant véritable a été trompé pour envoyer. Un nœud devrait traiter un tel message (ainsi qu'un message réseau comme ICMP destination inaccessible) comme un indice qu'il pourrait y avoir des problèmes avec les SA vers cette adresse IP et devrait initier une vérification de vivacité pour toute IKE SA de ce type. Une implémentation DEVRAIT limiter la fréquence de tels tests pour éviter d'être trompée pour participer à une attaque DoS.

Si une erreur se produit en dehors du contexte d'une demande IKE (par exemple, le nœud reçoit des messages ESP sur un SPI inexistant), le nœud DEVRAIT initier un échange INFORMATIONAL avec un payload Notify décrivant le problème.

Un nœud recevant un message suspect d'une adresse IP (et port, si le traveral NAT est utilisé) avec laquelle il a une IKE SA DEVRAIT envoyer un payload Notify IKE dans un échange IKE INFORMATIONAL sur cette SA. Le destinataire NE DOIT PAS modifier l'état de toute SA suite à cela, mais peut souhaiter auditer l'événement pour aider au diagnostic de dysfonctionnements.