2.9. Traffic Selector Negotiation

Lorsqu'un sous-système IPsec conforme à RFC4301 reçoit un paquet IP correspondant à un sélecteur « protect » dans la SPD, il applique IPsec. Sans SA existante, IKE la crée. La maintenance de la SPD est hors scope d'IKE (certaines implémentations peuvent la mettre à jour, voir 1.1.3).

Les charges Traffic Selector (TS) transmettent une partie de la SPD au pair. Elles DOIVENT être fournies par la SPD à IKE (ex. : PF_KEY [PFKEY], SADB_ACQUIRE). Elles précisent les critères des paquets qui transiteront sur la nouvelle SA.

Cela peut servir de cohérence ou guider une mise à jour dynamique de la SPD.

Deux charges TS apparaissent dans chaque message de l'échange créant une paire de Child SA. Chaque charge contient un ou plusieurs sélecteurs (plage d'adresses IPv4/IPv6, plage de ports, ID de protocole IP).

La première est TSi (initiateur), la seconde TSr (répondant). TSi décrit la source du trafic depuis l'initiateur de la paire (ou la destination vers l'initiateur). TSr la destination vers le répondant (ou la source depuis le répondant). Exemple : tunneliser 198.51.100.* vers 192.0.2.* : une plage par charge ; si le répondant accepte, il renvoie les mêmes TS.

IKEv2 permet au répondant de choisir un sous-ensemble proposé (mises à jour asymétriques de configuration, ou politiques volontairement différentes).

Le répondant réduit les TS à un sous-ensemble non vide du proposé. Un type inconnu est ignoré et n'apparaît pas dans l'ensemble réduit.

Si la demande vient d'un paquet de données, l'initiateur DEVRAIT mettre en premier dans TSi et TSr un TS très spécifique avec les adresses du paquet déclencheur, puis des plages plus larges. Sans paquet déclencheur (ex. : démarrage), les premières entrées peuvent être des plages.

Réduction côté répondant :

Aucune partie acceptable → TS_UNACCEPTABLE.
Tout acceptable → renvoyer les mêmes TSi/TSr.
Premier sélecteur acceptable → réduire en incluant le premier choix de l'initiateur (ex. : hôte unique 198.51.100.43).
Sinon → sous-ensemble acceptable quelconque.

Si plusieurs sous-ensembles disjoints sont acceptables, le répondant en choisit un arbitrairement et PEUT ajouter ADDITIONAL_TS_POSSIBLE (sans données). N'arrive que si configurations diffèrent.

Si la politique exige une SA par paire d'adresses mais que l'initiateur n'a pas fourni de premier TS précis, le répondant devine ou envoie SINGLE_PAIR_REQUIRED : la demande n'accepte qu'une seule paire d'adresses ; le demandeur doit restreindre au trafic réel.

Peu de politiques exigent une SA par paire ; si seule une partie des TS est acceptable, les répondants DEVRAIENT réduire plutôt que SINGLE_PAIR_REQUIRED.

2.9.1. Traffic Selectors Violating Own Policy

L'initiateur ne doit pas proposer des TS violant sa propre politique sous peine de perte de trafic valide. Les politiques décorrélées [IPSECARCH] évitent ce cas.

Exemple : A envoie 198.51.100.66 via B en AES et le reste du /24 en 3DES ; B accepte tout. Si A propose 3DES avec TSr couvrant tout le /24, B peut envoyer depuis .66 vers A qui jette le trafic. A aurait dû partitionner TSr en excluant .66 de la SA 3DES.

En général, si l'initiateur propose une SA pour X mais refuse une partie X' avec cette SA tout en acceptant X' avec une autre SA', le trafic peut être perdu car le répondant peut choisir l'une ou l'autre SA.

2.9.2. Traffic Selectors in Rekeying

Le rekey remplace un Child SA : une nouvelle SA avec des sélecteurs plus étroits ferait tomber du trafic autorisé sur l'ancienne, contraire au principe de remplacement. La nouvelle SA NE DOIT PAS avoir des sélecteurs plus étroits. Un besoin plus étroit signifie changement de politique : l'ancienne SA aurait dû être supprimée après le changement.

Lors d'un rekey, les TS proposés DEVRAIENT être identiques ou sur-ensemble de l'ancien Child SA (politique active décorrélée). Le répondant NE DOIT PAS réduire en dessous de l'étendue actuellement utilisée.

Comme le rekey ne peut pas rétrécir, les sélecteurs issus du paquet ne sont pas nécessaires et NE DEVRAIENT PAS être envoyés.