2. Détails et variantes du protocole IKE
IKE écoute et envoie normalement sur le port UDP 500, bien que les messages IKE puissent également être reçus sur le port UDP 4500 avec un format légèrement différent (voir section 2.23). Comme UDP est un protocole datagramme (non fiable), IKE inclut dans sa définition la récupération des erreurs de transmission, y compris la perte de paquets, le rejeu de paquets et la falsification de paquets. IKE est conçu pour fonctionner tant que (1) au moins un des paquets retransmis atteint sa destination avant l'expiration du délai ; et (2) le canal n'est pas si saturé de paquets falsifiés et rejoués qu'il épuise les capacités réseau ou CPU de l'un des points de terminaison. Même en l'absence de ces exigences de performance minimales, IKE est conçu pour échouer proprement (comme si le réseau était cassé).
Bien que les messages IKEv2 soient censés être courts, ils contiennent des structures dont la taille n'a pas de limite supérieure stricte (en particulier les certificats numériques), et IKEv2 ne dispose pas lui-même d'un mécanisme de fragmentation des messages volumineux. IP définit un mécanisme de fragmentation des messages UDP trop grands, mais les implémentations varient selon la taille maximale de message prise en charge. En outre, l'utilisation de la fragmentation IP expose l'implémentation à des attaques par déni de service (DoS) [DOSUDPPROT]. Enfin, certaines implémentations NAT et/ou pare-feu peuvent bloquer les fragments IP.
Toutes les implémentations IKEv2 DOIVENT pouvoir envoyer, recevoir et traiter des messages IKE d'une longueur allant jusqu'à 1280 octets, et elles DEVRAIENT pouvoir envoyer, recevoir et traiter des messages d'une longueur allant jusqu'à 3000 octets. Les implémentations IKEv2 doivent être conscientes de la taille maximale de message UDP prise en charge et PEUVENT raccourcir les messages en omettant certains certificats ou propositions de suites cryptographiques si cela permet de maintenir les messages sous le maximum. L'utilisation des formats "Hash and URL" plutôt que l'inclusion de certificats dans les échanges, lorsque possible, peut éviter la plupart des problèmes. Toutefois, les implémentations et les configurations doivent garder à l'esprit que si les recherches d'URL ne sont possibles qu'après l'établissement de la Child SA, des problèmes de récursion pourraient empêcher cette technique de fonctionner.
Le payload UDP de tous les paquets contenant des messages IKE envoyés sur le port 4500 DOIT commencer par le préfixe de quatre zéros ; sinon, le récepteur ne saura pas comment les traiter.