4.1. Définition et portée (Definition and Scope)

Une SA est une « connexion » simplex qui fournit des services de sécurité au trafic qu'elle transporte. Les services de sécurité sont fournis à une SA par l'utilisation d'AH ou d'ESP, mais pas les deux. Si les protections AH et ESP sont toutes deux appliquées à un flux de trafic, alors deux SA doivent être créées et coordonnées pour effectuer la protection par application itérée des protocoles de sécurité. Pour sécuriser une communication bidirectionnelle typique entre deux systèmes compatibles IPsec, une paire de SA (une dans chaque direction) est requise. IKE crée explicitement des paires de SA en reconnaissance de cette exigence d'utilisation courante.

Identification SA

Pour une SA utilisée pour transporter du trafic unicast, l'indice de paramètres de sécurité (Security Parameters Index, SPI) seul suffit pour spécifier une SA. (Pour des informations sur le SPI, voir l'annexe A et les spécifications AH et ESP [Ken05b, Ken05a].) Cependant, en tant que question locale, une implémentation peut choisir d'utiliser le SPI en conjonction avec le type de protocole IPsec (AH ou ESP) pour l'identification de la SA. Si une implémentation IPsec prend en charge le multicast, elle DOIT prendre en charge les SA multicast en utilisant l'algorithme ci-dessous pour mapper les datagrammes IPsec entrants vers les SA. Les implémentations qui ne prennent en charge que le trafic unicast n'ont pas besoin d'implémenter cet algorithme de démultiplexage.

Considérations sur les SA multicast

Dans de nombreuses architectures multicast sécurisées, par exemple [RFC3740], un contrôleur de groupe/serveur de clés (Group Controller/Key Server) central attribue unilatéralement le SPI de l'association de sécurité de groupe (Group Security Association, GSA). Cette attribution de SPI n'est pas négociée ni coordonnée avec les sous-systèmes de gestion de clés (par exemple, IKE) qui résident dans les systèmes d'extrémité individuels qui constituent le groupe. Par conséquent, il est possible qu'une GSA et une SA unicast utilisent simultanément le même SPI. Une implémentation IPsec capable de multicast DOIT démultiplexer correctement le trafic entrant même dans le contexte de collisions de SPI.

Chaque entrée dans la base de données SA (SA Database, SAD) (section 4.4.2) doit indiquer si la recherche de SA utilise l'adresse IP de destination, ou les adresses IP de destination et source, en plus du SPI. Pour les SA multicast, le champ de protocole n'est pas utilisé pour les recherches de SA. Pour chaque paquet entrant protégé par IPsec, une implémentation doit effectuer sa recherche de la SAD de telle sorte qu'elle trouve l'entrée qui correspond à l'identifiant SA « le plus long ». Dans ce contexte, si deux entrées SAD ou plus correspondent en fonction de la valeur SPI, alors l'entrée qui correspond également en fonction de l'adresse de destination, ou des adresses de destination et source (comme indiqué dans l'entrée SAD) est la correspondance « la plus longue ». Cela implique un ordre logique de recherche de la SAD comme suit :

1. Rechercher dans la SAD une correspondance sur la combinaison de SPI, adresse de destination et adresse source. Si une entrée SAD correspond, alors traiter le paquet entrant avec cette entrée SAD correspondante. Sinon, passer à l'étape 2.

2. Rechercher dans la SAD une correspondance sur le SPI et l'adresse de destination. Si l'entrée SAD correspond, alors traiter le paquet entrant avec cette entrée SAD correspondante. Sinon, passer à l'étape 3.

3. Rechercher dans la SAD une correspondance sur le SPI uniquement si le récepteur a choisi de maintenir un espace SPI unique pour AH et ESP, et sur le SPI et le protocole, sinon. Si une entrée SAD correspond, alors traiter le paquet entrant avec cette entrée SAD correspondante. Sinon, rejeter le paquet et enregistrer un événement auditable.

