Spécification de l'architecture globale
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Spécification de l’architecture globale
Déliverable 2 - 13 Janvier 2003
Houda Labiod, Guy Pujolle
labiod@enst.fr, Pujolle@lip6.fr
Résumé
Un des objectifs majeurs des réseaux mobiles multiservices de 4ème génération est d’offrir un
environnement mobile performant qui permettra à un utilisateur muni de son ordinateur
portable (PC, PDA, …) ; équipé de plusieurs interfaces d’accès sans fil ; de se déplacer de
manière transparente entre plusieurs réseaux gérés par différents fournisseurs. Deux autres
éléments clés sont importants à prendre en considération qui sont la sécurité et la qualité de
service à offrir aux utilisateurs tout en assurant une optimisation de l’utilisation des
ressources.
Dans le contexte de ce projet qui est celui d’une interconnexion de systèmes sans fil multi-
fournisseur et dans le but d’atteindre les objectifs cités ci-dessus, nous nous sommes penchés
sur la spécification d’une architecture globale de maîtrise de qualité de service de bout-en-
bout et de sécurité. Cette architecture intègre principalement les fonctionnalités de contrôle
d’accès basé sur RADIUS ainsi que des mécanismes de contrôle de qualité de service basés
sur le développement de politiques avec COPS. La qualité de service ainsi que le contrôle
d’accès sont gérés en grande partie par une carte à puce virtuelle. De nouveaux concepts et
protocoles ont été définis et seront détaillés dans ce document.
Mots-clés : réseaux 4G, contexte multi-fournisseur, carte SIM-IP, COPS, RADIUS, WiFi,
802.1x1. Introduction
Le formidable essor que connaît actuellement les technologies sans fil Wireless Local Area
Networks (WLAN) et Wireless Personal Area Networks (WPAN), est certainement un
phénomène majeur qui a marqué ces dernières années le domaine de l’accès sans fil [1].
Probablement, une convergence de toutes ces technologies avec les réseaux mobiles 2.5G/3G
[2,3] entraînera une panoplie de solutions intégrées et la combinaison de plusieurs standards
améliorera la connectivité sans couture. Chaque standard sera optimisé et adapté à un
environnement donné. Une panoplie de travaux est menée dans le cadre de consortia
d’industriels et d’organismes de normalisation afin de définir des solutions plus robustes en
termes de sécurisation, de QoS, ….. Parmi ces instances, on peut citer la famille des groupes
de travail IEEE 802 (802.11x, 802.15, 802.16), ITU-R, et ETSI BRAN. Jusqu’à présent, ces
travaux n’ont pas encore abouti à l’approbation de standards; une échéance d’achèvement des
travaux est annoncée pour le début de l’année 2003. Dans l’attente d’un ou de plusieurs
standards, des solutions intermédiaires sont adoptées. Plusieurs standards WLANs sont en
compétition (IEEE 802.11, HomeRF, Hiperlan2) mais aujourd’hui un consensus émerge
autour des normes IEEE 802.11b (WiFi) et IEEE 802.11a (WiFi 5) [4].
Plusieurs facteurs clés laissent prévoir une montée en puissance du marché WLAN, parmi
lesquels nous pouvons citer :
- une maturité progressive des normes (spécialement celles dérivées du 802.11
WiFi et WiFi 5),
- une baisse progressive des prix,
- une évolution des débits (11Mbit/s avec WiFi et 54Mbit/s avec 802.11a/g),
- le ‘retard’ des systèmes mobiles de 3ème génération,
- un investissement considérable des grands constructeurs dans la fabrication des
terminaux, carte et points d’accès,
- une augmentation du déploiement du multi-équipement à domicile,
- une mobilité accrue des utilisateurs.
Dans le cadre de la 4ème génération des systèmes mobiles multiservices, le WLAN occupe une
place importante et de ce fait nous nous sommes focalisés, dans un premier temps, sur une
étude basée sur la technologie WLAN.
Par ailleurs, le boom de l’Internet a fait jaillir des applications diverses telles la messagerie
électronique, instant messaging et les services web qui peuvent être lancés sur la majorité des
périphériques disponibles actuellement (notebooks, PDAs, ordinateurs portables, ...). Par
conséquent, accéder à ces applications constitue un élément important. Actuellement, la
majorité des infrastructures véhicule explicitement le trafic IP. Par conséquent, les futures
architectures 4G devront inclure des réseaux hétérogènes ainsi qu’un backbone-coeur IP. Par
ailleurs, comme l’Internet évolue vers des réseaux multiservices, un élément clé est de
supporter des services avec une garantie de QoS.
Dans le cadre de ce contexte multi-technologies, l’utilisateur sera probablement muni de
plusieurs terminaux supportant plusieurs interfaces d’accès. Il choisira les réseaux d’accès
selon le service désiré. Néanmoins, établir un contrat fixe avec chaque fournisseur est une
solution chère et complexe à gérer. L’utilisateur préfèrera plutôt d’autres alternatives plus
souples telles qu’un paiement par service indépendamment du fournisseur lui-même mais
dépendant par contre de la qualité de service offerte (bande passante effective, délai, jigue).
Les réseaux constituant notre architecture doivent supporter les fonctionnalités élémentaires
de support de QoS. En effet, l’identification des utilisateurs ainsi que le contrôle d’accès
constituent des problèmes critiques à résoudre dans un tel contexte de support de QoS.
2Indépendamment du cadre juridique, qui incombe des restrictions selon certains pays, des
interrogations demeurent quant aux limitations actuelles de cette technologie. La sécurité
constitue particulièrement un problème crucial pour ces réseaux dont le support de
transmission diffusant est partagé. En outre, la qualité de service représente un verrou majeur
à lever.
Actuellement, le marché des hotspots (lieux de passage de grande densité ouverts au public)
représente le marché qui suscite le plus d’intérêt, il concerne l’accès haut débit à des données
en des lieux publics de forte densité (aéroport, gare, hôtel, café, bibliothèque, métro, centres
commerciaux, centres de conférences, parcs de loisirs, restaurants, ..). Une effervescence de
hotspots a vu le jour en Europe, on compte plus de 1000 hotspots dont la majorité se trouvent
dans les pays nordiques. Concernant la France, très récemment un assouplissement de la
réglementation a été annoncé par l’ART [5] autorisant l’installation de hotspots ouverts au
public.
Les opérateurs de télécommunications mobiles français perçoivent désormais la technologie
WLAN comme une technique d'accès complémentaire de la 3G. Ils sont donc fortement
intéressés par mettre en oeuvre des mécanismes efficaces qui gèrent la mobilité des
utilisateurs entre les infrastructures sans fil leurs propres réseaux mobiles. Il reste à proposer
des solutions pour pallier aux limitations concernant la qualité de service et les questions de
sécurité.
En se basant sur le contexte ainsi décrit et en mettant un accent sur la technologie WLANs
nous décrivons dans ce rapport, de manière détaillée, la spécification de l’architecture globale
qui offre une solution englobant des mécanismes de sécurisation des réseaux et des
procédures d’accès aux services avec support de roamingt et de QoS.
Ce rapport comprend principalement six sections. La deuxième section décrit le contexte
multi-fournisseur des réseaux 4G et souligne les principaux verrous techniques à lever. La
section 3 rappelle les objectifs visés par le projet. Quant à la quatrième section, elle donne une
description détaillée de notre architecture et les approches proposées pour résoudre les
problèmes techniques citées en Section 1. Dans la Section 5, nous décrivons de manière
détaillée la solution de contrôle d’accès que nous proposons. L’architecture de contrôle de la
qualité de service est donnée en Section 6. Une synthèse sur l’insécurité de WiFi est donnée
en annexe I. Une brève présentation de l’architecture 802.1x est donnée en annexeII.
2. Description du contexte du projet
Nous considérons le cas d’une multitude de réseaux gérés par plusieurs autorités. Dans un tel
contexte multi-fournisseur, le roaming constitue un problème critique à résoudre.
Pour des raisons de performance, nous considérons que la majorité des WLANs est gérée
exclusivement par un seul opérateur. Ainsi, un utilisateur peut changer de localisation
géographique sans faire appel à un autre opérateur au niveau de la même localisation (sauf
certaines exceptions biensûr). Les avantages principaux offerts par un opérateur seraient le
débit effectif, la QoS et le nombre de sites où le service est disponible. Par conséquent, une
coopération entre les opérateurs WLANs permettra de fournir un accès aux utilisateurs sur
une zone géographique plus étendue.
En plus d’un mécanisme de nommage commun des utilisateurs, les fournisseurs de services
impliqués doivent établir différents accords (service level agreement , technologies, prix, …)
dans le but d’offrir un accès avec roaming depuis ou vers les autres réseaux. Les détails
relatifs aux “contrats de roaming” ne sont pas traités dans le cadre du projet MMQoS et sont
généralement négociés entre les différents fournisseurs. Dans la suite, nous résumons les
3principaux problèmes soulevés par ce type d’architecture. Principalement, nous distinguons
trois problèmes cruciaux à résoudre:
• contrôle d’accès avec mobilité: Chaque fournisseur A doit assurer un accès sécurisé à
des utilisateurs potentiellement inconnus par le fournisseur B.
- Quel est le schéma de nommage à adopter pour la définition des identités des
utilisateurs ?
- Où sera localisée cette identité et comment peut-elle être protégée contre d’éventuelles
attaques?
- Quelles informations (identité, ..) l’utilisateur mobile doit-il présenter au réseau visité
et comment le fournisseur A peut-il vérifier l’exactitude de ces informations des
utilisateurs provenant du réseau du fournisseur B?
- Une fois authentifié, comment l’utilisateur a accès au réseau de service? Comment
peut-on offrir l’accès au service localisé dans le home network de l’utilisateur?
• QoS: A cause de la bande passante limitée, les environnements wireless sont
particulièrement sensibles à la détérioration de service dans le cas d’une forte charge du
réseau.
- Comment peut-on contrôller le trafic de l’utilisateur?
- Comment un service offert peut-il être garanti aux visiteurs avec certaines contraintes
de QoS?
- Comment un fournisseur A peut-il prouver à un utilisateur X et à son propre
fournisseur B que cet utilisateur utilise réellement les ressources du réseau A?
• Facturation: L’information de facturation dépend du contrat de roaming.
- Comment peut-on collecter l’information de facturation associée aux utilisateurs
itinérants?
- Comment peut-on délivrer des preuves de l’exactitude de cette information?
Généralement, les réseaux mobiles 2.5G et 3G supportent différents niveaux de QoS et des
mécanismes de facturation bien définis. L’authentification est basée sur l’utilisation de la
carte SIM subscriber’s identity module (SIM in GSM [6], USIM in UMTS [7]) qui stocke les
informations et les algorithmes d’authentification. Donc, ce type de réseau est adapté pour
servir en tant que domaine d’autorité dans un contexte multi-fournisseur.
Jusqu’à présent, les standards WLAN existants ne supportent pas les trois fonctionnalités
citées ci-dessus malgré que différents working groups (WG) IEEE sont impliqués dans la
recherche de solutions à ces problèmes. Il s’agit notamment de :
• WG 802.1x qui définit des mécanismes de contrôle d’accès pour les réseaux 802
networks avec support de roaming,
• WG 802.11e qui traite les aspects relatifs à la QoS,
• WG 802.11i qui propose un standard global pour améliorer la sécurité des réseaux sans fil.
Un premier challenge consiste à définir une architecture de réseau à adopter par chaque
fournisseur de telle sorte à ce qu’elle soit réalisable de manière simple et qui permette de
répondre efficacement aux besoins de sécurité et de garantie des exigences de QoS. Cette
architecture reprend certains protocoles en cours de normalisation à l’IETF et àl’IEEE. Un
deuxième challenge est de spécifier les protocoles à mettre en place pour gérer
l’interconnexion des différents réseaux des divers fournisseurs et permettre le roaming des
utilisateurs..
43. Principaux objectifs
3.1 Description
Le principal objectif du projet est d’offrir la mobilité des utilisateurs avec support de QoS de
bout-en-bout dans un contexte multi-fournisseur de réseaux sans fil hétérogènes avec
différentes autorités de management (voir Figure 1). La carte à puce SIM-IP [8], qui est
décrite en détail dans le déliverable 1 et résumée dans la Section 4.3, constitue un élément clé
de l’architecture proposée. Elle est utilisée pour stocker de manière sécurisée l’identité de
l’utilisateur et des éléments nécessaires pour le contrôle d’accès au réseau. En particulier, le
contrôle de QoS basée sur l’utilisation de politiques est appliqué du moment qu’il est adapté
au contexte de notre projet. Dans la phase préliminaire du projet, nous limitons nos
investigations en considérant uniquement les hotspots WiFi.
Figure 1. Architecture globale du projet MMQoS
Les objectifs du projet sont les suivants.
3.2 Mobilité
La mobilité constitue une caractéristique cruciale. Nous définissons la mobilité comme étant
la possibilité à un utilisateur de se déplacer à travers les différents réseaux constituant
l’infrastructure globale sans changer d’identité. Les hotspots sont géographiquement espacés.
Le maintien de l’identité de l’utilisateur facilitera donc les opérations de facturation. Par
ailleurs, nous supposons que le contexte multi-fournisseur est défini pour une période assez
longue. Les procédures telles que les seamless handoffs et les fast handoffs ne feront pas
l’objet d’études dans le cadre du projet mais devront être étudiées de manière approfondie.
3.3 QoS
La QoS englobe deux objectifs principaux. Le premier objectif consiste à assurer à
l’utilisateur que le service a respecté les critères de QoS exigés. Le second objectif consiste à
fournir une solution qui permet d’offrir la qualité demandée en optimisant l’utilisation des
ressources selon le profil de l’utilisateur. Dans le but d’offrir une solution flexible pour la
gestion de la QoS, nous proposons d’utiliser le standard COPS [9]. Introduire une entité de
contrôle de réseau centrale permettra donc d’adapter dynamiquement des profils QoS selon
5l’état du réseau. De plus, un échange d’informations concernant les profils peut être fait entre
les fournisseurs concernés.
3.4 Sécurité
Afin d’offrir un accès sécurisé aux réseaux pour garantir la QoS basée sur le niveau de service
défini par l’utilisateur et dans le but d’assurer une facturation fiable, des mécanismes
d’authentification robustes sont indispensables. Bien évidemment, ces mécanismes doivent
supporter le roaming.
Il est également indispensable d’élaborer des schémas de cryptage efficaces sur les liens sans
fil. Nous devons inclure aussi l’identité de l’utilisateur dans les paquets véhiculés dans le but
d’assurer un accès sécurisé aux services aussi bien dans le réseau home que dans les réseaux
visités.
4 La solution proposée
Afin d’explorer les problèmes fondamentaux et critiques soulevés par les futures architectures
de réseaux mobiles, nous proposons de considérer l’architecture système 4G décrite par la
Figure 2. Cette architecture ouverte supporte une multitude de services multimédias. Elle
permet une évolution de ces services. Elle intègre aussi bien les fonctionnalités de base liées à
la mobilité (authentification, roaming, ..) que de nouvelles procédures de support de QoS.
Le but de cette section est de présenter les entités et les protocoles impliqués dans
l’architecture globale. Elle comprend une description générale de l’architecture globale
fonctionnelle. Une présentation détaillée de l’architecture du réseau du fournisseur de service
est donnée.
4.1 Architecture système 4G
L’architecture globale est vue comme une architecture ouverte qui permet une évolution des
caractéristiques des services via la collaboration de diverses entités réseau filaires et sans fil.
Globalement, elle est composée par une panoplie de réseaux de service de fournisseur service
‘provider networks’ (SPNs) interconnectés par un réseau backbone IP . Les hotspots WLANs
sont gérés par chacun des fournisseurs.
Les tâches de gestion sont exécutées en se basant sur l’utilisation de politiques de gestion qui
reflètent les exigences du fournisseur et des utilisateurs. Pour ce faire, on fait appel aux entités
COPS telles que les PDPs (Policy Decision Point) et les PEPs (Policy Enforcement Point).
PEPs sont des Edge routers qui sont connectés via des liens de communication à grande
vitesse.
6PDP PDP
SPN A SPN B
IP backbone
PDP
SPN C SPN D
PDP
WLAN C
Legend
Data traffic
Control traffic
PEP PDP PDP
SPN C Service Provider Network C
Figure 2. Architecture système globale
4.2 Architecture du réseau du fournisseur de service (SPN)
L’architecture proposée consiste en une série d’entités qui se situent dans divers plans (voir
Figure3). Ces entités communiquent par le biais de protocoles dépendant du plan et de la
nature des entités. L’architecture fonctionnelle est composée de trois plans: un plan business,
un plan management plan et un plan réseau.
Service model
Policy repository
Routing policies
Accounting
admin
an ss
pl ine
e
s
Bu
LDAP
e ent
AAA PDP
pl gem
a
an
an
M
RADIUS COPS
an rk
pl wo
e
et
N
Figure3. Plans fonctionnels
7 Plan Business :
Base de politiques
Politiques de routage
Modèle de service
Accounting
Plan Management :
Serveur Central AAA
Serveur Central COPS PDP
Base de données SessionDB
Plan réseau:
Clients AAA
Clients COPS
Carte SIM-IP
Comme le montre la Figure 4, le système d’exploitation ‘operating system’ (OS) exécute
toutes les commandes de l’utilisateur. L’OS utilise la carte SIM-IP pour accéder à
l’équipement du terminal (TER), i.e. généralement l’adaptateur réseau. Le réseau lui-même
est caractérisé par un edge device i.e. un access point (AP), des serveurs responsables des
fonctions de management et quelques serveurs optionnels dépendant du fournisseur. Nous
proposons que la carte SIM-IP implémente une partie des ‘core services’ suivants :
• Accès réseau utilisant 802.1x et RADIUS,
• QoS basé sur COPS,
• Accès Service basé sur une identification-IP (information encapsulée dans les paquets
envoyés)
Chaque fournisseur doit intégrer au minimum les services d’accès au réseau et de gestion de
QoS présentés dans cette section. La carte SIM-IP fait partie du réseau visité, elle est
considérée comme un nœud du réseau. Elle intègre les services réseau locaux et les
mécanismes de contrôle; de ce fait elle représente un élément central de l’architecture globale.
La carte SIM-IP se connecte au réseau (home ou visité). Etant donné la diversité des réseaux
d’accès, la carte SIM-IP doit supporter les méthodes d’accès nécessaires pour chaque
technologie. La carte doit être capable de répondre aux challenges envoyés par les edge
devices des réseaux visités tels que les points d’accès ou les stations de base qui sont les
équipements qui contiennent les algorithmes et les éléments nécessaires.
Le premier lien i.e. le lien sans fil entre le TER et l’AP est protégé par un mécanisme de
cryptage ISO/OSI de niveau 2 basé sur les informations stockées dans la carte. La carte SIM-
IP peut vérifier l’identité de l’utilisateur.
8Misc. servers LDAP
POLICY XML
REP
LDAP admin
Control AAA DB
Session PDP
DB
Key AAA
RADIUS + EAP
COPS
WEP
Service Provider Network
EAP
TER
eap/tls Legend
Data traffic PEP
CONF
Control traffic AP
ID, auth
SIM IP OS
Figure4. Architecture SPN
Néanmoins, le contexte WLAN est plus compliqué. Les méthodes d’accès ne sont pas aussi
bien définies comparées aux réseaux téléphoniques. Pour cela, nous proposons de faire appel
aux méthodes proposées actuellement car elles sont plus efficaces. Les procédures de
protection décrites dans cette étude sont basées sur la protection de l’accès aux ressources
réseau contre une utilisation non autorisée. Néanmoins, ces méthodes ne résolvent pas le
problème de l’identification de l’utilisateur pour l’accès aux services. En effet, les
applications IP existantes ne possèdent pas l’information de niveau 2 nécessaire pour pouvoir
vérifier l’identité de l’utilisateur. Nous supposons que les réseaux cœur des réseaux visités
sont sécurisés au moyen de protocoles usuels.
Plusieurs bases de données sont nécessaires stocker l’information de management. Nous
distinguons principalement :
- Une base de données de politiques ‘policy repository’ contenant toutes les politiques
nécessaires,
- Une base de données AAA database (AAA DB) faisant partie de l’infrastructure
d’authentification RADIUS,
- Une base de donnée appelée Session Data Base (SessionDB) pour collecter toutes les
informations sur les utilisateurs connectés au réseau fournisseur.
Comme il est clairement illustré sur la Figure 4, la carte SIM-IP et les protocoles COPS et
RADIUS constituent les éléments clés de notre solution globale.
94.3 La carte SIM-IP
4.3.1 Description
La carte SIM-IP est une carte SIM java intelligente qui contient une pile IP et supporte des
services intégrés comme le montre la Figure 5. Similairement aux cartes SIM GSM/3G , la
carte SIM-IP fournit un mécanisme pour l’authentification et la facturation. Elle inclut les
fonctionnalités IP et peut ainsi compléter les terminaux qui ne supportent pas nativement la
pile protocolaire IP. La carte contient un ensemble de données (clés, …), les procédures
d’authentification, les algorithmes et stocke les données dans des fichiers XML. Elle peut
exécuter des applets Java dans un environnement sécurisé. En particulier, elle intègre un
serveur WEB et supporte divers protocoles tels que HTTP, LDAP, COPS, EAP, etc.
Globalement, elle peut être vue comme un noeud du réseau avec des services intégrés qui
offre trois principaux avantages:
• un service d’authentification commun, fiable et extensible,
• une pile TCP/IP indépendente du terminal associé et opérant comme une machine hôte
Internet,
• l’opportunité d’inclure des points terminaux de service sur la carte permettra de préconiser
de futures solutions intéressantes.
Data Procedures
X.509 CA Cert RSA, MD5
X.509 own Cert
TLS Master Key
Protocols
NSSSK EAP
Applications WEP ucast key DHCP
COPS
WEP bcast key
IP config SIM CONF
Transport SERVICE cfg TLS
Communication module
IP
Traffic shaper
LLC
Security Interface
TCP/IP
Host
Figure 5. Carte SIM-IP
La proposition innovante d’utiliser la carte SIM-IP est très intéressante car elle permet d’offrir
un accès réseau sécurisé, la QoS et le support de services réseau sur la carte. Etant donné que
nous suggérons dans notre solution d’installer les composants réseau sur la carte, chaque carte
SIM-IP sera la propriété du fournisseur. Elle est pré-configurée par le fournisseur qui la
délivre et elle est vue comme un nœud confiant fiable de son réseau opéré une fois la
connexion est bien réussie. Elle permet donc d’intervenir et de superviser l’accès au réseau.
10Aussi, elle applique une classification du trafic de l’utilisateur et exécute les opérations de
contrôle. L’accès au réseau se déroule en deux phases :
- Première phase
Dans la première phase, la carte se connecte au réseau du fournisseur en utilisant les
informations nécessaires au contrôle d’accès qui y sont installées et les algorithmes
nécessaires.
- Deuxième phase
La carte vérifie l’identité et les droits de l’utilisateur (OS). Dans ce cas, la vérification de
l’utilisateur (OS) est très simple car elle est établie localement par des algorithmes
propriétaires (PIN, password, token, etc.). Il a fallu rajouter la mise en place d’une méthode
sécurisée pour l’accès au réseau de la carte SIM-IP spécialement dans le contexte des WLANs
existants.
4.3.2 Le concept SoC (Service on Card)
L’architecture fonctionnelle de la carte ainsi que ses capacités IP permettent la prolongation
du service du réseau jusqu’à la carte. Ceci procure de nouvelles et importantes opportunités.
Un fournisseur qui commercialise une carte peut installer un certain nombre de ses
composants de contrôle internes tels qu’un classificateur de paquets, des filtres, etc, sur la
carte elle-même permettant le contrôle du comportement de l’utilisateur.
D’un autre côté, un fournisseur peut intégrer des points d’accès aux services sur la carte SIM-
IP offrant ainsi à l’utilisateur une palette de services disponibles directement sur la carte,
indépendamment de la localisation actuelle du point terminal du service associé. Cette palette
de services est appelée Services on Card (SoC). A la suite de la phase de connexion, les points
d’accès aux services localisés sur la carte choisissent dynamiquement le fournisseur du
service (réseau home ou réseau visité) dépendant de la disponibilité du service dans le réseau
visité courant ou de quelques critères (propriétés du service, ….).
Globalement, le service d’accès au réseau représente déjà un service réseau interne prolongé
jusqu’à la carte SIM-IP. La carte fonctionne comme un edge device qui appartient à
l’infrastructure réseau. Les points de contrôle pour la QoS, la mobilité, chiffrement et la
signature des paquets appartiennent à la même catégorie. Une autre catégorie contient les
services usuels tels que HTTP, SMTP ou SIP. De tels services peuvent être implémentés
comme des proxies configurés par défaut pour contacter le home network. Le fournisseur de
services qui délivre la carte peut assurer la disponibilité du service dans son réseau et
concevant sa carte selon son offre. Dans le cas de la présence de service dans le réseau visité,
le proxy SoC peut être reconfiguré dynamiquement par la logique de la carte et utilise le
service localement dans le réseau du fournisseur.
L’avantage de cette approche est la capacité de fournir l’accès aux services du home network,
une grande disponibilité des services et une transparence complète du service pour
l’utilisateur.
Mais est ce que cette approche est-elle réalisable et raisonnable?
Soient P1,…,Pn un ensemble de fournisseurs avec leurs ensembles de services associés
SS1,…,SSn , i.e. pour chaque Pi on définit un SSi := {Service1, …, ServiceN}. Dans le cas où
tous les ensmbles de services sont équivalents (SS1 = … = SSn) l’utilisateur peut toujours être
sûr de trouver un service dans le réseau visité. Dans le cas où les services sets sont
complètement disjoints, les services du réseau visité sont inconnus à la carte et les services
home ne sont pas disponibles dans le réseau visité. Cela implique une connexion permanente
au réseau home. Sous certaines conditions not even l’accès au réseau visité n’est pas possible,
dans ce cas, on parle de minimal service subsets (MSS) défini comme l’intersection des
services sets de tous les fournisseurs impliqués. Pour un fonctionnement minimal correct, il
11serait raisonnable que le MSS comporte au minimum tous les services indispensables pour les
fonctionnalités de management (accès, QoS, etc.).
Par ailleurs, pour le support de la QoS, un module spécifique est intégré dans la carte SIM-IP
qui est le ‘traffic classifier’. Son rôle majeur est de classifier les paquets IP selon le niveau de
priorité de la classe de trafic. Des classes de trafic différentes sont définies; chacune d’elles
possède des propriétés communes concernant divers critères (délai, bande passante, ..). A
chaque classe est attribué un niveau de priorité.
OS
Proxy http core EAP/TLS
COPS
SOC CONF PEP
applet applet applet CONF
…..
os
Carte Many cases
Si, i=1…N - Si on card
- Si available in HN (home network) or in VN (visisted network)
HN VN
Figure 6. Carte SIM-IP et SoC
4.3.3 Implications
La carte SIM-IP exige certains changements dans la configuration du système. Tout d’abord,
les applications sur la machine hôte (OS) doivent être configurées de manière appropriée pour
pouvoir utiliser les SoCs. Si un utilisateur utilise un serveur SMTP dans son réseau de
fournisseur il peut configurer un serveur sur la carte. Ce serveur fonctionnera comme un
SMTP-smarthost relayant le message au serveur SMTP utilisé. Nous devons prévoir un
mécanisme de découverte ou de configuration dynamique dans la carte elle même, car après
ou durant la phase d’authentification la carte doit avoir les informations nécessaires sur les
services actuellement disponibles dans le réseau visité. Au minimum, pour chaque SoC il
serait raisonnable de reconfigurer les proxies sur la carte.
Finalement, les implications sur la sécurité doivent être étudiées sérieusement pendant
l’installation des éléments réseau sur la carte. Classiquement, les protocoles réseau ne sont pas
suffisamment sécurisés et dans le but de prévenir contre les attaques de tels protocoles feront
appel à d’autres méthodes de protection telles que (IPSec, secure tunneling, etc.) ou une
conception réseau appropriée (séparation physique entre le trafic de l’utilisateur et celui du
fournisseur). Evidemment, nous devons sécuriser le trafic qui est véhiculé sur les liens
wireless contre les attaques possibles.
124.4 Common Open Policy Service protocol (COPS)
COPS [9] est un protocole proposé pour permettre l’échange de l’information de contrôle
entre des entités réseau spécifiques. Ces informations sont liées à des politiques. Le standard
décrit une architecture centralisée qui comprend un central policy decision point (PDP) et un
ensemble de policy enforcement points (PEP) généralement installés dans les edge devices du
réseau. Ce type d’architecture permet l’installation et le contrôle d’une politique de QoS
centralisée sur le PDP, l’adaptation dynamique en fonction la charge du réseau et le contrôle
du trafic au niveau du network edge. Dans la solution que nous proposons, COPS joue un des
rôles prépondérants.
Néanmoins, dans le contexte des liens de communication sans fil avec des ressources
partagées limitées, ceci a une incidence néfaste : le lien entre l’équipement terminal et le edge
device constitue le maillon faible de la sécurité de l’architecture globale.
Nous proposons d’installer le PEP sur la carte SIM-IP (see Figure 4). Les avantages
principaux de cette intégration sont :
- appliquer des politiques de QoS dépendant de la charge du lien
- contrôler le trafic de l’utilisateur à sa source en empêchant l’OS (user) d’envoyer des
paquets incorrects.
- optimiser la charge les liens sans fil.
Il y a des aspects sécurité qui sont étroitement liés à cette proposition du moment que le
protocole COPS est non protégé et nous voulons installer ces entités en différents poins
terminaux des liens sans fil. Cependant, comme l’information COPS est échangée après
terminaison avec succès de la phase de connexion de la carte SIM-IP au réseau visité, les
paquets vont traverser la distance séparant la carte du core network sécurisé par des liens
crypté (per-user L2-encrypted link). Ce qu’il faudra assurer est un mécanisme de cryptage
fiable, un autre utilisateur ne peut pas lire les données transmises par l’AP ou par la carte
même si l’utilisateur est connecté au même AP. Ceci est particulièrement possible en utilisant
des clés WEP dynamiques (en attendant la disponibilité de WEPv2).
Une description détaillée de l’architecture de contrôle de la QoS est donnée en Section 6.
5 Architecture d’accès au réseau
Typiquement, les apects sécurité consituent l’élémént clé dans chaque réseau de fournissuer.
Dans cette Section, nous donnons les éléments de réponse que nous proposons pour sécuriser
l’architecture 4G en prenant en compte le roaming global de l’utilisateur.
5.1 Sécurisation de la connexion Carte – réseau par 802.1x
Comme il été mentionné, il est impératif de résoudre le problème de la sécurisation de la
connexion entre la carte SIM-IP et le réseau visité dans le contexte des WLANs.
Nous proposons d’utiliser une architecture basée sur IEEE 802.1x [10] avec EAP/TLS [11]
pour le contrôle d’accès aux WLANs. Cette solution permettra de pallier à un nombre
considérable de failles de sécurité [12] décelées dans le modèle d’authentification par clé
partagée basée sur WEP (SKA shared key authentication) dans les systèmes 802.11 WLANs
[13]. L’architecture en question consiste en un élément central qui est qui est le EAP/TLS-
capable RADIUS-server et plusieurs RADIUS [14] et 802.1x capable APs. De plus, dans
notre proposition, chaque machine hôte est équipée de la carte SIM-IP qui stocke la clé privée
de l’utilisateur (sous forme de certificat), les certificats des autorités de certification (CA) et
les algorithmes nécessaires pour la méthode EAP/TLS (voir Figure 7). La carte SIM-IP et le
serveur RADIUS établissent une authentification mutuelle en utilisant TLS [15] véhiculés
13dans des trames EAPOL [10] et négocient un secret TLS master secret [15]. Les deux côtés
dériveront les clés de communication appelées Negotiated Shared Session Secret Keys
(NSSSK) indépendamment. Le serveur RADIUS envoie cette clé à l’AP avec la confirmation
de l’authentification comme il a été décrit dans [16]. L’AP ouvre le port de communication
associé, crée les clés WEP dynamiques et les envoie à la carte SIM-IP signés et cryptés par la
clé de communication (NSSSK) dans la trame EAPOL-Key [10]. La méthode EAP/TLS est
alors enclenchée i.e. la carte SIM-IP installe les clés WEP reçues dans l’adaptateur réseau et
active la procédure de chiffrement WEP sur le lien.
La transmission des données sur le lien sans fil n’est possible qu’après la confirmation de
l’identité de la carte. Cette transmission est cryptée en utilisant les clés WEP dynamiques.
L’AP peut et devrait changer les clés utilisées fréquemment. En attendant l’achèvement des
travaux sur WEPv2, cette méthode est considérée comme la meilleure procédure à adapter
pour protéger nativement la connexion de la carte SIM-IP au réseau du fournisseur dans le
contexte du WLAN.
Phases
1. Phase: Card conn
2. Phase: Card conf Misc. servers LDAP
3. Phase: User auth POLICY XML
4. Phase: QoS REP
5. Phase: Data LDAP admin
Control AAA DB
Session PDP
COPS DB
Key AAA
TER WEP RADIUS + EAP
eap/tls
EAP
CONF
DHCP, SIRUP
SIM IP
Service Provider Network
Legend
OS Data traffic PEP
Control traffic AP
ID, auth
Figure 7 : Architecture d’accès sécurisée
5.2 Roaming
La carte SIM-IP est responsable de la vérification de l’identité et du profil de l’utilisateur, du
contrôle de trafic et de l’accès aux services. Du moment que l’utilisateur se connecte toujours
via sa carte SIM-IP, il n’y a pas de nécessité pour le ‘user roaming’ dans notre architecture.
Après la reconnexion de la carte, l’utilisateur peut simplement utiliser les services de la même
manière indépendamment du réseau visité.
Plus spécialement, nous avons à mettre en place des mécanismes pour le roaming de la carte
SIM-IP. Plus précisément, nous distinguons trois aspects liés à ce problème.
• Roaming et accès au réseau,
• Roaming et Configuration de la carte SIM-IP,
• Roaming et accès aux services.
Une description de chacune de ces situations est décrite dans les sections suivantes.
145.2.1 Roaming et accès au réseau
Le standard IEEE 802.1x proposé dans le contexte actuel pour renforcer la sécurité de l’accès
aux réseaux sans fil recommande l’utilisation d’un serveur RADIUS en tant que serveur
d’authentification. Pour supporter le roaming en utilisant RADIUS, de mineurs changements
doivent être réalisés.
La méthode utilisée 802.1x EAP/TLS exige l’utilisation d’autorités de certification et le
déploiement de certificats. Cependant, une infrastructure commune Public Key Infrastructure
(PKI) n’est pas nécessaire i.e. chaque fournisseur peut simplement installer et maintenir sa
propre et indépendante CA. Le déploiement de certificats est donc particulièrement facile, du
moment que les certificats doivent être installés sur la carte et cette dernière est délivrée par le
fournisseur. En utilisant la fonctionnalité proxying [14] de RADIUS, nous pouvons assurer le
roaming de la carte au moyen de 802.1x mis en place localement. La conversation EAP/TLS a
lieu entre la carte SIM-IP et le home RADIUS-server en traversant l’AP et le foreign
RADIUS-server . Le home RADIUS-server délivre la clé de session (NSSSK) au foreign
RADIUS server qui la transmet à l’AP concerné. Une interconnexion des serveurs RADIUS
des différents fournisseurs devra être établie permettant le proxying. Pour des raisons de
sécurité, nous proposons d’interconnecter les serveurs RADIUS en utilisant le protocole
IPSec.
Une description détaillée des échanges protocolaires, des considérations de sécurité et des
solutions plus optimisées sont données dans l’article [17].
SessionDB information
server
user
services
SPN1 SPN2
Secure communication by IPsec
Identification IP
5.2.2 Roaming et configuration de la carte SIM-IP
La procédure globale de connexion se déroule en quatre phases principales:
1. La carte se connecte au réseau visité, négocie les clés WEP et établit un lien crypté en
appliquant un chiffrement de niveau 2 (voir description section précédente).
2. La carte lance une requête DHCP et obtient une adresse IP et l’adresse IP du serveur
SessionDB. La carte se connecte au serveur SessionDB en utilisant la procédure propriétaire
SIM-IP Roaming Update Protocol (SIRUP). La SessionDB se connecte au réseau home de la
carte, si nécessaire, en utilisant RADIUS et échange des informations de facturation
concernant l’utilisateur. Au cours de la procédure SIRUP, la carte obtient les informations sur
la configuration, les services disponibles et les descripteurs des classes QoS, etc.
3. La carte présente un système à login à l’utilisateur lui proposant des informations sur le
réseau visité, i.e. un ensemble particulier de services disponibles et les prix. L’utilisateur se
connecte en utilisant la combinaison login/password.
4. En se basant sur le choix de l’utilisateur ou sur les applications lancées; la carte négocie et
réserve la QoS.
Le protocole SIM-IP Roaming Update Protocol (SIRUP) constitue la partie la plus
importante du processus. Ce protocole doit être développé mais comme la carte est déjà
équipée de la pile du protocole TLS (méthodes existantes (RSA, MD5, etc.) et http), nous
projetons de le baser sur HTTPS (support d’applets, intégration de Java dans http). En effet,
15puisque le serveur RADIUS et la méthode EAP/TLS ont déjà négocié une clé TLS master
secret, nous pouvons directement passer à la phase suivante du protocole qui encapsule tout le
trafic HTTP. Pour cette raison, le serveur RADIUS écrit l’information relative à la clé dans la
base de données SessionDB juste après une connexion de l’utilisateur avec succès.
Au cours de la conversation SIRUP TLS, la SessionDB installe le mapping bidirectionnel IP-
to-user qui extrait les paquets arrivés. Il donne accès à cette information à tous les services
réseau enregistrés. En plus de l’information sur les calsses QoS disponibles et les services, la
carte peut télécharger et installer de nouvelles applets. Elles peuvent être des proxies ou, dans
le home network, des updates des ‘core services’. La carte utilise l’information réseau obtenue
dans le but de configurer correctement ses points d’accès aux services.
5.2.3 Roaming et accès aux services
Le mécanisme de cryptage de niveau a lieu entre la carte SIM-IP et l’AP. Ainsi, après que les
paquets arrivent dans la partie IP du réseau du fournisseur, l’information sur l’identité de
l’utilisateur est perdue. Donc, comment peut-on identifier l’utilisateur afin de lui offrir un
accès à des services personnalisés ? La seule information qui reste incluse dans le paquet IP
est la source IP address elle-même. A cause de la simplicité de l’attaque de IP-spoofing, ce
mécanisme ne peut pas être utilisé pour l’identification de l’utilisateur. Moyennant certains
changements, cette simple et puissante méthode d’identification peut-être réutilisée de
manière sécurisée.
L’information relative à la IP-configuration délivrée à la carte par DHCP est transportée sur le
lien crypté (avec cryptage de niveau 2) et ne peut être sniffé par les attaquants. La machine
hôte OS réagit avec une requête DHCP sur l’événement de l’établissement de lien. Ce
message sera intercepté et la carte SIM-IP va y répondre, ainsi l’OS (user) recevra
l’information IP nécessaire. A partir de ce moment, tout paquet délivré par l’OS sera vérifié
par la carte SIM-IP sur l’exactitude de l’adresse IP source. En supposant que des mécanismes
de sécurité sont établis par le fournisseur lui-même au sein de son réseau, le mécanisme de
chiffrement de niveau 2 jusqu’au edge device et l’impossibilité de faire du IP-spoofing par les
utilisateurs connectés (grâce au contrôle initié par la carte), aucun paquets avec une fausse
adresse IP ne peut entrer dans le réseau.
Les serveurs doivent être localisés dans la partie IP du réseau du fournisseur, qui est
physiquement ou logiquement (subnetting, firewall or packet filter) protégée contre les accès.
Le mapping (identité –utilisateur-adresse IP) est effectuée au sein de la SessionDB. Ce
mapping peut être facilement obtenu par tous les serveurs. La SessionDB installe les règles
appropriées de routage pour les adresse IP source des cartes autorisant ou refusant le trafic
Internet. Chaque service demandé par une source IP peut identifier l’utilisateur en
interrogeant la SessionDB.
Pour le roaming, les fournisseurs concernés établissent un tunnel IPSec. Le trafic généré par
la carte ayant une adresse IP source destiné à son réseau home doit être routé via ce tunnel
IPSec. Donc, le mapping IP-to-user obtenu à partir de la SessionDB du réseau visité peut
aussi être utilisé par le réseau home afin d’autoriser/bloquer/facturer l’accès au service.
6 Architecture globale de contrôle de la qualité de service par politique
6.1 Introduction
Les contrôles à effectuer dans un réseau IP ont été mis dans la machine terminale au début
de l’Internet et continue de l’être en grande partie. Par exemple, la fenêtre de contrôle de flux
avec son algorithme du « Slow Start and Congestion Avoidance » est gérée dans le protocole
TCP de la machine terminale. Pour améliorer ce contrôle, les routeurs du réseau sont devenus
16plus complexes et intègrent des éléments de configuration du routeur, par exemple la prise en
charge d’une politique de gestion de la qualité de service comme DiffServ. L’inconvénient de
cette solution provient d’une chaîne protocolaire qui se divise en deux parties : une partie
allant de la machine terminale au routeur de bord et une partie allant du routeur de bord au
serveur ou à l’utilisateur distant. Une des difficultés provient de la sécurisation de la liaison
entre l’équipement terminal et le routeur de bord. En effet, les décisions de sécurité décidées
par le réseau ne peuvent que démarrer du routeur de bord. De plus, le routeur de bord se
retrouve à devoir gérer une quantité importante de flux et à mémoriser toutes leurs
caractéristiques. De plus, lorsqu’un client est mobile, son routeur de raccordement change et
donc nécessite une nouvelle négociation avec l’utilisateur pour s’adapter à sa demande.
Nous pensons que le contrôle des futurs grands réseaux qui allieront à la fois des terminaux
fixes et des terminaux mobiles demande une forte intelligence dans le terminal de l’utilisateur,
d’autant plus que ce terminal est de plus en plus puissant et permet donc la décentralisation de
la puissance nécessaire au contrôle des flux dans le terminal. La décentralisation vers
l’équipement terminal permet également de mieux prendre en compte les demandes de
l’utilisateur. Bien évidemment cette décentralisation demande une sécurité plus importante de
la partie du terminal qui contrôle les accès au réseau. En effet, ne faut pas que le client puisse
modifier la valeur des paramètres déterminés par le serveur de politique. Il faudra donc
sécuriser une partie du terminal, cette partie pouvant être vue comme une extension de
l’opérateur dans le terminal, comme la carte à puce qui se trouve dans un combiné GSM
(Global System for Mobile communication). Nous y reviendrons plus longuement dans la
suite de ce rapport.
Nous nous intéressons ici à définir une nouvelle architecture qui utilise un environnement
contrôlé par politique et qui repousse les fonctions de contrôle dans le terminal de
l’utilisateur, qu’il soit fixe ou mobile
6.2 L’architecture de contrôle par politique
Les politiques peuvent être définies comme un ensemble de règles capables de gérer et de
contrôler l’accès aux ressources d’un réseau. L’apparition de ce concept de gestion par
politique provient du besoin de simplifier la configuration des routeurs par un mécanisme
automatique. De nombreux domaines s’intéressent à cette gestion par politique dont le plus
avancé concerne la qualité de service (QoS) mais également la sécurité et la gestion de la
mobilité. Un nouveau protocole de signalisation a été introduit, COPS [9], définissant un
nouvel ensemble architectural. Pour généraliser cette approche, un groupe de travail a été
formé à l’IETF (Internet Engineering Task Force) pour spécifier le modèle d’information et
parfaire l’architecture générale. Le but du modèle d’information est de définir un modèle
général qui puisse s’adapter aux différents domaines de la gestion et du contrôle dans les
réseaux, et ceci de façon totalement indépendante du type d’équipements physiques.
Le cœur du modèle d’information de l’environnement politique, Policy Core Information
Model (PCIM), est une extension du modèle CIM (Common Information Model) du DMTF
(Distributed Management Task Force). Le réseau est vu comme une machine à états où les
politiques sont là pour contrôler les changements d’état. Il faut dans cet environnement être
capable d’identifier et de modéliser les états en cours et de définir les transitions possibles à
partir des règles définissant les politiques [2]. Ce modèle définit les rôles, les priorités et les
ordres d’exécution, mais il reste dans une forme abstraite en ce qui concerne les objets.
Les travaux en cours concernant la QoS définissent deux niveaux d’extension : le modèle
QPIM (QoS Policy Information Model) et le modèle QDDIM (QoS Device Datapath
17Vous pouvez aussi lire
