2.4. State Synchronization and Connection Timeouts
2.4. State Synchronization and Connection Timeouts
Une extrémité IKE PEUT oublier tout état lié à une IKE SA et aux Child SA associées à tout moment, notamment après crash et redémarrage. Lorsqu'une extrémité échoue ou réinitialise son état, l'autre DOIT détecter la situation et ne pas continuer à gaspiller la bande passante sur des SA abandonnées.
La notification INITIAL_CONTACT indique que cette IKE SA est la seule active entre les identités authentifiées. Elle PEUT être envoyée après un crash ; le destinataire PEUT supprimer d'autres IKE SA vers la même identité sans attendre un délai. Elle NE DOIT PAS être envoyée par une entité réplicable (ex. : utilisateur autorisé à deux connexions simultanées). Si envoyée, elle DOIT figurer dans la première requête ou réponse IKE_AUTH, pas dans un échange ultérieur ; les destinataires PEUVENT l'ignorer ailleurs.
Comme IKE résiste aux attaques DoS, une extrémité NE DOIT PAS conclure à la panne du pair sur la seule base d'informations de routage (ICMP) ou de messages IKE non protégés (Notify d'SPI inconnus). Elle NE DOIT conclure à la panne qu'après échecs répétés jusqu'à expiration ou réception d'un INITIAL_CONTACT protégé sur une autre IKE SA vers la même identité. Elle peut suspecter une panne à partir du routage et lancer une vérification de présence. IKE définit une requête INFORMATIONAL vide exigeant un accusé (dans une IKE SA, « vide » signifie en-tête IKE puis charge chiffrée sans charges internes). Si un message protégé récent a été reçu, les Notify non protégés PEUVENT être ignorés. Les implémentations DOIVENT limiter le débit des actions basées sur des messages non protégés.
Le nombre de tentatives et les durées de temporisation ne sont pas normalisés. Il est suggéré d'effectuer au moins une douzaine de retransmissions sur plusieurs minutes avant d'abandonner ; les temporisations DOIVENT croître exponentiellement. S'il n'y a eu que du trafic sortant sur toutes les SA liées à une IKE SA, il faut confirmer la présence du pair. Sans message protégé récent sur l'IKE SA ou ses Child SA, un contrôle de présence est nécessaire (« DPD », bien qu'il détecte plutôt les pairs vivants). Un message protégé récent sur l'IKE SA ou un Child SA garantit la vivacité de l'IKE SA et de tous ses Child SA. Une implémentation DOIT cesser d'émettre sur une SA si une défaillance l'empêche de recevoir sur toutes les SA associées. Si des Child SA peuvent échouer indépendamment sans que l'IKE SA puisse envoyer de suppression, ces Child SA DOIVENT être négociées via des IKE SA distinctes.
Pour limiter une attaque sur l'initiateur pendant les deux premiers messages non protégés, l'initiateur PEUT accepter plusieurs réponses à son premier message, répondre à chacune, puis abandonner les connexions semi-ouvertes invalides lorsqu'une réponse protégée valide arrive. Après cela, toutes les réponses suivantes doivent être ignorées.
Avec ces règles, il n'est pas nécessaire de négocier une durée de vie de SA : si IKE déclare le pair mort faute d'accusés répétés, l'IKE SA et les Child SA associées sont supprimées.
Une extrémité PEUT supprimer des Child SA inactives. Si elle le fait, elle DOIT envoyer des charges Delete. Elle PEUT aussi expirer l'IKE SA. Fermer l'IKE SA ferme implicitement les Child SA ; dans ce cas elle DEVRAIT envoyer une Delete pour l'IKE SA sauf si le pair ne répond plus.