2. Incompatibilités connues entre NA(P)T et IPsec

Les incompatibilités entre NA(P)T et IPsec peuvent être divisées en trois catégories:

Problèmes intrinsèques de NA(P)T. Ces incompatibilités découlent directement de la fonctionnalité NA(P)T décrite dans [RFC3022]. Ces incompatibilités seront donc présentes dans tout périphérique NA(P)T.
Faiblesses d'implémentation NA(P)T. Ces incompatibilités ne sont pas intrinsèques à NA(P)T, mais sont présentes dans de nombreuses implémentations NA(P)T. Cette catégorie comprend les problèmes de gestion des fragments entrants ou sortants. Étant donné que ces problèmes ne sont pas intrinsèques à NA(P)T, ils peuvent, en principe, être résolus dans de futures implémentations NA(P)T. Cependant, comme les problèmes d'implémentation semblent être répandus, ils doivent être pris en compte dans une solution de traversée NA(P)T.
Problèmes d'assistance. Ces incompatibilités sont présentes dans les périphériques NA(P)T qui tentent de fournir une traversée IPsec NA(P)T. Ironiquement, cette fonctionnalité "d'assistance" crée d'autres incompatibilités, rendant un problème déjà difficile plus difficile à résoudre. Bien que la fonctionnalité "d'assistance" de traversée IPsec ne soit pas présente dans tous les NA(P)T, ces fonctionnalités deviennent suffisamment populaires pour qu'elles doivent également être prises en compte dans une solution de traversée NA(P)T.

2.1. Problèmes intrinsèques de NA(P)T

Les incompatibilités intrinsèques à NA(P)T comprennent:

a) Incompatibilité entre IPsec AH [RFC2402] et NAT. Étant donné que l'en-tête AH incorpore les adresses IP source et de destination dans la vérification d'intégrité du message avec clé, les périphériques NAT ou NAT inverse apportant des modifications aux champs d'adresse invalideront la vérification d'intégrité du message. Étant donné qu'IPsec ESP [RFC2406] n'incorpore pas les adresses IP source et de destination dans sa vérification d'intégrité du message avec clé, ce problème ne se pose pas pour ESP.

b) Incompatibilité entre les sommes de contrôle et NAT. Les sommes de contrôle TCP et UDP dépendent des adresses IP source et de destination par l'inclusion du "pseudo-en-tête" dans le calcul. En conséquence, lorsque les sommes de contrôle sont calculées et vérifiées à la réception, elles seront invalidées par le passage à travers un périphérique NAT ou NAT inverse.

En conséquence, le Payload de sécurité encapsulant IPsec (Encapsulating Security Payload, ESP) ne passera à travers un NAT sans entrave que si les protocoles TCP/UDP ne sont pas impliqués (comme en mode tunnel IPsec ou GRE protégé par IPsec), ou si les sommes de contrôle ne sont pas calculées (comme c'est possible avec UDP IPv4). Comme décrit dans [RFC793], le calcul et la vérification de la somme de contrôle TCP sont requis dans IPv4. Le calcul et la vérification de la somme de contrôle UDP/TCP sont requis dans IPv6.

Le protocole de transmission par contrôle de flux (Stream Control Transmission Protocol, SCTP), tel que défini dans [RFC2960] et [RFC3309], utilise un algorithme CRC32C calculé uniquement sur le paquet SCTP (en-tête commun + morceaux), de sorte que l'en-tête IP n'est pas couvert. En conséquence, les NAT n'invalident pas le CRC SCTP, et le problème ne se pose pas.

Notez que comme le trafic IPsec en mode transport est protégé en intégrité et authentifié à l'aide d'une cryptographie forte, les modifications du paquet peuvent être détectées avant de vérifier les sommes de contrôle UDP/TCP. Ainsi, la vérification de la somme de contrôle ne fournit qu'une assurance contre les erreurs commises dans le traitement interne.

c) Incompatibilité entre les identifiants d'adresse IKE et NAT. Lorsque les adresses IP sont utilisées comme identifiants dans le protocole d'échange de clés Internet (Internet Key Exchange Protocol, IKE) Phase 1 [RFC2409] ou Phase 2, la modification des adresses IP source ou de destination par les NAT ou les NAT inverses entraînera une incompatibilité entre les identifiants et les adresses dans l'en-tête IP. Comme décrit dans [RFC2409], les implémentations IKE sont tenues de rejeter de tels paquets.