En pratique, une implémentation peut choisir n'importe quelle méthode (ou aucune) pour accélérer cette recherche, bien que son comportement visible de l'extérieur DOIVE être fonctionnellement équivalent à avoir effectué une recherche dans la SAD dans l'ordre ci-dessus. Par exemple, une implémentation logicielle pourrait indexer dans une table de hachage par le SPI. Les entrées SAD dans la liste chaînée de chaque compartiment de table de hachage pourraient être maintenues triées pour avoir ces entrées SAD avec les identifiants SA les plus longs en premier dans cette liste chaînée. Les entrées SAD ayant les identifiants SA les plus courts pourraient être triées de sorte qu'elles soient les dernières entrées de la liste chaînée. Une implémentation matérielle peut être en mesure d'effectuer intrinsèquement la recherche de correspondance la plus longue, en utilisant des fonctionnalités de mémoire adressable par contenu ternaire (Ternary Content-Addressable Memory, TCAM) couramment disponibles.

L'indication de savoir si la correspondance d'adresses source et destination est requise pour mapper le trafic IPsec entrant vers les SA DOIT être définie soit comme effet secondaire de la configuration manuelle de SA, soit via négociation à l'aide d'un protocole de gestion de SA, par exemple, IKE ou domaine d'interprétation de groupe (Group Domain of Interpretation, GDOI) [RFC3547]. Typiquement, les groupes multicast spécifique à la source (Source-Specific Multicast, SSM) [HC03] utilisent un identifiant SA à 3 tuples composé d'un SPI, d'une adresse multicast de destination et d'une adresse source. Une SA de groupe multicast à source quelconque (Any-Source Multicast) ne nécessite qu'un SPI et une adresse multicast de destination comme identifiant.

QoS et SA multiples

Si différentes classes de trafic (distinguées par les bits de point de code de services différenciés (Differentiated Services Code Point, DSCP) [NiBlBaBL98], [Gro02]) sont envoyées sur la même SA, et si le récepteur utilise la fonctionnalité anti-rejeu optionnelle disponible dans AH et ESP, cela pourrait entraîner un rejet inapproprié de paquets de priorité inférieure en raison du mécanisme de fenêtrage utilisé par cette fonctionnalité. Par conséquent, un expéditeur DEVRAIT placer le trafic de différentes classes, mais avec les mêmes valeurs de sélecteur, sur différentes SA pour prendre en charge de manière appropriée la qualité de service (Quality of Service, QoS). Pour permettre cela, l'implémentation IPsec DOIT permettre l'établissement et la maintenance de plusieurs SA entre un expéditeur et un récepteur donnés, avec les mêmes sélecteurs. La distribution du trafic entre ces SA parallèles pour prendre en charge la QoS est déterminée localement par l'expéditeur et n'est pas négociée par IKE. Le récepteur DOIT traiter les paquets des différentes SA sans préjugé. Ces exigences s'appliquent aux SA en mode transport et en mode tunnel. Dans le cas des SA en mode tunnel, les valeurs DSCP en question apparaissent dans l'en-tête IP interne. En mode transport, la valeur DSCP peut changer en cours de route, mais cela ne devrait pas causer de problèmes en ce qui concerne le traitement IPsec car la valeur n'est pas utilisée pour la sélection de SA et NE DOIT PAS être vérifiée dans le cadre de la validation SA/paquet. Cependant, si un réordonnancement significatif de paquets se produit dans une SA, par exemple, à la suite de changements de valeurs DSCP en cours de route, cela peut déclencher le rejet de paquets par un récepteur en raison de l'application du mécanisme anti-rejeu.

