RFC 2401-fr – Architecture de sécurité pour IP

Statut de ce document
Ce document spécifie un protocole standard d'Internet, pour la communauté Internet, et ne sera éprouvé qu'après plusieurs discussions et suggestions. Referez-vous à l'édition courante de "Internet Official Protocol Standards" (STD 1) pour savoir l'état de sa standardisation et son statut. La distribution de cette note illimitée.

Table des matières

1. Introduction
2. Objectifs de conception
3. Vision globale du système
4. Association de Sécurité
5. Traitement du trafic IP
6. La traitement d'ICMP (en relation avec IPsec)
7. Faire de l'audit
8. Utilisation dans les système supportant la sécurité du flux d'information
9. En terme de performance
10. Conditions de conformité
11. Considération sur la sécurité
12. Différences avec la RFC 1825
Remerciements
Annexe A -- Glossaire
Annexe B -- Analyse et discussion sur PMTU/DF/Fragmentation
Annexe C -- Code d'exemple de la fenêtre d'espace des séquences
Annexe D -- Catégories des messages ICMP
Références
Démenti
Information concernant les auteurs
Note intégrale et originale de Copyright

1. Introduction

1.1 Résumé du contenu de ce document

Ce document spécifie l'architecture de base pour les système compatible avec IPsec. Le but de cette architecture est d'apporter divers services en terme de sécurité du trafic au niveau de la couche IP, à la fois dans les environnements IPv4 et IPv6. Ce document décrit le but de tels systèmes, leurs composants, et comment ils se lient entre eux dans l'environnement IP. Il décrit également les services de sécurité offerts par le protocole IPsec, et comment ces services peuvent être employés dans l'environnement IP. Ce document ne détaille pas tous les aspects de l'architecture IPsec. D'autres documents s'intéresseront aux autres détails architecturaux de nature plus avancée, comme l'utilisation d'IPsec dans un environnement de translation d'adresse (NAT, Network Address Translation) ou encore pour un support plus complet du multicast IP. Les composants fondamentaux qui suivent sur l'architecture de sécurité Ipsec sont vus en termes de fonctionnalités fondamentales et nécessaires.

D'autres RFC (voir la section 1.3 pour avoir des liens vers d'autres documents) définissent les protocoles en (a), (c) et (d).
a. Protocoles de sécurité -- Authentification Header (AH, entête d'authentification) et Encapsulating Security Payload (ESP, encapsulation de données de sécurité).
b. Associations de sécurité -- Qu'est-ce que c'est, comment elles fonctionnent, comment elles sont gérés, le traitement associé
c. Gestion de clefs -- Automatique et manuelle (IKE, Internet Key Exchange, échange de clefs Internet).
d. Algorithme pour l'authentification et le chiffrement.

Ce document ne décrit pas une architecture de sécurité complète pour Internet. Il s'intéresse seulement à la sécurité de couche IP, obtenue par l'utilisation combinée de la cryptographie et des mécanismes d'un protocole de sécurité.

Les mots-clefs tels DEVOIR, RECOMMENDER, POUVOIR ou OPTIONNEL et leurs déclinaisons, lorqu'il 1000 s apparaissent dans ce document, sont à interpréter de la façon dont la RFC 2119 [Bra97] le décrit.

1.2 Audience

L'audience ciblée par ce document inclut ceux qui doivent implémenter cette technologie de sécurité IP, où d'autres qui sont intéressés par l'acquisition d'une certaine compréhension de ce système. En particulier, les utilisateurs éventuels de cette technologie (utilisateurs finaux ou administrateurs de système) font partie du public ciblé. Un glossaire est donné en annexe pour combler les problèmes de vocabulaire ou de contexte. Ce document suppose que le lecteur connaît IP (Internet Protocol) et les technologies qui lui sont liés, ainsi que les termes et concepts généraux concernant la sécurité.

1.3 Documents liés au sujet

Comme mentionné plus haut, d'autres document donne des définitions détaillées de certains composants d'IPsec et de leurs interactions. Cela inclut les RFC sur les sujets suivants :
a. "IP Security Document Roadmap" [TDG97] - un document qui donne les grandes lignes sur la description des spécifications des algorithmes de chiffrement et d'authentification utilisés dans ce système.
b. Protocoles de sécurité - Les RFC décrivant les protocoles Authentication Header (AH) [KA98a] et Encapsulating Security Payload (ESP)[KA98b].
c. Les algorithmes d'authentification et de chiffrement - une RFC séparée pour chaque algorithme.
d. Gestion automatique des clefs - Les RFC "The Internet Key Exchange (IKE)" [HC98], "Internet Security Association and Key Management Protocol (ISAKMP)" [MSST97], "The OAKLEY Key Determination Protocol" [Orm97], et "The Internet IP Security Domain of Interpretation for ISAKMP" [Pip98].

2. Objectifs de conception

2.1 Description des objectifs, des besoins et des problèmes

IPsec est conçu pour donner une sécurité de haute qualité, basée sur la cryptographie, sans problème d'interopérabilité, pour IPv4 et IPv6. L'ensemble des services de sécurité proposé inclut le contrôle d'accès, l'intégrité en mode non connecté, l'authentification de l'origine des données, la protection contre le rejeu (une forme d'intégrité), la confidentialité (chiffrement), et une certaine confidentialité sur le flux de trafic. Ces services sont offerts par IP ou par d'autres protocoles de couches supérieures.

Ces objectifs sont atteints par l'utilisation de deux protocoles de sécurité de trafic, Authentication Header (AH) et Encapsulating Security Payload (ESP), et par l'utilisation de procédures et de protocoles de gestion de clefs de cryptographie. L'ensemble des protocoles IPsec, employés dans n'importe quel contexte, et la façon dont ils sont utilisés, seront déterminés par les besoins des utilisateurs ou/et des sites/organisations sur la sécurité et les systèmes.

Quand ces mécanismes sont correctement implémentés et déployés, ils ne doivent pas compromettre les uti 1000 lisateurs, les hôtes, ni les autres composants d'Internet qui n'utilisent pas ces mécanismes de sécurité pour protéger leur trafic. Ces mécanismes sont également conçu pour être indépendant de tout algorithme. Cette modularité permet de sélectionner différents types d'algorithme sans affecter la partie implémentation. Par exemple, des communautés différentes d'utilisateurs peuvent sélectionner (ou même créer) différents types d'algorithmes si nécessaire.

Un ensemble standard d'algorithmes par défaut est spécifié pour facilité l'interopérabilité avec l'ensemble d'Internet. L'utilisation de ces algorithmes, en conjonction avec la protection du trafic IPsec et des protocoles de gestion de clefs, devrait permettre aux développeurs d'applications et de systèmes de déployer des technologies de sécurité cryptographique de haute qualité sur la couche Internet.

2.2. Avertissements et suppositions

La suite de protocoles IPsec et des algorithmes associés par défaut sont conçus pour donner de la sécurité de haute qualité pour le trafic d'Internet. Quoiqu'il en soit, la sécurité offerte par l'utilisation de ces protocoles dépend de la qualité de leur implémentation, qui n'est pas le sujet de ce standard. De plus, la sécurité d'un système ou d'un réseau est fonction de nombreux facteurs, qu'il soit entre autres personnels, physiques, procéduraux, d'émanations compromettantes, et de pratiques de sécurité informatique. Donc, IPsec est seulement une partie d'une architecture globale de sécurité d'un système.

Finalement, la sécurité offerte par l'utilisation d'IPsec est extrêmement dépendante de plusieurs aspects de l'environnement dans lequel l'implémentation d'IPsec s'exécute. Par exemple, les problèmes de sécurité des systèmes d'exploitations, les sources de nombres aléatoires de piètre qualité, les pratiques et les protocoles négligés pour la gestion du système, etc. peuvent tous dégrader la sécurité offerte par IPsec. Comme vu plus haut, aucun de ces attributs environnementaux ne sont étudiés dans le présent standard, ou d'autres concernant IPsec.

3. Vision globale du système

Cette section donne une description vue de haut du fonctionnement d'IPsec, des composants du système, et de la façon dont il interagissent entre eux, pour obtenir les services de sécurité décrits plus haut. Le but de cette description est de permettre au lecteur d'avoir en tête l'ensemble du processus/système, de voir comment il s'intègre à l'environnement IP, et de présenter le contexte avant les sections suivantes de ce document, qui décrit chacun des composants plus en détails.

Une implémentation d'IPsec s'exécute dans un environnement hôte ou sur une passerelle de sécurité pour protéger le trafic IP. La protection offerte est basée sur des besoins définis par la base de données de la politique de sécurité (SPD, Security Policy Database) établie et maintenue par un utilisateur ou un administrateur système, ou par une application s'exécutant avec les contraintes & 1000 eacute;tablies par l'un des deux. En général, les paquets sont sélectionnés pour l'un des trois modes d'utilisation basés sur IP, selon l'information de la couche de transport (Sélecteurs, Section 4.4.2), empêchant les entrées dans la SPD. Chaque paquet peut utiliser les services de sécurité IPsec, ou de les éviter, selon les règles de la SPD identifiées par les Sélecteurs.

3.1 Que fait IPsec ?

IPsec offre des services de sécurité au niveau de la couche IP en permettant au système de choisir le protocole de sécurité dont il a besoin, de déterminer l'algorithme à utiliser pour ce ou ces services, et de mettre en place les clefs de cryptographie nécessaire pour assurer ces services. IPsec peut être utilisé pour protéger un ou plusieurs accès entre deux hôtes, entre deux passerelles de sécurité, ou entre une passerelle de sécurité et un hôte (Le terme "passerelle de sécurité" ou "security gateway" est utilisé tout au long de ce document pour parler d'un système intermédiaire qui utilise les protocoles d'IPsec. Par exemple, un routeur ou un firewall utilisant IPsec est une passerelle de sécurité).

L'ensemble des services de sécurité que peut proposer IPsec inclut le contrôle d'accès, l'intégrité en mode non connecté, l'authentification de l'origine des données, le rejet des paquets de rejeu (une forme d'intégrité), la confidentialité (chiffrement), et une certaine confidentialité sur le flux de trafic. Parce que ces services sont proposés au niveau IP, ils peuvent être utilisés par un protocole appartenant à une couche supérieure, comme TCP, UDP, ICMP, BGP, etc.

Le DOI d'IPsec supporte également la négociation de compression IP [SMPT98], motivée entre autre par le fait que lorsque le chiffrement est utilisé au sein d'IPsec, il empêche une compression efficace par les protocoles des couches inférieures.

3.2 Comment fonctionne IPsec ?

IPsec utilise deux protocoles pour assurer la sécurité du trafic -- Authentication Header (AH) et Encapsulating Security Payload (ESP). Ces deux protocoles sont décrits en détails dans leurs RFC respectives [KA98a, KA98b].
- L'entête d'authentification IP (AH, Authentication Header [KA98a]) apporte l'intégrité en mode non connecté, l'authentification de l'origine des données, et un service anti-rejeu optionnel.
- Le protocole Encapsulating Security Payload (ESP, [KA98b]) peut apporter la confidentialité (chiffrement), ainsi qu'une certaine confidentialité du flux de trafic. Il peut également apporter l'intégrité en mode non connecté, l'authentification de l'origine des données, et un service anti-rejeu optionnel (un ou plusieurs de ces services de sécurité doit être impliqué quand ESP est évoqué).
- AH et ESP apportent tous deux le contrôle d'accès, basé sur une distribution de clefs de cryptographie et la gestion des flux de trafic relatifs à ces protocoles de sécurité.

Ces protocoles peuvent être impliqués seuls ou ensemble pour apporter l'ensemble d& 1000 eacute;siré des services de sécurité dans IPv4 et IPv6. Chaque protocole supporte deux modes d'utilisation : le mode transport et le mode tunnel. En mode transport, le protocole propose une protection préliminaire pour les protocoles supérieurs, et en mode tunnel, le protocole est utilisé dans les paquets IP envoyés en tunneling. La différence entre ces deux modes est évoqué dans la Section 4.

IPsec permet à l'utilisateur (ou l'administrateur système) de contrôler la granularité de ce qui utilise un service de sécurité. Par exemple, on peut créer un simple tunnel chiffré pour transporter tout le trafic entre deux passerelles de sécurité ou un tunnel chiffré séparé pour chaque connexion TCP entre les deux hôtes communiquant par ces passerelles. La gestion d'IPsec doit incorporer des équipements pour spécifier :
- quels services de sécurité utiliser et dans quel cas
- la granularité avec laquelle une protection donnée doit être appliquée
- les algorithmes utilisés pour une sécurité basée sur la cryptographie

Comme ces services de sécurité utilisent des valeurs secrètes partagées (clefs de cryptographie), IPsec repose sur un ensemble séparé de mécanismes permettant de mettre ces clefs en place. (Les clefs sont utilisées pour l'authentification/intégrité et services de chiffrement.) Ce document nécessite d'autres supports pour la distribution automatique ou manuelle de clefs. Il spécifie une approche spécifique basée sur les clefs publiques (IKE -- [MSST97, Orm97, HC98]) pour la gestion automatique des clefs, mais d'autres techniques de distribution automatique de clef PEUVENT être utilisées. Par exemple, les systèmes basés sur KDC comme Kerberos ou d'autres systèmes à clefs publiques comme SKIP peuvent être utilisés.

3.3 Où IPsec peut-il être implémenté ?

Il y a plusieurs façons d'implémenter IPsec sur un hôte ou en conjonction avec un routeur ou un firewall (pour créer une passerelle de sécurité). Plusieurs exemples sont données ci-dessous :
a. Intégration d'IPsec dans l'implémentation native d'IP. Ceci demande un accès au code source d'IP et est applicable à la fois sur les hôtes et les passerelles de sécurité.
b. Les implémentations "Bump-in-the-stack" (BITS), où IPsec est implémenté "en dessous" d'une implémentation existante de la pile IP, entre l'IP natif et les drivers du réseau local. L'accès au code source de la pile IP n'est pas nécessaire dans ce cas, ce qui rend cette approche appropriée pour utiliser les systèmes tels quels. Cette approche, quand elle est adoptée, est généralement utilisée sur les hôtes.
c. L'utilisation d'un processeur de cryptographie extérieur est une fonction courante sur les systèmes de sécurité réseaux utilisés par les militaires, et même quelques systèmes commerciaux. C'est quelquefois vu comme une implémentation "Bump-in-the-wire" (BITW). Ces implémentations peuvent être conçues 1000 pour servir sur un hôte ou sur une passerelle de sécurité. Généralement, l'élément BITW est adressable par IP. Quand il s'agit d'un simple hôte, ça peut se rapprocher d'une implémentation BITS, mais dans un routeur ou un firewall, il doit fonctionner comme pour une passerelle de sécurité.

4. Association de Sécurité

Cette section définit les besoins en terme de gestion des Associations de Sécurité nécessaire à toute implémentation d'IPv6 et les implémentations d'IPv4 qui utilisent AH, ESP, ou les deux. Le concept de "Association de Sécurité" (SA, Security Association) est fondamental dans IPsec. AH et ESP utilisent tous les deux les SA et une des fonctions majeures de IKE est l'établissement et le maintien d'Associations de Sécurité. Toute implémentation de AH ou ESP DOIT supporter le concept d'Association de Sécurité comme décrit par la suite. Le reste de cette section décrit différents aspects de la gestion des Associations de Sécurité, définissant les caractéristiques requises pour la gestion d'une politique de SA, le traitement du trafic, et les techniques de gestion d'une SA.

4.1 Définition et étendue

Une Association de Sécurité (SA) est une connexion simplex qui apporte des services de sécurité au trafic qui transite par elle. Les services de sécurité sont apportés par la SA par l'intermédiaire de AH ou de ESP, mais pas des deux. Si les protections de AH et ESP sont toutes deux appliquées à un flux, alors au moins deux SA sont créées pour apporter la protection de ce flux. Pour sécuriser une transmission bi-directionnelle typique entre deux hôtes, ou entre deux passerelles de sécurité, deux Associations de Sécurité (une dans chaque direction) sont nécessaires.

Une Association de Sécurité est identifiée de façon unique par trois variables que sont l'index du paramètre de sécurité (SPI, Security Parameter Index), l'adresse IP destination, et l'identifiant du protocole de sécurité (AH ou ESP). En principe, l'adresse destination peut être une adresse unicast, broadcast ou de groupe multicast. Cependant, les mécanismes actuels de gestion des SA dans IPsec sont définis seulement pour les SA unicast. Par conséquent, dans les discussions qui suivent, les SA seront décrites dans le contexte d'une communication point-à-point, même si le concept est également applicable dans le cas d'une communication multipoint.

Comme indiqué ci-dessus, deux types de SA sont définies : en mode transport et en mode tunnel. Le mode transport d'une SA est une Association de Sécurité entre deux hôtes. Dans IPv4, l'entête du protocole de sécurité en mode transport apparaît juste après l'entête d'IP et toutes ses options, et avant n'importe quel protocole des couches plus élevées (comme TCP ou UDP). Dans IPv6, l'entête du protocole de sécurité apparaît après l'entête IP et ses extensions de base, mais peut apparaître avant ou après les options de destination, et avant les protocoles des couches supérieures. Dans le cas d'ESP, le mode transport de SA fournit des services de sécurité uniquement pour les protocoles supérieurs, pas pour l'ent&eci 1000 rc;te IP ou tous les entêtes d'extension précédant l'entête ESP. Dans le cas d'AH, la protection est également étendue à certaines parties choisies de l'entête IP, à certaines parties choisies des entêtes d'extension, et à certaines options choisies (contenues dans l'entête IPv4, dans l'entête d'extension Hop-by-Hop et dans les entêtes d'extension de destination pour IPv6). Pour plus de détails sur la protection accordée par AH, référez-vous aux spécifications d'AH [KA98a].

Le mode tunnel d'une SA est essentiellement une SA appliquée à un tunnel IP. Chaque fois que l'extrémité d'une Association de Sécurité est une passerelle de sécurité, la SA DOIT être en mode tunnel. Ainsi, une SA entre deux passerelle de sécurité est toujours en mode tunnel, de même qu'une SA entre un hôte et une passerelle de sécurité. Notez que dans le cas d'un trafic destiné à une passerelle de sécurité, comme les commandes SNMP, la passerelle de sécurité agit en tant qu'hôte et que le mode transport est possible. Dans ce cas, la passerelle de sécurité n'agit pas en tant que passerelle, c'est-à-dire que le trafic ne transite pas par elle. Deux hôtes PEUVENT établir entre eux une SA en mode tunnel. Les conditions nécessaires au mode tunnel, pour une SA impliquant une passerelle de sécurité, sont plus sévères pour éviter d'éventuels problèmes de fragmentation et de réasssemblage de paquets IPsec, ou quand les accès sont multiples (comme par l'intermédiaire de différentes passerelles de sécurité), jusqu'à une même destination se trouvant derrière des passerelles de sécurité.