Afin d'éviter l'utilisation d'adresses IP comme identifiants IKE Phase 1 et Phase 2, les userID et FQDN peuvent être utilisés à la place. Lorsque l'authentification de l'utilisateur est souhaitée, un type d'ID de ID_USER_FQDN peut être utilisé, comme décrit dans [RFC2407]. Lorsque l'authentification de la machine est souhaitée, un type d'ID de ID_FQDN peut être utilisé. Dans les deux cas, il est nécessaire de vérifier que l'identifiant proposé est authentifié en conséquence du traitement d'un certificat d'entité finale, si des certificats sont échangés en Phase 1. Bien que l'utilisation des types d'identité USER_FQDN ou FQDN soit possible dans IKE, il existe des scénarios d'utilisation (par exemple, les entrées de base de données de politique de sécurité (Security Policy Database, SPD) décrivant des sous-réseaux) qui ne peuvent pas être pris en charge de cette manière.

Étant donné que l'adresse source dans l'identifiant Phase 2 est souvent utilisée pour former un sélecteur SA entrant complet à 5 tuples, l'adresse de destination, le protocole, le port source et le port de destination peuvent être utilisés dans le sélecteur afin de ne pas affaiblir le traitement SA entrant.

d) Incompatibilité entre les ports source IKE fixes et NAPT. Lorsque plusieurs hôtes derrière le NAPT initient des SA IKE vers le même répondeur, un mécanisme est nécessaire pour permettre au NAPT de démultiplexer les paquets IKE entrants du répondeur. Ceci est généralement accompli en traduisant le port source UDP IKE sur les paquets sortants de l'initiateur. Ainsi, les répondeurs doivent être capables d'accepter le trafic IKE d'un port source UDP autre que 500, et doivent répondre à ce port. Il faut faire attention à éviter un comportement imprévisible lors des re-clés. Si le port source flotté n'est pas utilisé comme port de destination pour la re-clé, le NAT peut ne pas être en mesure d'envoyer les paquets de re-clé à la destination correcte.

e) Incompatibilités entre les entrées SPD qui se chevauchent et NAT. Lorsque les hôtes initiateurs derrière un NAT utilisent leurs adresses IP source dans les identifiants Phase 2, ils peuvent négocier des entrées SPD qui se chevauchent avec la même adresse IP de répondeur. Le répondeur pourrait alors envoyer des paquets dans le mauvais SA IPsec. Cela se produit parce que pour le répondeur, les SA IPsec semblent être équivalents, car ils existent entre les mêmes points de terminaison et peuvent être utilisés pour passer le même trafic.

f) Incompatibilités entre la sélection SPI IPsec et NAT. Étant donné que le trafic IPsec ESP est crypté et donc opaque pour le NAT, le NAT doit utiliser des éléments de l'en-tête IP et IPsec pour démultiplexer le trafic IPsec entrant. La combinaison de l'adresse IP de destination, du protocole de sécurité (AH/ESP) et du SPI IPsec est généralement utilisée à cette fin.

Cependant, étant donné que les SPI sortants et entrants sont choisis indépendamment, il n'y a aucun moyen pour le NAT de déterminer quel SPI entrant correspond à quel hôte de destination simplement en inspectant le trafic sortant. Ainsi, si deux hôtes derrière le NAT tentaient de créer des SA IPsec à la même destination simultanément, il est possible que le NAT livre les paquets IPsec entrants à la mauvaise destination.