DISCUSSION : Bien que les champs DSCP [NiBlBaBL98, Gro02] et notification de congestion explicite (Explicit Congestion Notification, ECN) [RaFlBl01] ne soient pas des « sélecteurs », tel que ce terme est utilisé dans cette architecture, l'expéditeur aura besoin d'un mécanisme pour diriger les paquets avec un ensemble donné de valeurs DSCP vers la SA appropriée. Ce mécanisme pourrait être appelé « classificateur » (classifier).

Mode transport vs mode tunnel

Comme indiqué ci-dessus, deux types de SA sont définis : le mode transport et le mode tunnel. IKE crée des paires de SA, donc pour simplifier, nous choisissons d'exiger que les deux SA d'une paire soient du même mode, transport ou tunnel.

SA en mode transport

Une SA en mode transport est une SA généralement employée entre une paire d'hôtes pour fournir des services de sécurité de bout en bout. Lorsque la sécurité est souhaitée entre deux systèmes intermédiaires le long d'un chemin (par opposition à l'utilisation de bout en bout d'IPsec), le mode transport PEUT être utilisé entre des passerelles de sécurité ou entre une passerelle de sécurité et un hôte. Dans le cas où le mode transport est utilisé entre des passerelles de sécurité ou entre une passerelle de sécurité et un hôte, le mode transport peut être utilisé pour prendre en charge le tunneling IP-dans-IP (par exemple, IP-in-IP [Per96] ou tunneling d'encapsulation de routage générique (Generic Routing Encapsulation, GRE) [FaLiHaMeTr00] ou routage dynamique [ToEgWa04]) sur des SA en mode transport. Pour clarifier, l'utilisation du mode transport par un système intermédiaire (par exemple, une passerelle de sécurité) n'est autorisée que lorsqu'elle est appliquée à des paquets dont l'adresse source (pour les paquets sortants) ou l'adresse de destination (pour les paquets entrants) est une adresse appartenant au système intermédiaire lui-même. Les fonctions de contrôle d'accès qui constituent une partie importante d'IPsec sont considérablement limitées dans ce contexte, car elles ne peuvent pas être appliquées aux en-têtes de bout en bout des paquets qui traversent une SA en mode transport utilisée de cette manière. Ainsi, cette façon d'utiliser le mode transport doit être évaluée attentivement avant d'être employée dans un contexte spécifique.

En IPv4, un en-tête de protocole de sécurité en mode transport apparaît immédiatement après l'en-tête IP et toutes les options, et avant tous les protocoles de couche suivante (par exemple, TCP ou UDP). En IPv6, l'en-tête de protocole de sécurité apparaît après l'en-tête IP de base et les en-têtes d'extension sélectionnés, mais peut apparaître avant ou après les options de destination ; il DOIT apparaître avant les protocoles de couche suivante (par exemple, TCP, UDP, protocole de transmission de contrôle de flux (Stream Control Transmission Protocol, SCTP)). Dans le cas d'ESP, une SA en mode transport fournit des services de sécurité uniquement pour ces protocoles de couche suivante, pas pour l'en-tête IP ou les en-têtes d'extension précédant l'en-tête ESP. Dans le cas d'AH, la protection est également étendue aux portions sélectionnées de l'en-tête IP qui le précède, aux portions sélectionnées des en-têtes d'extension et aux options sélectionnées (contenues dans l'en-tête IPv4, l'en-tête d'extension IPv6 saut par saut ou les en-têtes d'extension de destination IPv6). Pour plus de détails sur la couverture offerte par AH, voir la spécification AH [Ken05b].

SA en mode tunnel

Une SA en mode tunnel est essentiellement une SA appliquée à un tunnel IP, avec les contrôles d'accès appliqués aux en-têtes du trafic à l'intérieur du tunnel. Deux hôtes PEUVENT établir une SA en mode tunnel entre eux. Outre les deux exceptions ci-dessous, chaque fois que l'une des extrémités d'une association de sécurité est une passerelle de sécurité, la SA DOIT être en mode tunnel. Ainsi, une SA entre deux passerelles de sécurité est généralement une SA en mode tunnel, tout comme une SA entre un hôte et une passerelle de sécurité. Les deux exceptions sont les suivantes.

• Lorsque le trafic est destiné à une passerelle de sécurité, par exemple, les commandes du protocole simple de gestion de réseau (Simple Network Management Protocol, SNMP), la passerelle de sécurité agit en tant qu'hôte et le mode transport est autorisé. Dans ce cas, la SA se termine à une fonction hôte (gestion) au sein d'une passerelle de sécurité et mérite donc un traitement différent.

• Comme indiqué ci-dessus, les passerelles de sécurité PEUVENT prendre en charge une SA en mode transport pour fournir une sécurité au trafic IP entre deux systèmes intermédiaires le long d'un chemin, par exemple, entre un hôte et une passerelle de sécurité ou entre deux passerelles de sécurité.

Plusieurs préoccupations motivent l'utilisation du mode tunnel pour une SA impliquant une passerelle de sécurité. Par exemple, s'il existe plusieurs chemins (par exemple, via différentes passerelles de sécurité) vers la même destination derrière une passerelle de sécurité, il est important qu'un paquet IPsec soit envoyé à la passerelle de sécurité avec laquelle la SA a été négociée. De même, un paquet qui pourrait être fragmenté en cours de route doit avoir tous les fragments livrés à la même instance IPsec pour réassemblage avant le traitement cryptographique. De plus, lorsqu'un fragment est traité par IPsec et transmis, puis fragmenté en cours de route, il est essentiel qu'il y ait des en-têtes internes et externes pour conserver les données d'état de fragmentation pour les formats de paquets pré- et post-IPsec. Il existe donc plusieurs raisons d'utiliser le mode tunnel lorsque l'une des extrémités d'une SA est une passerelle de sécurité. (L'utilisation d'un tunnel IP-dans-IP en conjonction avec le mode transport peut également résoudre ces problèmes de fragmentation. Cependant, cette configuration limite la capacité d'IPsec à appliquer des politiques de contrôle d'accès sur le trafic.)

Note : AH et ESP ne peuvent pas être appliqués en utilisant le mode transport aux paquets IPv4 qui sont des fragments. Seul le mode tunnel peut être utilisé dans de tels cas. Pour IPv6, il serait possible de transporter un fragment en clair sur une SA en mode transport ; cependant, pour des raisons de simplicité, cette restriction s'applique également aux paquets IPv6. Voir la section 7 pour plus de détails sur la gestion des fragments en clair du côté protégé de la barrière IPsec.

Pour une SA en mode tunnel, il existe un en-tête IP « externe » qui spécifie la source et la destination de traitement IPsec, ainsi qu'un en-tête IP « interne » qui spécifie la source et la destination (apparemment) ultimes pour le paquet. L'en-tête de protocole de sécurité apparaît après l'en-tête IP externe et avant l'en-tête IP interne. Si AH est utilisé en mode tunnel, des portions de l'en-tête IP externe bénéficient de la protection (comme ci-dessus), ainsi que l'ensemble du paquet IP tunnelé (c'est-à-dire que tout l'en-tête IP interne est protégé, ainsi que les protocoles de couche suivante). Si ESP est utilisé, la protection n'est offerte qu'au paquet tunnelé, pas à l'en-tête externe.

Exigences d'implémentation

En résumé,

a) Une implémentation d'IPsec pour hôte DOIT prendre en charge le mode transport et le mode tunnel. Cela est vrai pour les implémentations natives, BITS et BITW pour les hôtes.

b) Une passerelle de sécurité DOIT prendre en charge le mode tunnel et PEUT prendre en charge le mode transport. Si elle prend en charge le mode transport, cela ne devrait être utilisé que lorsque la passerelle de sécurité agit en tant qu'hôte, par exemple, pour la gestion du réseau, ou pour fournir une sécurité entre deux systèmes intermédiaires le long d'un chemin.