2.4. Synchronisation d'état et expirations de connexion

2.4. Synchronisation d'état et expirations de connexion

Un point final IKE est autorisé à oublier tout son état associé à une IKE SA et à la collection des Child SAs correspondantes à tout moment. C'est le comportement anticipé en cas de plantage et de redémarrage d'un point final. Il est important lorsqu'un point final échoue ou réinitialise son état que l'autre point final détecte ces conditions et ne continue pas à gaspiller la bande passante réseau en envoyant des paquets sur des SAs abandonnées pour les voir tomber dans un trou noir.

La notification INITIAL_CONTACT affirme que cette IKE SA est la seule IKE SA actuellement active entre les identités authentifiées. Elle PEUT être envoyée lorsqu'une IKE SA est établie après un plantage, et le destinataire PEUT utiliser cette information pour supprimer toute autre IKE SA qu'il a vers la même identité authentifiée sans attendre un délai d'expiration. Cette notification NE DOIT PAS être envoyée par une entité qui peut être répliquée (par exemple, les identifiants d'un utilisateur itinérant où l'utilisateur est autorisé à se connecter au pare-feu d'entreprise depuis deux systèmes distants en même temps). La notification INITIAL_CONTACT, si elle est envoyée, DOIT être dans la première requête ou réponse IKE_AUTH, et non comme un échange séparé ultérieur ; les parties recevant PEUVENT l'ignorer dans les autres messages.

Comme IKE est conçu pour fonctionner malgré les attaques DoS depuis le réseau, un point final NE DOIT PAS conclure que l'autre point final a échoué sur la base de toute information de routage (par exemple, messages ICMP) ou de messages IKE arrivant sans protection cryptographique (par exemple, messages Notify se plaignant de SPI inconnus). Un point final DOIT conclure que l'autre point final a échoué uniquement lorsque des tentatives répétées de le contacter sont restées sans réponse pendant une période d'expiration ou lorsqu'une notification INITIAL_CONTACT cryptographiquement protégée est reçue sur une IKE SA différente vers la même identité authentifiée. Un point final devrait soupçonner que l'autre point final a échoué sur la base d'informations de routage et initier une requête pour voir si l'autre point final est vivant. Pour vérifier si l'autre côté est vivant, IKE spécifie un message INFORMATIONAL vide qui (comme toutes les requêtes IKE) requiert un accusé de réception (notez que dans le contexte d'une IKE SA, un message « vide » consiste en un en-tête IKE suivi d'un payload Encrypted qui ne contient aucun payload). Si un message (cryptographiquement protégé, c'est-à-dire non retransmis) a été reçu de l'autre côté récemment, les messages Notify non protégés PEUVENT être ignorés. Les implémentations DOIVENT limiter le débit auquel elles prennent des actions basées sur des messages non protégés.

Le nombre de nouvelles tentatives et la durée des délais d'expiration ne sont pas couverts par cette spécification car ils n'affectent pas l'interopérabilité. Il est suggéré que les messages soient retransmis au moins une douzaine de fois sur une période d'au moins plusieurs minutes avant d'abandonner une SA, mais différents environnements peuvent nécessiter des règles différentes. Pour être un bon citoyen du réseau, les temps de retransmission DOIVENT augmenter exponentiellement pour éviter d'inonder le réseau et d'aggraver une situation de congestion existante. S'il n'y a eu que du trafic sortant sur toutes les SAs associées à une IKE SA, il est essentiel de confirmer la vivacité de l'autre point final pour éviter les trous noirs. Si aucun message cryptographiquement protégé n'a été reçu sur une IKE SA ou l'une de ses Child SAs récemment, le système doit effectuer une vérification de vivacité afin d'éviter d'envoyer des messages à un pair mort. (Ceci est parfois appelé « détection de pair mort » ou « DPD », bien que cela détecte réellement les pairs vivants, et non les morts.) La réception d'un message cryptographiquement protégé (récent) sur une IKE SA ou l'une de ses Child SAs garantit la vivacité de l'IKE SA et de toutes ses Child SAs. Notez que cela impose des exigences sur les modes de défaillance d'un point final IKE. Une implémentation doit arrêter d'envoyer sur toute SA si une défaillance l'empêche de recevoir sur toutes les SAs associées. Si un système crée des Child SAs qui peuvent échouer indépendamment les unes des autres sans que l'IKE SA associée soit capable d'envoyer un message de suppression, alors le système DOIT négocier de telles Child SAs en utilisant des IKE SAs séparées.

Il existe une attaque DoS sur l'initiateur d'une IKE SA qui peut être évité si l'initiateur prend les précautions appropriées. Comme les deux premiers messages d'une configuration de SA ne sont pas protégés cryptographiquement, un attaquant pourrait répondre au message de l'initiateur avant le véritable répondeur et empoisonner la tentative de configuration de connexion. Pour prévenir cela, l'initiateur PEUT accepter plusieurs réponses à son premier message, traiter chacune comme potentiellement légitime, y répondre, puis supprimer toutes les connexions à demi ouvertes invalides lorsqu'il reçoit une réponse valide cryptographiquement protégée à l'une de ses requêtes. Une fois une réponse cryptographiquement valide reçue, toutes les réponses ultérieures doivent être ignorées qu'elles soient ou non cryptographiquement valides.

Notez qu'avec ces règles, il n'y a aucune raison de négocier et d'approuver une durée de vie de SA. Si IKE présume que le partenaire est mort, sur la base d'un manque répété d'accusé de réception à un message IKE, alors l'IKE SA et toutes les Child SAs configurées via cette IKE SA sont supprimées.

Un point final IKE peut à tout moment supprimer des Child SAs inactives pour récupérer les ressources utilisées pour conserver leur état. Si un point final IKE choisit de supprimer des Child SAs, il DOIT envoyer des payloads Delete à l'autre extrémité l'informant de la suppression. Il PEUT de même faire expirer la IKE SA. Fermer la IKE SA ferme implicitement toutes les Child SAs associées. Dans ce cas, un point final IKE DEVRAIT envoyer un payload Delete indiquant qu'il a fermé la IKE SA à moins que l'autre point final ne réponde plus.