Aller au contenu principal

4.4.1.2. Structure d'une entrée SPD (Structure of an SPD Entry)

Cette section contient une description textuelle d'une entrée SPD. De plus, l'Annexe C fournit un exemple de définition ASN.1 d'une entrée SPD.

Considérations de compatibilité IKE​

Ce texte décrit la SPD d'une manière qui est destinée à se mapper directement aux charges utiles IKE pour garantir que la politique requise par les entrées SPD puisse être négociée via IKE. Malheureusement, la sémantique de la version d'IKEv2 publiée simultanément avec ce document [Kau05] ne s'aligne pas précisément avec celles définies pour la SPD. Plus précisément, IKEv2 ne permet pas la négociation d'une seule SA qui lie plusieurs paires d'adresses et de ports locaux et distants à une seule SA. Au lieu de cela, lorsque plusieurs adresses et ports locaux et distants sont négociés pour une SA, IKEv2 les traite non pas comme des paires, mais comme des ensembles (non ordonnés) de valeurs locales et distantes qui peuvent être appariées arbitrairement.

IMPORTANT: Jusqu'à ce qu'IKE fournisse une fonctionnalité qui transmet la sémantique exprimée dans la SPD via des ensembles de sélecteurs (comme décrit ci-dessous), les utilisateurs NE DOIVENT PAS (MUST NOT) inclure plusieurs ensembles de sélecteurs dans une seule entrée SPD, sauf si l'intention de contrôle d'accès s'aligne avec la sémantique de "mélange et correspondance" d'IKE. Une implémentation PEUT (MAY) avertir les utilisateurs, pour les alerter de ce problème si les utilisateurs créent des entrées SPD avec plusieurs ensembles de sélecteurs, dont la syntaxe indique des conflits possibles avec la sémantique IKE actuelle.

Considérations sur l'interface de gestion​

L'interface de gestion peut offrir à l'utilisateur d'autres formes de saisie et d'affichage de données, par exemple, l'option d'utiliser des préfixes d'adresse ainsi que des plages, et des noms symboliques pour les protocoles, les ports, etc. (Ne confondez pas l'utilisation de noms symboliques dans une interface de gestion avec le sélecteur SPD "Nom".)

Note: Distant/Local s'appliquent uniquement aux adresses IP et aux ports, pas au type/code de message ICMP ou au type d'en-tête de mobilité. De plus, si la valeur de sélecteur symbolique réservée OPAQUE ou ANY est employée pour un type de sélecteur donné, seule cette valeur peut apparaître dans la liste pour ce sélecteur, et elle ne doit apparaître qu'une seule fois dans la liste pour ce sélecteur.

Note: ANY et OPAQUE sont des conventions de syntaxe locales —— IKEv2 négocie ces valeurs via les plages indiquées ci-dessous:

ANY:     start = 0        end = <max>
OPAQUE:  start = <max>    end = 0

Champs d'une entrée SPD​

Une SPD est une liste ordonnée d'entrées dont chacune contient les champs suivants.

o Nom (Name)​

Une liste d'identifiants. Ce quasi-sélecteur est optionnel. Les formes qui DOIVENT être prises en charge sont décrites ci-dessus dans la Section 4.4.1.1 sous "Nom".

o Drapeaux PFP (PFP flags)​

Un par sélecteur de trafic. Un drapeau donné, par exemple, pour le protocole de couche suivante, s'applique au sélecteur pertinent dans tous les "ensembles de sélecteurs" (voir ci-dessous) contenus dans une entrée SPD. Lors de la création d'une SA, chaque drapeau spécifie pour le sélecteur de trafic correspondant s'il faut instancier le sélecteur à partir du champ correspondant dans le paquet qui a déclenché la création de la SA ou à partir de la ou des valeurs dans l'entrée SPD correspondante (voir Section 4.4.1, "Comment dériver les valeurs pour une entrée SAD"). Qu'un seul drapeau soit utilisé pour, par exemple, le port source, le type/code ICMP et le type MH, ou qu'un drapeau séparé soit utilisé pour chacun, est une question locale.

Il existe des drapeaux PFP pour:

  • Adresse locale (Local Address)
  • Adresse distante (Remote Address)
  • Protocole de couche suivante (Next Layer Protocol)
  • Port local, ou type/code de message ICMP ou type d'en-tête de mobilité (selon le protocole de couche suivante)
  • Port distant, ou type/code de message ICMP ou type d'en-tête de mobilité (selon le protocole de couche suivante)

o Un à N ensembles de sélecteurs (One to N selector sets)​

Ceux-ci correspondent à la "condition" pour appliquer une action IPsec particulière. Chaque ensemble de sélecteurs contient:

  • Adresse locale (Local Address)
  • Adresse distante (Remote Address)
  • Protocole de couche suivante (Next Layer Protocol)
  • Port local, ou type/code de message ICMP ou type d'en-tête de mobilité (selon le protocole de couche suivante)
  • Port distant, ou type/code de message ICMP ou type d'en-tête de mobilité (selon le protocole de couche suivante)

Note: Le sélecteur "protocole suivant" est une valeur individuelle (contrairement aux adresses IP locales et distantes) dans une entrée d'ensemble de sélecteurs. Cela est cohérent avec la façon dont IKEv2 négocie les valeurs de sélecteur de trafic (TS) pour une SA. Cela a également du sens car on peut avoir besoin d'associer différents champs de port avec différents protocoles. Il est possible d'associer plusieurs protocoles (et ports) avec une seule SA en spécifiant plusieurs ensembles de sélecteurs pour cette SA.

o Informations de traitement (Processing info)​

Quelle action est requise —— PROTECT (protéger), BYPASS (contourner) ou DISCARD (rejeter). Il n'y a qu'une seule action qui va avec tous les ensembles de sélecteurs, pas une action séparée pour chaque ensemble. Si le traitement requis est PROTECT, l'entrée contient les informations suivantes.

Champs d'informations de traitement (pour PROTECT):

  • Mode IPsec (IPsec mode) —— mode tunnel ou mode transport

  • (si mode tunnel) adresse de tunnel locale (local tunnel address) —— Pour un hôte non mobile, s'il n'y a qu'une seule interface, c'est simple; s'il y a plusieurs interfaces, cela doit être configuré statiquement. Pour un hôte mobile, la spécification de l'adresse locale est gérée en externe à IPsec.

  • (si mode tunnel) adresse de tunnel distante (remote tunnel address) —— Il n'y a pas de méthode standard pour déterminer cela. Voir 4.5.3, "Localisation d'une passerelle de sécurité".

  • Numéro de séquence étendu (Extended Sequence Number) —— Cette SA utilise-t-elle des numéros de séquence étendus?

  • Vérification de fragment avec état (stateful fragment checking) —— Cette SA utilise-t-elle la vérification de fragment avec état? (Voir Section 7 pour plus de détails.)

  • Contourner le bit DF (Bypass DF bit) (T/F) —— applicable aux SA en mode tunnel

  • Contourner DSCP (Bypass DSCP) (T/F) ou mapper vers des valeurs DSCP non protégées (tableau) si nécessaire pour restreindre le contournement des valeurs DSCP —— applicable aux SA en mode tunnel

  • Protocole IPsec (IPsec protocol) —— AH ou ESP

  • Algorithmes (algorithms) —— lesquels utiliser pour AH, lesquels utiliser pour ESP, lesquels utiliser pour le mode combiné, classés par ordre de priorité décroissante

Note: C'est une question locale de savoir quelles informations sont conservées en ce qui concerne la gestion des SA existantes lorsque la SPD est modifiée.

Dernière mise à jour le