Spécification de l'architecture globale

 
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.1x
1. 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.

                                               2
Indé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

                                                3
principaux 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..

                                                4
3. 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

                                               5
l’é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.

                                                 6
PDP                                                   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.

                                               8
Misc. 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.

                                                9
4.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.

                                                            10
Aussi, 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

                                              11
serait 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.

                                                     12
4.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

                                                13
dans 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.

                                                     14
5.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,

                                                  15
puisque 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

                                               16
plus 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

                                                17
Vous pouvez aussi lire
DIAPOSITIVES SUIVANTES ... Annuler