Pour la SA en mode tunnel, il y a un entête IP "externe" qui indique la destination traitée par IPsec, plus un entête IP "interne" qui indique la destination finale (apparente) du paquet. L'entête du protocole de sécurité apparaît après l'entête IP externe, et avant l'entête IP interne. Si AH est utilisé en mode tunnel, les parties de l'entête IP externe sont protégées (comme vu ci-dessus), de même que tout paquet IP passant en tunneling (c.-à-d., tout l'entête IP interne est protégé, ainsi que les protocoles des couches plus élevées). Si ESP est utilisé, la protection est appliquée uniquement au paquet passant en mode tunneling, pas à l'entête externe.

En résumé,
a) l'hôte DOIT supporter à la fois le mode transport et le mode tunnel.
b) Une passerelle de sécurité supporte uniquement le mode tunnel. S'elle supporte le mode transport, elle ne devrait être utilisé que quand la passerelle de sécurité agit en tant qu'hôte, comme pour l'administration du réseau, par exemple.

4.2 Fonctionnalités des SA

L'ensemble des services de sécurité offerts par la SA dépend du protocole de sécurité choisi, du mode de la SA, des extrémités de la SA, et de l'utilisation des services optionnels du protocole. Par exemple, AH fournit l'authentification de l'origine de données et l'intégrité en mode non connecté des datagrammes IP (ci-après désignés sous le nom d'"au 1000 thentification"). La "précision" du service d'authentification est fonction de la granularité de l'association de sécurité avec laquelle AH est utilisé, comme nous le verrons dans la Section 4.4.2, sur les "Sélecteurs".

AH offre également le service d'anti-rejeu (intégrité) pour le récepteur, afin de contrer les attaques de déni de service. AH est un protocole à utiliser quand la confidentialité n'est pas nécessaire (ou n'est pas autorisé, par exemple, en raison des restrictions du gouvernement sur le chiffrement). AH fournit également l'authentification pour les parties choisies de l'entête IP, ce qui peut être nécessaire dans certains cas. Par exemple, si l'intégrité d'un entête d'option IPv4 ou d'une extension IPv6 doit être assurée le long du chemin entre l'expéditeur et le récepteur, AH peut fournir ce service (sauf sur les parties non-prévisibles pouvant changer dans l'entête IP).

ESP fournit en option la confidentialité du trafic (la puissance du service de confidentialité dépend en partie de l'algorithme de chiffrement utilisé). ESP peut également fournir l'authentification en option (comme défini ci-dessus). Si l'authentification est négociée pour une SA ESP, le récepteur peut également choisir d'imposer le service d'anti-rejeu avec les mêmes dispositifs que le service anti-rejeu d'AH. La portée de l'authentification offerte par ESP est plus étroite que celle d'AH, c'est-à-dire que le ou les entêtes IP situés hors de l'entête ESP ne sont pas protégés. Si les protocoles des couches supérieures sont les seuls qui doivent être authentifiés, alors l'authentification ESP est un choix approprié et plus efficace que l'utilisation de AH encapsulant ESP. Notons que même si la confidentialité et l'authentification sont facultatives, elles ne peuvent pas être toutes les deux absentes. Au moins l'une d'elles DOIT être choisie.

Si le service de confidentialité est choisi, alors la SA ESP (en mode tunnel) peut offrir une confidentialité partielle du flux entre deux passerelles de sécurité. L'utilisation du mode tunnel permet aux entêtes IP internes d'être chiffrés, cachant l'identité de la source et de la destination (finale) du flux. D'ailleurs, le bourrage de la charge utile d'ESP peut également être utilisé pour cacher la taille des paquets. Des services similaires de confidentialité du flux peuvent être offerts quand un utilisateur mobile se voit assigner une adresse IP dynamique lors de la connexion. Ces services établissent une SA ESP (en mode tunnel) avec le firewall (agissant en tant que passerelle de sécurité). Notez que les SA de bonne granularité sont généralement plus vulnérables à l'analyse du trafic que ceux de granularité brute qui transportent le trafic de beaucoup d'abonnés.

4.3 Combiner les SA

Les datagrammes IP transmis au-dessus d'une SA individuelle sont protégés par un unique protocole de sécurité, soit AH, soit ESP, mais pas les deux. Parfois, une politique de sécurité peut nécessiter une combinaison des services pour un flux particulier qui n'est pas réalisable avec une SA simple. Dans ce cas, il sera nécessaire d'utiliser plusieurs SA pour mettre en application la politique de sécurité demandée. Le terme "paquet d'associations de sé 1000 curité" ou "paquet de SA" est appliqué à une séquence de SA spécifiant le traitement que le trafic doit recevoir pour satisfaire une politique de sécurité. L'ordre de la séquence est définie par la politique (notons que les SA peuvent comporter un paquet qui peut être destiné aux différentes extrémités. Par exemple, une SA peut s'étendre d'un hôte mobile à une passerelle de sécurité et une autre SA emboîtée peut s'étendre jusqu'à un hôte placé derrière cette passerelle).

Les Associations de Sécurité peuvent être combinées dans des paquets de deux façons : la juxtaposition du transport et la création d'un tunnel itératif.

- La juxtaposition du transport se rapporte à l'application de plus d'un protocole de sécurité au même datagramme IP, sans demander la création d'un tunnel. Ce mélange d'AH et d'ESP est possible pour un seul niveau de combinaison ; davantage d'emboîtement n'apporte aucun autre avantage (utilisation d'algorithmes suffisamment forts pour chaque protocole) puisque le traitement est exécuté en une instance d'IPsec jusqu'à la destination (finale).

Hôte 1 -- Passerelle -- Internet -- Passerelle -- Hôte 2
| | de sécurité n°1 de sécurité n°2 | |
| | | |
| ----Association de sécurité 1 (transport ESP)----- |
| |
------Association de sécurité 2 (transport AH)--------

- Le tunneling itératif se rapporte à l'application de plusieurs couches de protocoles de sécurité par la création d'un tunnel IP. Cette approche tient compte de plusieurs niveaux d'emboîtement, puisque chaque tunnel peut commencer ou se terminer à un lieu IPsec différent tout au long du chemin. Aucun traitement spécial n'est prévu pour le trafic ISAKMP aux passerelles de sécurité intermédiaires autres que ce qui peut être indiqué par les entrées appropriées de la SPD (voir le cas 3 de la Section 4.5)

Il y a 3 cas de base pour le tunneling itératif -- le support n'est nécessaire que pour les cas 2 et 3 :

1. Les deux extrémités de la SA sont les mêmes -- Les tunnels internes et externes peuvent être soit AH, soit ESP, bien qu'il soit peu probable que l'hôte 1 les indiquerait tous deux comme étant les mêmes, i.e., AH dans AH et ESP dans ESP.

& 1000 nbsp; Hôte 1 -- Passerelle -- Internet -- Passerelle -- Hôte 2
| | de sécurité n°1 de sécurité n°2 | |
| | | |
| -------Association de sécurité 1 (tunnel)--------- |
| |
---------Association de sécurité 2 (tunnel)-----------

2. Une des deux extrémités de la SA est la même -- les tunnels internes et externes peuvent être soit AH, soit ESP.

Hôte 1 -- Passerelle -- Internet -- Passerelle -- Hôte 2
| | de sécurité n°1 de sécurité n°2 |
| | | |
| ---Association de sécurité 1 (tunnel)--- |
| |
---------Association de sécurité 2 (tunnel)-----------

3. Aucunes des deux extrémités n'est la même -- les tunnels internes et externes peuvent être soit AH, soit ESP.

Hôte 1 -- Passerelle -- Internet 1000 -- Passerelle -- Hôte 2
| de sécurité n°1 de sécurité n°2 |
| | | |
| -------- SA 1 (tunnel) ----- |
| |
---------Association de sécurité 2 (tunnel)-----------

Ces deux approches peuvent également être combinées. Par exemple, le paquet de SA pourrait être construit à partir d'une SA en mode tunnel et une ou deux SA en mode transport, appliquées dans un certain ordre (voir la Section 4.5 "Combinaisons de base des Associations de Sécurité"). Notons qu'il peut aussi arriver que des tunnels emboîtés n'aient en commun ni leurs sources, ni leurs destinations. Dans ce cas, il n'y aurait aucun hôte ou passerelle de sécurité ayant un paquet correspondant aux tunnels emboîtés. Pour les SA en mode transport, un seul ordre pour les protocoles de sécurité semble approprié. AH est appliqué à la fois aux protocoles des couches supérieures et à (certaines parties de) l'entête IP. Ainsi, si AH est utilisé en mode transport, en même temps qu'ESP, AH DEVRAIT apparaître dans le premier entête suivant IP, avant ESP. Dans ce cas, AH est appliqué au texte chiffré sorti d'ESP. En revanche, pour les SA en mode tunnel, on peut imaginer des ordres différents pour AH et ESP. L'ensemble des types de paquet de SA nécessaires DEVANT être supportés par une implémentation conforme d'IPsec est décrit dans la Section 4.5.

4.4 Les bases de données des Associations de Sécurité (Security Association Databases)

Plusieurs détails associés au traitement du trafic IP d'une implémentation IPsec sont en grande partie des problèmes locaux, pas d'étalonnage. Cependant, quelques aspects externes du traitement doivent être normalisés, pour assurer leur interopérabilité et pour fournir une capacité minimum de gestion qui est essentielle pour assurer un usage productif d'IPsec. Cette section décrit un modèle général pour le traitement du trafic IP en relation avec des SA, en rapport avec ce but d'interopérabilité et de fonctionnalité. Le modèle décrit ci-dessous est nominal ; l 1000 es implémentations conformes n'ont pas besoin de correspondre aux détails du modèle tel qu'il est présenté, mais le comportement externe de telles implémentations doit pouvoir correspondre aux caractéristiques extérieurement observables de ce modèle.

Il y a deux bases de données nominales dans ce modèle : la base de données de la politique de sécurité (SPD, Security Policy Database) et la base de données des Associations de Sécurité (SAD, Security Association Database). La première indique les politiques qui déterminent la destination de l'ensemble du trafic IP d'arrivée ou venant d'un hôte, d'une passerelle de sécurité, ou d'une implémentation IPsec BITS ou BITW. La seconde base de données contient les paramètres qui sont associés à chaque Association (active) de Sécurité. Cette section définit également le concept de Sélecteur, un ensemble de valeurs de champs de protocole IP des couches supérieures qui est utilisé par la base de données de la politique de sécurité pour faire correspondre un trafic à une politique, c.-à-d., une SA (ou le paquet de SA).

Chaque interface où IPsec est activée exige nominalement des entrées séparées dans les bases de données (SAD et SPD), en raison de la directionalité de plusieurs des champs qui sont utilisées comme Sélecteurs. En général, il y a une seule interface, pour un hôte ou une passerelle de sécurité (SG). Notons qu'une SG aura toujours au minimum 2 interfaces, mais celle qui est "interne" au réseau n'a généralement pas IPsec activé et donc seules une paire de SAD et une paire de SPD seraient nécessaires. D'autre part, si un hôte ou une SG avait plusieurs interfaces externes, il pourrait être nécessaire d'avoir des paires SAD et SPD séparées pour chaque interface.

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

Finalement, une Association de Sécurité est un outil de gestion utilisé pour imposer une politique de sécurité dans un environnement IPsec. Ainsi, un élément essentiel au traitement de SA est la base de données fondamentale de politique de sécurité (SPD) qui indique quels services doivent être offerts aux datagrammes IP et de quelle façon. La forme de la base de données et de son interface ne sont pas abordés dans ces spécifications. Cependant, cette section indique quelles fonctionnalités minimum de gestion doivent être fournies, pour permettre à un utilisateur ou un administrateur système de contrôler la façon dont IPsec est appliqué au trafic transmis ou reçu par hôte, ou passant par une passerelle de sécurité.

La SPD doit être consultée pendant le traitement de tout le trafic (ENTRANT et SORTANT), y compris le trafic non-IPsec. Afin d'assurer ceci, la SPD exige des entrées distinctes pour le trafic entrant et sortant. On peut utiliser des SPD séparées (entrante ou sortante). En outre, une SPD séparée doit être utilisée pour chaque interface où IPsec est activée.

Une SPD doit distinguer le trafic qui est protégé par IPsec et celui qui passe IPsec. Ceci concerne la protection IPsec devan 1000 t être appliquée par un expéditeur et la protection IPsec qui doit être présente chez le récepteur. A n'importe quel datagramme entrant ou sortant, trois choix de traitement sont possibles : jeter, passer IPsec, ou appliquer IPsec. Le premier choix se rapporte au trafic qui n'est pas autorisé à quitter l'hôte, à traverser la passerelle de sécurité, ou à être fourni à une application. Le deuxième choix se rapporte au trafic qui est autorisé à passer sans protection IPsec supplémentaire. Le troisième choix se rapporte au trafic protégé par IPsec, et pour un tel trafic, la SPD doit indiquer les services de sécurité à fournir, les protocoles et les algorithmes à utiliser, etc...

Pour chaque implémentation d'IPsec, il DOIT y avoir une interface administrative qui permet à un utilisateur ou un administrateur système de contrôler la SPD. Spécifiquement, chaque paquet entrant ou sortant est sujet au traitement IPsec, et la SPD doit indiquer l'action à effectuer dans chaque cas. Ainsi, cette interface administrative doit permettre à l'utilisateur (ou administrateur système) d'indiquer le traitement en sécurité à appliquer sur n'importe quel paquet entrant ou sortant du système, pour un paquet ou un type de paquets (dans une implémentation d'hôte IPsec utilisant une interface basée sur les sockets, on peut consulter la SPD pour un type de paquet, mais le résultat est le même). L'administrateur système de la SPD DOIT permettre la création d'entrées conformes aux Sélecteurs définis dans la Section 4.4.2, et DOIT permettre le contrôle total de ces entrées. On s'attend à ce que l'utilisation de types d'informations différents (wildcards) dans les Sélecteur pose problème, et ce parce que tous les paquets d'une connexion simple UDP ou TCP tendent à correspondre à une entrée simple de la SPD, mais cette condition n'imposera pas un niveau de détails irraisonnable dans les spécifications de la SPD. Les Sélecteurs sont identiques à ceux que l'on trouve actuellement dans un firewall ou un routeur filtrant.

Dans des systèmes hôtes, on PEUT permettre à des applications de choisir quel traitement de sécurité doit être appliqué au trafic qu'elles produisent et consomment (les moyens de signaler de telles demandes dans l'implémentation IPsec ne sont pas du ressort de cette norme). Cependant, l'administrateur système DOIT pouvoir indiquer si un utilisateur ou une application peut ignorer les politiques du système (par défaut). Notez que les politiques indiquées par l'application peuvent répondre à certaines exigences du système, de sorte que le système ne soit pas obligé de procéder à un traitement IPsec supplémentaire pour répondre aux exigences d'une application. La forme de l'interface de gestion n'est pas indiquée par ce document et peut différer entre les hôtes et les passerelles de sécurité, et d'un hôte à l'autre, l'interface peut différer entre une implémentation BITS et une basée sur les sockets. Cependant, ce document indique un ensemble standard d'éléments de SPD que toutes les implémentations IPsec DOIVENT avoir.

La SPD contient une liste ordonnée d'entrées de politique. Chaque entrée de politique est introduite par un ou plusieurs Sélecteurs qui définissent l'ensemble du trafic IP concerné par cette entr&e 1000 acute;e de politique (les types de Sélecteur exigés sont définis dans la Section 4.4.2). Ceux-ci définissent la granularité des politiques ou des SA. Chaque entrée inclut une indication permettant de savoir si le trafic correspondant à cette politique sera passé, rejeté, ou sujet à un traitement d'IPsec. Si le traitement par IPsec est nécessaire, l'entrée donne les spécifications de la SA (ou paquet de SA), précisant les protocoles IPsec, les modes, et les algorithmes à utiliser, ainsi que leurs interactions. Par exemple, une entrée peut nécessiter de protéger tout son trafic associé par ESP en mode transport, en utilisant 3DES-CBC avec un IV explicite, encapsulé à l'intérieur de AH en mode tunnel, utilisant HMAC/SHA-1. Pour chaque Sélecteur, l'entrée de la politique indique comment dériver les valeurs correspondantes pour obtenir une nouvelle entrée dans la base de données d'Association de Sécurité (SAD, voir la Section 4.4.3) de celles de le SPD et du paquet (notons qu'actuellement, les intervalles sont seulement supportés pour les adresses IP, mais les types d'informations différents (wildcarding) peuvent être exprimés pour tous les Sélecteurs):

a. Utilisation de la valeur dans le paquet elle-même -- ceci limitera l'utilisation de la SA aux paquets qui ont la valeur de ce paquet pour le Sélecteur, même si le Sélecteur de l'entrée de la politique a un intervalle de valeurs autorisées ou un type d'informations différentes pour ce Sélecteur.

b. Utilisation de la valeur associée à l'entrée de la politique -- si ça devaient être uniquement une valeur simple, alors il n'y aurait aucune différence entre (b) et (a). Cependant, si les valeurs autorisées pour le Sélecteur appartiennent à un intervalle (pour des adresses IP) ou un type d'informations différentes (wildcard), alors, dans le cas d'un intervalle, (b) permettrait l'utilisation de la SA par n'importe quel paquet avec une valeur de Sélecteur appartenant à cet intervalle, et pas seulement par les paquets dont la valeur de Sélecteur du paquet est celle qui a déclenché la création de la SA. Dans le cas d'un type d'informations différent (wildcard), (b) permettrait l'utilisation de la SA par des paquets ayant n'importe quelle valeur pour ce Sélecteur.

