1.5. Messages informationnels en dehors d'une SA IKE
1.5. Messages informationnels en dehors d'une SA IKE
Il existe certains cas dans lesquels un nœud reçoit un paquet qu'il ne peut pas traiter, mais où il peut souhaiter informer l'émetteur de cette situation.
o Si un paquet ESP ou AH arrive avec un SPI non reconnu. Cela peut être dû au fait que le nœud récepteur a récemment planté et perdu son état, ou à un autre dysfonctionnement du système ou à une attaque.
o Si un paquet de requête IKE chiffré arrive sur le port 500 ou 4500 avec un SPI IKE non reconnu. Cela peut être dû au fait que le nœud récepteur a récemment planté et perdu son état, ou à un autre dysfonctionnement du système ou à une attaque.
o Si un paquet de requête IKE arrive avec un numéro de version majeure supérieur à celui pris en charge par l'implémentation.
Dans le premier cas, si le nœud récepteur dispose d'une SA IKE active vers l'adresse IP d'où provient le paquet, il PEUT envoyer une notification INVALID_SPI concernant le paquet égaré sur cette SA IKE dans un échange INFORMATIONAL. Les données de la notification contiennent le SPI du paquet invalide. Le destinataire de cette notification ne peut pas déterminer si le SPI est pour AH ou ESP, mais cela n'est pas important car les SPI sont censés être différents pour les deux. Si aucune SA IKE appropriée n'existe, le nœud PEUT envoyer un message informationnel sans protection cryptographique à l'adresse IP source, en utilisant le port UDP source comme port de destination si le paquet était UDP (ESP ou AH encapsulés en UDP). Dans ce cas, il ne doit être utilisé par le destinataire que comme un indice que quelque chose pourrait clocher (car il pourrait facilement être falsifié). Ce message ne fait pas partie d'un échange INFORMATIONAL, et le nœud récepteur NE DOIT PAS y répondre, car cela pourrait provoquer une boucle de messages. Le message est construit comme suit : il n'existe aucune valeur de SPI IKE qui aurait un sens pour le destinataire d'une telle notification ; l'utilisation de valeurs nulles ou de valeurs aléatoires est acceptable dans les deux cas, ceci étant l'exception à la règle de la section 3.1 qui interdit les SPI d'initiateur IKE nuls. Le drapeau Initiator est défini à 1, le drapeau Response est défini à 0, et les drapeaux de version sont définis de la manière habituelle ; ces drapeaux sont décrits dans la section 3.1.
Dans les deuxième et troisième cas, le message est toujours envoyé sans protection cryptographique (en dehors d'une SA IKE), et inclut soit une notification INVALID_IKE_SPI, soit une notification INVALID_MAJOR_VERSION (sans données de notification). Le message est un message de réponse, et il est donc envoyé à l'adresse IP et au port d'où il provient, avec les mêmes SPI IKE, et l'identifiant de message et le type d'échange sont copiés depuis la requête. Le drapeau Response est défini à 1, et les drapeaux de version sont définis de la manière habituelle.