Distribution de politiques de sécurité IPsec

Distribution de politiques de sécurité IPsec
F. Barrère, A. Benzekri, F. Grasset, R. Laborde, Y. Raynaud
Université Paul Sabatier - IRIT/SIERA 118 Rte de Narbonne F31062 Toulouse Cedex04
Téléphone : +33 (0) 5 61 55 60 86 - Télécopie : +33 (0) 5 61 52 14 58
{barrere,benzekri,grasset,laborde,raynaud}@irit.fr
: Le déploiement du réseau Internet et la richesse des services proposés permet de
positionner aujourd'hui ce réseau comme infrastructure d'interconnexion complémentaire de
celles traditionnellement utilisées. Le standard IPsec de l'IETF présente les mécanismes de
base permettant d'élaborer une architecture de réseau privé virtuel (VPN). Afin d'enrichir cet
environnement, une architecture complète de gestion répondant à différentes politiques doit
être définie pour faciliter la mise en oeuvre de ces architectures d'interconnexion. Notre
contribution s'inscrit dans le cadre des architectures de gestion de VPN dynamiques multi
plates-formes. Elle porte en particulier sur les problématiques liées à la distribution d'une
politique de sécurité IPsec. Après avoir défini la notion de politique, une analyse du
fonctionnement des réseaux incluant des politiques est réalisée et les composants mis en
oeuvre sont examinés. A ce jour, trois protocoles semblent se dégager pour réaliser la
distribution des politiques (DIAMETER, COPS, SNMP). L'étude comparative de ces
protocoles nous a permis de mettre en évidence COPS et son extension COPS-PR comme
étant les mieux dotés. Enfin, Nous étudions le modèle d'information utilisé par COPS-PR : la
PIB IPsec.
RÉSUMÉ
: Politique de sécurité, Réseaux à base de politique, VPN dynamiques, COPS,
COPS-PR, PIB.
MOTS-CLÉS
2
GRES, Décembre 2001, Marrakech
1. Introduction
Le déploiement du réseau Internet et la richesse des services proposés permettent
de positionner aujourd'hui ce réseau comme infrastructure d'interconnexion
complémentaire de celles traditionnellement utilisées (X.25, Frame Relay ou les
liaisons spécialisées). Si la flexibilité de déploiement, la couverture mondiale et le
faible coût d'utilisation sont autant de qualités ayant imposé ce choix, il n'en demeure
pas moins que ce réseau est ouvert à tout type d'attaque. De nombreuses technologies
de tunnelisation et de chiffrement ont vu le jour afin de proposer des solutions de
sécurité au-dessus de l'Internet. Parmi celles-ci1, nous nous sommes particulièrement
intéressés à IPsec standard IETF offrant des mécanismes de construction de réseaux
privés virtuels.
Un réseau privé virtuel peut être vu comme une interconnexion de tunnels
sécurisés. La mise en place de ces tunnels est effectuée de manière statique ou
dynamique en utilisant le protocole IKE2, et ce sur la base d'un secret pré-partagé ou
de certificats électroniques authentifiant les deux parties grâce à une autorité de
certification tiers. La gestion de ces tunnels nécessite la configuration préalable des
équipements impliqués (routeurs, firewalls, PC, etc) ce qui rend difficile le
déploiement à grande échelle. De plus, la mise en place de VPN dynamiques
(ajout/suppression dynamique de tunnel, VPN au-dessus d'un VPN, etc)
correspondant à la définition de gestion de groupes d'utilisateurs est une tâche
laborieuse car nécessitant une vision cohérente de la configuration de tous les
membres du VPN. Il est donc nécessaire de mettre en oeuvre un système de gestion
complet adapté à une telle flexibilité.
2. Comment mettre en place un système de distribution ?
Pour pouvoir mettre en place un tel système, une politique de sécurité doit être
définie. Mais pour effectuer cette opération, il est nécessaire de caractériser avant
toute chose la notion de politique. Aucune spécification formelle n'existe, seule
l'IETF tente de manière informelle (Westerinen et al., 2001) d'effectuer ce travail
que nous avons complété.
3.1. Caractérisation une politique
Chacun semble avoir sa propre définition de la notion de politique. Pour la
plupart des gens, le terme politique est associé au concept de règles à respecter avec
divers degrés d'abstraction. Cependant, l'idée de politique implique aussi un certain
nombre de traitements à effectuer pour pouvoir l'utiliser. Le seul leitmotiv à propos
1
PPTP, L2TP, IPsec, SSL, TLS, PCT, Secure HTTP, PGP, S/MIME, SSH.
IKE permet de générer automatiquement les différentes clés nécessaires à la mise en place
des tunnels sécurisés IPsec.
2
Distribution de politiques de sécurité IPsec
3
de ce terme est qu'une politique permet de prendre des décisions pour une situation
donnée. Nos travaux nous ont permis de caractériser une politique selon trois
critères:
- selon quel niveau d'abstraction est considérée la politique,
- quel est le modèle d'information utilisé,
- quelle est la portée de cette politique.
3.1.1 Niveaux d'abstraction
La politique peut être représentée à différents niveaux d'abstraction, des buts
aspirés par l'entreprise (niveau le plus haut) aux paramètres de configuration
spécifiques aux équipements. La translation d'un niveau d'abstraction à un autre (plus
bas) peut nécessiter des informations autres que la politique, comme les paramètres
de configuration et les capacités du réseau ou de l'hôte. Ce mécanisme sera vu par la
suite. Il existe des documents et des implémentations qui tentent de spécifier de
manière explicite les niveaux d'abstraction. Cependant, ils se limitent à un certain
environnement. Pour exemple, une politique de haut niveau peut être « sécuriser les
données entre la machine de Fred et celle de Romain ». La même politique de niveau
plus bas peut être « Pour les trafics entre 115.141.64.21 et 115.141.64.30, utiliser les
certificats X509 pour l'authentification des parties lors des échanges des clés et IPsec
avec ESP en 3DES et mode tunnel pour le chiffrement ». Dans notre étude, nous
avons isolé quatre niveaux d'abstraction :
1. Le but de la politique,
2. Le niveau application,
3. Le niveau réseau,
4. Et le niveau équipement.
Le but d'une politique est le niveau le plus haut, c'est l'objectif posé par l'entreprise
ou l'état destiné à être maintenu par un système à base de politique. La politique est
énoncée sous forme de but à atteindre car la personne ne possède pas les
compétences techniques pour l'exprimer autrement. Ce niveau d'abstraction ne sera
pas considéré par la suite car il n'est pas possible de mettre en oeuvre un travail
automatisé partant de celui-ci. Le niveau applicatif est indépendant de la nature des
objets à traiter. Le niveau réseau tient compte des spécifications de l'équipement (par
exemple : adresse IP, port, etc) sans tenir compte de l'environnement (IOS de
CISCO, etc). Le niveau équipement correspond à la configuration existante sur les
équipements.
3.1.2 Le modèle d'information
Le modèle d'information d'une politique est la structure qui va permettre de
stocker la politique (par exemple : la MIB, la PIB, le modèle CIM). Cependant il ne
peut exister une seule structure pour tous les niveaux d'abstraction. En effet, la
pertinence des informations est différente entre chaque niveau. L'utilisation que l'on
veut en faire peut aussi amener à préférer un modèle plutôt qu'un autre.
4
GRES, Décembre 2001, Marrakech
3.1.3 La portée d'une politique
Une politique a une portée d'action limitée. La portée d'action représente
l'ensemble des équipements qui doivent respecter cette politique. La portée de la
politique générée par l'administrateur s'appelle le domaine d'administration.
3.1.4 Dérivation d'une politique
La politique définie par un administrateur étant de haut niveau, elle ne peut pas
être directement comprise par les équipements ou les applications. Il est donc
nécessaire de la traduire en règles de configuration. A chaque étape, plusieurs
politiques peuvent être en conflit. Il n'existe pas de recette simple pour résoudre tous
les conflits rencontrés. En fin de compte, c'est l'administrateur qui a la responsabilité
d'effectuer cette tâche. Les étapes suivantes doivent être appliquées de manière
récursive à chaque politique, jusqu'à ce que chaque règle puisse être comprise par la
cible :
- L'instanciation qui caractérise la politique par rapport à l'environnement
où elle s'applique.
- La localisation qui détermine l'entité chargée de faire appliquer la
politique.
- La translation qui transforme la politique en règles de configuration
propre à l'équipement.
3.2 Méthodes de distribution
La méthode de distribution de politique de sécurité IPsec doit répondre à
plusieurs contraintes:
- pouvoir gérer des VPN à grande échelle, c'est à dire des VPN comportant
un grand nombre de tunnels,
- permettre la gestion dynamique de ces VPN.
De plus, ceci doit être considérer dans un contexte industriel qui implique d'autres
contraintes comme une maîtrise exclusive de la politique de sécurité. Plusieurs
architectures ont été développées dans ce but. Cependant, aucune d'entre elles ne
semble satisfaire aux problèmes des VPN dynamiques.
3.2.1 Distribuée : SPP
Le groupe de travail IPSP a défini dans le draft (Sanchez et al., 2000) une
architecture complète de gestion de politique de sécurité IPsec dont les principales
caractéristiques sont :
1. Un serveur de sécurité gère un domaine de sécurité (ensemble
d'équipements terminaux et de passerelles) - il va fournir en politique IPsec
tout son domaine.
2. Les politiques sont échangées lors de la demande d'établissement d'une
connexion IPsec - c'est au moment où l'équipement terminal désire créer un
tunnel que la politique est constituée si l'autre extrémité n'appartient pas au
Distribution de politiques de sécurité IPsec
5
même domaine de sécurité, et est retournée aux différents équipements
concernés.
Cette architecture présente de nombreux problèmes :
1. C'est mécanique lourde - le nombre de messages et leur taille importante
deviennent une tare du fait de la seconde caractéristique.
2. La cohérence de la politique d'un VPN est fragile - la modification de la
politique d'un domaine n'est pas signalée aux serveurs des autres domaines.
De plus, SPP permet l'utilisation de cache qui met en péril l'homogénéité de
la politique.
3.2.2 Hybride
Pour résoudre ce problème de cohérence, (Seung-Jin et al., 2000) propose de
centraliser la politique de tous les domaines de sécurité ce qui permet à une autorité
de gestion de VPN de maîtriser la politique dans son intégralité (Figure 1).
Interface
administrateur VPN
Système
de gestion
Domaine de sécurité A
Base de
Règles
Domaine de sécurité B
Figure 1. Architecture hybride
Cette autorité sert donc de fournisseur de VPN ce qui amène deux problèmes :
- Les différentes entreprises impliquées dans un VPN (par exemple EADS)
ne désirent peut être pas qu'un tiers détienne une partie de leur politique
de sécurité.
- Les VPN que l'on souhaite obtenir ont une caractéristique importante : ils
sont dynamiques. Ceci implique entre autre que l'on puisse ajouter ou
supprimer des équipements du VPN. Il est nécessaire que le fournisseur
réagisse rapidement à ce type de requête.
Il est donc préférable que la politique de sécurité IPsec soit contrôlée par des
administrateurs locaux et non un fournisseur. De plus, cette solution ne prévoit pas le
cas de deux domaines gérés par deux fournisseurs différents désirant mettre en place
un VPN.
6
GRES, Décembre 2001, Marrakech
3.2.3 Centralisée : Les réseaux à base de politique
L'idée des réseaux à base de politique repose sur la proposition faite par le
Network Working Group de l'IETF dans (Yavatkar et al., 2000). Elle permet aux
administrateurs réseaux ou aux fournisseurs de services de faire appliquer leur
politique d'utilisation de leur réseau à partir de critères comme l'identité des
utilisateurs ou des applications, le trafic demandé, etc. Son principe est de centraliser
la politique dans une base de données et garantir son application par des mécanismes
de distribution (Figure 2).
Les réseaux à base de politique introduisent un nouveau concept : le domaine
d'administration. Un domaine d'administration est un ensemble d'équipements, situés
ou non sur un même réseau, contrôlés par une entité unique. Cette notion est un
concept central dans la gestion des réseaux à base de politique. En effet, le domaine
administratif représente la portée de la politique définie par l'administrateur.
Système de gestion de politique
d'a Dom
dm a
inis ine
tra
tio
n
PDP
Protocole de
transaction
Protocole d'accès
Base de
à la base
Règles
Protocole de
transaction
PEP
PEP
Figure 2. Architecture des réseaux à base de politique
L'administrateur configure la politique de niveau application via le système de
gestion. La politique est ensuite stockée dans une base de règle, elle est alors de
niveau réseau. Enfin, le PDP et les PEP se chargent de la faire appliquer par les
équipements concernés. L'administrateur possède un contrôle total sur son domaine
d'administration3. Cependant, dans le cas d'une coopération entre différentes
3
qui ne correspond pas forcément à un domaine IP.
Distribution de politiques de sécurité IPsec
7
entreprises qui impliquerait la mise en oeuvre d'un VPN, un dialogue inter-domaines
est nécessaire pour concevoir une politique de sécurité commune.
3. Notre solution
Le modèle que nous proposons (Figure 3) est une extension du modèle des
réseaux à base de politique (Benzekri et al., 2001) (Laborde, 2001). L'étude faite
dans (Laborde, 2001) de cette architecture montre qu'elle répond aux besoins d'un
système de gestion VPN dynamiques :
- Permettre à l'administrateur d'avoir une vision globale en centralisant la
politique du domaine d'administration dans la base de règles,
- Distribuer la politique de manière automatique à chaque équipement
concerné grâce au PDP, aux PEP et au protocole de transaction.
PIB
Domaine
administratif
PEP
INTERNET
COPS-PR/
IPsec
PIB
PDP
COPS-PR/
IPsec
Service de
gestion de la
politique de
sécurité
LDAP
COPS-PR/
IPsec
PIB
PEP
COPS-PR/
IPsec
PDP
COPS-PR/
IPsec
LDAP
PEP
PIB
PIB
LDAP
PEP
PIB
PEP
Domaine
administratif
PIB
Figure 3. Notre architecture
Elle apporte en plus une facilité de gestion en permettant de faire abstraction de
l'hétérogénéité des systèmes implémentant IPsec par l'utilisation de différents
niveaux d'abstractions de la politique permettant ainsi d'obtenir une architecture
multi plates-formes. Cependant, il est nécessaire d'y ajouter la communication interdomaines pour pouvoir créer des VPN entre équipements faisant partie de domaines
d'administration différents.
8
GRES, Décembre 2001, Marrakech
4.1 Le PDP et les PEP
Le lien qui existe entre le PDP et ses PEP est comparable à celui qui unie un juge
aux policiers. Le PDP prend les décisions que les PEP font respecter. Ils
fonctionnent en mode "provisionning", i.e., le PDP va approvisionner les PEP en
politique. Un agent PEP est implanté sur chaque équipement que l'on désire
configurer. Au démarrage, le PEP va chercher la politique associée à l'équipement
auprès du PDP via le protocole de transaction. A la réception, il vérifie si elle ne
contient pas d'erreur et translate cette politique de niveau réseau en une politique de
niveau équipement. Lorsque l'administrateur modifie la politique de son domaine, le
PDP envoie, de manière non sollicitée, la nouvelle politique aux PEP concernés.
4.2 La base de règles
Nous utilisons un annuaire LDAP pour base de règles. Un annuaire est une base
de données spécialisée permettant de partager des bases d'informations sur le réseau
interne ou externe. Il est optimisé pour la lecture des informations qu'il contient mais
non pour l'écriture. Cette caractéristique est très intéressante pour les besoins de
l'architecture car les lectures faites par le PDP doivent être rapides. De plus,
l'administrateur ne va créer des politiques qu'occasionnellement. Les annuaires sont
conçus pour stocker une grande quantité de données mais de faible volume. Ils
supportent des informations extensibles, ce qui permet de pouvoir ajouter ou
supprimer des attributs à des types d'informations. L'évolution des équipements étant
un facteur important, il est nécessaire de pouvoir modifier les politiques sans devoir
en créer de nouvelles.
4.3 Le protocole de distribution
Le PEP et le PDP dialoguent par un protocole dit protocole de transaction.
Plusieurs candidats postulent à être ce protocole
de distribution de politiques :
- COPS (Common Open Policy Service) qui est spécialement conçu pour la
gestion de politique. Il respecte toutes les exigences de (Yavatkar et al.,
2000).
- SNMP (Simple Network Management Protocol) qui est le standard
actuel pour la gestion de réseaux et qui est en train d'être modifié pour
devenir conforme aux exigences des réseaux à bases de politiques.
- DIAMETER qui est une extension de RADIUS. Ce protocole est assez
flexible et peut donc être personnalisé pour la gestion de politique.
Une étude comparative entre ces différents protocoles est effectuée dans (Laborde,
2001). Le protocole DIAMETER qui n'est définit que sous forme de draft se
préoccupe du niveau utilisateur et non du niveau réseaux ; nous l'avons donc mis à
l'écart. Il reste encore COPS et SNMP qui possèdent chacun des avantages et des
défauts. Cependant notre choix s'est porté sur COPS et plus particulièrement sur son
Distribution de politiques de sécurité IPsec
9
extension COPS-PR pour ses caractéristiques assurant un niveau de sûreté plus élevé
que SNMP.
4.3.1 Le protocole COPS-PR
Le Network Working Group de l'IETF définit le protocole COPS (Boyle et al.,
2000) comme un mécanisme simple de type demande/réponse permettant l'échange
de politique entre un serveur de politique (Policy Decision Point ou PDP) et ses
différents clients (Policy Enforcement Point or PEP). Il peut être, conceptuellement,
divisée en deux sous-couches : le protocole de base, les directives d'usages du
protocole de base (Figure 4).
COPS-PR
COPS-RSVP COPS-SIP ...
...
COPS
TCP
Modèle Provisionning
Modèle Outsourcing
Futures Extensions
Figure 4. La pile COPS
Le protocole COPS-PR (Chan et al., 2001) est l'extension du protocole COPS
pour le fonctionnement en mode provisionning. Il ajoute une sémantique aux
messages COPS en introduisant un modèle d'information qui contient la politique de
niveau réseau : la PIB. Donc distribuer une politique IPsec avec COPS-PR équivaut
à définir la PIB IPsec.
4.3.2 La PIB IPsec
La PIB est un modèle d'information comparable à la MIB de SNMP (Chan et al.,
2001) (Mc Cloghrie et al., 2001). En effet, la politique est construite comme une
collection de règles identifiées par des PRID4 (OID). Elle est structurée sous la
forme d'un arbre où les branches sont des PRC5 et les feuilles des PRI6 ce qui permet
4
PRovisionning IDentifier
PRovisionning Class : les types
6
PRovisionning Instances : les instances des PRC
5
10
GRES, Décembre 2001, Marrakech
à la PIB de s'adapter facilement à l'évolution de la politique (modifications des
équipements, des technologies, etc). De plus, elle évite toute redondance.
SPD
IKE phase 1
Règle IPsec
IKE phase 2
Sélecteur
Filtre sur
les
adresses
IP
Action
Filtre sur
les ports
niveau 4
Règles IKE
Autre
extrémité de
l'association
Période de
validité
SA ISAKMP
SA IPsec
Période de
validité
Proposition
IPsec
Proposition
IKE
Figure 5. La PIB IPsec
Cependant, au contraire de la MIB qui considère la politique pour chaque
équipement7, la PIB se préoccupe du type d'équipement en introduisant la notion de
combinaison de rôles. Lorsque le PEP se connecte au PDP, il envoie un ensemble de
7
point de vue cohérent pour SNMP où le serveur se "connecte" à l'agent SNMP
Distribution de politiques de sécurité IPsec
11
combinaisons de rôles qui vont caractériser les fonctionnalités des interfaces qu'il
gère. Par rapport à ces informations, le PDP retourne la politique adéquate au PEP.
Le problème est maintenant de définir la gestion de ces combinaisons de rôles
pour la PIB IPsec. L'IETF propose dans (Li et al., 2001) une spécification (Figure
5). Ce schéma ne présente que les éléments les plus importants afin de garantir une
clarté suffisante à la compréhension. Une case correspond donc soit à une PRC, soit
à un ensemble de PRC. Les parties concordantes à la configuration de la SPD ainsi
qu 'IKE sont présentes. Elle contient donc les informations nécessaires pour la
distribution d'une politique de sécurité IPsec.
Les combinaisons de rôles se trouvent dans les PRC « Règles IPsec » et « Règles
IKE », mais ce ne sont pas ces dernières qui sont envoyées au PDP dans les requêtes.
Lorsque le PEP se connecte en utilisant COPS-PR, il informe tout d'abord le PDP
des PRC qu'il supporte en utilisant deux PRC définies dans (Fine et al., 2001). Il
envoie ensuite deux autres PRC (frwkIfCaps Group) qui contiennent les
combinaisons de rôles correspondantes aux interfaces de l'équipement et des
informations précisant leur capacité. Par rapport à ces informations, le PDP remplit
la PIB IPsec du PEP. S'il intervient un changement, le PEP informe le PDP grâce
aux PRC du frwkIfCaps Group.
Il est donc légitime de se demander à quoi servent les combinaisons de rôles qui
sont contenues dans les PRC « Règles IPsec » et « Règles IKE ». Voici comment (Li
et al., 2001) nous en donne l'explication.
Lorsque le PDP reçoit une requête d'un PEP contenant les combinaisons de rôles
des interfaces, il regarde :
- Si elles correspondent seulement aux combinaisons de rôles de la PRI «
Règles IPsec », alors la politique n'utilise pas IKE, i.e., la partie phase 1
d'IKE ne sera pas envoyée au PEP.
- Si elles correspondent seulement aux combinaisons de rôles de la PRI «
Règles IKE », alors la partie phase 2 d'IKE ne sera pas envoyée au PEP.
- Si elles correspondent aux deux, la politique oblige l'utilisation d'IKE et
d'IPsec.
Cette glose amène à être critiquée.
La PIB n'est que le modèle d'information utilisé par COPS-PR pour distribuer les
politiques. Le fait d'utiliser les combinaisons de rôles dans les PRC « Règles IPsec »
et « Règles IKE » comme le stipule (Li et al., 2001) amène à penser que cette
structure est celle qui sera aussi employée dans la base de règles, ce qui est une fort
mauvaise tactique. La base de règles stocke la politique et optimise les temps de
lecture alors que la PIB transporte la politique et donc minimise la place prise par les
informations. Le modèle d'information ne doit pas être le même car l'utilisation
désirée n'est pas la même. De plus, le modèle d'information de la base de données
LDAP est indépendant du protocole de transaction au contraire de la PIB. Cette
12
GRES, Décembre 2001, Marrakech
séparation permet d'utiliser un autre protocole que COPS-PR pour la distribution en
politique. Pour gérer les combinaisons de rôles, nous proposons l'ajout d'une
nouvelle base de données qui permet de faire la correspondance entre les
combinaisons de rôles et les entrées dans la base de règles. La Figure 6 présente un
scénario qui explique comment le PDP retourne la politique adéquate à la requête
envoyée par le PEP.
(1)
PEP
COPS-PR
PDP
Base de
règles
PIB
PIB
(3)
(4)
Correspondance
rôle <-> Règle
(2)
Figure 6. Solution de gestion des combinaisons de rôles
1) Le PDP reçoit les deux PRC du frwkIfCaps Group lui permettant de
prendre ses décisions.
2) Il regarde dans une base de correspondance (rôle,règles) dans la base
LDAP pour déterminer quelles sont les règles à appliquer.
3) Il récupère l'ensemble des règles.
4) Le PDP les transforme pour quelles soient conformes au modèle
d'information PIB.
L'utilisation des combinaisons de rôles dans la PRC « Règles IPsec » et dans la
PRC « Règles IKE » est-elle justifiée pour le PEP ?
En théorie, le gain de place engendré par ces deux combinaisons de rôles est
clairement visible. Néanmoins dans la pratique, deux interfaces d'un même
équipement n'auront pas la même partie réservée à la SPD. La combinaison de rôles
se trouvant sur la PRC « Règle IKE » est donc totalement inutile.
Distribution de politiques de sécurité IPsec
13
5. Extension
Dans cet article, nous avons identifié le besoin de mettre en oeuvre un système de
gestion de VPN dynamiques. Nous avons exposé les différentes architectures de
gestion ainsi que leurs limites. Pour ceci, nous proposons une architecture de gestion
de VPN IPsec dynamiques multi plates-formes construite sur les réseaux à base de
politique. Une maquette fonctionnant pour les implémentations IPsec FreeS/WAN
et CISCO corrobore nos résultats (Benzekri et al., 2001) (Laborde, 2001).
Le concept de VPN dynamique apporte une nouvelle approche de la notion de
réseau. Pour l'instant, un VPN est un environnement sécurisé d'équipements
dialoguant ensemble. Cependant, la flexibilité de ces VPN dynamiques permet de ne
plus considérer un réseau par les équipements qui le constituent, mais par les
utilisateurs qui y accèdent. Il serait donc intéressant d'inclure la couche application à
notre architecture.
Enfin, à ce stade notre architecture fonctionne pour un seul domaine
d'administration ce qui est comme nous l'avons vu insuffisant. Des travaux ultérieurs
présenteront les communications inter-domaines permettant de construire des VPN
entre équipements appartenant à des domaines d'administration différents.
9. Bibliographie
Benzekri A., Barrère F., Grasset F., Laborde R., Raynaud Y., “A security policy management
architecture for the Extended Enterprise”, ICE 2001, 7th International Conference on
Concurrent Enterprising, Brème – Allemagne, Juin 2001.
Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R. and A. Sastry, “The COPS(Common
Open Policy Service) Protocol”, RFC 2748, January 2000.
Chan K., Seligson J., Durham D., Gai S., McCloghrie K., Herzog S., Reichmeyer F.,
Yavatkar R., Smith A., “COPS Usage for Policy Provisioning (COPS-PR)”, RFC 3084,
March 2001.
Fine M., McCloghrie K., Seligson J., Chan K., Hahn S., Sahita R., Smith A., Reichmeyer F.,
“Framework Policy Information Base”, “draft-ietf-rap-frameworkpib-05.txt”, July 2001.
Laborde R., “Distribution d’une politique de sécurité IPsec, DEA”, Université Paul Sabatier
Toulouse III, 2001.
Li Man, Arneson David, Doria Avri, Jason Jamie, Wang Cliff, “ IPsec Policy Information
Base”, “draft-ietf-ipsp-ipsecpib-03.txt”, Juillet 2001.
McCloghrie K., Fine M., Seligson J., Chan K., Hahn S., Sahita R., Smith A., Reichmeyer F.,
“Structure of Policy Provisioning Information (SPPI)”, “draft-ietf-rap-sppi-07.txt”, May
2001.
Sanchez L.A., Condell M.N., “Security Policy Protocol”, “draft-ietf-ipsp-spp-00.txt”, July
2000.
14
GRES, Décembre 2001, Marrakech
Seung-Jin Baek, Moon-Sang Jeong, Jong-Tae Park, Tai-Myoung Chung, “Policy-based
Hybrid Management Architecture for IP-based VPN”, IEEE/IFIP Network Operations
and Management Symposium, Honolulu, Hawaii, April 2000.
Westerinen A., Schnizlein J., Strassner J., Scherling Mark, Quinn Bob, Herzog Shai, Huynh
An-Ni, Carlson Mark, Perry Jay, Waldbusser Steve, “Terminology”, draft-ietf-policyterminology-03.txt, April 2001.
Yavatkar R., Pendarakis D., Guerin R., “A Framework for Policy-based Admission Control”,
RFC 2753, January 2000.