Par exemple, supposez qu'il y a une entrée de la SPD où la valeur autorisée pour l'adresse source est une partie quelconque d'un intervalle d'hôtes (192.168.2.1 à 192.168.2.10). Supposez ensuite qu'un paquet doit être envoyé a l'adresse source de 192.168.2.3. La valeur à utiliser pour la SA pourrait être n'importe laquelle de des valeurs ci-dessous selon ce que l'entrée de la politique pour ce Sélecteur indique comme étant la source de valeur de Sélecteur:

Source de la valeur Exemple pour la nouvelle
à utiliser pour la SA valeur du Sélecteur SAD
--------------------- ------------------------
a. paquet 192.168.2.3 (un hôte)
b. entrée SPD &nb 1000 sp; 192.168.2.1 à 192.168.2.10 (intervalle d'hôtes)

Notez que si l'entrée de la SPD avait une valeur autorisée de type d'informations différentes (wildcard) pour l'adresse source, alors la valeur de Sélecteur SAD pourrait être d'un type d'informations différent (wildcard) (n'importe quel hôte). Le cas (a) peut être utilisé pour empêcher les partages, même entre les paquets correspondant à la même entrée de la SPD.

Comme décrit ci-dessous dans la Section 4.4.3, les Sélecteurs peuvent inclure des entrées d'un type différent ("wildcard") et, par conséquent, les Sélecteurs de deux entrées peuvent se superposer (c'est analogue à la superposition apparaissant avec les acces-lists (ACL) ou les entrées de filtrage des paquets dans les routeurs ou firewalls). Ainsi, pour assurer un traitement conforme et prévisible, les entrées de la SPD DOIVENT être ordonnées et la SPD DOIT toujours être parcourue dans le même ordre, de sorte que la première entrée correspondante soit toujours la même (cette condition est nécessaire, de même que le fait de traiter le trafic, et les entrées de la SPD doivent être déterministes, mais on ne peut pas normaliser des entrées de la SPD, étant donné l'utilisation des types différents (wildcards) pour quelques Sélecteurs). On fournit plus de détails la correspondance des paquets et des entrées de la SPD dans la Section 5.

Notons que si ESP est utilisé, soit l'authentification, soit le chiffrement (mais pas les deux) peuvent être supprimé. Par conséquent, il DOIT être possible de configurer la valeur de la SPD concernant les algorithmes d'authentification et de chiffrement comme étant "NULL". Quoiqu'il en soit, au moins un de ces services doit être sélectionné, c'est-à-dire qu'on NE DOIT PAS pouvoir configurer les deux à "NULL".

La SPD peut être employée pour associer un trafic à certains SA ou paquets de SA. Ainsi, elle peut être utilisée comme base de données de référence pour la politique de sécurité et comme point de référence pour les SA (ou paquets de SA) existants (pour faciliter les politiques de rejet ou de passage citées ci-dessus, la SPD DOIT également fournir des moyens d'associer un trafic à ces fonctions, quoique ce ne soit pas, intrinsèquement, du traitement IPsec). La façon dont la SPD fonctionne est différente pour le trafic entrant et sortant. Ceci peut également différer pour un hôte et une passerelle de sécurité, ou pour les implémentations BITS et BITW. Les Sections 5.1 et 5.2 décrivent l'utilisation de la SPD pour le traitement du trafic entrant et sortant.

Etant donné qu'une politique de sécurité peut demander que plus d'une SA soit appliquée dans un ordre précis à un certain trafic, l'entrée de la politique dans la SPD doit conserver ces conditions ordonnées, quand il y en a. Ainsi, il doit être possible pour une implémentation d'IPsec de savoir qu'un paquet entrant ou sortant doit être traité par une suite de SA. Conceptuellement, pour le traitement sortant, on a pourrait imaginer des liens (vers la SAD) à partir d'une entrée de la SPD pour laquelle il y a des SA actifs, et chaque entrée se composerait d'une simple SA ou d'une liste ordonnée de SA qui comportent un paquet de SA 1000 . Quand un paquet est associé à une entrée de la SPD et qu'il y a une SA ou un paquet de SA existant qui peut être utilisé pour transporter le trafic, le traitement du paquet est contrôlé par l'entrée de la SA ou du paquet de SA de la liste. Pour un paquet IPsec entrant ayant plusieurs SA IPsec devant être appliquées, une consultation basée sur l'adresse destination, le protocole IPsec, et le SPI devrait identifier une SA unique.

La SPD est utilisée pour contrôler l'écoulement de l'ENSEMBLE du trafic par un système IPsec, ce qui comprend la sécurité et le trafic de gestion des clés (comme ISAKMP) allant ou venant d'entités se trouvant derrière une passerelle de sécurité. Cela signifie que le trafic ISAKMP doit être explicitement noté dans la SPD, sous peine d'être rejeté. Notez qu'une passerelle de sécurité pourrait interdire la traversée de paquets chiffrés de plusieurs façons, en ayant par exemple une entrée REJET dans la SPD pour les paquets ESP ou en fournissant un échange de clé par proxy. Dans ce dernier cas, le trafic serait routé en interne jusqu'au module de gestion des clefs dans la passerelle de sécurité.

4.4.2 Sélecteurs

Une SA (ou paquet de SA) peut être à grain fin ou à grain grossier, selon les sélecteurs utilisés pour définir l'ensemble du trafic pour SA. Par exemple, tout trafic entre deux hôtes peut être transporté par l'intermédiaire d'une simple SA, et apporter un ensemble uniforme de services de sécurité. Alternativement, le trafic entre deux hôtes pourrait être réparti entre plusieurs SA, selon les applications utilisées (comme défini par les champs Next Protocol et Port), avec différents services de sécurité offerts par différentes SA. De même, tout le trafic entre deux passerelles de sécurité pourrait être transporté par une simple SA, ou une SA pourrait être assignée à chaque paire d'hôtes communicants. Les paramètres suivants de Sélecteurs DOIVENT être supportés pour que la gestion de SA facilite le contrôle de la granularité de la SA. Notez cela dans le cas de la réception d'un paquet ayant un entête ESP, par exemple, à une passerelle de sécurité encapsulante ou dans une implémentation BITW, le protocole de la couche transport, les ports source et destination, et le nom (si il y est) peuvent être "OPAQUES", c.-à-d., inaccessible en raison du chiffrement ou de la fragmentation. Notez également que les adresses source et destination devraient être au format IPv4 ou IPv6.

- Adresse IP destination (IPv4 ou IPv6): ça peut être une adresse IP simple (unicast, anycast, broadcast (IPv4 seulement), ou groupe multicast), un intervalle d'adresses (bornes incluses), une adresse et un masque, ou une adresse de type différent (wildcard). Les trois derniers sont employés pour qu'un système destination puisse partager une même SA (par exemple, derrière une passerelle de sécurité). Notez que ce sélecteur est conceptuellement différent du champ "Adresse IP destination" dans l'ensemble employé pour identifier une SA unique. Quand un paquet tunnelé arrive à l'extrémité du tunnel, son SPI/Adresse Destination/Protocole sont utilisés pour rechercher la SA associ&ea 1000 cute;e au paquet dans la SAD. Cette adresse destination vient de l'entête IP encapsulée. Une fois que le paquet a été traité selon la SA du tunnel et est sorti du tunnel, ses sélecteurs "sont recherchés" dans la SPD d'arrivée. La SPD d'arrivée a un sélecteur appelé adresse destination. Cette adresse IP destination est celle de l'entête IP interne (encapsulé). Dans le cas d'un paquet transporté, il y aura seulement un entête IP donc aucune ambiguïté possible. [REQUIS pour toutes les implémentations]

- Adresse(s) IP source (IPv4 ou IPv6): ça peut être une adresse IP simple (unicast, anycast, broadcast (IPv4 seulement), ou groupe multicast), un intervalle d'adresses (bornes incluses), une adresse et un masque, ou une adresse différente (wildcard). Les trois derniers sont employés que plus d'un système source puissent partager la même SA (par exemple, derrière une passerelle de sécurité ou dans un hôte "multihomed"). [REQUIS pour toutes les implémentations]

- Nom : Il y a deux cas (notez que ces formes de nom sont supportées par DOI d'IPsec).
1. User ID (IDentificateur d'utilisateur)
a. Une chaîne de caractère complète de nom d'utilisateur (DNS), par exemple, mozart@foo.bar.com
b. Un nom particulier X.500, par exemple C = US, SP = MA, O = GTE Internetworking, CN = Stephen T. Kent.
2. Un nom de système (hôte, passerelle de sécurité, etc.)
a. Un nom DNS complet, comme foo.bar.com
b. Un nom particulier X.500
c. Un nom général X.500

Remarque : Une des valeurs possibles de ce sélecteur est "OPAQUE". [REQUIS pour les cas suivants. Notez que le support des formes de nom autres que les adresses n'est pas indispensable pour les SA ajoutées manuellement.

o User ID
- implémentations native des hôtes
- implémentations BITW/BITS considérés comme des HOTES avec un seul utilisateur
- implémentations d'une passerelle de sécurité pour le traitement ENTRANT

o Noms de systèmes -- toutes implémentations]
- Niveau de sensibilité des données : (labels IPSO/CIPSO)
[REQUIS pour tous les systèmes donnant une sécurité au flux d'information comme vu à la Section 8, OPTIONNEL pour les autres systèmes.]
- Protocole de la couche transport : Obtenu à partir du champ "Protocole" IPv4 ou des champs "Next Header" d'IPv6. Il peut s'agir d'un numéro individuel de protocole. Ces champs de paquet peuvent ne pas contenir le protocole de transport à cause des entêtes d'extension IP, comme par exemple, un entête de routage, AH, ESP, de fragmentation, les options de destination, les options de saut-par-saut, etc... Notez que le protocole de transport peut ne pas être disponible en cas de réception d'un paquet ayant un entête ESP. Ainsi, la valeur "OPAQUE" DEVRAIT être supportée. [REQUI 1000 S pour toutes les implémentations]

Remarque : Pour localiser le protocole de transport, un système doit enchaîner les entêtes des paquets en contrôlant le champ "Protocole" ou "Next Header" jusqu'à ce qu'il en rencontre un qu'il reconnaît comme protocole de transport, ou jusqu'à ce qu'il en atteigne un qui n'est pas sur sa liste d'entêtes d'extension, ou jusqu'à ce qu'il rencontre un entête ESP qui rend le protocole de transport opaque.

- Ports source et destination (par exemple, TCP/UDP): Ceux-ci peuvent être de différentes valeurs de ports de UDP ou de TCP ou un port de type différent (wildcard) (l'utilisation du champ "Prochain protocole" ou des champs "Ports source et/ou destination" (en même temps que les champs adresses source et/ou destination), comme sélecteur de SA est quelquefois abordé sous le nom de "session oriented keying"). Notez que les ports source et destination peuvent ne pas être disponibles en cas de réception d'un paquet ayant un entête ESP. Aussi, la valeur "OPAQUE" DEVRAIT être supportée.

Le tableau suivant résume les relations entre la valeur du "Next Header" dans le paquet et la SPD, et la valeur du Sélecteur de Port qui en découle pour la SPD et la SAD.

Next Header Protocole de la couche Valeur dérivée du champ Sélecteur
du paquet transport dans la SPD de Port dans la SPD ou la SAD
----------- ---------------------- ---------------------------------
ESP ESP ou ANY ANY (c.à.d, ne pas le regarder)
-sans importance- ANY ANY (c.à.d, ne pas le regarder)
valeur spécifique Valeur spécifique NOT ANY (c.à.d, passer le paquet)
fragment
valeur spécifique Valeur spécifique Champ Sélecteur de Port actuel
pas fragment

Si le paquet a été fragmenté, l'information de port peut ne pas être disponible dans le fragment traité. Dans ce cas, on jette le fragment. Un PMTU ICMP devrait être envoyé en premier fragment, qui aura l'information de port [PEUT être supporté]

Le contexte d'implémentation IPsec détermine la façon dont les sélecteurs sont utilisés. Par exemple, une implémentation d'hôte au sein de la pile peut se servir d'une interface de "socket". Quand une nouvelle connexion est établie, la SPD peut être consultée et une SA (ou paquet de SA) s'occupe de la socket. Ainsi, le trafic envoyé par l'intermédiaire de cette socket n'a pas besoin de consultations s 1000 upplémentaires des SPD/SAD. En revanche, les implémentations BITS, BITW, ou d'une passerelle de sécurité doit scruter chaque paquet et consulter les SPD/SAD à partir des sélecteurs. Les valeurs autorisées pour les champs Sélecteur diffèrent en fonction du flux de trafic, de l'association de sécurité, et de la politique de sécurité.

Le tableau suivante récapitule les différents types d'entrées nécessaires pour pouvoir être utilisés dans la SPD et la SAD. Il montre comment ils s'associent aux champs dans le trafic de données, étant soumis au criblage d'IPsec. (note: les entrées "sauvages" (wild) ou différentes (wildcard) pour les adresses source et destination comprennent un masque, un intervalle, etc...)

Champ Valeur du trafic Entrée de la SAD Entrée de la SPD
------- ------------- ---------------- --------------------
adr src adr IP unique single,range,wild single,range,wildcard
adr dest adr IP unique single,range,wild single,range,wildcard
prot. xpt* protocole xpt single,wildcard single,wildcard
port src* port src unique single,wildcard single,wildcard
port dest* port dst unique single,wildcard single,wildcard
user id* user id unique single,wildcard single,wildcard
labels sec. valeur unique single,wildcard single,wildcard

* Les entrées SAD et SPD pour ces champs peuvent être "OPAQUE" si la valeur du trafic est chiffrée.

Remarque : En principe, on peut avoir des sélecteurs et/ou des valeurs de sélecteur dans la SPD que l'on ne peut négocier pour une SA ou paquet de SA. Certains exemples pourraient montrer des valeurs de sélecteur employées pour choisir le trafic à jeter ou des listes énumératives qui engendrent la création d'une SA séparée pour chaque élément de la liste. Pour l'instant, ceci est laissé de côté et sera vu dans des futures versions de ce document et la liste de sélecteurs nécessaires et des valeurs de sélecteur est la même pour la SPD et la SAD. Cependant, il est acceptable d'avoir une interface administrative qui supporte l'utilisation des valeurs de sélecteur ne pouvant pas être négociées à condition qu'elles ne trompent pas l'utilisateur en lui faisant croire qu'il crée une SA avec ces valeurs de sélecteur. Par exemple, l'interface peut permettre à l'utilisateur d'indiquer une liste énumérative de valeurs mais cela aurait comme conséquence la création d'une politique et d'une SA séparée pour chaque élément de la liste. Un constructeur pourrait implémenter une telle interface pour que ce soit plus facile pour ses clients, et pour avoir des spécifications claires et précises de la politique.

1000 4.4.3 Base de données d'association de sécurité (SAD, Security Association Database)

Dans chaque implémentation d'IPsec, il y a une base de données nominale d'association de sécurité, dans laquelle chaque entrée définit les paramètres associés à une SA. Chaque SA a une entrée dans la SAD. Pour le traitement sortant, les entrées sont pointées par les entrées de la SPD. Notez que si une entrée de SPD ne pointe pas vers la SA appropriée pour le paquet, l'implémentation crée une SA (ou paquet de SA) appropriée et relie l'entrée de la SPD à l'entrée de la SAD (voir Section 5.1.1). Pour le traitement du trafic entrant, chaque entrée de la SAD est classée par une adresse IP destination, un protocole IPsec, et un SPI. Les paramètres suivants sont associés à chaque entrée de la SAD. Cette description ne prétend pas être une MIB, mais seulement quelques spécifications de données élémentaires minimales et nécessaires au support d'une SA dans une implémentation IPsec.

Pour le traitement entrant : Les champs suivants du paquet sont utilisés pour trouver la SA dans la SAD :
- Adresse IP destination dans l'entête externe : l'adresse de destination IPv4 ou IPv6. [REQUIS pour toutes les implémentations]
- Protocole IPsec : AH ou ESP, utilisé comme index lors de la consultation de la SA dans cette base de données. Indique le protocole IPsec à appliquer au trafic sur cette SA. [REQUIS pour toutes les implémentations]
- SPI : la valeur de 32 bits utilisée pour choisir parmi les différentes SA ayant la même destination et utilisant le même protocole IPsec. [REQUIS pour toutes les implémentations]

Pour chacun des Sélecteurs définis dans la Section 4.2.2, l'entrée de la SA dans la SAD DOIT contenir la ou les valeurs qui ont été négociées quand la SA a été créée. Pour l'émetteur, ces valeurs sont utilisées pour décider si une SA donnée est appropriée pour traiter un paquet sortant. Cela fait partie de la vérification permettant de voir s'il y a une SA existante qui peut être utilisée. Pour le récepteur, ces valeurs sont utilisées pour vérifier que les valeurs de sélecteurs dans un paquet entrant correspondent celles de la SA (et donc indirectement, celles de la police correspondante). Pour le récepteur, cela fait partie de la vérification permettant de s'assurer que la SA est appropriée pour ce paquet (voir Section 4.4.2 pour les messages ICMP). Ces champs peuvent être sous la forme de valeurs spécifiques, d'intervalles, de types différents(wildcards), ou "OPAQUE" comme décrit dans la section 4.4.2, "Les Sélecteurs". Notez que pour une SA de ESP, l'algorithme de chiffrement ou d'authentification peut être "NULL". Quoiqu'il en soit, ils ne peuvent pas tous les deux être "NULL".

Les champs suivants de la SAD sont utilisés pour le traitement IPsec :
- Compteur de numéro de séquence (SNC, Sequence Number Counter) : une valeur sur 32 bits utilisée pour générer le champ Numéro de Séquence (Sequence Number) dans les entêtes AH ou ESP. [REQUIS pour toutes les impl&eacu 1000 te;mentations, mais utilisé uniquement pour le trafic sortant]
- Débordement du compteur de séquence (Sequence Counter Overflow : un flag indiquant si le débordement du compteur de numéro de séquence devrait générer un événement notable et empêcher la transmission d'autres paquets sur cette SA. [REQUIS pour toutes les implémentations, mais utilisé uniquement pour le trafic sortant]
- Fenêtre anti-rejeu : un compteur sur 32 bits et une carte des bits (bit-map)(ou équivalent) utilisé pour déterminer si un paquet AH ou ESP entrant est un rejeu. [REQUIS pour toutes les implémentations, mais utilisé uniquement pour le trafic entrant. Remarque : Si l'anti-rejeu a été désactivé par le récepteur, comme par exemple, en cas d'une SA entrée manuellement, alors la fenêtre anti-rejeu n'est pas utilisée]
- Algorithme d'authentification d'AH, clefs, etc. [REQUIS pour l'implémentation d'AH]
- Algorithme de chiffrement d'ESP, clefs, mode IV, IV, etc. [REQUIS pour l'implémentation d'ESP]
- Algorithme d'authentification d'ESP, clefs, etc. Si le service d'authentification n'est pas sélectionné, ce champ sera nul. [REQUIS pour l'implémentation d'ESP]
- Durée de vie de cette Association de Sécurité : un intervalle de temps après lequel une SA doit être remplacée par une nouvelle SA (et un nouveau SPI) ou être supprimée, ainsi qu'une indication sur laquelle de ces actions devrait survenir. Cela pourrait être exprimé comme un temps ou un compteur d'octet, ou une utilisation simultanée des deux, la première durée de vie expirant prenant le dessus. Une implémentation conforme DOIT supporter ces deux types de durée de vie, et doit supporter une utilisation simultanée des deux. Si le temps est utilisé, et si IKE utilise les certificats X.509 pour l'établissement des SA, la durée de vie de la SA doit être restreinte à l'intervalle de validité du certificat et à la NextIssueDate (prochaine date importante) des CRLs utilisés dans l'échange IKE pour la SA. A la fois l'initiateur et le répondeur sont responsable de la restriction de la durée de vie de la SA de cette façon. [REQUIS pour toutes les implémentations].
Remarque : les détails de la façon dont les clefs sont rafraîchies quand les SA expirent est un problème local. Cependant, une approche raisonnable est :
(a) Si un compteur d'octets est utilisé, alors l'implémentation DEVRAIT compter le nombre d'octets auxquels IPsec est appliqué. Pour ESP, c'est l'algorithme de chiffrement (en incluant le chiffrement Null) et pour AH, c'est l'algorithme d'authentification. Ceci inclut les bits de bourrage, etc. Notez que les implémentations DEVRAIENT pouvoir utiliser le fait d'avoir des compteurs désynchronisés entre eux aux extrémités d'une SA, par exemple, à cause la perte d'un paquet ou parce que les implémentations à chaque extrémité de la SA ne font pas les choses de la même façon.
(b) Il DEVRAIT y avoir deux types de durée de vie -- une durée de vie logicielle, qui avertit l'implémentation qu'il faut initier une action comme le remplacement d'une SA et un durée de vie matérielle 1000 quand la SA actuelle se termine.
(c) Si le paquet complet n'est pas délivré pendant la durée de vie des SA, le paquet DEVRAIT être jeté.
- Le mode du protocole IPsec : tunnel, transport, ou différent (wildcard). Indique le mode AH ou ESP qui est appliqué au trafic de cette SA. Notez que si ce champ est "wildcard" à l'extrémité émettrice de la SA, alors l'application doit spécifier le mode à l'implémentation IPsec. Cette utilisation de wildcard autorise l'utilisation d'une même SA pour un trafic en mode tunnel ou transport, par unité de paquet, comme, par exemple, par différentes sockets. Le récepteur n'a pas besoin de connaître le mode pour traiter correctement l'entête des paquets Ipsec. [REQUIS comme suit, est sinon implicitement défini par le contexte :
- Les implémentations d'hôtes doivent supporter tous les modes.
- Les implémentations de passerelles doivent supporter le mode tunnel].
Remarque : L'utilisation de wildcard pour le mode du protocole d'une SA entrante peut rendre plus complexe la situation dans le récepteur (hôte seulement). Etant doné que les paquets sur une telle SA peuvent être délivrés en mode tunnel ou transport, la sécurité d'un paquet entrant peut dépendre en partie du mode utilisé pour le délivrer. Par conséquent, si une application s'occupe du mode de la SA pour un paquet donné, alors l'application nécessitera un mécanisme pour obtenir cette information de mode.
- Path MTU : toutes les variables path MTU observées et "vielles" (aging). Voir la section 6.1.2.4 [REQUIS pour toutes les implémentations mais utilisé uniquement pour le trafic sortant].

4.5 Combinaisons de base d'Associations de Sécurité

Cette section décrit quatre exemples de combinaisons d'Associations de Sécurité qui DOIVENT être supportées par les hôtes ou les passerelles de sécurité conforme à IPsec. Des combinaisons AH et/ou ESP en mode tunnel et/ou transport supplémentaires PEUVENT être supportés à la discrétion de celui qui fait l'implémentation. Les implémentations conformes DOIVENT être capable de produire ces quatre combinaisons et à la réception, de les traiter, mais DEVRAIENT pouvoir recevoir et traiter n'importe quelle combinaison. Les diagrammes et le texte ci-dessous décrivent les cas de base. La légende des diagrammes est :

==== = une ou plusieurs SA (AH ou ESP, tunnel ou transport)
---- = connectivité (ou, s'il est appelé ainsi, borne administrative)
Hx = hôte x
SGx = passerelle de sécurité x
X* = X supporte IPsec

Les SA suivantes peuvent être AH ou ESP. Le mode (tunnel ou transport) est déterminé par la nature des extrémités. Pour l 1000 es SA d'hôte-à-hôte, le mode peut être soit tunnel, soit transport.

Cas 1. Le cas où on apporte une sécurité de bout en bout entre deux hôtes à travers Internet (ou un intranet).

====================================
| |
H1* ------ (Inter/Intranet) ------ H2*

Notez que soit le mode tunnel, soit le mode transport peut être activé par les hôtes. Donc les entêtes d'un paquet entre H1 et H2 peut ressembler à n'importe lequel des suivants :

Transport Tunnel
----------------- ---------------------
1. [IP1][AH][supérieur] 4. [IP2][AH][IP1][supérieur]
2. [IP1][ESP][ supérieur] 5. [IP2][ESP][IP1][supérieur]
3. [IP1][AH][ESP][ supérieur]

Notez qu'il n'y a aucune condition sur le support de l'emboîtement, mais en mode transport, AH et ESP peuvent être appliqués au paquet. Dans ce cas, le procédé d'établissement de la SA DOIT s'assurer que d'abord ESP, puis AH sont appliqués au paquet.

Cas 2. Ce cas illustre le support d'un simple VPN (Virtual Private Network).

===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
borne administrative borne administrative

Seul le mode tunnel est requis ici. Donc les entêtes d'un paquet entre SG1 et SG2 peuvent ressembler à n'importe laquelle des formes suivantes :

Tunnel
---------------------
4. [IP2][AH][IP1][supérieur]
5. [IP2][ESP][IP1][supérieur]

Cas 3. Ce cas combine les cas 1 et 2, en ajoutant une sécurité de bout en bout entre l'hôte émetteur et l'hôte récepteur. Il n'impose aucune nouvelles conditions sur les hôtes ou les passerelles de sécurité, autre que la nécessité pour la passerelle de sécurité d'être configurable pour laisser passer le trafic IPsec (dont le trafic ISAKMP) pour les hôtes qui sont derrière elle.

===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | &n 1000 bsp; | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
borne administrative borne administrative

Cas 4. Ce cas couvre la situation où l'hôte distant (H1) utilise Internet pour atteindre le firewall d'une organisation (SG2) pour accéder ensuite à un serveur quelconque ou à toute autre machine (H2). L'hôte distant pourrait être un hôte mobile (H1) se connectant à un serveur local PPP/ARA (non montré) sur l'Internet et traversant ensuite Internet jusqu'au firewall central de l'organisation (SG2), etc... Les détails du support de ce cas, (comment H1 localise SG2, l'authentifie, et vérifie son autorisation pour représenter H2) sont vus dans la section 4.6.3 "Localiser une passerelle de sécurité".

======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
peut-être une connexion borne administrative
au serveur PPP/ARA (optionnelle)

Seul le mode tunnel est demandé entre H1 et SG2. Donc les choix de la SA entre H1 et SG2 serait une de celles du cas 2. Les choix pour la SA entre H1 et H2 serait une de celles du cas 1.

Notez que dans ce cas, l'émetteur DOIT appliquer l'entête de transport avant l'entête du tunnel. Par conséquent, l'interface de gestion de l'implémentation d'IPsec DOIT offrir la possibilité de configurer la SPD et la SAD pour assurer cet ordre dans l'application de l'entête IPsec.

Comme vu précédemment, le support de combinaisons AH et ESP supplémentaires est optionnel. L'utilisation d'autres combinaisons optionnelles peut compromettre l'interopérabilité.

4.6 SA et gestion des clefs

Les mandats IPsec supporte les SA manuelle et automatisée, ainsi que la gestion des clefs de cryptographie. Les protocoles IPsec, AH et ESP, sont en grande partie indépendants des techniques de gestion des SA associées, bien que les techniques impliquées affectent certains des services de sécurité offerts par ces protocoles. Par exemple, l'anti-rejeu disponible pour AH et ESP exige la gestion automatisée des SA. D'ailleurs, la granularité de la distribution de clefs utilisée avec IPsec détermine la granularité de l'authentification fournie (voir également la discussion de ce point dans la section 4.7.). En général, l'authentification de l'origine de données dans AH et ESP est limitée par la taille des secrets utilisés avec l'algorithme d'authentification (ou avec un protocole de gestion des clefs qui crée ces secrets) qui sont partagés entre plusieurs sources possibles.

Le texte suivant décrit les conditions minimum pour les deux types de gestion des SA.

4.6.1 Techniques manuelles

La forme la plus simple de gestion est la gestion manuelle, dans laquelle une personne configure manuellement chaque système avec des données de gestion des Associations de Sécurité et de matériel de base concernant la transmission sécurisée avec d'autres systèmes. Les techniques manuelles sont pratiques dans des environnements petits et statiques mais elles ne s'étendent pas bien entre elles. Par exemple, une société pourrait créer un réseau privé virtuel (VPN) utilisant IPsec dans des passerelles de sécurité sur plusieurs sites. Si le nombre de sites est petit 1000 , et puisque tous les sites relèvent de la portée d'un seul domaine d'administration, c'est un contexte où il est faisable d'utiliser des techniques de gestion manuelles. Dans ce cas, la passerelle de sécurité pourrait, de façon sélective, protéger le trafic en provenance ou à destination d'autres sites de l'organisation en utilisant une clé configurée manuellement, sans protéger le trafic vers d'autres destinations. Cela peut également s'avérer utile quand seule une partie sélectionnée des communications doivent être sécurisées. Un argument similaire peut s'appliquer pour l'utilisation complète d'IPsec au sein d'une organisation pour un nombre restreint d'hôtes et/ou de passerelles. Les techniques manuelles de gestion utilisent souvent des clefs symétriques configurées statiquement, bien qu'ils existent d'autres possibilités.

4.6.2 Les SA automatisées et la gestion des clefs

Le déploiement et l'utilisation massive d'IPsec exige un protocole de gestion des SA standard sur Internet, extensible et automatisé. Un tel support est exigé pour faciliter l'utilisation des dispositifs d'anti-rejeu de AH et d'ESP, et pour faciliter la création des SA sur demande, par exemple, pour l'introduction d'utilisateurs et de sessions (notez que la notion de "réintroduction" d'une SA implique réellement la création d'une nouvelle SA avec un nouveau SPI, processus qui implique généralement l'utilisation d'un protocole automatisé de gestion de SA et de clefs).

Le protocole de gestion automatisée des clefs choisi par défaut pour IPsec est IKE [MSST97, Orm97, HC98] dans son interprétation IPsec [Pip98]. D'autres protocoles de gestion automatique de SA PEUVENT être utilisés.

Quand un protocole de gestion automatisée de SA/clefs est utilisé, ce qui sort de ce protocole peut être utilisé pour générer plusieurs clefs, comme par exemple, pour une SA ESP simple. Cela peut arriver parce que :
- L'algorithme de chiffrement utilise plusieurs clefs (exemple, triple DES)
- L'algorithme d'authentification utilise plusieurs clefs
- Les algorithmes de chiffrement et d'authentification sont tous deux utilisés

Le système de gestion des clefs peut fournir une suite de bits séparée pour chaque clé ou il peut générer une suite de bits à partir desquels toutes sont extraites. Si une simple suite de bits est fournie, il faut prendre beaucoup de soin pour s'assurer que les parties du système qui donnent cette suite de bits aux clés nécessaires le font de la même façon aux deux extrémités de la SA. Pour s'assurer que les implémentations d'IPsec situées à chaque extrémité de la SA utilisent les mêmes bits pour les mêmes clés, et indépendamment de la partie du système qui divise la suite de bits en différentes clés, la ou les clefs de chiffrement DOIVENT être prises à partir des premiers bits (les bits de poids forts à gauche) et la ou les clefs d'authentification DOIVENT être prises à partir des bits restants. Le nombre de bits pour chaque clé est défini dans la RFC donnant les spécifications de l'algorithme. Dans le cas où il y a plusieurs clefs de chiffrement ou d'authentification, 1000 les spécifications de l'algorithme doivent indiquer l'ordre dans lequel elles doivent être choisies dans la simple suite de bits fournie à l'algorithme.

4.6.3 Localiser une passerelle de sécurité

Cette section étudie les solutions concernant la façon dont un hôte se renseigne sur l'existence des passerelles de sécurité appropriées et une fois qu'un hôte est entré en contact avec ces passerelles de sécurité, comment sait-il que ce sont des passerelles de sécurité correctes. Les détails sur l'endroit où sont stockées les informations nécessaires relèvent d'un problème local.

Considérons la situation où un hôte distant (H1) utilise Internet pour accéder à un serveur ou à une autre machine (H2), et où il y a une passerelle de sécurité (SG2), comme par exemple un firewall, par lequel le trafic de H1 doit passer. Un exemple pour cette situation serait un hôte mobile passant à travers Internet jusqu'au firewall central de l'organisation (SG2) (voir le cas 4 des combinaisons de base des SA, dans la section 4.5). Cette situation soulève plusieurs questions :
1. Comment H1 connaît ou apprend l'existence de la passerelle de sécurité SG2?
2. Comment authentifie-t-il SG2, et une fois qu'il l'a authentifié, comment est-il sûr que SG2 est autorisé à représenter H2?
3. Comment SG2 authentifie-t-il H1 et vérifie que H1 est autorisé à contacter H2?
4. Comment H1 sait ou apprend quelles sont les passerelles de sauvegarde donnant une alternative d'accès à H2?

Pour résoudre ces problèmes, un hôte ou passerelle de sécurité DOIT avoir une interface d'administration qui permet à l'utilisateur ou l'administrateur de configurer l'adresse d'une passerelle de sécurité pour toutes les adresses destination qui l'utilisent. Cela comprend la possibilité de configurer :
- l'information requise pour localiser et authentifier la passerelle de sécurité et vérifier son droit à représenter l'hôte destination.
- l'information requise pour localiser et authentifier toutes les passerelles de sauvegarde et vérifier leur droit à représenter l'hôte destination.

On suppose que la SPD est également configurée avec l'information de la politique qui couvre toutes les autres conditions d'IPsec pour avoir accès à la passerelle de sécurité et à l'hôte destination.

Ce document ne s'intéresse pas aux solutions d'automatisation de la découverte ou vérification des passerelles de sécurité.

4.7 Les Associations de sécurité et le multicast

L'orientation "récepteur" de l'Association de Sécurité implique, dans le cas d'un trafic unicast, que normalement, le système destination choisit la valeur du SPI. Si la destination choisit la valeur du SPI, il est impossible, pour que les associations de sécurité configurées manuellement (par exem 1000 ple, par un protocole de gestion de clés), d'être en conflit avec des associations de sécurité configurées automatiquement ou pour des associations de sécurité ayant plusieurs sources d'être en conflit entre elles. Pour le trafic multicast, il y a plusieurs systèmes destination par groupe multicast. Donc, un système ou une personne devra se charger de la coordination parmi tous les groupes multicast afin de choisir un SPI ou des SPIs au nom de chaque groupe multicast, puis pour communiquer l'information IPsec du groupe à tous les membres légitimes de ce groupe multicast, par l'intermédiaire de mécanismes non définis ici.

Les multiples émetteurs vers un groupe de multicast DEVRAIENT utiliser une association de sécurité simple (et par conséquent, incrémenter le SPI) pour l'ensemble du trafic à destination de ce groupe quand un algorithme de chiffrement à clé symétrique ou d'authentification est utilisé. Dans de telles circonstances, le récepteur sait seulement que le message est venu d'un système possédant la clé de ce groupe multicast. Dans de telles circonstances, un récepteur ne pourra généralement pas authentifier le système ayant envoyé le trafic multicast. Les spécifications sur d'autres cas plus généraux ayant trait au multicast sont reportées aux futurs documents IPsec.

Lorsque ces spécifications ont été éditées, les protocoles automatisés pour la distribution de clefs multicast n'ont pas été considérés suffisamment mûrs pour leur standardisation. Pour les groupes multicast ayant relativement peu de membres, une distribution manuelle des clefs ou l'utilisation multiple d'algorithmes existants de distribution de clefs unicast tels que Diffie-Hellman modifié semble possible. Pour les groupes importants, de nouvelles techniques "scalable" seront nécessaires. Un exemple de travail actuel dans ce domaine est le Group Key Management Protocol (GKMP) [HM97].

5. Traitement du trafic IP

Comme mentionné dans la Section 4.4.1 "La base de données de la politique de sécurité (SPD, Security Policy Database), la SPD doit être consultée pendant le traitement de tout trafic (ENTRANT et SORTANT), ce qui comprend le trafic non-IP. Si aucune politique correspondant à ce paquet (soit entrant, soit sortant) n'est trouvée dans la SPD, le paquet DOIT être jeté.

Remarque : Tous les algorithmes de cryptographie utilisés dans IPsec sont supposés avoir en entrée "in canonical network byte order" (voir Annexe de la RFC 791) et génèrent à la sortie "in canonical network byte order". Les paquets IP sont également transmis "in network byte order".

5.1 Traitement du trafic IP sortant

5.1.1 Choisir et utiliser une SA ou un paquet de SA

Dans une passerelle de sécurité ou une implémentation BITW (et dans beaucoup d'implémentations BITS), chaque paquet sortant est comparé avec la SPD pour déterminer le traitement exigé pour ce paquet. Si le paquet doit être jeté, c'est un événement auditable. Si on permet au le trafic de passer le traitement IPsec, le paquet suit ensuite le traitement "normal" de l'environnement dans lequel le traitement IPsec 1000 a lieu. Si le traitement IPsec est requis, le paquet est attaché à une SA (ou paquet de SA) existante, ou une nouvelle SA (ou paquet de SA) est créé pour ce paquet. Puisque les Sélecteurs d'un paquet pourraient correspondre à plusieurs politiques ou plusieurs SA existantes, et puisque la SPD est ordonnée, contrairement à la SAD, IPsec DOIT:
1. Faire correspondre le champ Sélecteur de paquet aux politiques sortantes dans la SPD pour localiser la première politique appropriée, qui pointera vers aucune ou plus SA dans la SAD.
2. Faire correspondre le champ Sélecteur de paquet à ceux du paquet de SA trouvé en (1) pour localiser le premier paquet de SA qui correspond. Si aucune SA n'a été trouvée ou qu'aucune ne correspond, il faut créer un paquet de SA appropriée et lier l'entrée de la SPD à l'entrée de la SAD. Si aucune entité de gestion de clefs n'est trouvée, on abandonne le paquet.
3. Utiliser le paquet de SA trouvé ou créé en (2) pour appliqué le traitement IPsec requis, comme par exemple, l'authentification et le chiffrement.

Dans une implémentation d'hôte IPsec basée sur les sockets, la SPD sera consultée à chaque fois qu'une nouvelle socket est créée, pour déterminer le traitement IPsec, s'il y en a un, à appliquer au trafic qui transitera par cette socket.

Remarque : Une implémentation conforme NE DOIT PAS autoriser l'instanciation d'une SA ESP qui utilise à la fois des algorithmes de chiffrement et d'authentification NULL. Le fait de négocier une telle SA est un évenèment auditable.

5.1.2 Construction de l'entête en mode tunnel

Cette section décrit comment manipuler les entêtes IP internes et externes, les entêtes d'extension, et les options des tunnels AH et ESP des tunnels. Ceci inclut la façon de construire l'entête (externe) IP encapsulé, la façon de manipuler les champs de l'entête IP interne, et d'autres manipulations à effectuer. L'idée générale est modelée d'après celle utilisée dans la RFC 2003, "IP Encapsulation with IP":
- Les adresses source et destination de l'entête IP externe identifient les "extrémités" du tunnel (l'encapsulateur et le décapsulateur). Les adresses source et destination de l'entête IP interne identifient l'émetteur et le récepteur originaux du datagramme (à l'origine du tunnel), respectivement (voir les remarques suivants le tableau en 5.1.2.1 pour plus de détails sur l'adresse IP source encapsulée.
- L'entête IP interne n'est pas modifiée, sauf pour décrémenter le TTL comme noté plus bas, et reste inchangée jusqu'à ce qu'elle soit délivrée à la sortie du tunnel.
- Aucun changement n'intervient dans les options IP ou dans les entêtes d'extension de l'entête interne pendant l'acheminement du datagramme encapsulé à travers le tunnel.
- Si besoin, d'autres entêtes de protocole comme l'entête d'authentification IP peuvent être insérés entre l'entête IP externe et l'entête IP interne.

Les tableaux des sous-sections suivantes montre la manipulation à effectuer sur les champs des différents entêtes ou options (construit = la valeur du champ externe est construit indépendamment de la valeur en interne).

5.1.2.1 IPv4 -- Construction de l'entête en le mode tunnel

<---- Lien en entête interne et externe ---->
Entête externe Entête interne
IPv4 de l'encapsulateur du décapsulateur
Champs d'entête: -------------------- -----------------
version 4 (1) pas de changement
longueur d'entête construit pas de changement
TOS copié de l'interne (5) pas de changement
longueur totale construit pas de changement
ID construit pas de changement
flags (DF,MF) construit, DF (4) pas de changement
fragment offset construit pas de changement
TTL construit (2) décrément (2)
protocole AH, ESP, entête de routage pas de changement
checksum construit 1000 construit (2)
adresse source construit (3) pas de changement
adresse dest construit (3) pas de changement
Options jamais copiées pas de changement

1 - La version IP dans l'entête d'encapsulation peut être différente de la valeur dans l'entête interne.

2 - Le TTL de l'entête interne est décrémenté par l'encapsulateur avant l'expédition et par le décapsulateur s'il fait suivre le paquet (le checksum change quand TTL change).

Remarque : Décrémenter le TTL est une des actions habituelles lors de l'expédition d'un paquet. Les paquets provenant du même noeud que l'encapsulateur n'ont pas leur TTL décrémenté, car le noeud émetteur est à l'origine du paquet plutôt qu'il ne le fait suivre.

3 - Les adresse source et destination dépendent de la SA, qui est utilisée pour déterminer l'adresse destination afin de déterminer quelle adresse source (interface réseau) est utilisée pour faire suivre le paquet.

Remarque : En principe, l'adresse IP source d'encapsulation peut être n'importe laquelle des adresses d'interface d'encapsulateur ou même une adresse différente de n'importe quelle adresse IP d'encapsulateur, (par exemple, si elle agit en tant qu'appareil faisant du NAT) à condition que l'adresse soit accessible par l'encapsulateur à partir de l'environnement dans lequel le paquet est envoyé. Ceci ne pose pas de problème parce qu'IPsec n'a actuellement aucune condition de traitement D'ARRIVÉE qui implique l'adresse source de l'entête IP d'encapsulation. Ainsi, tandis que l'extrémité réceptrice du tunnel regarde l'adresse destination dans l'entête IP d'encapsulation, il regarde seulement l'adresse source dans l'entête IP (encapsulé) interne.

4 - La configuration détermine s'il faut copier l'entête interne (uniquement pour IPv4), l'effacer ou mettre le DF.

5 - Si l'entête interne est IPv4 (Protocole = 4), on copie le TOS. Si l'entête interne est IPv6 (Protocole = 41), on associe le Class au TOS.

5.1.2.2 IPv6 -- Construction de l'entête en mode tunnel

Voir la section précédente 5.1.2 pour les notes 1 à 5 indiquées entre parenthèses.

<---- Lien en entête interne et externe ---->
Entête externe Entête intern 1000 e
IPv6 de l'encapsulateur du décapsulateur
Champs d'entête: -------------------- -----------------
version 6 (1) pas de changement
class copiée ou configurée (6) pas de changement
flow id copiée ou configurée pas de changement
longueur construit pas de changement
next header AH, ESP, entête de routage pas de changement
hop limit construit (2) décrément (2)
adresse source construit (3) pas de changement
adresse dest construit (3) pas de changement
Entêtes d'extension jamais copiés pas de changement

6 - Si l'entête interne est IPv6 (Next Header = 41), on copie le Class. Si l'entête interne est IPv4 (Next Header = 4), on associe le TOS au Class.

5.2 Traitement du trafic IP entrant

Avant d'exécuter le traitement AH ou ESP, tous les fragments IP sont rassemblés. Chaque datagramme IP entrant auquel le traitement IPsec sera appliqué est identifié par la valeur de AH ou ESP du champ Next Header du protocole IP (ou de AH ou ESP comme entête d'extension dans IPv6).

Remarque : L'annexe C contient l'exemple du code pour le contrôle du bitmask pour une fenêtre de 32 paquets qui peut être utilisé pour mettre en application le service d'anti-rejeu.

5.2.1 Choisir et utiliser une SA ou un paquet de SA

Faire correspondre un datagramme IP à la SA appropriée est simplifié grâce au SPI dans l'entête AH ou ESP. Notez que les vérifica 1000 tions du sélecteur (selector checks) sont fait sur les entêtes internes, et non sur les entêtes externes (tunnels). Les étapes à suivre sont :

1 - Utiliser l'adresse destination du paquet (entête IP externe), le protocole IPsec, et le SPI pour trouver la SA dans la SAD. Si la recherche de la SA échoue, jeter le paquet et rapporter (et loguer) l'erreur.

2 - Utilisez la SA trouvée en (1) pour effectuer le traitement IPsec, par exemple, authentifiez et déchiffrez. Cette étape inclut le fait de faire correspondre les sélecteurs du paquet (entête interne en cas de tunnel) aux sélecteurs de la SA. La politique locale détermine la spécificité des sélecteurs de la SA (valeur, liste, intervalle, wildcard simples). En général, l'adresse source d'un paquet DOIT correspondre à la valeur du sélecteur de la SA. Cependant, un paquet ICMP reçu sur une SA en mode tunnel peut avoir une adresse source autre que les valeurs limites de la SA et de tels paquets devraient être autorisés comme des exceptions à ce contrôle. Pour un paquet ICMP, les sélecteurs du paquet incluant le problème (les adresses source et destination et les ports devraient être permutés) devraient être comparés avec les sélecteurs de la SA. Notez que quelques ou tous les sélecteurs peuvent être inaccessibles en raison des limitations sur combien de bits du paquet posant problème le paquet ICMP est autorisé à porter ou en raison du chiffrement. Voir La Section 6.

Faire (1) et (2) pour chaque entête IPsec jusqu'à ce qu'un entête de protocole de transport ou un entête IP n'étant PAS pour ce système soit rencontré. Garder une trace des SA utilisées et de l'ordre dans lequel elles sont appliquées.

3 - Trouvez une politique entrante dans la SPD qui correspond au paquet. Cela peut être fait, par exemple, par l'utilisation de pointeurs inversés (backpointers) de la SA vers la SPD, ou en faisant correspondre les sélecteurs du paquet (entête interne en cas de tunnel) avec ceux des entrées de politique dans la SPD.

4 - Vérifiez si le traitement IPsec requis a été appliqué, c'est-à-dire vérifiez que la SA trouvée en (1) et (2) correspond au type et à l'ordre des SA requises par la politique trouvée en (3).

Remarque : La politique correcte "correspondante" ne sera pas forcement la première politique entrante trouvée. Si la vérification du (4) échoue, les étapes (3) et (4) sont répétées jusqu'à ce que toutes les entrées de politique aient été vérifiées ou jusqu'à ce que la vérification soit un succès.

À la fin de ces étapes, passez le paquet résultant à la couche transport ou expédiez le paquet. Notez que tous les entêtes IPsec traités dans ces étapes peuvent avoir été effacés, mais que cette information, c.-à-d., quelles SAs ont été utilisés et dans quel ordre elles sont appliquées, peut être nécessaire pour un traitement IPsec ultérieur ou pour un traitement par un firewall.

Notez que dans le cas d'une passerelle de sécurité, si l'expédition entraine la sortie d'un paquet par une interface IPsec, alors un traitement IPs 1000 ec supplémentaire peut être appliqué.

5.2.2 Manipulation des tunnels AH et ESP

La manipulation des entêtes IP interne et externe, des entêtes d'extension et, des options pour les tunnels AH et ESP devraient être réalisée comme décrit dans les tableaux de la Section 5.1.

6. La traitement d'ICMP (en relation avec IPsec)

Le but de cette section est la manipulation des messages d'erreur ICMP. Le reste du trafic ICMP, comme l'Echo/Reply, devrait être traité comme tous les autres flux et peut être protégé sur la base du end-to-end utilisant des SA de façon classique.

Un message d'erreur ICMP protégé par AH ou ESP et produit par un routeur DEVRAIT être traité et expédié par une SA en mode tunnel. La politique locale détermine si elle est soumise aux contrôles de l'adresse source par le routeur à l'extrémité sortante du tunnel. Notez que si le routeur à l'extrémité entrante du tunnel fait suivre le message d'erreur ICMP d'un autre routeur, le contrôle de l'adresse source échouerait. Un message ICMP protégé par AOH ou ESP et produit par un routeur NE DOIT PAS être expédié par une SA en mode transport (à moins que la SA n'ait été établie jusqu'au routeur en tant qu'hôte, comme par exemple, une connexion Telnet employée pour contrôler un routeur). Un message ICMP produit par un hôte DEVRAIT être comparé avec les sélecteurs de l'adresse IP source liés à la SA à laquelle le message arrive. Notez que même si la source du message d'erreur ICMP est authentifiée, l'entête IP retourné pourrait être incorrect. En conséquence, les valeurs de sélecteur dans l'entête IP DEVRAIENT également être vérifiées pour être sûres qu'elles sont conformes aux sélecteurs de la SA par laquelle le message ICMP a été reçu.

Le tableau de l'annexe D caractérisent les messages ICMP comme étant soit produit par l'hôte, soit par le routeur, soit par les deux, ou inconnu/non-assigné. Les messages ICMP entrant dans les deux dernières catégories devraient être manipulés comme déterminés par la politique du récepteur.

Un message ICMP non protégé par AH ou ESP est non-authentifié et son traitement et/ou son expédition peuvent avoir comme conséquence le déni de service. Ceci suggère que, en général, il soit souhaitable d'ignorer de tels messages. Cependant, on s'attend à ce que beaucoup de routeurs (contrairement aux passerelles de sécurité) n'implémentent pas IPsec pour le trafic transitant et une adhérence stricte à cette règle causeraient le rejet de nombreux messages ICMP. Le résultat serait que quelques fonctions critiques d'IP seraient détruites, comme par exemple, la redirection et le traitement des PMTU. Ainsi, il DOIT être possible de configurer une implémentation IPsec pour recevoir ou rejeter (routeur) le trafic ICMP selon la politique locale de sécurité.

Le reste de cette section s'intéresse à comment le traitement des PMTU DOIT être exécuté par les hôtes et les passerelles de sécuri 1000 té. Il s'occupe du traitement des messages PMTU ICMP authentifiés et non-authentifiés. Cependant, comme noté ci-dessus, les messages ICMP non-authentifiés PEUVENT être jeté sur la base de la politique locale.

6.1 Traitement des PMTU/DF

6.1.1 Bit DF

Dans les cas où un système (hôte ou passerelle) ajoute un entête d' encapsulation (tunnel ESP ou AH), il DOIT supporter l'option de copie du bit de DF du paquet initial à l'entête d'encapsulation (et le traitement des messages PMTU ICMP). Ceci signifie qu'il DOIT être possible de configurer le traitement système du bit DF (positionnement, effacement, copie à partir de l'entête encapsulé) pour chaque interface. (voir l'annexe B pour le raisonnement.)

6.1.2 Path MTU Discovery (PMTU)

Cette section discute de la manipulation IPsec pour les messages Path MTU Discovery. le PMTU ICMP est utilisé ici pour référencer un message ICMP pour :

IPv4 (RFC 792):
- Type = 3 (Destination injoignable)
- Code = 4 (Besoin de fragmentation et de positionnement du DF)
- Next-Hop MTU dans les 16 bits faibles du deuxième mot de l'entête ICMP (appelé "unused" dans la RFC 792), avec les 16 bits de poids forts à zéro.

IPv6 (RFC 1885):
- Type = 2 (Paquet trop large)
- Code = 0 (Besoin de fragmentation)
- Next-Hop MTU dans le champ de 32 bits du MTU du message ICMP6

6.1.2.1 Propagation du PMTU

La quantité d'information retournée avec le message PMTU ICMP (IPv4 ou IPv6) est limitée et ceci affecte quels sélecteurs sont disponibles pour l'utilisation de la propagation avancée de l'information du PMTU. (voir l'annexe B pour une discussion plus détaillée de ce sujet.)

- Le message PMTU avec 64 bits d'entête IPsec -- Si le message PMTU ICMP contient seulment 64 bits d'entête IPsec (minimum pour IPv4), alors une passerelle de sécurité DOIT supporter les options suivantes pour la base SPI/SA:

a. Si l'hôte d'origine peut être déterminé (ou si les sources possibles en nombre gérable), envoyer l'information PM à tous les hôtes d'origine possibles.
b. Si l'hôte d'origine ne peut être déterminé, stocker le PMTU avec la SA et attendre que le ou les paquets suivants arrivent de l'hôte d'origine pour la SA concernée. Si le ou les paquets sont plus importants que le PMTU, jeter le ou les paquets, et faire un ou des messages PMTU ICMP avec le ou les nouveaux paquets et le PMTU mis-à-jour, et envoyer le ou les messages ICMP concernant le problème à l'hôte d'origine. Garder l'information du PMTU pour tout message pouvant arriver par la suite (voir Section 6.1.2.4, "PMTU Aging").

- Message PMTU avec plus de 64 bits d'entête IPsec -- Si le message ICMP contient plus d'information du paquet initial, alors il peut y avoir assez d'informa 1000 tion non-opaque pour déterminer immédiatement à quel hôte propager le message PMTU ICMP et pour fournir à ce système les 5 champs (adresse source, adresse destination, port source, port destination, protocole de transport) requis pour déterminer où stocker ou mettre à jour le PMTU. Dans ce cas, une passerelle de sécurité DOIT produire un message PMTU ICMP dès la réception d'un PMTU ICMP .. .. ..(from further down the path).

- Distribuer le PMTU à la couche Transport -- Le mécanisme de l'hôte pour obtenir et mettre à jour le PMTU à la couche Transport est inchangée, comme spécifié dans la RFC 1191 (Path MTU Discovery).

6.1.2.2 Calcul du PMTU

Le calcul du PMTU à partir d'un PMTU ICMP DOIT prendre en compte l'addition d'un entête IPsec quel qu'il soit -- AH transport, ESP transport, AH/ESP transport, tunnel ESP, tunnel AH (voir Annexe B pour les solutions d'implémentation).

Remarque : Dans certaines situations, l'ajout des entêtes IPsec pourrait avoir comme conséquence un PMTU efficace (vu par l'hôte ou l'application) qui est trop petit. Pour éviter ce problème, l'implémentation peut établir un seuil au-dessous duquel elle n'enregistrerait pas un PMTU réduit. Dans ces cas-là, l'implémentation appliquerait IPsec et réduirait ensuite fragmenterait le paquet résultant selon le PMTU. Ceci aurait comme conséquence une utilisation plus efficace de la largeur de bande disponible.

6.1.2.3 Granularité du traitement du PMTU

Dans les hôtes, la granularité avec laquelle le traitement PMTU ICMP peut être fait diffère selon la situation de l'implémentation. En regardant un hôte, il y a 3 situations intéressantes en ce qui concerne les possibilités du PMTU (voir l'annexe B pour les détails supplémentaires à ce sujet) :
a. Intégration d'IPsec dans les implémentations natives
b. Implémentations Bump-in-the-stack, où IPsec est implémenté "en dessous" d'une implémentation existante de la pile TCP/IP, en le driver natif d'IP et les drivers du réseau local.
c. Pas d'implémentation d'IPsec -- Ce cas est inclus parce qu'il y a un rapport dans le cas où une passerelle de sécurité renvoie l'information de PMTU à un hôte.

C'est seulement dans le cas (a) que les données PMTU pourraient être mises à jour avec la même granularité que des associations de transmission. En (b) et (c), la couche IP pourra seulement mettre à jour des données du PMTU avec la granularité des adresses IP source et destination (et éventuellement TOS), comme décrit dans la RFC 1191. C'est une différence importante, parce que plus d'une association de transmission peut correspondre aux mêmes adresses IP source et destination, et chaque association de transmission peut avoir une quantité différente d'entête IPsec supplémentaire (par exemple, en raison de l'utilisation de différentes transformations ou différents algorithmes).

L'implémentation du calcul du PMTU et du support des PMTU avec la granularité de différentes associations de transmission est un probl&eg 1000 rave;me local. Cependant, une implémentation d'IPsec basée sur les sockets sur un hôte DEVRAIT mettre à jour l'information sur la base des sockets. La mémoire annexe (bump) des systèmes par pile DOIT passer le PMTU ICMP à l'implémentation de l'hôte IP, après son ajustement à n'importe quel surdébit d'entête d'IPsec ajouté par ces systèmes. Le calcul du surdébit DEVRAIT être déterminé par l'analyse du SPI et de n'importe quelle autre information de sélecteur présents dans un message PMTU ICMP retourné.

6.1.2.4 Vieillissement du PMTU

Dans tous les systèmes (hôte ou passerelle) mettant en application IPsec et mettant à jour l'information de PMTU, le PMTU associé à une association de sécurité (transport ou tunnel) DOIT "être vieilli" et un mécanisme doit être mis en place pour mettre à jour le PMTU d'une façon opportune, particulièrement pour découvrir si le PMTU est plus petit qu'il ne doit l'être. Un PMTU donné doit rester en place assez longtemps pour qu'un paquet aille de l'extrémité source de l'Association de Sécurité au système à l'autre extrémité de l'Association de Sécurité et pour qu'il propage en retour un message d'erreur ICMP si le PMTU actuel est trop grand. Notez que s'il y a les tunnels emboîtés, plusieurs paquets et des temps de voyage ronds pourraient être exigés pour recevoir un message ICMP en retour à un encapsulateur ou à un hôte d'origine.

Les systèmes DEVRAIENT utiliser l'approche décrite dans le document du Path MTU Discovery (RFC 1191, Section 6.3), qui suggère un reset périodique du PMTU au MTU de la liaison de données du premier saut et laisser ensuite le processus normal du PMTU Discovery agir et mettre à jour le PMTU si nécessaire. La période DEVRAIT être configurable.

7. Faire de l'audit

Tous les systèmes implémentant IPsec n'implémenteront pas l'audit. Pour la plupart, la granularité de l'audit est un problème locale. Cependant, plusieurs événements auditables sont identifiés dans les spécifications d'AH et d'ESP et pour chacun de ces événements, un ensemble minimum d'information DEVANT être inclus dans les logs d'audit est définie. De l'information supplémentaire PEUT également être incluse dans les logs d'audit pour chacun de ces événements, et des événements supplémentaires, pas explicitement exigés dans ces spécifications, POURRAIENT aussi entraîner des entrées dans les logs d'audit. Il n'y a aucune obligation pour le récepteur de transmettre n'importe quel message à un prétendu émetteur lors de la détection d'un événement auditable, à cause de la possibilité d'induire un déni de service par l'intermédiaire d'une telle action.

8. Utilisation dans les système supportant la sécurité du flux d'information

De l'information de niveaux de sensibilité variés peut être transportée par un réseau simple. Les étiquettes (labels) de l'information (par exemple, inclassable, Propriété de la société, secret) [DoD85, DoD87] sont souven 1000 t utilisés pour distinguer ces informations. L'utilisation des étiquettes facilite la ségrégation de l'information, comme par les modèles de sécurité du flux de l'information, par exemple, le modèle Bell-LaPadula [BL73]. De tels modèles, et leur technologie correspondante, sont conçus pour protéger le flux non autorisé d'information, même face aux attaques par chevaux de Troyes. Les mécanismes conventionnels et discrétionnaires du contrôle d'accès (DAC, Discretionary Access Control), comme par exemple, basés sur des listes de contrôle d'accès, ne sont généralement pas suffisants pour supporter de telles politiques, ainsi, les équipements tels que la SPD ne suffisent pas dans de tels environnements.

Dans le contexte militaire, la technologie qui supporte de tels modèles est souvent désigné sous le nom de sécurité à plusieurs niveaux (MLS, Multi-Level Security). Les ordinateurs et les réseaux sont souvent indiqués comme étant "sécurisés à plusieurs niveaux" s'ils supportent la séparation des données étiquetées en même temps que des politiques de sécurité du flux de l'information. Bien qu'une telle technologie soit plus largement utilisable qu'uniquement pour des applications militaires, ce document utilise l'acronyme "MLS" pour parler de cette technologie, ce qui est conforme à la littérature existante.

Les mécanismes IPsec peuvent facilement supporter les réseaux MLS. Les réseaux MLS exigent l'utilisation de contrôles d'accès obligatoires forts (MAC), où les utilisateurs non privilégiés ou les processus non privilégiés sont incapables de faire du contrôle ou de la violation. Cette section concerne seulement l'utilisation des mécanismes de sécurité IP dans des environnements MLS (politique de sécurité du flux de l'information). Rien dans cette section ne s'applique aux systèmes ne prétendant pas fournir de MLS.

Tel qu'il est utilisé dans cette section, le terme "information de sensibilité" peut inclure des niveaux hiérarchiques définis lors de l'implémentation, des catégories, ou/et version d'information (releasability information).

AH peut être utilisé pour fournir de l'authentification forte pour supporter les décisions obligatoires de contrôle d'accès dans des environnements MLS. Si de l'information IP explicite de sensibilité (par exemple, IPSO [Ken91]) est utilisée et que la confidentialité n'est pas considérée nécessaire dans un environnement opérationnel particulier, AH peut être utilisé pour authentifier les liens entre les étiquettes de sensibilité de l'entête IP et la charge utile IP (y compris données d'utilisateur). C'est une amélioration significative par rapport aux réseaux IPv4 étiquetés où on fait confiance à l'information sensible quoiqu'il n'y ait aucune authentification ou lien cryptographique entre l'information et les données IP de l'entête et de l'utilisateur. Les réseaux IPv4 pourraient ou ne pourraient pas utiliser un étiquetage explicite. IPv6 utilisera normalement l'information implicite de sensibilité qui fait partie de l'association de sécurité d'IPsec mais non transmise par chaque paquet au lieu d'utiliser l'information explicite de sensibilité. Toute l'information IP explicite de sensibilité DOIT être authent 1000 ifiée en utilisant par AH, ESP, ou les deux.

Le chiffrement est utile et peut être souhaitable même lorsque tous les hôtes sont dans un environnement protégé, comme par exemple derrière un firewall ou dépourvu de toute connectivité externe. ESP peut être utilisé, en même temps que des algorithmes appropriés de gestion de clefs et de chiffrement, comme DAC et MAC (le choix des algorithmes de chiffrement et d'authentification, et le niveau d'assurance d'une implémentation IPsec détermineront les environnements dans lesquels une implémentation peut être considérée comme suffisante pour répondre à des exigences de la MLS). La gestion de clefs peut se servir de l'information de sensibilité pour fournir du MAC. Les implémentations d'IPsec sur des systèmes prétendant fournir de la MLS DEVRAIENT être capables d'employer IPsec pour fournir du MAC pour les transmissions IP.

8.1 Relations entre les Associations de Sécurité et la sensibilité des données

AH et ESP peuvent tous deux être combinés avec des politiques appropriées d'association de sécurité pour arriver à des réseaux sécurisés à plusieurs niveaux (MLS). Normalement, dans ce cas, chaque SA (ou paquet de SA) est utilisé pour seulement une instance simple d'information de sensibilité. Par exemple, "PROPRIÉTAIRES - ingénierie Internet" doit être associé à une SA (ou paquet de SA) différente de "PROPRIÉTAIRES - finances".

8.2 Vérification de la cohérence de la sensibilité

Une implémentation MLS (hôte et routeur) PEUT associer l'information de sensibilité, ou un intervalle d'information de sensibilité, avec une interface, ou de adresse IP configuré avec son préfixe associé (ce dernier désigné parfois sous le nom d'interface logique, ou d'interface alias). Si de telles propriétés existent, une implémentation DEVRAIT comparer l'information de sensibilité associée au paquet avec l'information de sensibilité associée à l'interface ou à l'adresse/préfixe à partir duquel le paquet est arrivé, ou celui par lequel le paquet partira. Ce contrôle vérifiera soit que les sensibilités correspondent, soit que la sensibilité du paquet fait partie de l'intervalle de l'interface ou de l'adresse/préfixe.

Cette vérification DEVRAIT être faite sur le traitement entrant et sortant.

8.3 Attributs MLS supplémentaires pour la SAD

La section 4.4 s'est occupé de deux bases de données d'association de sécurité (la base de données de politique de sécurité (SPD) et la base de données d'association de sécurité (SAD)) et des sélecteurs de politique associés et des attributs de SA. Les réseaux MLS présente un selecteur/attribut supplémentaire:
- Information de sensibilité.

L'information de sensibilité aide à choisir les algorithmes appropriés et la longueur des clefs, de sorte que le trafic obtienne un niveau de la protection en relation avec son importance ou sa sensibilité comme décr 1000 it dans la section 8.1. La syntaxe exacte de l'information de sensibilité est définie lors de l'implémentation.

8.4 Etapes supplémentaires du traitement entrant pour les réseaux MLS

Après qu'un paquet entrant ait traversé le traitement IPsec, une implémentation de MLS DEAVRAIT d'abord vérifier la sensibilité du paquet (comme défini par la SA (ou paquet de SA) utilisée pour ce paquet) avec l'interface ou l'adresse/préfixe comme décrit dans la section 8.2 avant de faire suivre le datagramme ou de le livrer au protocole de la couche supérieure.

Le système MLS DOIT maintenir la liaison entre les données reçues dans un paquet protégé par IPsec et l'information de sensibilité de la SA ou les SA utilisées pour le traitement, ainsi, des décisions appropriées de politique peuvent être prises en livrant le datagramme à une application ou en le faisant suivre. Les moyens de mettre à jour cette liaison sont spécifique à l'implémentation.

8.5 Etapes supplémentaires du traitement sortant pour les réseaux MLS

Une implémentation IPsec MLS DOIT exécuter deux contrôles supplémentaires en plus des étapes normales détaillées dans la section 5.1.1. En consultant la SPD ou la SAD pour trouver une association sortante de sécurité, l'implémentation MLS DOIT utiliser la sensibilité des données pour choisir une SA (ou paquet de SA) sortante appropriée. Le deuxième contrôle vient avant l'expédition du paquet vers sa destination, et est le contrôle de cohérence de la sensibilité décrit dans la section 8.2.

8.6 Traitement MLS supplémentaire pour les passerelles de sécurité

Une passerelle de sécurité MLS DOIT suivre les règle de traitement d'entrée et de sortie précédemment mentionné, mais aussi exécuter un traitement supplémentaire spécifique à la protection intermédiaire des paquets dans un environnement MLS.

Une passerelle de sécurité PEUT agir en tant que proxy de sortie, créant des SA pour les systèmes MLS qui font suivre des paquets expédiés par la passerelle. Ces systèmes MLS peuvent explicitement étiqueter les paquets à expédier, ou l'ensemble du réseau d'origine peut avoir des caractéristiques de sensibilité associées à cela. La passerelle de sécurité DOIT créer et employer les SA appropriées pour AH, ESP, ou les deux, pour protéger ce trafic qu'il expédie.

De même, une telle passerelle DEVRAIT accepter et traiter les paquets entrant AH ou/et ESP et les expédier de façon appropriée, en utilisant un étiquetage explicite, ou en passant le relais aux caractéristiques de sensibilité du réseau destination.

9. En terme de performance

L'utilisation d'IPsec impose des coûts en terme de performance d'exécution sur les hôtes ou les passerelles de sécurité qui implémentent ces protocoles. Ces coûts sont associés à la mé 1000 ;moire nécessaire pour le code et les structures données d'IPsec, et au calcul des valeurs de contrôle d'intégrité, du chiffrage et du déchiffrage, et des manipulations supplémentaires pour chaque paquet. Les coûts de calcul par paquet se manifesteront par une latence plus importante et probablement une réduction de tout. L'utilisation d'un protocole de gestion de clefs/SA, particulièrement ceux qui utilisent la cryptographie à clef public, ajoute également des coûts de performance d'exécution à l'utilisation d'IPsec. Ces coûts se manifesteront par l'augmentation de la latence dans l'établissement d'association. Pour beaucoup d'hôtes, on prévoit que la cryptographie logicielle ne réduira pas sensiblement le débit, mais du matériel peut être nécessaire pour des passerelles de sécurité (puisqu'ils représentent des points d'agrégation), et pour quelques hôtes.

L'utilisation d'IPsec impose également des coûts d'utilisation de bande passante pour les composants de transmission, de commutation, et de routage de l'infrastructure Internet, composants n'implémentant pas IPsec. C'est dû à l'augmentation de la taille des paquets résultant de l'ajout des entêtes AH et/ou ESP, du tunneling AH et ESP (qui ajoute un deuxième entête IP), et l'augmentation du trafic de paquet associé aux protocoles de gestion de clefs. On prévoit que, dans la plupart des cas, ce besoin plus important de bande passante n'affectera pas vraiment l'infrastructure Internet. Cependant, parfois, les effets peuvent être significatifs, comme par exemple la transmission de trafic ESP chiffré par une liaison dialup qui sans ça, aurait compressé le trafic.

Remarque : Le surdébit d'établissement initiale de la SA sera ressenti dans le premier paquet. Ce retard peut avoir un impact sur la couche transport et application. Par exemple, il pourrait faire retransmettre le bit SYN par TCP avant que l'échange ISAKMP ne soit fait. L'effet de ce retard serait différent sur UDP parce que TCP ne devrait rien transmettre d'autre que le bit SYN jusqu'à ce que la connexion soit établie tandis qu'UDP avancera et transmettra des données au delà du premier paquet.

Remarque : Comme vu plus tôt, la compression peut encore être utilisé sur les couches au-dessus d'IP. Il y a un groupe de travail de l'IETF (IP Payload Compression Protocol (ippcp)) qui travaille sur les "spécifications de protocole qui permettent la compression sans perte sur différentes charges utiles avant que la charge utile ne soit traitée par un protocole qui la chiffre. Ces spécifications laisseront des opérations de compression s'exécutées avant le chiffrement d'une charge utile par des protocoles IPsec. "

10. Conditions de conformité

Tous les systèmes IPv4 prétendant implémenter IPsec DOIVENT être conformes à toutes les conditions de ce document d'architecture de sécurité. Tous les systèmes IPv6 DOIVENT être conformes à toutes les conditions de ce document d'architecture de sécurité.

11. Considération sur la sécurité

Le centre d'intérêt de ce document est la sécurité; par conséquent, les considérations sur la sécurité sont impré 1000 gnées dans ces spécifications.

12. Différences avec la RFC 1825

Ce document d'architecture diffère sensiblement de la RFC 1825 dans les détails et dans son organisation, mais les notions fondamentales sont inchangées. Ce document fournit des détails supplémentaires considérables en termes de spécifications de conformité. Il présente la SPD et la SAD, et la notion de Ssélecteurs de SA. Il est en correspondance avec les nouvelles versions de AH et ESP, qui diffèrent également de leurs prédécesseurs. Des conditions spécifiques pour les combinaisons de AH et ESP supportées sont nouvellement ajoutées, de même que les détails sur la gestion du PMTU.

Remerciements

Plusieurs des concepts incorporés dans ces spécifications sont dérivés ou influencés par le protocole de sécurité SP3 du gouvernement des USA, les NLSP ISO/IEC, le protocole de sécurité proposé par swIPe [SDNS, OIN, IB93, IBK93], et le travail effectué pour la sécurité de SNMP et SNMPv2.

Pendant plus de 3 années (même si ça semble parfois *beaucoup* plus long), ce document est passé par plusieurs versions et itérations. Pendant tout ce temps, beaucoup de gens ont contribué au processus et aux documents eux-mêmes en apportant des idées significatives et de l'énergie. Les auteurs voudraient remercier Karen Seo pour avoir apporté une aide importante dans la relecture, l'édition, la recherche de fond, et la coordination de cette version des spécifications. Les auteurs voudraient également remercier les membres des groupes de travail IPsec et IPng, avec une mention spéciale pour les efforts de (dans l'ordre alphabétique): Steve Bellovin, Steve Deering, James Hughes, Phil Karn, Kastenholz franc, Perry Metzger, David Mihelcic, Hilarie Orman, Shulman normand, William Simpson, Harry Varnis, et Nina Yuan.

Annexe A -- Glossaire

Cette section donne des définitions pour plusieurs mots-clefs utilisés dans ce document. D'autres documents donne des définitions supplémentaires et des informations de base en rapport avec cette technologie, comme [VK83, HA94]. Des termes relatifs aux mécanismes de sécurité ou à la sécurité en général sont inclus dans ce glossaire, ainsi que des termes spécifiques à IPsec.

Contrôle d'accès (Access Control) : Le contrôle d'accès est un service de sécurité qui prévient l'utilisation non-autorisée d'une ressource, où l'utilisation d'une ressource d'une façon non-autorisée. Dans le contexte IPsec, la ressource dont l'accès est contrôlé est souvent :
- Pour un hôte, les cycles de calcul et les données
- Pour une passerelle de sécurité, le réseau qui se trouve derrière la passerelle ou la bande passante de ce réseau.

Anti-rejeu (Anti-replay) : Voir "Intégrité" plus bas.

Authentification : Ce terme est utilisé de façon informelle pour désigner la combinaison de deux 1000 services de sécurité de base distincts, l'authentification de l'origine des données et l'intégrité en mode non connecté. Voir les définitions plus bas pour chacun de ces services.

Disponibilité (Availability) : La disponibilité, en tant que service de sécurité, s'intéresse aux attaques contre les réseaux qui bloque ou dégrade un service. Par exemple, dans le cas d'IPsec, l'utilisation de mécanismes anti-rejeu dans AH et ESP supporte la disponibilité.

Confidentialité (Confidentiality) : La confidentialité est le service de sécurité qui protège les données d'une fuite non-autorisé. La confidentialité de base concerne dans la plupart des cas la fuite non-autorisé aux données de la couche application, mais les fuites des caractéristiques externes de la communication peuvent être concernées dans certaines circonstances. La confidentialité du flux du trafic est le service qui s'occupe de ce dernier cas en cachant les adresses source et destination, la taille des messages, ainsi que la fréquence des échanges. Dans le cas d'IPsec, utilisant ESP en mode tunnel, surtout sur une passerelle de sécurité, peut apporter un certain niveau de confidentialité du flux du trafic (voir aussi "Analyse du trafic" plus bas).

Chiffrement (Encryption) : Le chiffrement est un mécanisme de sécurité utilisé pour transformer les données d'une forme intelligible (texte) en une forme inintelligible (texte chiffré), pour apporter la confidentialité. La transformation inverse est appelé "déchiffrage". Souvent, le terme "chiffrement" désigne les deux procédés.

Authentification de l'origine des données (Data Origin Authentication) : L'authentification de l'origine des données est un service de sécurité qui vérifie l'identité de celui qui se réclame comme la source des données. Ce service généralement combiné avec le service d'intégrité en mode non connecté.

Intégrité (Integrity) : L'intégrité est un service qui s'assure que les modifications des données sont détectables. L'intégrité vient de plusieurs façon correspondre avec les bsoins de l'application. IPsec supporte deux formes d'intégrité : en mode non connecté et une forme d'intégrité partielle des séquences. L'intégrité en mode non connecté est un service qui détecte les modifications sur un paquet IP particulier, sans s'occuper de la place du datagramme dans le flux de trafic. La forme d'intégrité partielle des séquences offerte par IPsec désigne l'intégrité anti-rejeu, et détecte l'arrivée d'un datagramme IP recopié (au sein d'une fenêtre limitée). Ceci est en opposition avec l'intégrité en mode orienté-connexion, qui impose des conditions plus sévère (stringent) sur le séquencement, comme par exemple d'être capable de détecter les messages perdus ou réordonnés. Même si l'authentification et l'intégrité sont souvent citées séparément, en pratique, elles sont intimement liées et sont toujours offertes en même temps.

Association de Sécurité (Security Association, SA) : Une connexion logique simplex (unidirectionnelle), créée pour des b 1000 esoins de sécurité. Tout le trafic passant par une SA reçoit le même traitement de sécurité. Dans IPsec, une SA est une chose abstraite de la couche Internet implémenté par l'utilisation d'AH ou d'ESP.

Passerelle de sécurité (Security Gateway) : Une passerelle de sécurité est un système intermédiaire qui agit comme interface de communication entre deux réseaux. L'ensemble des hôtes (et des réseaux) du côté extérieur de la passerelle de sécurité est en ensemble d'entités en lesquelles on ne peut pas avoir confiance (ou moins confiance), tandis que les réseaux et les hôtes côté intérieur sont considérés comme sûrs (ou plus sûrs). Les sous-réseaux internes et les hôtes servis par une passerelles de sécurité sont présumés sûrs grâce à l'administration de sécurité commune, locale et partagée (voir "Sous-réseaux de confiance" plus bas). Dans le cas d'IPsec, la passerelle de sécurité est un point où AH et/ou ESP sont implémentés pour servir un ensemble d'hôtes internes, en apportant des services de sécurité à ces hôtes lorsqu'ils communiquent avec des hôtes externes qui utilisent également IPsec (soit directement, soit par une autre passerelle de sécurité).

SPI : Acronyme pour "Security Parameters Index" ou Index des Paramètres de Sécurité. La combinaison d'une adresse destination, d'un protocole de sécurité et d'un SPI unique identifie une Association de Sécurité (voir plus haut). Le SPI est transporté dans les protocoles AH et ESP pour permettre au système récepteur de choisir la SA sous laquelle le paquet reçu sera traité. Un SPI a uniquement une signification locale, tel qu'il est défini par le créateur de la SA (généralement le récepteur du paquet transportant le SPI). Ainsi, un SPI est généralement vu comme une suite opaque de bits. Quoiqu'il en soit, le créateur de la SA peut choisir d'interpréter les bits du SPI pour faciliter le traitmeent local.

Analyse du trafic (Traffic Analysis) : L'analyse d'un flux de trafic réseau pour en déduire des informations est utile pour un adversaire. Les exemples d'information sont la fréquence des transmissions, les identités des deux parties en jeu, la taille des paquets, les identificateurs de flux, etc. [Sch94]

Sous-réseau de confiance (Trusted Subnetwork) : Un sous-réseau contenant des hôtes et des routeurs ont confiance les uns en les autres pour ne pas engager d'attaques actives ou passives. Ici aussi, il y a une supposition, qui est que le canal de transmission (par exemple, un LAN ou un CAN) n'est pas attaqué par d'autres.

Annexe B -- Analyse et discussion sur PMTU/DF/Fragmentation

B.1 Le bit DF

Au cas où un système (hôte ou passerelle) ajoute un entête encapsulé (comme un tunnel ESP), est-ce que le bit DF du paquet original doit être copié dans l'entête encapsulé?

Le fait de fragmenter est approprié dans certaines situations, par exemple, il peut être bon de fragmenter des paquets sur un réseau ayant un petit MTU, comme par exemple un réseau de paquets radio, ou po 1000 ur un saut depuis téléphone cellulaire à un nœud mobile, plutôt que propager avant un très petit PMTU tout au long du reste du chemin. Dans d'autres situations, il peut être bon de mettre le bit DF pour obtenir un feedback des derniers routeurs sur les contraintes du PMTU demandant de la fragmentation. L'existence de ces deux situations donne une bonne raison de laisser le système décider s'il doit ou non fragmenter sur une liaison particulière, c'est-à-dire de demander à une implémentation d'être capable de copier le bit DF (et de traiter les messages PMTU ICMP), mais en en faisant une option à choisir à partir d'une interface de base. En d'autres termes, un administrateur devrait pouvoir configurer le traitement des routeurs sur les bit DF (donner une valeur, effacer, copier de l'entête encapsulé) pour chaque interface.

Remarque : Si une implémentation BITS d'IPsec essaie d'appliquer des algorithmes IPsec différents basés sur les ports source et destination, il sera difficile d'appliquer des ajustements du Path MTU.

B.2 Fragmentation

S'il y a lieu, la fragmentation IP se produit après le traitement IPsec dans une implémentation d'IPsec. Ainsi, le mode transport d'AH et d'ESP est appliqué seulement aux datagrammes IP entiers (pas aux fragments IP). Un paquet IP auquel AH ou ESP a été appliqué peut lui-même être réduit en fragments par des routeurs au cours de l'acheminement, et de tels fragments DOIVENT être rassemblés avant le traitement IPsec du récepteur. En mode tunnel, AH ou ESP est appliqué à un paquet IP, dont la charge utile peut être un paquet réduit de fragments IP. Par exemple, une passerelle de sécurité, une implémentation BITS ou BITW d'IPsec, peut appliquer le mode tunnel d'AH à de tels fragments. Notez que les implémentations BITS ou BITW sont des exemples à partir desquels une implémentation d'hôte IPsec pourrait recevoir des fragments auxquels le mode tunnel doit être appliqué. Cependant, si le mode transport doit être appliqué, alors ces implémentations DOIVENT rassembler les fragments avant d'appliquer IPsec.

NOTE: IPsec doit toujours savoir quels sont les champs de l'entête IP encapsulé. C'est indépendant de l'endroit où IPsec est inséré et c'est intrinsèque à la définition d'IPsec. Toute implémentation IPsec non intégrée à IP doit inclure le code pour construire les entêtes nécessaires à IP (par exemple, IP2):
o AH-tunnel --> IP2-AH-IP1-Transport-Data
o ESP-tunnel --> IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer

De façon générale, l'approche par fragmentation/réassembage décrite ci-dessus fonctionne pour tous les cas a étudiés.

AH Xport AH Tunnel ESP Xport ESP Tunnel
Approche d'implémentation IPv4 IPv6 IPv4 IPv6 IPv4 IPv6 IPv4 IPv6
------------------------- ---- ---- ---- ---- ---- ---- ---- ----
Hôtes (integr dans pile IP) Y Y Y Y Y Y Y Y
Hôtes (entre IP et drivers) Y Y Y Y Y Y Y Y
Pass.S. (integr dans pile IP) Y Y Y Y
Processeur crypto externe *

* Si le système par processeur de crypto a sa propre adresse IP, alors il est couvert par le cas de la passerelle de sécurité. Cette boîte reçoit le paquet de l'hôte et exécute le traitement IPsec. Il doit pouvoir manipuler de la même façon AH, ESP, et le traitement d'un tunnel IPv4/IPv6 associé qu'une passerelle de sécurité devrait manipuler. S'il n'a pas sa propre adresse, alors il est semblable au implémentation BITS entre IP et les drivers réseau.

L'analyse suivante suppose que :
1. Il y a un seul module IPsec dans la pile d'un système donné. Il n'y a pas de module A (ajoutant ESP/chiffrement et donc) cachant le protocole de transport, port SRC et DEST d'un module IPsec B.
2. Il y a plusieurs endroits où IPsec peut être implémenté (comme montré par le tableau plus bas).
a. Hôtes avec intégration d'IPsec dans l'implémentation native d'IP. Celui qui implémente a accès au source de la pile.
b. Hôtes avec une implémentation "bump-in-the-stack" (BITS) où IPsec est implémenté entre IP et les drivers du réseau local. L'accès au source de la pile ne sont pas disponible; mais il y a des interfaces bien définies qui permettent au code IPsec d'être incorporé au système.
c. Les passerelles de sécurité et les processeurs externes de crypto qui intègre IPsec dans leur pile.
3. Toutes les approches vues plus bas ne sont pas faisables sur tous les hôtes. Mais on suppose que pour chaque approche, il y a certains hôtes pour qui l'approche est faisable.

Pour chacune des trois catégories ci-dessus, il y a IPv4 et IPv6, les modes transport et tunnel de ESP et de AH -- pour un total de 24 cas (3 x 2 x 4).

Quelques champs d'entête et d'interface sont énumérés ici pour la facilité de la référence -- ils ne sont pas dans l'ordre de l'entête, mais plutôt énumérés pour permettre la comparaison entre les deux colonne. (* = non couvert par l'authentification AH. L'authentification ESP ne couvrent aucun entête qui le précède).

Interface IP/Transport
IPv4 IPv6 (RFC 1122 -- Sec 3.4)
---- ---- ----------------------
Version = 4 Version = 6
Header Len
*TOS Class,Flow Lbl TOS
Packet Len Payload Len Len
ID ID (optional)
*Flags DF
*Offset
*TTL *Hop Limit TTL
Protocol Next Header
*Checksum
Src Address Src Address Src Address
Dst Address Dst Address Dst Address
Options? Options? Opt

? = AH couvre Option-Type et Option-Length, mais peut ne pas couvrir Option-Data.

Les résultats des 20 cas est donné ci-dessous ("works" = fonctionnera si le système fragmente après le traitement IPsec sortant, réassemble avant le traitement IPsec entrant). Les notes donne des indications pour l'implémentation.

a. Hôtes (intégré dans la pile IP)
o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
&nb 1000 sp; - IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works

b. Hôte (BITS) -- met IPsec entre la couche IP et les drivers réseau. Dans ce cas, le module IPsec devrait suivre une des propositions suivantes pour la segmentation et le réassemblage :
- faire le travail de fragmentation/réassemblage lui-même et émettre/recevoir le paquet directement à/de la couche réseau. En mode transport de AH ou de ESP, il n'y a pas de problème. En mode tunnel de AH ou de ESP où l'extrémité du tunnel est la destination finale, pas de problème. Mais en mode tunnel de AH ou de ESP où l'extrémité du tunnel est différente de la destination finale et où l'hôte source est multihomed, cette approche pourraient avoir comme conséquence un routage suboptimal parce que le module IPsec peut ne pouvoir pas obtenir l'information nécessaire (interface LAN et passerelle next-hop) pour diriger le paquet vers l'interface appropriée du réseau. Ce n'est pas un problème si l'interface et la passerelle next-hop sont les mêmes pour la destination finale et pour l'extrémité du tunnel. Mais s'ils sont différents, alors IPsec devrait connaître l'interface du réseau local et la passerelle next-hop pour l'extrémité du tunnel. (note: L'extrémité du tunnel (passerelle de sécurité) est généralement la voie d'accès habituelle pour atteindre la destination finale. Mais il pourrait également y avoir plus d'une voie d'accès pour atteindre la destination, par exemple, l'hôte pourrait être dans une organisation ayant 2 firewalls. Et l'accès utilisée peut comporter le firewall le moins connu). OU
- passer le paquet traité par IPsec de nouveau à la couche IP où un dernier entête IP supplémentaire serait ajouté au début et le module IPsec devrait le vérifier et laisser les fragments IPsec y passer.
OU
- Passer le contenu du paquet à la couche IP de telle façon que la couche IP recrée un entête IP approprié.

Au niveau de la couche réseau, le module IPsec aura accès aux sélecteurs suivants du paquet -- adresse SRC, adresse DST, Next Protocol, et s'il y a un entête de la couche transport --> ports SRC et DST. On ne peut pas supposer qu'IPsec a accès au Nom. On suppose que les informations disponibles du Sélecteur sont suffisantes pour retrouver l'e 1000 ntrée de la Politique de Sécurité et de(s) SA.

o AH-transport --> (IP1-AH-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-transport --> (IP1-ESP_hdr-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works

c. Passerelles de sécurité -- intégrer IPsec dans la pile IP

Remarque : Le module IPsec aura accès accès aux Sélecteurs suivants du paquet -- adresse SRC, adresse DST, Next Protocol, et s'il y a un entête transport --> port SRC et port DST. Il n'aura pas accès au User ID (seuls les hôtes ont accès au User ID). Contrairement à quelques implémentations BITS, les passerelles de sécurité peuvent être capable de retrouver l'adresse source dans le DNS pour avoir un nom de système, comme par exemple dans le cas où on utilise des adresses IP assignées dynamiquement avec des entrées DNS dynamiques et mises à jour. Il n'aura également pas accès aux informations de la couche transport s'il y a un entête ESP, ou si ce n'est pas le premier fragment du message fragmenté. On suppose que les informations disponibles du Sélecteur sont suffisantes pour retrouver l'entrée de la Politique de Sécurité et de(s) SA.

o AH-tunnel --> (IP2-AH-IP1-Transport-Data)
- IPv4 -- works
- IPv6 -- works
o ESP-tunnel --> (IP2-ESP_hdr-IP1-Transport-Data-ESP_trailer)
- IPv4 -- works
- IPv6 -- works

**********************************************************************

B.3 Path MTU Discovery

Comme vu plus haut, "PMTU ICMP" désigne un message ICMP utilisé pour le Path MTU Discovery.

La légende du diagramme plus bas en B.3.1 et B.3.3 (mais pas B.3.2) est :

==== = SA (AH ou ESP, transport et tunnel)
---- = connectivité (ou, si c'est indiqué, borne administrative)
.... = message ICMP (désigne le PMTU ICMP) pour

IPv4:
- Type = 3 (Destination Inatteignable)
- Code = 4 (Fragmentation nécessaire et positionner DF)
- Next-Hop MTU dans les 16 bits de poids faibles du second mot de
l'entête ICMP (appelé "inutilisé" dans la RFC 792), avec les 16
bits de poids forts à zéro

IPv6 (RFC 1885):
- Type = 2 (Paquet trop gros)
- Code = 0 (Fragmentation nécessaire et positionner DF)
- Next-Hop MTU dans le champ MTU de 32 bits de ICMP6

Hx = hôte x
Rx = routeur x
SGx = passerelle de sécurité x
X* = X supporte IPsec

B.3.1 Identifier le ou les hôtes d'origine

L'ensemble des informations renvoyées par le message ICMP est limité et affecte quels Sélecteurs sont disponibles pour identifier les SA, les hôtes d'origine, etc. dans l'utilisation pour la propagation des informations du PMTU.

En bref... Un message ICMP doit contenir les informations suivantes dans le paquet du problème :

- IPv4 (RFC 792) -- Entête IP plus un minimum de 64 bits

Par convention, dans le contexte IPv4, un PMTU ICMP peut seulement identifier la première SA (externe). Ceci est du au fait que le PMTU ICMP ne peut que contenir 64 bits du paquet du problème dans l'entête IP, et ne capturerait que le premier SPI de AH ou de ESP. Dans le contexte IPv6, un PMTU ICMP donnera probablement tous les SPI et les Sélecteurs dans l'entête IP, mais peut-être pas les ports SRC/DST (dans l'entête transport) ou les protocoles encapsulés (TCP, UDP, etc.). De plus, si ESP est utilisé, les ports transport et les Sélecteurs de protocoles peuvent être chiffrés.

Regardons le diagramme suivant d'un tunnel de passerelle de sécurité (comme dit autre part, les passerelles de sécurité n'utilise pas le mode transport)...

H1 =================== H3
\ | | /
H0 -- SG1* ---- R1 ---- SG2* ---- R2 -- H5
/ ^ | \
H2 |........| H4

Supposez que la politique de sécurité pour SG2 est utilisée pour une seule SA vers SG2 pour tout le trafic entre les hôtes H0, H1 et H2 et les hôtes H3, H4 et H5. Et supposez que H0 envoie un paquet de données à H5, ce qui entraîne le fait que R1 envoie un message de PMTU ICMP à SG1. Si le message PMTU a uniquement le SPI, SG1 sera capable de trouver la SA et de retrouver la liste des hôtes possibles (H0, H1, H2, wildcard); mais SG1 n'aura aucun moyen de trouver que H0 a envoyé le flux contenant le message PMTU ICMP.

paquet original après traitement IPsec paquet ICMP
---------------- ---------------------- -----------
entête IP-3 (S = R1, D = SG1)
entête ICMP (incluant PMTU)
entête IP-2 entête IP-2 (S = SG1, D = SG2)
entête ESP minimum 64 bits pour entête ESP (*)
entête IP-1 entête IP-1
entête TCP entête TCP
données TCP données TCP
1000 trailer ESP

(*) Les 64 bits incluront une partie suffisante de l'entête ESP (ou AH) pour inclure le SPI.
- ESP -- SPI (32 bits), Numéro de séquence (32 bits)
- AH -- Next header (8 bits), Longueur entête (8 bits), Réservé (16 bits), SPI (32 bits)

Cette limitation des informations renvoyées avec un message ICMP pose un problème pour identifier les hôtes d'origine du paquet (donc pour savoir à qui propager l'information PMTU ICMP). Si le message ICMP contient seulement 64 bits d'entête IPsec (minimum pour IPv4), alors les Sélecteurs IPsec (par exemple adresses source et destination, Next Protocol, ports source et destination, etc.) seront perdus. Mais le message d'erreur ICMP donnera toujours SG1 avec le SPI, les informations PMTU et les passerelles source et destination pour la SA associée.

La passerelle de sécurité destination et le SPI définissent de façon unique une association de sécurité pour définir un ensemble d'hôtes d'origine possibles. Dans ce cas, SG1 pourrait :
a. Envoyer l'information PMTU à tous les hôtes possibles d'origine. Cela ne fonctionnera pas très bien si la liste des hôtes est une wildcard où si plusieurs ou une majorité des hôtes n'envoyaient rien à SG1 ; mais cela peut marcher si les SPI/destination/etc correspondent à un ou peu d'hôtes.
b. Stocker le PMTU avec le SPI/etc et attendre le ou les paquets suivants de l'hôte d'origine pour la SA associée. Si il ou ils sont plus gros que le PMTU, on jette le ou les paquets, on compose le ou les messages PMTU ICMP avec le ou les nouveaux paquets et la mise à jour du PMTU, et on envoie le ou les messages ICMP concernant le problème à l'hôte ou aux hôtes d'origine. Ceci entraîne un délai dans la notification de l'hôte ou des hôtes d'origine, mais évite le problème de (a).

Etant donné que seule la deuxième approche est faisable dans tous les cas, une passerelle de sécurité DOIT donner une telle possibilité en option. Quoiqu'il en soit, si le message ICMP contient plus d'informations du paquet original, alors on aura peut-être suffisamment d'informations pour déterminer immédiatement l'hôte à qui on doit envoyer le message PMTU ICMP et pour trouver ce système avec les 5 champs (adresse source, adresse destination, port source, port destination, et protocole de transport) nécessaires pour déterminer l'endroit où stocker ou mettre à jour le PMTU. Dans ce cas, une passerelle de sécurité DOIT générer un message PMTU ICMP immédiatement après la réception d'un PMTU ICMP d'un accès. Remarque : Le champ Next Protocol peut ne pas être présent dans le message ICMP et l'utilisation du chiffrement ESP peut cacher les champs du Sélecteur qui ont été chiffrés.

B.3.2 Calcul du PMTU

Le calcul du PMTU à partir d'un PMTU ICMP doit prendre en compte l'addition d'un éventuel entête IPsec par H1 -- mode transport ou tunnel AH et/ou ESP. A partir d'un hôte unique, plusieurs applications peuvent partager un SPI et un problème de SA peut subvenir (Voir Section 4.5 "Combinaisons de base pour les SA" 1000 pour une description des combinaisons qui doivent être supportées). Le diagramme suivant illustre un exemple de SA entre deux hôtes (telle qu'elle est vu par l'un des hôtes). (ESPx ou AHx = mode transport)

Socket 1 -------------------------|
|
Socket 2 (ESPx/SPI-A) ---------- AHx (SPI-B) -- Internet

Pour retrouver le PMTU de chaque socket qui correspond à SPI-B, il sera nécessaire d'avoir des pointeurs de retour de SPI-B vers chacun des deux accès pour y parvenir -- Socket 1 et Socket 2/SPI-A.

B.3.3 Granularité du maintien des données PMTU

Dans les hôtes, la granularité avec laquelle le le traitement ICMP PMTU peut être exécuté diffère en fonction de la situation d'implémentation. En regardant l'hôte, il y a trois situations d'intérêt en respect des règles du PMTU :
a. Intégration d'IPsec dans l'implémentation native d'IP
b. Implémentations BITS, où IPsec est implémenté en dessus une implémentation existante de la pile du protocole TCP/IP, l'IP natif et les drivers du réseau local.
c. Pas d'implémentation IPsec -- Ce cas en fait partie parce qu'il nous intéresse dans le cas où une passerelle de sécurité renvoie les informations de PMTU à un hôte.

C'est seulement dans le cas (a) où les données du PMTU pourraient être mises à jour avec la même granularité que les associations de communication. Dans les autres cas, la couche IP mettra à jour les données du PMTU avec la granularité des adresses IP source et destination (et sur option les TOS/Class), comme décrit dans la RFC 1191. C'est une différence importante, parce que plus d'une association de communication peuvent correspondre aux mêmes adresses IP source et destination, et chaque association de communication peut avoir une quantité différente d'entête IPsec supplémentaire (par exemple, en raison de l'utilisation de différentes transformations ou différents algorithmes). Les exemples ci-dessous illustrent ceci.

Dans les cas (a) et (b)... Supposez que vous avez la situation suivante. H1 envoie à H2 et le paquet à envoyer de R1 à R2 excède le PMTU du réseau entre les deux.

==================================
| |
H1* --- R1 ----- R2 ---- R3 ---- H2*
1000 ^ |
|.......|

Si R1 est configuré pour ne pas fragmenter le trafic des abonnés, alors R1 envoie un message PMTU ICMP avec le PMTU approprié à H1. Le traitement de H1 change selon le type d'implémentation. Dans le cas (a) (IP natif), les services de sécurité seraient liés aux sockets ou équivalent. Ici, l'implémentation d'IP/IPsec dans H1 peut stocker ou mettre à jour le PMTU pour la socket associée. Dans le cas (b), la couche IP de H1 peut stocker ou mettre à jour le PMTU mais seulement avec la granularité des adresses source et destination et probablement du TOS/Class, comme vu ci-dessus. Ainsi le résultat peut être sub-optimal, puisque le PMTU pour un SRC/DST/TOS/Class donné sera la soustraction de la plus grande taille d'entête IPsec utilisée pour n'importe quelle association de communication entre une source et une destination données.

Dans le cas (c), il doit y avoir une passerelle de sécurité pour avoir un traitement IPsec. Supposez ainsi que vous avez la situation suivante. H1 envoie à H2 et le paquet à envoyer de SG1 à R excède le PMTU du réseau qui les sépare.

================
| |
H1 ---- SG1* --- R --- SG2* ---- H2
^ |
|.......|

Comme décrit ci-dessus pour le cas (b), la couche IP de H1 peut stocker ou mettre à jour le PMTU mais seulement avec la granularité des adresses source et destination, et probablement le TOS/Class. Ainsi le résultat peut être sub-optimal, puisque le PMTU pour un SRC/DST/TOS/Class donné sera la soustraction de la plus grande quantité d'entête d'IPsec utilisée pour n'importe quelle association de communication entre une source et une destination données.

B.3.4 Maintenance par socket des données PMTU

L'implémentation du calcul du PMTU (Section B.3.2) et le support des PMTU à la granularité d'"associations de communication" individuelles (Section B.3.3) est un problème local. Cependant, une implémentation IPsec sur un hôte basée sur les sockets DEVRAIT garder l'information pour chaque socket. Les systèmes BITS DOIVENT passer un PMTU ICMP à l'implémentation IP hôte, après l'avoir ajusté pour un tout entête IPsec ajouté par ces systèmes. La détermination de ce surplus DEVRAIT être déterminée par l'analyse du SPI et de toute information de Sélecteur présente dans le message PMTU ICMP renvoyé.

B.3.5 Livraison des données PMTU à la c 1000 ouche transport

Le mécanisme hôte pour mettre à jour le PMTU dans la couche transport est inchangé, comme spécifié dans la RFC 1191 (Path MTU Discovery).

B.3.6 Durée de vie des données PMTU

Ce sujet est vu dans la Section 6.1.2.4.

Annexe C -- Exemple de code pour la fenêtre d'espace des séquences

Cette annexe contient une routine qui implémente une vérification du bitmask pour une fenêtre de 32 paquets. Elle est apportée par James Hughes (jim_hughes@stortek.com) et Harry Varnis (hgv@anubis.network.com) et est un exemple d'implémentation. Notez que ce code teste à la fois le rejeu et les mises à jour de la fenêtre. Aussi, l'algorithme, tel qu'il est, devrait être appelé uniquement APRES que le paquet a été authentifié. Ceux qui implémentent pourraient vouloir étudier la possibilité de découper le code pour effectuer la vérification de rejeu avant de calculer l'ICV. Si le paquet n'est pas un rejeu, le code calculerait alors l'ICV, (jetant tous les mauvais paquets), et si le paquet est OK, on met à jour la fenêtre.

#include
#include
typedef unsigned long u_long;

enum {
ReplayWindowSize = 32
};

u_long bitmap = 0; /* session state - must be 32 bits */
u_long lastSeq = 0; /* session state */

/* Returns 0 if packet disallowed, 1 if packet permitted */
int ChkReplayWindow(u_long seq);

int ChkReplayWindow(u_long seq) {
u_long diff;

if (seq == 0) return 0; /* first == 0 or wrapped */
if (seq > lastSeq) { /* new larger sequence number */
diff = seq - lastSeq;
if (diff < ReplayWindowSize) { /* In window */
bitmap <<= diff;
bitmap |= 1; /* set bit for this packet */
} else bitmap = 1; &nbs 1000 p; /* This packet has a "way larger" */
lastSeq = seq;
return 1; /* larger is good */
}
diff = lastSeq - seq;
if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
if (bitmap & ((u_long)1 << diff)) return 0; /* already seen */
bitmap |= ((u_long)1 << diff); /* mark as seen */
return 1; /* out of order but good */
}

char string_buffer[512];

#define STRING_BUFFER_SIZE sizeof(string_buffer)

int main() {
int result;
u_long last, current, bits;

printf("Input initial state (bits in hex, last msgnum):\n");
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
sscanf(string_buffer, "%lx %lu", &bits, &last);
if (last != 0)
bits |= 1;
bitmap = bits;
lastSeq = last;
printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
printf("Input value to test (current):\n");

while (1) {
if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
sscanf(string_buffer, "%lu", &current);
result = ChkReplayWindow(current);
printf("%-3s", result ? "OK" : "BAD");
printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
}
return 0;
}

Annexe D -- Catégories des messages ICMP

Le tableau suivant caractérise les messages ICMP comme étant soit générés par l'hôte, soit par le routeur, les deux, ou non-assigné/inconnu. Le premier ensemble concerne IPv4. Le deuxième concerne IPv6.

IPv4

Type Nom/Codes Référence
========================================================================
GENERES PAR L'HOTE :
3 Destination inatteignable
2 Protocole inatteignable [RFC792]
3 Port inatteignable [RFC792]
8 Hôte source isolé [RFC792]
14 Violation de la précédence de l'hôte [RFC1812]
10 Sélection de routeur [RFC1256]

Type Nom/Codes Référence
========================================================================
GENERES PAR LE ROUTEUR :
3 Destination inatteignable
0 Réseau inatteignable [RFC792]
4 Besoin de fragmentation, le bit DF est à 1 [RFC792] < 1000 br> 5 Route désigné par la source a échoué [RFC792]
6 Réseau destination inconnu [RFC792]
7 Hôte destination inconnu [RFC792]
9 Communication avec réseau dest. est interdite [RFC792]
11 Réseau destination inatteignable pour ce TOS [RFC792]
5 Redirigé
0 Datagramme redirigé pour le réseau (ou sous-réseau)[RFC792]
2 Datatgrame redirigé pour le TOS et le réseau [RFC792]
9 Avertissement du routeur [RFC1256]
18 Réponse du masque de l'adresse [RFC950]

Type Nom/Codes Référence
========================================================================
GENERES A LA FOIS PAR L'HOTE ET LE ROUTEUR :
0 Réponse à l'écho [RFC792]
3 Destination inatteignable
1 Hôte inatteignable [RFC792]
10 Communication avec l'hôte destination interdite [RFC792]
&nbs 1000 p; 12 Hôte destination inatteignable pour Type of Service[RFC792]
13 Communication administrativement interdite [RFC1812]
15 Coupure de priorité en effet [RFC1812]
4 Source éteinte [RFC792]
5 Redirection
1 Datragramme redirigé pour l'hôte [RFC792]
3 Datagramme redirigé pour Type of Service et Hôte [RFC792]
6 Changement de l'adresse hôte [JBP]
8 Echo [RFC792]
11 Temps excédé [RFC792]
12 Problème de paramètre [RFC792,RFC1108]
13 Estampillage [RFC792]
14 Réponse estampillage [RFC792]
15 Demande d'information [RFC792]
16 Réponse d'information 1000 [RFC792]
17 Demande du masque de l'adresse [RFC950]
30 Traceroute [RFC1393]
31 Erreur de conversion de datagramme [RFC1475]
32 Redirection de l'hôte mobile [Johnson]
39 SKIP [Markson]
40 Photuris [Simpson]

Type Nom/Codes Référence
========================================================================
TYPE NON-ASSIGNE OU INCONNU GENERES :
1 Non-assigné [JBP]
2 Non-assigné [JBP]
7 Non-assigné [JBP]
19 Réservé (pour la sécurité) &n 1000 bsp; [Solo]
20-29 Réservé (pour les tests de robustesse) [ZSu]
33 IPv6 Où-es-tu (Where-are-you) [Simpson]
34 IPv6 Je-suis-là (I-am-here) [Simpson]
35 Demande d'enregistrement de mobile [Simpson]
36 Réponse d'enregistrement de mobile [Simpson]
37 Demande du nom de domaine [Simpson]
38 Réponse du nom de domaine [Simpson]
41-255 Réservé [JBP]

IPv6

Type Nom/Codes Référence
========================================================================
GENERES PAR L'HOTE :
1 Destination inatteignable [RFC 1885]
4 Port inatteignable

Type Nom/Codes Référence
================== 1000 ======================================================
GENERES PAR LE ROUTEUR :
1 Destination inatteignable [RFC1885]
0 Pas de route pour la destination
1 Communication avec destination administrativement interdite
2 Pas un voisin
3 Adresse inatteignable
2 Paquet trop gros [RFC1885]
0
3 Temps excédé [RFC1885]
0 Limite des sauts excédé pendant le transit
1 Temps de réassemblage des fragments excédé

Type Nom/Codes Référence
========================================================================
GENERES A LA FOIS PAR LE ROUTEUR ET L'HOTE :
4 Problème de paramètre [RFC1885]
0 Champ erroné rencontré dans l'entête
1 Type Next Header non-reconnu rencontré
2 Option IPv6 non-reconnue rencontré

Références

[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems : Mathematical Foundations and Model", Technical Report M74-244, The MITRE Corporation, Bedford, MA, May 1973.

[Bra97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", 1000 BCP 14, RFC 2119, March 1997.

[DoD85] US National Computer Security Center, "Department of Defense Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD., December 1985.

[DoD87] US National Computer Security Center, "Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD., 31 July 1987.

[HA94] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.

[HC98] Harkins, D., and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.

[HM97] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.

[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC DIS 11577, International Standards Organisation, Geneva, Switzerland, 29 November 1992.

[IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of Network-layer Security Under Unix", Proceedings of USENIX Security Symposium, Santa Clara, CA, October 1993.

[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer Security for IP", presentation at the Spring 1993 IETF Meeting, Columbus, Ohio

[KA98a] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.

[KA98b] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.

[Ken91] Kent, S., "US DoD Security Options for the Internet Protocol", RFC 1108, November 1991.

[MSST97] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.

[Orm97] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.

[Pip98] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.

[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6, John Wiley & Sons, New York, NY, 1994.

[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3, Document SDN.301, Revision 1.5, 15 May 1989, published in NIST Publication NIST-IR-90-4250, February 1990.

[SMPT98] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998.

[TDG97] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.

[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

Démenti

Les points de vue et les spécifications exprimés dans ce document sont ceux des auteurs et ne sont pas nécessairement ceux de leurs employeurs. Les auteurs et leurs employeurs démentent spécifiquement la responsabilité de tous les problèmes résultant de l'implémentation ou de l'utilisation correcte ou incorrecte de ce concept.

Information concernant ac5 les auteurs

Stephen Kent
BBN Corporation
70 Fawcett Street
Cambridge, MA 02140 (USA)
Phone: +1 (617) 873-3988
EMail: kent@bbn.com Randall Atkinson
@Home Network
425 Broadway
Redwood City, CA 94063 (USA)
Phone: +1 (415) 569-5000
EMail: rja@corp.home.net
Note originale de Copyright

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

FRAMEIP.COM

Partage des connaissances du monde TCP/IP

RFC 2401-fr – Architecture de sécurité pour IP