Aller au contenu principal

4.4.1. La base de données de politique de sécurité (The Security Policy Database, SPD)

Une SA est une construction de gestion utilisée pour appliquer une politique de sécurité au trafic traversant la frontière IPsec. Ainsi, un élément essentiel du traitement des SA est une base de données de politique de sécurité (Security Policy Database, SPD) sous-jacente qui spécifie quels services doivent être offerts aux datagrammes IP et de quelle manière. La forme de la base de données et son interface sont en dehors du cadre de cette spécification. Cependant, cette section spécifie les fonctionnalités de gestion minimales qui doivent être fournies pour permettre à un utilisateur ou à un administrateur système de contrôler si et comment IPsec est appliqué au trafic transmis ou reçu par un hôte ou transitant par une passerelle de sécurité. La SPD, ou les caches pertinents, doivent être consultés pendant le traitement de tout le trafic (entrant et sortant), y compris le trafic non protégé par IPsec, qui traverse la frontière IPsec. Cela inclut le trafic de gestion IPsec tel que IKE.

Exigences SPD​

Une implémentation IPsec DOIT avoir au moins une SPD, et elle PEUT prendre en charge plusieurs SPD, si approprié pour le contexte dans lequel l'implémentation IPsec fonctionne. Il n'y a aucune exigence de maintenir les SPD sur une base par interface, comme spécifié dans RFC 2401. Cependant, si une implémentation prend en charge plusieurs SPD, elle DOIT inclure une fonction de sélection de SPD explicite qui est invoquée pour sélectionner la SPD appropriée pour le traitement du trafic sortant. Les entrées de cette fonction sont le paquet sortant et toutes les métadonnées locales (par exemple, l'interface via laquelle le paquet est arrivé) nécessaires pour effectuer la fonction de sélection de SPD. La sortie de la fonction est un identifiant de SPD (SPD-ID).

Base de données ordonnée​

La SPD est une base de données ordonnée, cohérente avec l'utilisation de listes de contrôle d'accès (Access Control Lists, ACL) ou de filtres de paquets dans les pare-feu, routeurs, etc. L'exigence d'ordre se pose parce que les entrées se chevauchent souvent en raison de la présence de plages (non triviales) comme valeurs pour les sélecteurs. Ainsi, un utilisateur ou un administrateur DOIT pouvoir ordonner les entrées pour exprimer une politique de contrôle d'accès souhaitée. Il n'y a aucun moyen d'imposer un ordre canonique général sur les entrées SPD, en raison de l'utilisation autorisée de caractères génériques pour les valeurs de sélecteur et parce que les différents types de sélecteurs ne sont pas liés hiérarchiquement.

Choix de traitement: DISCARD, BYPASS, PROTECT​

Une SPD doit faire la distinction entre le trafic qui bénéficie d'une protection IPsec et le trafic autorisé à contourner IPsec. Cela s'applique à la protection IPsec à appliquer par un expéditeur et à la protection IPsec qui doit être présente au niveau du récepteur. Pour tout datagramme sortant ou entrant, trois choix de traitement sont possibles: DISCARD, BYPASS IPsec ou PROTECT en utilisant IPsec.

  • DISCARD: Trafic qui n'est pas autorisé à traverser la frontière IPsec (dans la direction spécifiée).
  • BYPASS: Trafic autorisé à traverser la frontière IPsec sans protection IPsec.
  • PROTECT: Trafic bénéficiant d'une protection IPsec. Pour un tel trafic, la SPD doit spécifier les protocoles de sécurité à utiliser, leur mode, les options de service de sécurité et les algorithmes cryptographiques à utiliser.

SPD-S, SPD-I, SPD-O​

Une SPD est logiquement divisée en trois parties:

  • SPD-S (trafic sécurisé secure traffic): Contient des entrées pour tout le trafic soumis à la protection IPsec.
  • SPD-O (sortant outbound): Contient des entrées pour tout le trafic sortant devant être contourné ou rejeté.
  • SPD-I (entrant inbound): Appliqué au trafic entrant qui sera contourné ou rejeté.

Ces trois parties peuvent toutes être décorrélées pour faciliter la mise en cache. Si une implémentation IPsec ne prend en charge qu'une seule SPD, alors la SPD se compose des trois parties. Si plusieurs SPD sont prises en charge, certaines d'entre elles peuvent être partielles, par exemple, certaines SPD peuvent contenir uniquement des entrées SPD-I, pour contrôler le trafic entrant contourné sur une base par interface. La division permet de consulter SPD-I sans avoir à consulter SPD-S, pour un tel trafic.

Étant donné que SPD-I n'est qu'une partie de la SPD, si un paquet recherché dans SPD-I ne peut pas être mis en correspondance avec une entrée là-bas, alors le paquet DOIT être rejeté. Notez que pour le trafic sortant, si aucune correspondance n'est trouvée dans SPD-S, alors SPD-O doit être vérifié pour voir si le trafic doit être contourné. De même, si SPD-O est vérifié en premier et qu'aucune correspondance n'est trouvée, alors SPD-S doit être vérifié. Dans une SPD ordonnée non décorrélée, les entrées pour SPD-S, SPD-I et SPD-O sont entrelacées. Il y a donc une seule recherche dans la SPD.

Entrées SPD​

Chaque entrée SPD spécifie la disposition du paquet comme BYPASS, DISCARD ou PROTECT. L'entrée est clé par une liste d'un ou plusieurs sélecteurs. La SPD contient une liste ordonnée de ces entrées. Les types de sélecteurs requis sont définis dans la section 4.4.1.1. Ces sélecteurs sont utilisés pour définir la granularité des SA créées en réponse à un paquet sortant ou en réponse à une proposition d'un pair. La structure détaillée d'une entrée SPD est décrite dans la section 4.4.1.2. Chaque SPD DEVRAIT avoir une entrée finale nominale qui correspond à tout ce qui n'est pas autrement mis en correspondance et le rejette.

La SPD DOIT permettre à un utilisateur ou à un administrateur de spécifier des entrées de politique comme suit:

  • SPD-I: Pour le trafic entrant devant être contourné ou rejeté, l'entrée se compose des valeurs des sélecteurs qui s'appliquent au trafic à contourner ou à rejeter.

  • SPD-O: Pour le trafic sortant devant être contourné ou rejeté, l'entrée se compose des valeurs des sélecteurs qui s'appliquent au trafic à contourner ou à rejeter.

  • SPD-S: Pour le trafic devant être protégé à l'aide d'IPsec, l'entrée se compose des valeurs des sélecteurs qui s'appliquent au trafic à protéger via AH ou ESP, des contrôles sur la façon de créer des SA en fonction de ces sélecteurs, et des paramètres nécessaires pour effectuer cette protection (par exemple, algorithmes, modes, etc.). Notez qu'une entrée SPD-S contient également des informations telles que l'indicateur « remplir à partir du paquet » (populate from packet, PFP) et des bits indiquant si la recherche SA utilise les adresses IP locales et distantes en plus du SPI.

Représentation de la directionnalité dans une entrée SPD​

Pour le trafic protégé par IPsec, les adresses et ports locaux et distants dans une entrée SPD sont échangés pour représenter la directionnalité, conformément aux conventions IKE. En général, les protocoles traités par IPsec ont la propriété de nécessiter des SA symétriques avec des adresses IP locales/distantes inversées. Cependant, pour ICMP, il n'y a souvent pas une telle exigence d'autorisation bidirectionnelle. Néanmoins, par souci d'uniformité et de simplicité, les entrées SPD pour ICMP sont spécifiées de la même manière que pour les autres protocoles. Notez également que pour ICMP, l'en-tête de mobilité et les fragments non initiaux, il n'y a pas de champs de port dans ces paquets.

OPAQUE et ANY​

Pour chaque sélecteur dans une entrée SPD, en plus des valeurs littérales qui définissent une correspondance, il existe deux valeurs spéciales: ANY et OPAQUE.

  • ANY: Un caractère générique qui correspond à n'importe quelle valeur dans le champ correspondant du paquet, ou qui correspond aux paquets où ce champ n'est pas présent ou est obscurci.

  • OPAQUE: Indique que le champ de sélecteur correspondant n'est pas disponible pour examen car il peut ne pas être présent dans un fragment, il n'existe pas pour le protocole de couche suivante donné, ou l'application préalable d'IPsec peut avoir chiffré la valeur.

La valeur ANY englobe la valeur OPAQUE. Ainsi, OPAQUE n'a besoin d'être utilisé que lorsqu'il est nécessaire de distinguer entre le cas d'une valeur autorisée quelconque pour un champ et l'absence ou l'indisponibilité (par exemple, en raison du chiffrement) du champ.

Sections connexes​

Dernière mise à jour le