Aller au contenu principal

1.1. Usage Scenarios

1.1 Usage Scenarios​

IKE sert à négocier des SA ESP ou AH dans plusieurs scénarios distincts, chacun avec ses exigences particulières.

1.1.1. Security Gateway to Security Gateway in Tunnel Mode​

               +-+-+-+-+-+            +-+-+-+-+-+
               |         | IPsec      |         |
   Protected    |Tunnel   | tunnel     |Tunnel   |     Protected
   Subnet   <-->|Endpoint |<---------->|Endpoint |<--> Subnet
               |         |            |         |
               +-+-+-+-+-+            +-+-+-+-+-+

          Figure 1: Security Gateway to Security Gateway Tunnel

Dans ce scénario, aucune extrémité de la connexion IP n'implémente IPsec, mais des nœuds réseau entre elles protègent le trafic sur une partie du chemin. La protection est transparente pour les extrémités et repose sur le routage ordinaire pour acheminer les paquets vers les extrémités du tunnel pour traitement. Chaque extrémité annoncerait l'ensemble des adresses « derrière » elle, et les paquets seraient envoyés en mode tunnel où l'en-tête IP interne contiendrait les adresses IP des extrémités réelles.

1.1.2. Endpoint-to-Endpoint Transport Mode​

  +-+-+-+-+-+                                          +-+-+-+-+-+
  |         |                 IPsec transport          |         |
  |Protected|                or tunnel mode SA         |Protected|
  |Endpoint |<---------------------------------------->|Endpoint |
  |         |                                          |         |
  +-+-+-+-+-+                                          +-+-+-+-+-+

                     Figure 2: Endpoint to Endpoint

Dans ce scénario, les deux extrémités de la connexion IP implémentent IPsec, comme exigé des hôtes dans [IPSECARCH]. Le mode transport sera couramment utilisé sans en-tête IP interne. Une seule paire d'adresses sera négociée pour les paquets protégés par cette SA. Ces extrémités PEUVENT implémenter des contrôles d'accès au niveau application d'après les identités IPsec authentifiées des participants. Ce scénario permet la sécurité de bout en bout qui est un principe directeur d'Internet depuis [ARCHPRINC], [TRANSPARENCY], et une manière de limiter les problèmes inhérents à la complexité des réseaux notés par [ARCHGUIDEPHIL]. Bien que ce scénario puisse ne pas s'appliquer pleinement à l'Internet IPv4, il a été déployé avec succès dans des cas précis au sein d'intranets avec IKEv1. Il devrait être plus largement activé lors de la transition vers IPv6 et avec l'adoption d'IKEv2.

Il est possible dans ce scénario qu'une ou les deux extrémités protégées soient derrière un nœud de traduction d'adresse réseau (NAT), auquel cas les paquets tunnelisés devront être encapsulés UDP afin que les numéros de port dans les en-têtes UDP identifient les extrémités individuelles « derrière » le NAT (voir section 2.23).

1.1.3. Endpoint to Security Gateway in Tunnel Mode​

  +-+-+-+-+-+                          +-+-+-+-+-+
  |         |         IPsec            |         |     Protected
  |Protected|         tunnel           |Tunnel   |     Subnet
  |Endpoint |<------------------------>|Endpoint |<--- and/or
  |         |                          |         |     Internet
  +-+-+-+-+-+                          +-+-+-+-+-+

              Figure 3: Endpoint to Security Gateway Tunnel

Dans ce scénario, une extrémité protégée (typiquement un ordinateur portable itinérant) se reconnecte à son réseau d'entreprise via un tunnel protégé par IPsec. Il peut n'utiliser ce tunnel que pour accéder aux informations sur le réseau d'entreprise, ou tunneliser tout son trafic via le réseau d'entreprise pour bénéficier de la protection du pare-feu d'entreprise contre les attaques Internet. Dans les deux cas, l'extrémité protégée souhaite une adresse IP associée à la passerelle de sécurité pour que les paquets qui lui sont retournés arrivent à la passerelle et soient tunnelisés en retour. Cette adresse IP peut être statique ou allouée dynamiquement par la passerelle. Pour ce dernier cas, IKEv2 inclut un mécanisme (les configuration payloads) permettant à l'initiator de demander une adresse IP appartenant à la passerelle pour la durée de sa SA.

Dans ce scénario, les paquets utilisent le mode tunnel. Sur chaque paquet de l'extrémité protégée, l'en-tête IP externe contient l'adresse source associée à sa position actuelle (c'est-à-dire l'adresse qui achemine le trafic directement vers l'extrémité), tandis que l'en-tête IP interne contient l'adresse source assignée par la passerelle (c'est-à-dire celle qui achemine le trafic vers la passerelle pour transmission vers l'extrémité). L'adresse de destination externe est toujours celle de la passerelle, tandis que l'adresse de destination interne est la destination ultime du paquet.

Dans ce scénario, il est possible que l'extrémité protégée soit derrière un NAT. Dans ce cas, l'adresse IP vue par la passerelle ne sera pas la même que celle envoyée par l'extrémité protégée, et les paquets devront être encapsulés UDP pour être correctement acheminés. L'interaction avec les NAT est détaillée à la section 2.23.

1.1.4. Other Scenarios​

D'autres scénarios sont possibles, de même que des combinaisons imbriquées des précédents. Un exemple notable combine des aspects des sections 1.1.1 et 1.1.3. Un sous-réseau peut effectuer tous ses accès externes via une passerelle de sécurité distante en utilisant un tunnel IPsec, où les adresses du sous-réseau sont routées vers la passerelle par le reste d'Internet. Un exemple serait le réseau domestique d'une personne virtuellement sur Internet avec des adresses IP statiques alors que la connectivité est fournie par un FAI qui assigne une seule adresse IP dynamique à la passerelle de sécurité de l'utilisateur (où les adresses IP statiques et un relais IPsec sont fournis par un tiers situé ailleurs).

Dernière mise à jour le