Notez que ce n'est pas une incompatibilité avec IPsec en soi, mais plutôt avec la façon dont il est généralement implémenté. Avec AH et ESP, l'hôte récepteur spécifie le SPI à utiliser pour un SA donné, un choix qui n'est significatif que pour le récepteur. Actuellement, la combinaison de l'IP de destination, du SPI et du protocole de sécurité (AH, ESP) identifie de manière unique une association de sécurité. De plus, les valeurs SPI dans la plage 1-255 sont réservées à l'IANA et peuvent être utilisées à l'avenir. Cela signifie que, lors de la négociation avec le même hôte ou passerelle externe, les hôtes internes derrière le même NAPT peuvent sélectionner la même valeur SPI, de sorte qu'un SA entrant d'un hôte est (SPI=470, Internal Dest IP=192.168.0.4) et un SA entrant d'un hôte différent est (SPI=470, Internal Dest IP=192.168.0.5). Le NAPT récepteur ne pourra pas déterminer à quel hôte interne un paquet IPsec entrant avec SPI=470 doit être transmis.

Il est également possible pour l'hôte récepteur d'allouer un SPI unique à chaque association de sécurité unicast. Dans ce cas, l'adresse IP de destination ne doit être vérifiée que pour voir si elle est "toute IP unicast valide pour cet hôte", et non vérifiée pour voir si elle est l'adresse IP de destination spécifique utilisée par l'hôte émetteur. En utilisant cette technique, le NA(P)T peut être assuré d'une faible mais non nulle chance de transmettre des paquets au mauvais hôte interne, même lorsque deux hôtes ou plus établissent des SA avec le même hôte externe.

Cette approche est complètement rétrocompatible, et nécessite seulement que l'hôte récepteur particulier apporte une modification à son allocation SPI et au code IPsec_esp_input(). Cependant, les périphériques NA(P)T peuvent ne pas être en mesure de détecter ce comportement sans problèmes associés à l'analyse des charges utiles IKE. Et un hôte peut toujours être tenu d'utiliser un SPI dans la plage réservée IANA à des fins assignées.

g) Incompatibilités entre les adresses IP intégrées et NAT. Étant donné que la charge utile est protégée en intégrité, toute adresse IP contenue dans les paquets IPsec ne sera pas traduisible par un NAT. Cela rend inefficaces les passerelles de couche application (Application Layer Gateway, ALG) implémentées dans les NAT. Les protocoles qui utilisent des adresses IP intégrées incluent FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (en option) et de nombreux jeux. Pour résoudre ce problème, il est nécessaire d'installer des ALG sur l'hôte ou la passerelle de sécurité qui peuvent fonctionner sur le trafic d'application avant l'encapsulation IPsec et après la décapsulation IPsec.

h) Directionnalité implicite de NA(P)T. Les NA(P)T nécessitent souvent qu'un paquet sortant initial les traverse afin de créer un état de mappage entrant. La directionnalité interdit l'établissement non sollicité de SA IPsec vers des hôtes derrière le NA(P)T.

i) Vérification du sélecteur SA entrant. En supposant qu'IKE négocie les sélecteurs de phase 2, le traitement SA entrant rejettera le paquet décapsulé, car [RFC2401] exige que l'adresse source d'un paquet corresponde à la valeur du sélecteur SA, que le traitement NA(P)T d'un paquet ESP modifierait.

2.2. Faiblesses d'implémentation NA(P)T

Les problèmes d'implémentation présents dans de nombreux NA(P)T comprennent:

j) Incapacité à gérer le trafic non UDP/TCP. Certains NA(P)T rejettent le trafic non UDP/TCP ou effectuent uniquement une traduction d'adresse lorsqu'un seul hôte est derrière le NAT. Ces NAPT ne peuvent pas activer le trafic SCTP, ESP (protocole 50) ou AH (protocole 51).

k) Timeouts de mappage NAT. Les NA(P)T varient dans le temps pendant lequel un mappage UDP sera maintenu en l'absence de trafic. Ainsi, même lorsque les paquets IKE peuvent être correctement traduits, l'état de traduction peut être supprimé prématurément.

