2.9. Négociation des sélecteurs de trafic
2.9. Négociation des sélecteurs de trafic
Lorsqu'un sous-système IPsec conforme à la RFC 4301 reçoit un paquet IP correspondant à un sélecteur "protect" dans sa base de données de politique de sécurité (SPD), le sous-système protège ce paquet avec IPsec. Lorsqu'aucune SA n'existe encore, il est de la responsabilité de IKE de la créer. La maintenance de la SPD d'un système est hors du champ de IKE, bien que certaines implémentations puissent mettre à jour leur SPD en relation avec l'exécution de IKE (pour un scénario d'exemple, voir la section 1.1.3).
Les payloads Traffic Selector (TS) permettent aux points terminaux de communiquer une partie des informations de leur SPD à leurs pairs. Celles-ci DOIVENT être communiquées à IKE depuis la SPD (par exemple, l'API PF_KEY [PFKEY] utilise le message SADB_ACQUIRE). Les payloads TS spécifient les critères de sélection pour les paquets qui seront transférés sur la SA nouvellement établie. Cela peut servir de vérification de cohérence dans certains scénarios pour s'assurer que les SPD sont cohérentes. Dans d'autres, cela guide la mise à jour dynamique de la SPD.
Deux payloads TS apparaissent dans chacun des messages de l'échange qui crée une paire de Child SA. Chaque payload TS contient un ou plusieurs sélecteurs de trafic. Chaque sélecteur de trafic consiste en une plage d'adresses (IPv4 ou IPv6), une plage de ports et un ID de protocole IP.
Le premier des deux payloads TS est appelé TSi (Traffic Selector-initiator). Le second est appelé TSr (Traffic Selector-responder). TSi spécifie l'adresse source du trafic transféré depuis (ou l'adresse de destination du trafic transféré vers) l'initiateur de la paire de Child SA. TSr spécifie l'adresse de destination du trafic transféré vers (ou l'adresse source du trafic transféré depuis) le répondeur de la paire de Child SA. Par exemple, si l'initiateur original demande la création d'une paire de Child SA, et souhaite tunneliser tout le trafic du sous-réseau 198.51.100.* du côté de l'initiateur vers le sous-réseau 192.0.2.* du côté du répondeur, l'initiateur inclurait un seul sélecteur de trafic dans chaque payload TS. TSi spécifierait la plage d'adresses (198.51.100.0 - 198.51.100.255) et TSr spécifierait la plage d'adresses (192.0.2.0 - 192.0.2.255). En supposant que la proposition était acceptable pour le répondeur, il renverrait des payloads TS identiques.
IKEv2 permet au répondeur de choisir un sous-ensemble du trafic proposé par l'initiateur. Cela peut se produire lorsque la configuration des deux points terminaux est en cours de mise à jour mais qu'une seule extrémité a reçu la nouvelle information. Puisque les deux points terminaux peuvent être configurés par des personnes différentes, l'incompatibilité peut persister sur une longue période même en l'absence d'erreurs. Cela permet également des configurations intentionnellement différentes, comme lorsqu'une extrémité est configurée pour tunneliser toutes les adresses et dépend de l'autre extrémité pour avoir la liste à jour.
Lorsque le répondeur choisit un sous-ensemble du trafic proposé par l'initiateur, il réduit les sélecteurs de trafic à un sous-ensemble de la proposition de l'initiateur (à condition que l'ensemble ne devienne pas l'ensemble vide). Si le type de sélecteur de trafic proposé est inconnu, le répondeur ignore ce sélecteur de trafic, de sorte que le type inconnu n'est pas retourné dans l'ensemble réduit.
Pour permettre au répondeur de choisir la plage appropriée dans ce cas, si l'initiateur a demandé la SA à cause d'un paquet de données, l'initiateur DEVRAIT inclure comme premier sélecteur de trafic dans chacun de TSi et TSr un sélecteur de trafic très spécifique incluant les adresses dans le paquet déclenchant la demande. Dans l'exemple, l'initiateur inclurait dans TSi deux sélecteurs de trafic : le premier contenant la plage d'adresses (198.51.100.43 - 198.51.100.43) et le port source et le protocole IP du paquet, et le second contenant (198.51.100.0 - 198.51.100.255) avec tous les ports et tous les protocoles IP. L'initiateur inclurait de manière similaire deux sélecteurs de trafic dans TSr. Si l'initiateur crée la paire de Child SA non pas en réponse à un paquet arrivant, mais plutôt, par exemple, au démarrage, alors il peut n'y avoir aucune adresse spécifique que l'initiateur préfère pour le tunnel initial par rapport à une autre. Dans ce cas, les premières valeurs dans TSi et TSr peuvent être des plages plutôt que des valeurs spécifiques.
Le répondeur effectue la réduction comme suit :
o Si la politique du répondeur ne lui permet pas d'accepter aucune partie des sélecteurs de trafic proposés, il répond avec un message de notification TS_UNACCEPTABLE.
o Si la politique du répondeur permet l'ensemble du trafic couvert par TSi et TSr, aucune réduction n'est nécessaire, et le répondeur PEUT renvoyer les mêmes valeurs TSi et TSr.
o Si la politique du répondeur lui permet d'accepter le premier sélecteur de TSi et TSr, alors le répondeur DOIT réduire les sélecteurs de trafic à un sous-ensemble incluant les premiers choix de l'initiateur. Dans l'exemple ci-dessus, le répondeur pourrait répondre avec TSi étant (198.51.100.43 - 198.51.100.43) avec tous les ports et tous les protocoles IP.
o Si la politique du répondeur ne lui permet pas d'accepter le premier sélecteur de TSi et TSr, le répondeur réduit à un sous-ensemble acceptable de TSi et TSr.
Lorsque la réduction est effectuée, il peut y avoir plusieurs sous-ensembles acceptables mais dont l'union ne l'est pas. Dans ce cas, le répondeur en choisit arbitrairement un, et PEUT inclure une notification ADDITIONAL_TS_POSSIBLE dans la réponse. La notification ADDITIONAL_TS_POSSIBLE affirme que le répondeur a réduit les sélecteurs de trafic proposés mais que d'autres sélecteurs de trafic auraient également été acceptables, bien que seulement dans une SA séparée. Il n'y a aucune donnée associée à ce type de notification. Ce cas ne se produira que lorsque l'initiateur et le répondeur sont configurés différemment l'un de l'autre. Si l'initiateur et le répondeur s'accordent sur la granularité des tunnels, l'initiateur ne demandera jamais un tunnel plus large que ce que le répondeur acceptera.
Il est possible que la politique du répondeur contienne plusieurs plages plus petites, toutes englobées par le sélecteur de trafic de l'initiateur, et que la politique du répondeur soit que chacune de ces plages devrait être envoyée sur une SA différente. En poursuivant l'exemple ci-dessus, le répondeur pourrait avoir une politique d'acceptation de tunneliser ces adresses vers et depuis l'initiateur, mais pourrait exiger que chaque paire d'adresses soit sur une Child SA séparément négociée. Si l'initiateur n'a pas généré sa demande basée sur le paquet, mais (par exemple) au démarrage, il n'y aurait pas les tout premiers sélecteurs de trafic très spécifiques aidant le répondeur à sélectionner la plage correcte. Il n'y aurait aucun moyen pour le répondeur de déterminer quelle paire d'adresses devrait être incluse dans ce tunnel, et il devrait deviner ou rejeter la demande avec un message de notification SINGLE_PAIR_REQUIRED.
L'erreur SINGLE_PAIR_REQUIRED indique qu'une demande CREATE_CHILD_SA est inacceptable parce que son émetteur n'est disposé à accepter que des sélecteurs de trafic spécifiant une seule paire d'adresses. Le demandeur est censé répondre en demandant une SA uniquement pour le trafic spécifique qu'il essaie de transférer.
Peu d'implémentations auront des politiques nécessitant des SA séparées pour chaque paire d'adresses. Pour cette raison, si seulement certaines parties des TSi et TSr proposés par l'initiateur sont acceptables pour le répondeur, les répondeurs DEVRAIENT réduire les sélecteurs à un sous-ensemble acceptable plutôt que d'utiliser SINGLE_PAIR_REQUIRED.
2.9.1. Sélecteurs de trafic enfreignant sa propre politique
Lors de la création d'une nouvelle SA, l'initiateur doit éviter de proposer des sélecteurs de trafic qui enfreignent sa propre politique. Si cette règle n'est pas suivie, du trafic valide peut être abandonné. Si vous utilisez les politiques décorrélées de [IPSECARCH], ce type de violation de politique ne peut pas se produire.
Ceci est mieux illustré par un exemple. Supposons que l'hôte A a une politique dont l'effet est que le trafic vers 198.51.100.66 est envoyé via l'hôte B chiffré en utilisant AES, et le trafic vers tous les autres hôtes dans 198.51.100.0/24 est également envoyé via B, mais doit utiliser 3DES. Supposons également que l'hôte B accepte toute combinaison de AES et 3DES.
Si l'hôte A propose maintenant une SA qui utilise 3DES, et inclut un TSr contenant (198.51.100.0-198.51.100.255), cela sera accepté par l'hôte B. Maintenant, l'hôte B peut également utiliser cette SA pour envoyer du trafic depuis 198.51.100.66, mais ces paquets seront abandonnés par A puisqu'il exige l'utilisation de AES pour ce trafic. Même si l'hôte A crée une nouvelle SA uniquement pour 198.51.100.66 qui utilise AES, l'hôte B peut continuer librement à utiliser la première SA pour le trafic. Dans cette situation,
lors de la proposition de la SA, l'hôte A aurait dû suivre sa propre politique, et inclus un TSr contenant ((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) à la place.
En général, si (1) l'initiateur fait une proposition "pour le trafic X (TSi/TSr), faire SA", et (2) pour un sous-ensemble X' de X, l'initiateur n'accepte pas réellement le trafic X' avec SA, et (3) l'initiateur serait disposé à accepter le trafic X' avec une SA' (!=SA), du trafic valide peut être abandonné inutilement puisque le répondeur peut appliquer soit SA soit SA' au trafic X'.