5. Considérations de sécurité
5. Considérations de sécurité
Par définition, la compatibilité IPsec-NAT exige que les hôtes et routeurs implémentant IPsec soient capables de traiter en toute sécurité des paquets dont les en-têtes IP ne sont pas protégés cryptographiquement. Un certain nombre de problèmes en découlent qui méritent d'être discutés.
Étant donné qu'IPsec AH ne peut pas passer à travers un NAT, l'un des effets secondaires de la fourniture d'une solution de compatibilité IPsec-NAT peut être l'utilisation d'IPsec ESP avec chiffrement nul à la place d'AH lorsqu'un NAT existe entre la source et la destination. Cependant, il convient de noter qu'ESP avec chiffrement nul ne fournit pas les mêmes propriétés de sécurité qu'AH. Par exemple, il existe des risques de sécurité liés au routage source IPv6 qui sont exclus par AH, mais pas par ESP avec chiffrement nul.
De plus, étant donné qu'ESP avec n'importe quelle transformation ne protège pas contre l'usurpation d'adresse source, une certaine forme de vérification de l'intégrité de l'adresse IP source doit être effectuée. L'importance de la vérification anti-usurpation n'est pas largement comprise. Il existe normalement une vérification anti-usurpation sur l'adresse IP source dans le cadre de IPsec_{esp,ah}_input(). Cela garantit que le paquet provient de la même adresse que celle revendiquée dans les associations de sécurité IKE Phase 1 et Phase 2 d'origine. Lorsqu'un hôte récepteur est derrière un NAT, cette vérification peut ne pas être strictement significative pour les sessions unicast, alors que dans l'Internet mondial, cette vérification est importante pour les sessions unicast en mode tunnel afin d'empêcher une attaque d'usurpation décrite dans [AuthSource], qui peut se produire lorsque les contrôles d'accès sur le récepteur dépendent de l'adresse IP source des paquets ESP vérifiés après décapsulation. Les schémas de compatibilité IPsec-NAT devraient fournir une protection anti-usurpation s'ils utilisent des adresses source pour les contrôles d'accès.
Considérons deux hôtes, A et C, tous deux derrière des NAT (différents), qui négocient des SA en mode tunnel IPsec vers le routeur B. Les hôtes A et C peuvent avoir des privilèges différents; par exemple, l'hôte A pourrait appartenir à un employé de confiance pour accéder à une grande partie de l'intranet d'entreprise, tandis que C pourrait être un entrepreneur autorisé uniquement à accéder à un site Web spécifique.
Si l'hôte C envoie un paquet en mode tunnel usurpant l'adresse IP d'A comme source, il est important que ce paquet ne se voie pas accorder les privilèges correspondant à A. Si l'authentification et la vérification d'intégrité sont effectuées, mais qu'aucune vérification anti-usurpation (vérifiant que l'adresse IP d'origine correspond au SPI) n'est effectuée, alors l'hôte C peut être autorisé à atteindre des parties du réseau qui sont interdites. En conséquence, un schéma de compatibilité IPsec-NAT DOIT fournir un certain degré de protection anti-usurpation.