l) Incapacité à gérer les fragments sortants. La plupart des NA(P)T peuvent correctement fragmenter les paquets IP sortants dans le cas où la taille du paquet IP dépasse le MTU sur l'interface sortante. Cependant, la traduction correcte des paquets sortants qui sont déjà fragmentés est difficile et la plupart des NAPT ne gèrent pas cela correctement. Comme indiqué dans la section 6.3 de [RFC3022], lorsque deux hôtes originent des paquets fragmentés vers la même destination, les identificateurs de fragment peuvent se chevaucher. Étant donné que l'hôte de destination s'appuie sur l'identificateur de fragmentation et le décalage de fragment pour le réassemblage, le résultat sera une corruption des données. Peu de NA(P)T protègent contre les collisions d'identificateurs en prenant en charge la traduction d'identificateurs. Les collisions d'identificateurs ne sont pas un problème lorsque les NAT effectuent la fragmentation, car l'identificateur de fragment ne doit être unique que dans une paire d'adresses IP source/destination.

Étant donné qu'un fragment peut être aussi petit que 68 octets [RFC791], il n'y a aucune garantie que le premier fragment contiendra un en-tête TCP complet. Ainsi, un NA(P)T cherchant à recalculer la somme de contrôle TCP peut avoir besoin de modifier un fragment ultérieur. Étant donné que les fragments peuvent être réordonnés, et que les adresses IP peuvent être intégrées et éventuellement même divisées entre les fragments, le NA(P)T devra effectuer un réassemblage avant de terminer la traduction. Peu de NA(P)T prennent en charge cela.

m) Incapacité à gérer les fragments entrants. Étant donné que seul le premier fragment contiendra généralement un en-tête IP/UDP/SCTP/TCP complet, les NAPT doivent être capables d'effectuer la traduction basée uniquement sur l'adresse IP source/dest et l'identificateur de fragment. Étant donné que les fragments peuvent être réordonnés, les en-têtes d'un identificateur de fragment donné peuvent ne pas être connus si un fragment ultérieur arrive avant le premier, et les en-têtes peuvent être divisés entre les fragments. En conséquence, le NAPT peut avoir besoin d'effectuer un réassemblage avant de terminer la traduction. Peu de NAPT prennent en charge cela. Notez qu'avec NAT, l'adresse IP source/dest suffit pour déterminer la traduction, de sorte que cela ne se produit pas. Cependant, il est possible que les en-têtes IPsec ou IKE soient divisés entre les fragments, de sorte que le réassemblage peut encore être nécessaire.

2.3. Incompatibilités des assistants

Les incompatibilités entre IPsec et la fonctionnalité "d'assistance" NAT comprennent:

n) Inspection de l'en-tête du protocole de gestion des associations de sécurité et des clés Internet (Internet Security Association and Key Management Protocol, ISAKMP). Aujourd'hui, certaines implémentations NAT tentent d'utiliser les cookies IKE pour démultiplexer le trafic IKE entrant. Comme avec le démultiplexage du port source, le démultiplexage des cookies IKE entraîne des problèmes avec le re-keying, car les re-clés de Phase 1 n'utiliseront généralement pas les mêmes cookies que le trafic antérieur.

o) Traitement spécial du port 500. Étant donné que certaines implémentations IKE ne peuvent pas gérer les ports source UDP non 500, certains NAT ne traduisent pas les paquets avec un port source UDP de 500. Cela signifie que ces NAT sont limités à un client IPsec par passerelle de destination, à moins qu'ils n'inspectent les détails de l'en-tête ISAKMP pour examiner les cookies, ce qui crée le problème noté ci-dessus.

p) Inspection de la charge utile ISAKMP. Les implémentations NA(P)T qui tentent d'analyser les charges utiles ISAKMP peuvent ne pas gérer toutes les combinaisons d'ordre de charge utile, ou prendre en charge les charges utiles vendor_id pour la négociation d'options IKE.