4.4. Principales bases de données IPsec (Major IPsec Databases)
De nombreux détails associés au traitement du trafic IP dans une implémentation IPsec sont en grande partie une question locale, non soumise à la normalisation. Cependant, certains aspects externes du traitement doivent être normalisés pour garantir l'interopérabilité et fournir une capacité de gestion minimale essentielle pour une utilisation productive d'IPsec. Cette section décrit un modèle général pour le traitement du trafic IP relatif à la fonctionnalité IPsec, pour soutenir ces objectifs d'interopérabilité et de fonctionnalité. Le modèle décrit ci-dessous est nominal ; les implémentations n'ont pas besoin de correspondre aux détails de ce modèle tels que présentés, mais le comportement externe des implémentations DOIT correspondre aux caractéristiques observables de l'extérieur de ce modèle pour être conforme.
Il existe trois bases de données nominales dans ce modèle : la base de données de politique de sécurité (Security Policy Database, SPD), la base de données d'association de sécurité (Security Association Database, SAD) et la base de données d'autorisation des pairs (Peer Authorization Database, PAD). La première spécifie les politiques qui déterminent la disposition de tout le trafic IP entrant ou sortant d'un hôte ou d'une passerelle de sécurité (section 4.4.1). La deuxième base de données contient des paramètres associés à chaque SA établie (avec clé) (section 4.4.2). La troisième base de données, le PAD, fournit un lien entre un protocole de gestion SA (tel que IKE) et la SPD (section 4.4.3).
Contextes IPsec séparés multiples
Si une implémentation IPsec agit comme une passerelle de sécurité pour plusieurs abonnés, elle PEUT implémenter plusieurs contextes IPsec séparés. Chaque contexte PEUT avoir et PEUT utiliser des identités, politiques, SA de gestion de clés et/ou SA IPsec complètement indépendantes. Ceci est pour la plupart une question d'implémentation locale. Cependant, un moyen d'associer les propositions (SA) entrantes avec les contextes locaux est requis. À cette fin, si pris en charge par le protocole de gestion de clés en cours d'utilisation, des identifiants de contexte PEUVENT être transmis de l'initiateur au répondeur dans les messages de signalisation, ce qui entraîne la création de SA IPsec avec une liaison à un contexte particulier. Par exemple, une passerelle de sécurité qui fournit un service VPN à plusieurs clients sera en mesure d'associer le trafic de chaque client au VPN correct.
Décisions de transfert vs décisions de sécurité
Le modèle IPsec décrit ici incarne une séparation claire entre les décisions de transfert (routage) et de sécurité, pour accommoder un large éventail de contextes où IPsec peut être employé. Le transfert peut être trivial, dans le cas où il n'y a que deux interfaces, ou il peut être complexe, par exemple, si le contexte dans lequel IPsec est implémenté utilise une fonction de transfert sophistiquée. IPsec suppose seulement que le trafic sortant et entrant qui a passé le traitement IPsec est transféré d'une manière cohérente avec le contexte dans lequel IPsec est implémenté. Le support des SA imbriquées est optionnel ; si nécessaire, il nécessite une coordination entre les tables de transfert et les entrées SPD pour faire traverser au paquet la frontière IPsec plus d'une fois.
"Local" vs "Distant"
Dans ce document, en ce qui concerne les adresses IP et les ports, les termes « Local » et « Distant » sont utilisés pour les règles de politique. « Local » fait référence à l'entité protégée par une implémentation IPsec, c'est-à-dire l'adresse/port « source » des paquets sortants ou l'adresse/port « destination » des paquets entrants. « Distant » fait référence à une entité pair ou à des entités pairs. Les termes « source » et « destination » sont utilisés pour les champs d'en-tête de paquet.
Fragments "non initiaux" vs "initiaux"
Tout au long de ce document, l'expression « fragments non initiaux » est utilisée pour désigner les fragments qui ne contiennent pas toutes les valeurs de sélecteur qui peuvent être nécessaires pour le contrôle d'accès (par exemple, ils pourraient ne pas contenir le protocole de couche suivante, les ports source et destination, le type/code de message ICMP, le type d'en-tête de mobilité). Et l'expression « fragment initial » est utilisée pour désigner un fragment qui contient toutes les valeurs de sélecteur nécessaires pour le contrôle d'accès. Cependant, il convient de noter que pour IPv6, le fragment qui contient le protocole de couche suivante et les ports (ou le type/code de message ICMP ou le type d'en-tête de mobilité) dépendra du type et du nombre d'en-têtes d'extension présents. Le « fragment initial » pourrait ne pas être le premier fragment, dans ce contexte.