ecole nationale supérieure d’informatique oued –...

Ministère de l’Enseignement Supérieure et de la Recherche Scientifique

Ecole Nationale Supérieure d’Informatique

Oued – Smar Alger

Ecole Doctorale STIC

Sciences et Technologies de l’Information et de la Communication

Mémoire En vue d’obtention du diplôme de

MAGISTER EN INFORMATIQUE

Option : Informatique Répartie et Mobile (IRM)

Présenté et soutenu le 30/06/2014 par :

Mr. ZERROUKI Noureddine

Directeur de mémoire : Mr. LOUDINI Malik Co-directrice : Mme YAHIAOUI Chafia

Membres de jury : Mr. CHALLAL Yacine MCA ESI Président Mr. HADDADOU Hamid MCA ESI Examinateur Mr. MENACER Djamel Eddine MCB ESI Examinateur Mr. LOUDINI Malik Prof ESI Directeur de mémoire

Année Universitaire 2013/2014

Gestion du passage des routeurs NAT et pare-feu

Par le protocole de téléphonie SIP

à la mémoire de mon père

REMERCIEMENTS

--------------------------

Je remercie, avant tout, mon dieu Allah le tout puissant, qui m’a donné la force et la patience pour l’accomplissement de ce travail.

Je tiens à remercier chaleureusement ma promotrice, Madame Chafia YAHIAOUI, pour m’avoir proposé ce projet, en me faisant confiance, ainsi pour ses orientations, ses précieux conseils, ses remarques, et son entière disponibilité consacrée tout au long de ce travail.

Je remercie vivement le directeur de mémoire Monsieur LOUDINI Malik, pour son aide, sa gentillesse, et les références précieuses qu’il m'a fournies.

Mes remerciements s’adressent également au président et aux membres du jury de m’avoir honoré en acceptant de juger ce modeste travail.

Je voudrais exprimer toute ma gratitude envers mes proches en particulier ma très chère mère qui priait tout le temps pour moi, et a fait beaucoup plus encore...

Finalement, tous ceux qui ont contribué de prés ou de loin, par leurs encouragements et conseils à l’accomplissement de ce travail, trouvent ici l’expression de ma profonde reconnaissance.

Que Allah nous garde, nous pardonne et nous guide vers le droit chemin

Résumé

---------------------------------

Les récents progrès dans le domaine des télécommunications ont permis la convergence des différents réseaux hétérogènes, de nature mobile, fixe et d’internet, ainsi que par la diversité des nouvelles applications multimédia nécessitant une bonne qualité de service telles que la téléphonie sur IP, la téléconférence, la vidéoconférence, la vidéo sur demande, ...etc. Le protocole SIP (session Initiation Protocol) s’avère être l'un des protocoles les plus prometteurs pour offrir les nouveaux services multimédia grâce à son extensibilité. En effet, SIP peut être combiné à d'autres protocoles de communication, afin de permettre un échange en temps réel de plusieurs médias entre usagers distants.

Cependant, les dispositifs de sécurité tels que les pare-feu et les routeurs NAT qui ont été mis en place dans les réseaux conventionnels empêchent leur traversée par le protocole SIP. Cette problématique de la traversée des routeurs NAT et des pare-feu par le protocole SIP a suscité plusieurs travaux de recherches qui ont abouti à une multitude de solutions. Notre intérêt s’est particulièrement porté sur le protocole NATFW NSLP de la plateforme NSIS (Next Steps In Signaling). Cependant l'approche adoptée par ce protocole fragilise le dispositif au point de vue sécurité. Afin d’éviter tout usager non authentifié et tout accès non autorisé, des mécanismes d'authentification et d'autorisation doivent être intégrés à ce protocole.

Dans ce travail, nous avons proposé deux mécanismes d'authentification, le premier, HMAC que nous avons intégré au protocole NATFW NSLP et grâce à une plateforme de test, nous avons ensuite évaluer ses métriques de performance en termes de temps de traitement, temps d'établissement de session, consommation du processeur et de la mémoire. Le second mécanisme appelé (E-MAC) s’articule sur une fonction de hachage universelle UMAC, pour garantir l’authentification et l'autorisation et qui, associé à un algorithme de chiffrement assure également la confidentialité des messages des usagers légitimes. Nous avons développé et proposé une méthodologie qui permet l’intégration de ce nouveau mécanisme au protocole NATFW NSLP.

Mots clés : SIP, NAT, Pare-feu, NSIS, NATFW NSLP, HMAC, UMAC

Abstract

---------------------------------

Recent advances in telecommunications have allowed the convergence of different heterogeneous networks, of mobile, fixed and internet nature, as well as a variety of new multimedia applications that require good quality of service such as voice over IP, teleconferencing, video conferencing, video on demand, ... etc. . SIP ( Session Initiation Protocol ) appears to be one of the most promising protocols to offer new multimedia services through its extensibility. In fact , SIP can be combined with other communication protocols to allow a real-time media exchange between multiple remote users.

However, security devices such as firewalls and NAT routers that have been implemented in conventional networks prevent them from passing through the SIP protocol. This problem of NAT and firewalls traversal for SIP has attracted several research work that led to a multitude of solutions. Our interest is particularly focused on NATFW NSLP protocol of NSIS platform (Next Steps In Signaling). However, the approach adopted by this protocol weakens the device from security point of view. To prevent unauthenticated users and unauthorized access, authentication and authorization mechanisms should be included in this protocol.

In this work, we have proposed two authentication mechanisms, the first HMAC which we integrated with NATFW NSLP protocol in a test platform, we then evaluate its performance metrics in terms of processing time, session setup time, and CPU and memory usage. The second mechanism known as (E-MAC) is based on a universal hash function UMAC to ensure authentication and authorization and that, combined with an encryption algorithm that also ensures the confidentiality of legitimate users messages. We have developed and proposed a methodology that allows the integration of this new mechanism to NATFW NSLP protocol.

Keywords : SIP , NAT, Firewall , NSIS , NATFW NSLP , HMAC , UMAC

Sommaire

Introduction générale........................................................................................................... 1

Chapitre 1 : Etude de la technique de translation d’adresse : le NAT............................... 4

1. Introduction ................................................................................................................. 5

2. Définition et principe du NAT ..................................................................................... 5

3. Les types du NAT ....................................................................................................... 6

3.1. Le NAT statique ................................................................................................... 6

3.2. Le NAT dynamique .............................................................................................. 7

4. Les types de NAT dynamique selon le port .................................................................. 8

4.1. Le Port Forwarding .............................................................................................. 9

4.2. Le Port Mapping .................................................................................................. 9

5. Les types du NAT dynamique selon la restriction : .................................................... 10

5.1. NAT cône plein (Full Cone) ............................................................................... 10

5.2. NAT à cône restreint (Restricted Cone) .............................................................. 11

5.3. NAT cône à restriction de port (Port Restricted Cone) ........................................ 11

5.4. NAT Symétrique ................................................................................................ 12

6. Les Pare-feu .............................................................................................................. 13

6.1. Définition ........................................................................................................... 13

6.2. Fonctionnement général ..................................................................................... 14

6.3. Types de filtrages ............................................................................................... 15

7. Conclusion ................................................................................................................ 16

Chapitre 2 : Le protocole SIP (Session Initiation Protocol) ............................................. 17

1. Introduction ............................................................................................................... 18

2. Bref historique de SIP ............................................................................................... 18

3. Introduction au fonctionnement de SIP ...................................................................... 19

4. Architecture et composants de SIP............................................................................. 20

5. Transaction SIP ......................................................................................................... 23

5.1. Les requêtes SIP .................................................................................................... 23

5.2. Les réponses SIP .................................................................................................. 24

5.3. Format de messages SIP ....................................................................................... 24

5.4. L'adressage ............................................................................................................ 26

6. Fonctionnement de SIP .............................................................................................. 27

6.1. Enregistrement ................................................................................................... 27

6.2. Etablissement et terminaison d'une session SIP................................................... 28

7. Sécurité de SIP .......................................................................................................... 31

7.1. Exemples d’attaques contre SIP .......................................................................... 31

7.2. Mécanismes de sécurisation................................................................................ 32

8. Problématique de la traversée du NAT et les Firewalls .............................................. 33

8.1. La traversée du NAT .......................................................................................... 33

8.2. Problème des Firewalls ....................................................................................... 35

9. Conclusion ................................................................................................................ 36

Chapitre 3 : Les solutions de la traversée du NAT ........................................................... 38

1. Introduction ............................................................................................................... 39

2. Les solutions basées sur le comportement du NAT .................................................... 39

2.1. Serveur d’application ............................................................................................ 39

2.2. Simple Traversal of UDP Through NAT devices (STUN) ..................................... 41

2.3. Traversal Using Relay NAT (TURN).................................................................... 43

2.4. Proxy RTP ............................................................................................................ 45

2.5. Session Border contrôler (SBC) ............................................................................ 47

3. Les solutions basées sur le contrôle du NAT .............................................................. 48

3.1. Tunnel de données ................................................................................................ 48

3.2. Universal Plug and Play (UPnP) ........................................................................... 49

3.3. Passerelle de couche applicative (ALG Application Layer Gateway) .................... 50

3.4. Realm Specific IP (RSIP) ..................................................................................... 51

3.5. Middlebox Communication (MidCom) ................................................................. 53

4. Les solutions combinant plusieurs techniques ............................................................ 54

4.1. Interactive Connectivity Establishement (ICE) ..................................................... 54

4.2. Serveur d’application avec agent .......................................................................... 55

5. Synthèse .................................................................................................................... 56

6. Conclusion ................................................................................................................ 57

Chapitre 4 : Présentation de la plateforme NSIS et du protocole NATFW NSLP .......... 58

1. Introduction ............................................................................................................... 59

2. Le groupe de travail NSIS et la plateforme NSIS ....................................................... 59

2.1. Le modèle en couches de NSIS ............................................................................. 60

2.2. Le concept fondamental de la signalisation de NSIS ............................................. 61

2.3. Les règles pour les NATs et les pare-feu ............................................................... 65

2.4. Introduction au protocole NATFW NSLP ............................................................. 65

3. Description du protocole NATFW NSLP.................................................................. 68

3.1. Présentation générale ............................................................................................ 68

3.2. Fonctionnement du protocole ................................................................................ 69

3.3. Comportement de NATFW NSLP avec SIP .......................................................... 76

3.4. Rapports des évènements asynchrones .................................................................. 78

3.5. Calcul de la durée de vie de session ...................................................................... 78

3.6. L'ordonnancement des messages ........................................................................... 80

4. Implémentation du protocole NATFW NSLP ............................................................ 81

4.1. Vue générale sur l'implémentation ........................................................................ 81

4.2. Pare-feu : Netfilter/Iptables ................................................................................... 82

4.3. L'automate d'état fini (FSM Finite State Machine) ................................................ 83

4.4. Gestion d'état ........................................................................................................ 86

5. Menaces et mécanismes de sécurité ........................................................................... 86

5.1. Les menaces ......................................................................................................... 87

5.2. Mécanismes de sécurité du protocole NATFW NSLP ........................................... 88

5.3. L'authentification et l'autorisation ......................................................................... 89

6. Travaux précédents en relation .................................................................................. 89

6.1. Travaux de la RFC 5981 ....................................................................................... 90

7. Description de l'objet d'autorisation de session .......................................................... 91

7.1. Format de l'objet d'autorisation de session ............................................................ 91

7.2. Format des attributs de l'objet d'autorisation de session ........................................ 92

7.3. Les types d'attributs .............................................................................................. 92

8. Composants de l’architecture utilisée dans la RFC 5981 ............................................ 97

9. Conclusion ................................................................................................................ 99

Chapitre 5 : Intégration des mécanismes d'authentification dans NATFW NSLP ....... 100

1. Introduction ............................................................................................................. 101

2. Premier mécanisme d'authentification adopté .......................................................... 102

2.1. Fonctionnement du mécanisme HMAC .............................................................. 102

2.2. L'objet SESSION_AUTH_OBJECT en utilisant le mécanisme HMAC ............... 104

3. Description des procédures d'authentification et d'autorisation ................................. 106

3.1. L'architecture proposée ....................................................................................... 106

3.2. Déroulement de la procédure d'authentification et d'autorisation ......................... 109

4. Analyse de mécanisme et de l'architecture adoptés .................................................. 111

5. Description de deuxième mécanisme adopté E-MAC .............................................. 112

5.1. E-MAC dans la composition AtE ......................................................................... 114

5.2. E-MAC dans la composition E&A ...................................................................... 115

6. Le mécanisme E-MAC dans le NATFW NSLP ....................................................... 115

6.1. L'objet d'autorisation en utilisant E-MAC ........................................................... 116

6.2. Déroulement de la procédure d'authentification par E-MAC ............................... 117

6.3. Performances de E-MAC .................................................................................... 119

7. Conclusion .............................................................................................................. 120

Chapitre 6 : Evaluation des performances ...................................................................... 121

1. Introduction ............................................................................................................. 122

2. Implémentation de l'objet d'autorisation ................................................................... 122

3. Plateforme de test .................................................................................................... 123

3.1. Techniques utilisées ............................................................................................ 124

4. Résultats et analyse ................................................................................................. 124

4.1. Temps de traitement ........................................................................................... 125

4.2. Temps d'établissement de session ...................................................................... 126

4.3. Consommation du CPU ...................................................................................... 127

4.4. Consommation de la mémoire ............................................................................ 128

5. Conclusion .............................................................................................................. 130

Conclusion Générale ........................................................................................................ 131

REFERENCES ................................................................................................................ 133

WEBOGRAPHIE ............................................................................................................ 140

ANNEXE A Problématique de la traversée des NAT/FW par le protocole SIP ........ 141

ANNEXE B Les messages NATFW NSLP .................................................................. 143

ANNEXE C Les objets NATFW NSLP ....................................................................... 144

ANNEXE D Installation et configuration de NSIS et NATFW NSLP ....................... 146

Liste des figures

Figure 1 : Principe du NAT ......................................................................................................5

Figure 2 : Principe du NAT statique..........................................................................................7

Figure 3 : Principe du NAT dynamique.....................................................................................8

Figure 4 : Port Forwarding.........................................................................................................9

Figure 5 : Port Mapping.............................................................................................................9

Figure 6 : Le NAT en plein cône.............................................................................................10

Figure 7 : NAT à cône restreint...............................................................................................11

Figure 8 : NAT cône à restriction de port................................................................................12

Figure 9 : NAT symétrique......................................................................................................12

Figure 10 : Principe de pare-feu...............................................................................................13

Figure 11 : Pare-feu protégeant LAN et DMZ.........................................................................14

Figure 12 : Position de SIP dans le modèle OSI......................................................................21

Figure 13 : UAC et UAS..........................................................................................................21

Figure 14 : Composants d'une architecture SIP.......................................................................22

Figure 15 : Le processus d'enregistrement...............................................................................28

Figure 16 : Etablissent et terminaison d'une session SIP.........................................................28

Figure 17 : Exemple d'un problème du NAT avec SIP............................................................34

Figure 18 : La problématique des pare-feu..............................................................................35

Figure 19 : Corps de la requête INVITE et sa réponse OK.....................................................36

Figure 20 : Serveur d'application dans un réseau privé...........................................................40

Figure 21 : Serveur d'application dans la zone DMZ..............................................................40

Figure 22 : Principe de STUN.................................................................................................42

Figure 23 : Principe de TURN.................................................................................................44

Figure 24 : Architecture de proxy RTP....................................................................................45

Figure 25 : Exemple d'invitation à une session SIP.................................................................46

Figure 26 : Principe de tunnel de données...............................................................................48

Figure 27 : Principe de ALG....................................................................................................51

Figure 28 : Principe de RSIP...................................................................................................52

Figure 29 : RSIP tunnel ...........................................................................................................52

Figure 30 : Principe de MidCom.............................................................................................53

Figure 31 : Principe de serveur d'application avec agent.........................................................55

Figure 32 : Les composants de NSIS.......................................................................................61

Figure 33 : Exemple du cheminement des flux de signalisation et de données.......................63

Figure 34 : Relation entre les entités NSIS..............................................................................64

Figure 35 : Architecture de NSIS dans le cas du NAT/FW....................................................66

Figure 36 : Exemple de topologie du NAT/FW dans les réseaux IP.......................................67

Figure 37 : Interfonctionnement de NATFW NSLP................................................................68

Figure 38 : Entête NSLP commun...........................................................................................70

Figure 39 : Entête d'objet NSLP commun...............................................................................70

Figure 40 : Phase de création de session..................................................................................72

Figure 41 : Flux des messages de réservation dans le cas où le DR se trouve derrière un NAT/FW..74

Figure 42 : Echange de rafraichissement de session, avec CREATE......................................75

Figure 43 : La suppression de session avec CREATE...................................................................76

Figure 44 : Interaction NATFW NSLP et SIP................................................................................77

Figure 45 : Exemple de calcul de durée de vie de session............................................................80

Figure 46 : Architecture du NATFW NSLP............................................................................82

Figure 47 : L'attaque Man In the Middle dans NSIS...............................................................87

Figure 48 : Principe d'authentification et d'autorisation pour le NATFW NSLP ...................89

Figure 49 : Format de l'objet d'autorisation de session ...........................................................91

Figure 50 : Format général d'un attribut d'autorisation............................................................92

Figure 51 : Format de l'attribut AUTH_ENT_ID....................................................................93

Figure 52 : Format de l'attribut NSLP_OBJ_LIST..................................................................96

Figure 53 : Architecture de la RFC5981..................................................................................97

Figure 54 : Diagramme d’échange de messages entre les nœuds............................................98

Figure 55 : Configuration de NAT/FW (CREATE, RESPONSE)........................................101

Figure 56 : Déroulement du hachage avec HMAC................................................................103

Figure 57 : Vérification d'authenticité avec le MAC.............................................................103

Figure 58 : Description de l’objet SESSION_AUTH_OBJECT..........................................105

Figure 59 : L'architecture proposée pour l'authentification et l'autorisation .........................108

Figure 60 : Diagramme d'échange des messages dans l'architecture proposée.....................109

Figure 61 : Les modes : EtA (a), AtE (b) et E&A (c)...........................................................113

Figure 62 : Structure de AtE avec E-MAC............................................................................114

Figure 63 : Structure de E&A avec E-MAC..........................................................................115

Figure 64 : Nouveau format de l'objet d'autorisation de session...........................................117

Figure 65 : Plateforme de test................................................................................................123

Figure 66 : Temps de traitement (NI)....................................................................................125

Figure 67 : Temps de traitement (NF)...................................................................................126

Figure 68 : Temps d'établissement de session.......................................................................127

Figure 69 : Consommation de CPU (NI)...............................................................................127

Figure 70 : Consommation de CPU (NF)..............................................................................128

Figure 71 : Consommation de mémoire (NI).........................................................................129

Figure 72 : Consommation de mémoire (NF)........................................................................129

Liste des Tableaux

Tableau 1 : Différents états de NI : NI-FSM................................................................84

Tableau 2 : Différents états de NF : NF-FSM.........................................................................84

Tableau 3 : Différents états de NR : NR-FSM........................................................................85

Acronymes

ACL Access Control List

ALG Application Layer Gateway

DMZ DeMilitarized Zone

DR Data Receiver

DS Data Sender

FW FireWall

GIST General Internet Signaling Transport

HMAC keyed-Hash message Authentication Code

HTTP Hypertext Transfer Protocol

ICE Interactive Connectivity Establishement

IETF Internet Engineering Task Force group

IP Internet Protocol

MGCP Media Gateway Control Protocol

MidCom Middlebox Communications

NAT Network Address Translation

NATFW NSLP NATFireWall Nsis Signaling Layer Protocol

NF Nsis Forwarder

NI Nsis Initiator

NSIS Next Steps In Signaling

NTLP Nsis Transport Layer Protocol

PAT Port Address Translation

PSTN Public Switched Telephone Network

QoS Quality of Service

RFC Request For Comments

RSIP Realm Specific IP

RSVP Resource reservation Protocol

RTC Réseau Téléphonique Commuté

RTP Real-time Transport Protocol

SBC Session Border Controller

SCCP Skinny Call Control Protocol

SDP Session Description Protocol

SHA Secure Hash Algorithm

SIP Session Initiation Protocol

SMTP Simple Mail Transfer Protocol

SSL Secure Sockets Layer

STUN Simple Traversal Using UDP for NAT

TCP Transmission Control Protocol

TLS Transport Layer Security

ToIP Telephony over IP

TURN Traversal Using Relay NAT

UAC/S User Agent Client/Server

UDP User Datagram Protocol

UMAC Universal Message Authentication Code

UPnP Universal Plug and Play

VoIP Voice over IP

VPN Virtual Private Network

1

Introduction générale

___________________________________________________________________________

Les récents progrès dans le domaine des télécommunications ont permis la convergence des différents réseaux hétérogènes, de nature mobile et fixe et d’internet, ainsi que par la diversité des nouvelles applications qui ont émergé. En effet, on dénombre des applications multimédia nécessitant une bonne qualité de service (hauts débits, faible latence, ...etc.) telle que la téléphonie sur IP, la téléconférence, la vidéoconférence, la vidéo sur demande, ...etc. Divers protocoles ont été mis en œuvre pour répondre aux exigences et aux contraintes de ces nouveautés, mais le protocole SIP (session Initiation Protocol) s’avère comme étant l'un des protocoles les plus prometteurs pour offrir les nouveaux services multimédia grâce à son extensibilité. En effet, SIP peut être combiné à d'autres protocoles de communication, afin de permettre un échange en temps réel de plusieurs médias entre usagers distants. Le protocole SIP standard décrit dans le RFC3261, permet l'établissement, la terminaison et le changement de session dans une architecture poste à poste et client/serveur.

Cependant, les dispositifs de sécurité tels que les pare-feu et les routeurs à translation d’adresse (communément appelés routeurs NAT: Network Address Translation) qui ont été mis en place dans les réseaux conventionnels, ne se laissent pas traverser par le protocole SIP : ils ne sont pas adaptés à son fonctionnement. Cette problématique de la traversée du NAT et pare-feu par le protocole SIP a suscité plusieurs travaux de recherches qui ont abouti à une multitude de solutions : extension ou modification de protocole SIP, la modification du NAT, des méthodes permettant la découverte de comportement du NAT...etc.

Dans ce mémoire, nous nous sommes intéressés à l’étude des solutions élaborées, plusieurs approches ont été proposées telles que STUN, TURN, ICE, ALG, UPnP, MidCom etc …, Cependant, à cause de la complexité du problème, de la variété des topologies réseau existantes, et le comportement du NAT lui même, aucune de ces approches ne s'adapte dans toutes les situations et différents cas de fonctionnement. De plus, certaines de ces solutions ajoutent des coûts de bande passante, augmentent la latence, et sont nuisibles aux performances des applications temps réel. D'autres, en particulier UPnP, sont dépourvues de toute sécurité.

Suite à cette étude, notre intérêt s’est particulièrement porté sur le protocole NATFW NSLP de la plateforme NSIS. Ce dernier se caractérise par sa robustesse face aux différents types de NATs, son efficacité et sa faculté de faciliter à SIP la traversée d’une chaine de

2

NATs avec de bonnes performances, par conséquent, il s’avère plus prometteur que les autres solutions proposées.

Le principe de ce protocole consiste à configurer dynamiquement les routeurs NATs en effectuant un mappage d’adresse et en ouvrant sur les pare feu, des trous d'épingle (ports) par lesquels passent le flux de signalisation SIP. Cette opération assez délicate, fragilise l'objectif principal de ces dispositifs et comporte un risque du point de vue sécurité, ce défi doit être pris en compte afin d’éviter tout usager non authentifié et tout accès non autorisé.

Afin de pallier à cette situation, un mécanisme d'authentification et d'autorisation doit être pris en charge par ce protocole. Dans le présent mémoire, nous proposons deux mécanismes d'authentification, la première, est le mécanisme HMAC, une fonction de hachage cryptographique, qui permet de fournir un haché utilisé par les NATs et pare-feu pour assurer l'authenticité des requêtes des usagers légitimes. La seconde, concerne un nouveau mécanisme appelé (E-MAC) qui s’articule sur une fonction de hachage universelle UMAC, qui permet de fournir un haché pour garantir l’authentification et, associé à un algorithme de chiffrement assure également la confidentialité des messages des usagers légitimes. Afin de mener ce travail, nous avons structuré notre mémoire autour de six chapitres.

Organisation du mémoire

Le premier chapitre est consacré à un état de l’art qui a tout d’abord porté sur les techniques de translation d'adresse (NAT). Pour cela, nous avons mené une synthèse comparative sur les différents types de NAT, en détaillant leur principe de fonctionnement selon les différentes architectures réseau. Par ailleurs, une présentation a été effectuée sur le principe de filtrage utilisé comme autre moyen de sécurité, au niveau des firewalls (pare-feu).

Dans le second chapitre, nous présentons le protocole d'initiation de session SIP. Nous commençons par décrire ce protocole, son architecture de base, ses composants, et ses différents messages. Nous décrivons ensuite son fonctionnement, suivi de l’aspect sécurité, les menaces et les mécanismes de sécurisation. A la fin de ce chapitre, nous développons la problématique que pose ce protocole lors de la traversée des routeurs NATs et des pare-feu.

Les solutions mises en place visant à permettre au protocole SIP de traverser les NATs et les pare-feu feront l'objet du troisième chapitre. Ces solutions sont regroupées en trois catégories, nous distinguons celles qui sont basées sur le comportement du NAT, celles basées sur le contrôle du NAT, et les solutions combinant plusieurs de ces techniques. Pour chaque solution proposée, nous présentons son principe de fonctionnement ainsi que ses avantages et inconvénients, et une synthèse générale est faite à la fin de ce chapitre.

Le quatrième chapitre est consacré à la présentation de la plateforme NSIS qui inclut le protocole NATFW NSLP. Nous effectuons une étude détaillée de ce dernier : son fonctionnement, ses messages, ses différentes opérations telle que la création de session, son

3

implémentation avec ses principaux modules, et enfin les menaces de sécurité auxquelles peut être soumis ainsi que les travaux déjà réalisés pour sa sécurisation.

Dans le chapitre 5, qui situe notre contribution, nous présentons les mécanismes d'authentification que nous avons adoptés : HMAC et E-MAC. Nous nous consacrons à leur adaptation au niveau de l'objet d'autorisation de session du protocole NATFW NSLP. Nous présentons ainsi les différents éléments du réseau impliqués dans ce mécanisme, en focalisant sur les diverses possibilités afin de parvenir à une authentification efficace qui ne dégrade pas les performances de l’application.

En dernier lieu, dans le chapitre 6, nous mettons en place l'implémentation et l’évaluation de la solution proposée par le biais des différents métriques reflétant la préservation des performances des applications temps réel, prouvant ainsi l’efficacité et l’adaptation de la solution HMAC pour gérer de façon sécurisée la traversée (à travers les middleboxes) du protocole SIP.

Nous terminons ce mémoire par une conclusion générale ainsi que des perspectives visant à compléter et améliorer ce travail.

Chapitre 1 Etude de la technique de translation d'adresse : le NAT

4

Chapitre 1

Etude de la technique de translation d’adresse : le NAT


5

1. Introduction

Avec le développement croissant de l'internet, et notamment des liaisons à connexions permanentes comme le câble ou l'ADSL, de plus en plus d'entreprises utilisent le NAT (Network Address Translation) pour partager leur accès Internet.

La traduction ou translation d'adresse permet aux hôtes au sein d'un réseau privé de communiquer de façon transparente avec des destinations sur un réseau externe et vice versa.

Par ailleurs, le NAT a notamment été une réponse à la pénurie d'adresses IPv4.

Le NAT malgré qu'il permet d'accéder à l'Internet et de communiquer avec l'extérieur, cette ouverture est indispensable et dangereuse en même temps; car le fait d'ouvrir l'entreprise vers le monde signifie aussi laisser place ouverte aux étrangers pour essayer de pénétrer le réseau local de l'entreprise, et y accomplir des actions douteuses, de destruction, vol d'informations confidentielles...etc. Pour parer à ces attaques, une architecture sécurisée est nécessaire. Pour cela, le cœur d'une tel architecture doit être basé sur un pare-feu. Cette outil a pour but de sécuriser au maximum le réseau local de l'entreprise, de détecter les tentatives d'intrusion et d'y parer au mieux possible.

Dans ce premier chapitre, nous allons effectuer une présentation du NAT et des pare-feu, leur principe et fonctionnement selon leurs différents types existants.

2. Définition et principe du NAT

La translation d'adresse réseau est une technique par laquelle les adresses IP sont transposées d'un domaine d'adresse à un autre, fournissant un acheminement transparent aux hôtes d'extrémité [1].

Le principe du NAT consiste donc à utiliser une passerelle (routeur) de connexion à internet, possédant au moins une interface réseau connectée sur le réseau interne et au moins une interface réseau connectée à Internet (possédant une adresse IP routable), pour connecter l'ensemble des machines du réseau.

Figure 1 : Principe du NAT


6

Il s'agit de réaliser, au niveau du routeur, une translation (traduction) des entêtes IP des paquets qui proviennent du réseau interne vers le réseau externe.

Ainsi, chaque machine du réseau nécessitant d'accéder à internet est configurée pour utiliser le routeur NAT (en précisant l'adresse IP de routeur : @ IP locale externe). Lorsqu'une machine du réseau effectue une requête vers Internet, le NAT effectue la requête à sa place, reçoit la réponse, puis la transmet à la machine destination, en échangeant l’adresse IP de machine dans le réseau local (@ IP locale interne) par l’une de ses adresses publiques (@ IP global interne). De ce fait, une machine avec une adresse privée (non routable sur Internet) pourra dialoguer avec une machine sur internet.

En bref, Le routeur NAT de sortie modifie l’entête IP de tout paquet provenant d’une machine interne en remplaçant l’adresse source IP privée par une adresse IP publique, et effectue l'opération inverse pour les paquets provenant de l'extérieur.

Intérêt du NAT

Possibilité d’utilisation d’adresses privées dans un réseau local. Tout en rendant possible l’accès à l’extérieur depuis et vers ces machines. Au départ, le NAT est conçu pour économiser les adresses publiques. Vue de l’extérieur : Plage d’adresse publique. Sécurité : Rend invisible la configuration d’un Intranet.

3. Les types du NAT

Il existe deux types de NAT : statique et dynamique.

3.1. Le NAT statique

3.1.1. Principe

Le principe du NAT statique consiste à associer à chaque adresse IP privée une adresse IP publique correspondante, ce qui permet à avoir autant d’adresses privées que d’adresses publiques [1, 2, 3].

La seule action qui sera effectuée dans ce type du NAT par le routeur est de remplacer l'adresse privée par l’adresse publique.


7

Figure 2 : Principe du NAT statique

3.1.2. Avantages et inconvénients du NAT statique

Avantages

Le NAT statique est un mécanisme simple et a permis facilement de rendre une machine accessible de l’Internet en associant une adresse IP publique à une adresse IP privée.

De plus, le NAT statique permet facilement de faire des modifications, changements, interventions sur le réseau local, sans perte d’adresses, en changeant la correspondance entre les adresses privées et les adresses publiques pour rediriger les requêtes vers un serveur en état de marche.

Inconvénient

Le problème de la pénurie d'adresses IP n’est pas régler par le NAT statique vu qu’on est obligé d'avoir une adresse publique par machine voulant accéder à Internet.

3.2. Le NAT dynamique

3.2.1. Principe

Le NAT dynamique (appelée aussi IP masquerading) permet d’attribuer dynamiquement lors des connexions des adresses IP publiques aux adresses privées [1,2 ,3]. Plus précisément, c’est l’association de m adresses privées à n adresses publiques (avec m > n, n >= 1) ; de ce fait, on peut associer une seule adresse publique à plusieurs adresses privées.


8

Figure 3 : Principe du NAT dynamique

Dans le NAT dynamique, contrairement au NAT statique, le routeur qui effectue le NAT devra à la fois modifier les adresses IP mais aussi les ports TCP/UDP (on appelle la modification des ports PAT, Port Address Translation). En réalité on fait que du PAT également.

3.2.2. Avantages et inconvénients du NAT dynamique

Avantages

Permet l’accès à Internet à des machines d’un réseau local ayant des adresses privées (non routables).

Permet de répondre le problème de la pénurie d'adresses IP vu qu’on peut "cacher" un grand nombre de machines derrière une seule adresse publique.

Permet d’augmenter un peu le niveau de sécurité : les machines n'étant pas accessibles de l'extérieur, puisque la passerelle camoufle complètement l'adressage interne de réseau, et pour un observateur externe au réseau, toutes les requêtes semblent provenir de l'adresse IP de routeur.

Inconvénients

Ne peut pas marcher si la connexion est initialisée de l'extérieur.

Ne permet pas à un serveur d’être accessible de l'extérieur.

4. Les types de NAT dynamique selon le port Le NAT dynamique ne permet donc que de sortir sur Internet, et non pas d'être joignable. Il est donc utile pour partager un accès Internet, mais pas pour rendre un serveur accessible, la solution est alors consiste à inclure les ports TCP/UDP dans la translation (PAT) :


9

Le PAT signifie que plusieurs adresses IP locales correspondent une seule adresse IP globale, et le suivi de la connexion se fait par l'utilisation de numéro de port [1]. Ce mécanisme est utilisé pour rendre une machine accessible depuis l’extérieur. On distingue deux types de PAT : le Port Forwarding et le Port Mapping.

4.1. Le Port Forwarding

Le port forwarding se base sur le principe de rediriger un paquet vers un hôte précis en fonction du port de destination du paquet [1]. Ceci permet d'initialiser une connexion de l'extérieur vers l'un des hôtes de réseau local (une seule adresse par port TCP/UDP). Par exemple on redirige tous les paquets provenant d'internet à destination du port 80, vers le port 80 de la machine interne (voir la figure 4).

Figure 4 : Port Forwarding

4.2. Le Port Mapping

Le Port Mapping est un peu équivalent au Port Forwarding, à la différence, il consiste à rediriger la requête sur un port différent que celui demandé (le port de la machine interne change) [1]. Par exemple dans la figure 5, tous les paquets provenant d'internet à destination du port 8080, sont redirigés vers le port : 80 de la machine interne.

Figure 5 : Port Mapping


10

5. Les types du NAT dynamique selon la restriction :

Selon la restriction, il existe quatre types de NAT dynamique, comme définis dans [1, 4, 5, 6, 7, 8, 9, 10] sont :

1. NAT en plein cône

2. NAT à cône restreint

3. NAT à restriction de port

4. NAT symétrique

5.1. NAT cône plein (Full Cone)

Un NAT en plein cône est le NAT le moins restrictif, dans ce type, tous les couples (adresse/port IP) internes en provenance de la même hôte source interne, sont translatés sur le même couple (adresse/port IP) externe. De plus, les hôtes externes peuvent envoyer un paquet à l’hôte interne, en envoyant un paquet à l’adresse externe transposée.

Par exemple comme dans la figure 6 : les paquets de l’hôte interne A avec (A/3478) à destination de l’hôte externe B, sont translatés toujours sur le même pair (Z/3001). Et n’importe quelle autre hôte externe peut envoyer à l’hôte A en spécifiant seulement l’adresse transposée (Z/3001).

Figure 6 : Le NAT en plein cône [44]

On remarque dans ce type de NAT que la translation tient seulement compte de l’adresse et du port source.


11

5.2. NAT à cône restreint (Restricted Cone)

Un NAT à cône restreint (Restricted Cone) est comme un NAT en plein cône avec une restriction sur l’adresse de destination, c.-à-d. un hôte externe ne peut envoyer un paquet à l’hôte interne que si l’hôte interne lui a envoyé un paquet auparavant. Cette restriction réduit ainsi les problèmes de sécurités du NAT plein Cône.

Par exemple : dans la figure 7, l’hôte externe B peut communiquer avec l’hôte interne A, contrairement à l’hôte C qui ne peut pas envoyer à A tant que A ne lui a pas envoyé au préalable.

Figure 7 : NAT à cône restreint [44]

Dans ce type de NAT, la translation tient compte de l’adresse source, le port source, et de l’adresse destination.

5.3. NAT cône à restriction de port (Port Restricted Cone)

Un NAT en cône à restriction de port (Port Restricted Cone) est presque identique à un NAT à cône restreint, à la différence de la NAT à cône restreint, la restriction inclut les numéros de port en plus, ce qui résulte qu’un hôte externe avec l’adresse IP X et le port P, ne peut envoyer un paquet à l’hôte interne, que si l’hôte interne avait préalablement envoyé un paquet à l’adresse IP X et au port P.

Dans la figure 8 l’hôte externe B ne peut pas envoyer des paquets à l’hôte interne A à travers le port 195, puisque A ne lui avait pas encore envoyé un paquet à travers ce port.


12

Figure 8 : NAT cône à restriction de port [44]

La translation dans ce type de NAT tient compte de l’adresse et du port source mais aussi de l’adresse destination et du port destination.

5.4. NAT Symétrique

La différence entre la NAT symétrique et les types précédents c’est que pour des hôtes externes différentes on utilise la même adresse translatée mais avec des ports différents. De plus, seulement l’hôte externe qui reçoit un paquet peut renvoyer un paquet à l’hôte interne en utilisant seulement le pair (adresse/port) à travers lequel a reçu ce paquet.

Par exemple comme sur la figure 9, le pair (10.0.0.1/8000) d’un hôte interne est translaté au pair (202.123.211.25/45678) pour le premier hôte externe, cependant pour l’autre hôte externe l’adresse est la même mais le port est différent (202.123.211.25/12345). En plus, aucun de ces deux hôtes externes ne peut envoyer un paquet à travers le port de l’autre.

Figure 9 : NAT symétrique

Notant dans ce type de NAT que la translation tient compte à la fois de l’adresse et du port source mais aussi de l’adresse et du port de destination.


13

6. Les Pare-feu

6.1. Définition

Un pare-feu (firewall en anglais), est un système permettant de protéger un ordinateur ou un réseau d'ordinateurs des intrusions provenant d'un réseau tiers (notamment internet) [10, 11, 12]. En effet, le pare-feu est un système permettant de filtrer les paquets de données échangés avec le réseau, il s'agit ainsi d'une passerelle filtrante comportant au minimum les interfaces réseau suivante (figure 10) :

une interface pour le réseau à protéger (réseau interne) ; une interface pour le réseau externe.

Figure 10 : Principe de pare feu

Le firewall peut être un système logiciel, reposant parfois sur un matériel réseau dédié, constituant un intermédiaire entre le réseau local (ou la machine locale) et un ou plusieurs réseaux externes. Il est possible de mettre un système pare-feu sur n'importe quelle machine et avec n'importe quel système pourvu que :

La machine soit suffisamment puissante pour traiter le trafic; Le système soit sécurisé ; Aucun autre service que le service de filtrage de paquets ne fonctionne sur le serveur.

Une description du mode de fonctionnement fondamental se trouve dans [11,12].


14

6.2. Fonctionnement général

Le pare-feu était jusqu'à ces dernières années considéré comme une des pierres angulaires de la sécurité d'un réseau informatique. Il permet d'appliquer une politique d'accès aux ressources réseau.

Il a pour principale tâche de contrôler le trafic entre différentes zones de confiance, en filtrant les flux de données qui y transitent. Généralement, les zones de confiance incluent Internet (une zone dont la confiance est nulle) et au moins un réseau interne (une zone dont la confiance est plus importante).

Le but est de fournir une connectivité contrôlée et maîtrisée entre des zones de différents niveaux de confiance, grâce à l'application de la politique de sécurité et d'un modèle de connexion basé sur le principe de moindre privilège.

Un pare-feu fait souvent office de routeur et permet ainsi d'isoler le réseau en plusieurs zones de sécurité appelées DMZ (zones démilitarisées) qui sont séparées suivant le niveau de confiance qu'on leur porte.

Figure 11 : Pare-feu protégeant LAN et DMZ

Un système pare-feu contient un ensemble de règles prédéfinies permettant :

o D'autoriser la connexion (allow) ; o De bloquer la connexion (deny) ; o De rejeter la demande de connexion sans avertir l'émetteur (drop).

L'ensemble de ces règles permet de mettre en œuvre une méthode de filtrage dépendant de la politique de sécurité adoptée par l'entité. On distingue habituellement deux types de politiques de sécurité permettant : soit d'autoriser uniquement les communications ayant été explicitement autorisées, soit d'empêcher les échanges qui ont été explicitement interdits.


15

6.3. Types de filtrages

Le filtrage se fait selon divers critères dont les plus courants sont :

l'origine ou la destination des paquets (adresse IP, port, interface réseau, etc.) ; les options contenues dans les données (fragmentation, validité, etc.) ; les données elles-mêmes (taille, correspondance à un motif, etc.) ; les utilisateurs pour les plus récents.

6.3.1. Le filtrage simple de paquets ou sans état (stateless)

C'est le plus vieux dispositif de filtrage réseau, introduit sur les routeurs. Il regarde chaque paquet indépendamment des autres et le compare à une liste de règles préconfigurées : ACL (pour Access Control List), politique, filtres, règles ...etc. Il analyse les en-têtes suivants de chaque paquet de données échangé : adresse IP de la machine émettrice; adresse IP de la machine réceptrice; type de paquet (TCP, UDP, etc.); numéro de port.

La configuration de ces dispositifs est souvent complexe et l'absence de prise en compte des machines à états des protocoles réseaux ne permet pas d'obtenir une finesse du filtrage très évoluée. Ces pare-feu ont donc tendance à tomber en désuétude mais restent présents sur certains routeurs ou systèmes d'exploitation.

6.3.2. Le filtrage dynamique ou à état (stateful)

Le système de filtrage dynamique de paquets est basé sur l'inspection des couches 3 et 4 du modèle OSI, permettant d'effectuer un suivi des transactions entre le client et le serveur.

Il est ainsi capable d'assurer un suivi des échanges, c'est-à-dire de tenir compte de l'état des anciens paquets pour appliquer les règles de filtrage. De cette manière, à partir du moment où une machine autorisée initie une connexion à une machine située de l'autre côté du pare-feu; l'ensemble des paquets transitant dans le cadre de cette connexion seront implicitement acceptés par le pare-feu.

6.3.3. Le pare-feu applicatif

Le filtrage applicatif (ou proxy) permet de filtrer les communications application par application. Le filtrage applicatif opère donc au niveau 7 (couche application) du modèle OSI, contrairement au filtrage de paquets simple (niveau 4). Le filtrage applicatif suppose donc une connaissance des protocoles utilisés par chaque application, et suppose une bonne connaissance des applications présentes sur le réseau, et notamment de la manière dont elle structure les données échangées (ports, etc.).

De plus, le filtrage applicatif permet la destruction des en-têtes précédant le message applicatif, ce qui permet de fournir un niveau de sécurité supplémentaire.


16

7. Conclusion

Le NAT est aujourd'hui un élément important en réseau étant donné son énorme déploiement à travers le monde. Un des motifs les plus importants du NAT est qu'il simplifie l'administration de réseau. NAT donne la flexibilité en assignant des adresses IP internes puisqu'il permet de séparer les espaces public des espaces privés, Par exemple, si on déplace un web server ou un FTP à un autre hôte, on doit seulement changer le mapping d'adresse de pare feu pour refléter le nouveau hôte. En outre, si on fait des changements au réseau interne, on n'a pas besoin de reconfigurer l'adresse IP de chaque hôte parce que l'adresse IP public pour chaque dispositif dans le réseau interne soit elle appartient au pare feu ou est associé à l'interface externe de pare feu.

Le NAT est également rentable. Les blocs d'adresse privés non routables définis dans le RFC 1918 peuvent être réutilisés pour plusieurs intranets sans coût d'enregistrement associé.

Tandis que le NAT est pratique, il ne peut pas être utilisé comme méthode pour sécuriser un réseau privé. Il est seulement capable de cacher les équipements de réseau, mais ne les sécurisant pas. La première étape pour en faire est de placer un pare feu à la frontière du réseau.

Un pare-feu, quant à lui, considéré comme un dispositif de sécurité, n'offre bien évidemment pas une sécurité absolue, bien au contraire. Les firewalls n'offrent une protection que dans la mesure où l'ensemble des communications vers l'extérieur passe systématiquement par leur intermédiaire et qu'ils sont correctement configurés. Ainsi, les accès au réseau extérieur par contournement du firewall sont autant de failles de sécurité. C'est notamment le cas des connexions effectuées à partir du réseau interne à l'aide d'un modem ou de tout moyen de connexion échappant au contrôle du pare-feu.

La technique de NAT, bien qu’elle procure de nombreux avantages, a également de nombreux inconvénients. Le plus gênant de ces inconvénients est le fait qu’elle rende difficile le développement de nouvelles applications multimedia comme la VoIP, la Vidéo, ...etc. [4,13]. Quelques protocoles échangent l'information de l'adresse IP et le port dans la partie de données d'un paquet IP, et le NAT généralement ne peut pas faire la translation des adresses IP dans cette partie. Un de ces protocoles est le protocole de signalisation SIP (Session Initiation protocole) destiné à la téléphonie sur IP (ToIP). D'autres protocoles tels que RTP sur UDP, dont ses paramètres sont négociés par SIP dans la VoIP, changent périodiquement les numéros de ports utilisés dans le transport de données multimédias et sont, par conséquent, bloqués par les pare-feu [10, 13].

Au cours du chapitre suivant, une étude de protocole SIP sera effectuée, en détaillant sa problématique avec le NAT et les pare-feu.

Chapitre 2 Le protocole SIP (Session Initiation Protocol)

17

Chapitre 2

Le protocole SIP (Session Initiation Protocol)


18

1. Introduction

La téléphonie sur IP (ToIP) utilise la technologie de voix sur IP (VoIP) qui transforme la voix en paquets de données et transmet les conversations via le même réseau que celui utilisé pour envoyer des données (fichiers, courrier électronique). Plus concrètement, la ToIP correspond au service téléphonique entre deux terminaux sur un réseau IP. Les avantages de cette technologie sont nombreux et facilitent notamment la mise en place d'outils informatiques. La réduction des coûts est l'un des meilleurs atouts de la ToIP, car le transport sur IP est moins cher que le RTC (Réseau Téléphonique Commuté).

En outre, l’utilisation de la ToIP permet la mobilité des agents d’une entreprise. En effet, puisque les communications se faisant via le réseau Internet, un agent peut travailler à son domicile, dans les locaux de l’entreprise, être affecté temporairement sur des sites de clients. Il suffit pour cela que l’agent dispose d’une connexion Internet sur le site où il se trouve.

Dans la technologie téléphonie sur IP (ToIP) une multitude de protocoles ont été développés pour la signalisation ToIP : H323, SIP, SCCP (Cisco), MGCP, GSM [14, 15]. Quelques uns de ces protocoles sont propriétaires (SCCP pour Cisco), tandis que d’autres sont des standards. Aujourd’hui le protocole SIP est devenu le plus répandu et de plus en plus adopté par les entreprises dans le monde entier, vu sa simplicité, sa souplesse, et sa rapidité.

Ce chapitre présente l’état de l’art du protocole SIP (Session Initiation Protocol) conçu pour initier et terminer une session multimédia. Dans les sections de ce chapitre, on présentera les notions liées à ce protocole : son architecture, ses composants, ses différents messages. Par la suite une description de son fonctionnement est introduite, suivie de l’aspect sécurité, les menaces et les mécanismes de sécurisation, et enfin on montre la problématique de ce protocole avec les NATs et les firewalls.

2. Bref historique de SIP

SIP (Session Initiation Protocol) a été initié et normalisé par le groupe de travail WG MMUSIC (Work Group Multi-party MultiMedia Session Control) de l’IETF. La version 1 est sortie en 1997, et une seconde version majeure a été proposée en mars 1999 (RFC 2543). Cette dernière a elle-même été largement revue, complétée et corrigée en juin 2002 (RFC 3261 [16]). Des compléments au protocole ont été définis dans les RFC 3262 à 3265 [17].

SIP est un protocole de signalisation de bout en bout permettant l’établissement, le maintien, la modification, la gestion et la terminaison des sessions entre utilisateurs pour toutes les communications multimédias telles que la téléphonie et la vidéoconférence [18, 19]. Il est le descendant des protocoles de signalisation plus classiques comme SS7 (Système de Signalisation numéro 7) [20].


19

SIP hérite [21] de certaines fonctionnalités des protocoles HTTP (Hyper Text Transport Protocol) utilisé pour naviguer sur le WEB, et SMTP (Simple Mail Transport Protocol) utilisé pour transmettre des messages électroniques (E-mails). SIP [20] se distingue par sa flexibilité et qu'il n'est pas lié à un type de données, ni à un type de réseau de transport. Cette qualité est sa grande force qui lui permettant d’être utilisé pour mettre en relation 2 équipements pour tout type d'échange de données : voix sur IP qui est l'échange de données le plus connu, vidéo, messagerie instantanée IM (Instant Messaging), indication de présence, notification d'événements...etc.

L’objectif principal de SIP [22] est d’encadrer les protocoles opérant pendant une communication audio ou vidéo : le protocole description de session (SDP), le protocole annonce d’une session (SAP) et le protocole de transmission temps réel (RTP). Ce protocole n’assure pas le transport des données utiles, mais son rôle se résume dans l'établissement de la liaison entre les interlocuteurs. En d'autre terme, il ne transporte pas la voix ou la vidéo, mais assure simplement la signalisation. Son positionnement se situe au niveau de la couche applicative du modèle OSI et son fonctionnement suit une architecture client-serveur, le client émette ses requêtes au serveur, et ce dernier exécute les actions sollicitées par le client en réponse.

Le protocole SIP [22] est devenu efficace et rapide pour un établissement d’une session, il nécessite qu’un aller et deux retours pour ouvrir un canal média entre des utilisateurs.

3. Introduction au fonctionnement de SIP

A l'origine, SIP a été conçu pour gérer des conférences téléphoniques sur des réseaux IP. Contrairement aux autres protocoles de la VoIP comme H.323 et à MGCP, SIP ne prend pas en charge le transport de la voix [23]. En revanche, SIP est plus simple et garantit des implémentations réellement standards.

En revanche, SIP ne standardise pas le transport des flux de données entre les deux équipements. Il ne prend en charge que la gestion des requêtes d'établissement des communications, laissant de côté la réservation de la bande passante tâche dévolue à Real Time Protocol (RTP), qui fonctionne au-dessus d'UDP et de TCP, ainsi que la numérisation de la voix elle-même qui est prise en charge par codecs [24].

SIP fournit les six services [25] suivants pour les conversations multimédia :

Localisation du terminal appelé. Analyse du profil et des ressources du destinataire. Négociation du type de média (voix, vidéo, données…), et des paramètres de

communication.


20

Disponibilité de l’appelé : détermine si le poste appelé souhaite communiquer, et autorise l’appelant à le contacter.

Etablissement et suivi de l’appel : avertit les parties appelant et appelé de la demande d’ouverture de session, gestion du transfert et de la fermeture des appels.

Gestion de fonctions évoluées : retour d’erreurs, …etc. SIP fournit des fonctions annexes évoluées, comme la redirection d’appel, la

modification des paramètres associés à la session en cours ou l’invocation de services. En fait, SIP ne fournit pas l’implémentation des services, mais propose des primitives génériques permettant de les utiliser. De cette manière, l’implémentation des services est laissée libre, et seul le moyen d’accéder aux services est fourni.

4. Architecture et composants de SIP

L’architecture du protocole SIP est définie dans RFC 3261 [16]. Elle utilise les protocoles Internet Protocol (IP), User Datagram Protocol (UDP), Transmission Control Protocol(TCP) pour permettre une communication audio ou vidéo [18, 14].

D’autres protocoles peuvent fonctionner en collaboration avec SIP tels :

- RTP (Real Time Protocol) : RFC 3550, comme son nom l’indique, ce protocole permet la transmission de données en temps réel pendant une session média.

- SDP (Session Description Protocol) RFC 2327, protocole de description des paramètres d’une session média.

- RTSP (Real time Streaming Protocol) RFC 2326, protocole de transmission de donnée temps réel.

- SAP (Session Annonce Protocol) RFC 2974, annonce les sessions média en mode multicast.

- MIME (Multipurpose Internet Mail Extension), RFC 2045, standard pour les descriptions de contenus, utilisé sur Internet.

- RSVP (Resource Reservation Protocol), RFC 2205, pour obtenir des garanties de qualité de service et effectuer des réservations de ressources.

- HTTP (HyperText Transfer Protocol), RFC 2616, pour le traitement des pages Web sur Internet (on peut inclure des adresses SIP directement dans des pages Web).

- MGCP (Media Gateway Control Protocol), RFC 3435, pour le contrôle des passerelles assurant la connectivité entre un réseau IP et un réseau téléphonique.

- La nature de tous ces protocoles est différente de celle de SIP, tandis que leur utilisation conjointe est possible, voire recommandée pour certains d’entre eux [17].

La figure ci-dessous (figure 12) donne le positionnement de SIP dans les couches de modèle OSI parmi les protocoles Internet.


21

Figure 12 : Position de SIP dans le modèle OSI [26]

SIP définit deux types d’entités : les clients et les serveurs. Ces entités sont [17, 26, 19] :

L’agent utilisateur (UA, User Agent) : c’est l'élément final de l'architecture SIP, Il s’agit d’une application sur un équipement de l’usager qui émet et reçoit des requêtes SIP. Il se matérialise par un logiciel installé sur un PC, sur un téléphone IP ou sur une station. Il est constitué réellement de deux entités, l’UAC (User Agent Client) et l’UAS (User Agent Server) [25] : UAC : C'est une application cliente qui envoie des requêtes SIP, c'est l’appelant

(voir figure 13). UAS : C’est une application de type serveur qui contacte l’utilisateur lorsqu’une

requête SIP est reçue. Puis, elle renvoie une réponse au nom de l’utilisateur. L'UA peut être : une station de travail, un téléphone IP, un Gateway. Le client initie les appels et le serveur répond aux appels initiés par le client. Un utilisateur peut utiliser des outils tels qu’un téléphone IP, un PDA, un casque ou même un logiciel pour effectuer et recevoir ses appels.

Figure 13 : UAC et UAS [17]

Le serveur proxy (Proxy server) : appelé aussi le relai de mandataire, auquel est relié un terminal, ce composant agit à la fois comme un serveur et comme un serveur, il reçoit les requêtes de clients qu’il traite lui-même ou qu’il transmet à d’autres serveurs après avoir éventuellement réalisé certaine modifications sur ces requêtes. Le serveur Proxy a la capacité de traduire le numéro de l’appelé dans le message SIP reçu, en un numéro de


22

renvoi d’appel et d'envoyer l’appel à cette nouvelle destination, et ce, de façon transparente pour le client origine.

Le serveur de redirection (Redirect server) : Il s’agit d’un serveur qui traduit l'adresse SIP de destination en une ou plusieurs adresses réseau et les retourne au client. Contrairement au serveur proxy, ce serveur n'achemine pas de requêtes SIP. Dans le cas d’un renvoi d’appel, le serveur de redirection retourne le nouveau numéro (numéro de renvoi) au client origine qui se charge d’établir un appel vers cette nouvelle destination.

Le serveur d’enregistrement (Registrar) : c’est un serveur qui accepte les requêtes SIP

REGISTER et offre également un service de localisation. Chaque serveur proxy ou serveur de redirection est généralement relié à un serveur d’enregistrement. La principale fonction du serveur est de gérer les comptes SIP alloués aux utilisateurs dont chacun dispose d’un compte unique [24]. Un utilisateur émis un message REGISTER au serveur indiquant l’adresse où il est joignable (adresse IP) afin de mettre à jour une base de données de localisation. Un utilisateur peut s’enregistrer sur différents UAs SIP; dans ce cas, l’appel lui sera délivré sur l’ensemble de ces UAs.

Le serveur de localisation (Location Server) : fournit la position courante des utilisateurs

dont la communication traverse le serveur d’enregistrement et le serveur proxy auxquels il est rattaché. Ce serveur n'est pas vraiment une entité mais plutôt une base de données (ou un fichier texte permet de mémoriser les différents utilisateurs, leurs droites, leurs mots de passe, etc.) utilisée par un serveur de redirection ou un serveur proxy.

La figure suivante (figure 14), présente les composants SIP, cependant les entités Gateway et PSTN ne font pas partie des entités SIP, le PSTN (Public Switched Telephone Network) appelé aussi RTPC est un réseau téléphonique public commuté présent partout dans le monde. Le Gateway (ou la passerelle) est un équipement IP/PSTN capable de convertir des conversations dans les deux sens, à la fois de l'IP vers le RTC et du RTC vers l'IP.

Figure 14 : Composants d'une architecture SIP [21]


23

5. Transaction SIP

Le SIP est basé sur le protocole de transfert hypertexte de protocole d'enchaînement (HTTP). Et comme le HTTP, SIP est un protocole requête/réponse et client/serveur : le client produit des requêtes et le serveur reçoit ces requêtes et renvoie des réponses. Cette terminologie est héritée du HTTP, où un web browser contient un client HTTP, quand on tape une adresse dans le navigateur web, tel que http://www.esi.dz, on envoie une requête à un web server particulier, ce dernier renvoie une réponse avec l'information demandée. SIP se conforme à la même procédure : l'UAC envoi des requêtes et l'UAS renvoi des réponses. Une requête SIP avec sa (ou ses) réponse (ensemble) est désigné sous le nom : transaction SIP.

5.1. Les requêtes SIP

Les requêtes sont envoyées généralement d’un client SIP à un serveur SIP [21]. La RFC 3261 définit six types de requêtes SIP : invite, bye, register, cancel, options [16, 18, 22, 19].

INVITE : cette requête est utilisée pour établir une session entre les agents utilisateurs, le client et le serveur, en invitant le serveur à cette session de média. INVITE contient les informations sur l’appelant et l’appelé et sur le type de flux qui seront échangés (voix, vidéo, etc.).Lorsqu’un UA ayant émis la requête INVITE reçoit une réponse finale, il confirme la réception de cette réponse par :

ACK : requête d'acquittement permet de confirmer la réception de la réponse finale d’une requête INVITE. Une réponse telle que busy ou ok est considérée comme finale, alors qu’une réponse telle que ringing signifiant que l’appelé est alerté, et est une réponse provisoire (pas finale).

BYE : cette requête permet la libération et la terminaison d’une session préalablement établie. Cette requête comme elle peut être émise par l’appelant, elle peut être également émise par l’appelé.

REGISTER cette requête est utilisée afin d’indiquer au serveur d'enregistrement la correspondance entre l'adresse SIP de l'UA et son adresse de contact (exemple, adresse IP).

CANCEL est une requête utilisée pour demander l'interruption d’un appel en cours, et pour annuler une transaction [19], mais n’a aucun effet sur un appel déjà accepté. En effet, la seule méthode qui peut terminer un appel établi est BYE.

OPTIONS : est utilisée afin d’interroger les capacités et l’état de l'autre côté telles que le type de média supporté, les méthodes supportées, la langue supportée.


24

5.2. Les réponses SIP

Après avoir reçu et interprété une requête SIP, le serveur SIP (UAS) répond à cette requête au moyen d'une ou plusieurs réponses. Il existe six classes de réponses, de 1xx à 6xx, Les réponses, dont les codes sont de la forme 1xx sont des réponses provisoires et ne terminent pas la transaction courante, tandis que les autres réponses dont les codes sont de la forme 2xx à 6xx sont des réponses finales et terminent la transaction courante. Ces réponses sont [21, 16, 19] :

1xx : les codes de réponses de cette forme sont des réponses provisoires et informatives, informant le client que la requête a été reçue par le serveur et elle est en cours de traitement (pas de réponse définitive). Ces codes de réponses comme définis dans [16] sont : 100: essai, 180 : sonnerie en cours, 181: l'appel et en cours de transmission, 182: en file d'attente, 183 : avancement de la session.

2xx : une réponse de réussite et de succès, signifiant que la requête a été acceptée. Le code de cette réponse est 200 : ok.

3xx : sont des réponses de redirection et réorientation qui donnent des informations sur la nouvelle localisation de l'utilisateur, ou sur des services de remplacements qui pourraient être capables de satisfaire à l'appel. Les codes dans cette classe compris dans cette classe sont : 300: choix multiples, 301: déplacement définitif, 302 : temporairement déplacé, 305 : utiliser un mandataire, 380 : service de remplacement.

4xx : sont des réponses d'échec et de défaillance de la requête, dans ce cas, la requête ne peut pas être interprétée ou servie par le serveur, et doit être modifiée avant d’être renvoyée. Par exemples : 400: mauvaise demande, 401: non autorisé, 402 : paiement exigé, 403: interdit, 404 : pas trouvé...etc.

5xx : ces codes déterminent les réponses de défaillance de serveur, le serveur échoue dans le traitement d’une requête apparemment valide à cause d'une condition inattendue qui lui empêche de satisfaire la requête. Cependant, le client peut réessayer sa requête si la condition est temporaire. Les codes de cette classes sont : 500 : erreur interne de serveur, 501 : non mis en œuvre, 502: mauvaise passerelle, 503: service indisponible, 504: expiration de délai de serveur, 505: version non acceptée, 513: message trop long.

6xx : sont les réponses d'échec global, la requête ne peut être traitée par aucun serveur. Les codes de réponses sont : 600 : occupé partout, 603 : refus, 604 : n'existe nul part, 606 : non acceptable.

5.3. Format de messages SIP

Les messages SIP sont basés sur le format texte, ils utilisent l’encodage UTF-8 en mode caractère défini dans (RFC 2279) [27]. Les messages SIP sont codés en utilisant la


25

syntaxe de message HTTP/1.1 (RFC2068). Un message SIP peut être une requête d’un client attaché à une session ou une réponse d’un serveur. Les messages de requête et réponse utilisent le format standardisé dans le RFC 2822 [28]. Une forme générale d’une requête SIP est [19] :

Request = Request-Line (si réponse : Response = Status-Line)

*( message-header )

CRLF

[ message-body ]

Comme présente la forme d’une requête (ou réponse) SIP, ses messages consistent en :

Un début de ligne : request/status-Line. Un ou plusieurs champs d’en-tête : *(message header). Un saut de ligne pour indiquer la fin des champs d’en-tête : CRLF. Un corps de message optionnel : [message body].

Voici un exemple d'un message INVITE :

L’entête se compose des champs : From, To,Call-ID, CSEQ, Subject, VIA, Expire, Content-Type et Content-Length

Le corps du message est : v=0 ..... m= audio 4142 RTP

Et voici un exemple qui montre la forme d’une réponse : 180 ringing :

INVITE sip :laurent@reseau_labo.fr SIP/2.0 From : Guy <sip : guy@reseau_labo.fr> To : Laurent <sip : laurent@reseau_labo.fr> Call-ID : 3210-zad-323-lo1@ reseau_labo.fr CSEQ : 123 INVITE Subject : Réunion d’équipe demain. VIA : SIP/2.0/UDP 192.168.1.3@reseau_labo.fr Expire : 7200 Content-Type: application/SDP Content Lenght : 13232 v= 0 o= IN IP4 132.227.60.2 s= Test de ToIP c= IN IP4 prox11AB.lip6.fr m= audio 4142 RTP


26

L’entête se compose des champs : VIA, From, To, Call-ID, CSEQ, Expire.

Certains champs d’en-têtes sont présents toujours dans les messages SIP formant l’en-tête général (general header), ces champs sont :

• Call-ID: Ce champ contient un identificateur globalement unique pour un appel.

• Cseq: un identificateur qui sert à rapprocher.

• From: identifie l’appelant et doit être présent dans chaque message.

• To : indique la destination et doit présenter dans toutes les requêtes et est simplement copié dans les réponses.

• Via : enregistre la route d’une requête pour permettre aux serveurs SIP intermédiaires de faire suivre aux réponses le chemin exactement inverse.

• Encryption: spécifie que le corps du message et certains champs d'entête ont été chiffrés.

• Content-Type: décrit le type de média contenu dans le corps message.

• Content-Length: longueur du corps du message en octets.

5.4. L'adressage

L’objectif de l’adressage est de localiser les utilisateurs dans un réseau. C’est une étape indispensable pour permettre à un utilisateur d’en joindre un autre.

SIP [20] possède un adressage pour identifier les applications SIP : c'est l'URI (Uniform Resource Identifier) comme on a l'URL (Uniform Resource Locator) pour HTTP.

Un exemple d'URI est : sip:[email protected] qui ressemble à une URL de type :

http://www.esi.dz

SIP/2.0 180 Ringing VIA : SIP/2.0/UDP 192.168.1.18@reseau_labo.fr From : Guy <sip : guy@reseau_labo.fr> To : Laurent <sip : laurent@reseau_labo.fr> Call-ID : 3210-zad-323-lo1@ reseau_labo.fr CSEQ : 123 INVITE Expires : 7200


27

L'URI dans sa forme la plus générale s'écrit :

sip:identifiant[:mot_de_passe]@serveur[?paramètres]

On distingue dans cette adresse plusieurs parties :

- Le mot clé sip (ou sips en mode sécurisé) spécifie le protocole à utiliser pour la communication.

- La partie identifiant définit le nom ou le numéro de l’utilisateur. - La partie mot_ de_passe est facultative. - La partie serveur spécifie le serveur chargé du compte SIP. Le serveur est

indiqué par son adresse IP ou par un nom qui sera résolu par DNS. - La partie paramètres est facultative. Les paramètres servent à modifier le

comportement par défaut (les protocoles de transport ou les ports) ou à spécifier des informations complémentaires.

L'utilisation de l'URI offre de nombreux avantages, en effet, facilement mémorisable par les utilisateurs, et il possible d'utiliser la même URI pour l'adresse émail et l'adressage téléphonique.

6. Fonctionnement de SIP

6.1. Enregistrement

Brièvement, un User agent envoi la requête REGISTER afin d’indiquer au serveur d’enregistrement la correspondance entre son adresse SIP et son adresse IP qui peut être statique ou obtenue dynamiquement par DHCP. Le serveur d’enregistrement met alors à jour une base de données de localisation (voir la figure 15). A partir de ce moment, le User Agent peut recevoir des appels puisqu'il est localisé [20].

Un des plus grands avantages de SIP est son capacité de supporter la mobilité de l’utilisateur [19], cette mobilité requiert l’enregistrement de la nouvelle localisation de l’utilisateur lorsqu’il se déplace. Pour renvoyer des appels d’un UA de son domaine courant à un autre domaine, il lui suffit d’indiquer au serveur d’enregistrement de domaine courant son adresse SIP dans le nouveau domaine de renvoie. Quand une requête INVITE est délivrée, le serveur d’enregistrement met à jour la base de données et informe le serveur proxy que la requête doit être relayé au nouveau domaine de renvoie. Alors le serveur proxy effectue une recherche par le DNS de l’adresse IP du serveur proxy du domaine de renvoie afin de lui relayer le message SIP à la destination appropriée.


28

Figure 15 : Le processus d'enregistrement [17]

Le délai [22] d’enregistrement est la durée entre l’envoi du message Register et la réception du message Ok.

6.2. Etablissement et terminaison d'une session SIP

6.2.1. Etablissement d'une session

Pour établir une session, quatre étapes seulement suffisent à mettre en relation les deux utilisateurs [20, 18, 19]. Dans l’exemple suivant, l'appelant a pour URL sip:[email protected],alors que celle de l'appelé est sip:[email protected] (Figure 16) :

sip:[email protected] sip:[email protected]

Figure 16 : Etablissent et terminaison d'une session SIP [20]


29

Première étape: L’appelant (UAC) envoie un message (requête INVITE) proposant à son correspondant(UAS) d’initier une communication. Ce message contient les paramètres désirés pour établir la communication :

Plus précisément, lorsque la requête INVITE est envoyé, le serveur proxy interroge la base de données de localisation pour déterminer la localisation de l'appelé (adresse IP) et achemine l'appel à la destination. La requête INVITE contient différents champs d’entête obligatoires qui sont : l'adresse SIP de l'appelé "To", l'adresse SIP de l'appelant "From", un identifiant d'appel "Call-ID", un numéro de séquence "Cseq", un nombre maximum de sauts « max-forwards ». Le champ Via est mis à jour par toutes les entités qui ont participé au routage de la requête dans le but d’assurer que la réponse suivra le même chemin que la requête.

De plus, la requête INVITE contient une syntaxe SDP (Session Description Protocol). Cette structure consiste en plusieurs lignes qui décrivent les caractéristiques du média que l’appelant "Omar" requiert pour l’appel. Dans cette requête exemple, Omar Nouali indique que la description SDP utilisation la version 0 du protocole (v=0), qu'il s'agit d'une session téléphonique (m=audio), que la voix (en paquets) doit lui être délivrée à l'adresse de transport (port UDP=45450, adresse IP = 192.23.34.45) avec le protocole RTP et en utilisant un format d'encodage défini dans le RFC AVP (Audio Video Profile) …etc.

Deuxième étape : Dès que l’UAS reçoit la requête INVITE, il en informe l’utilisateur appelant (le téléphone sonne, avec indication de l’appelant et du motif de son appel s’il a renseigné ce champ, ainsi que des services disponibles) en renvoyant une réponse provisoire 180 RINGING, que l’appelé est en train d’être averti de l’appel.

Troisième étape : dès que l’appelé accepte l’appel (en décrochant), la réponse 200 OK est émise par son UAS et acheminée à l’UA (de l’appelant) en lui indiquant que l’appel peut commencer. Ce message contient les paramètres que l’UAS supporte pour la session :

INVITE sip:[email protected] SIP/2.0 Via : SIP/2.0/UDP station1.cerist.dz:5060 Max-Forwards : 20 To :Fares Guarrech<sip:[email protected]> From :Omar Nouali<sip:[email protected]> Call-Id: [email protected] CSeq: 1 INVITE Contact: [email protected] Content-Type: application/sdp Content-Length:162 v = 0 c = IN IP4 192.190.132.20 m = audio 45450 RTP/AVP 0 15


30

Quatrième étape: L’UAC retourne à l’UAS un message d’acquittement (requête ACK) en lui indiquant qu’il a pris note que l’appel peut débuter. Ce message contient les paramètres fixés pour la session, qui tiennent compte de ces possibilités et de celles de l’UAS.

Après ces quatre étapes, les intervenants sont ensuite mis en relation et peuvent communiquer. Une fois que SIP a ouvert une session, c'est donc RTP (Real Time Protocole) qui prend le relais et se charge du transport de la voix ou de la vidéo.

6.2.2. Terminaison d'une session

Première étape : lorsque l'appelant raccroche, son UA envoie une requête BYE pour terminer la session. Cette requête est remise au serveur proxy qui la véhicule à l’UA de l'appelé :

Deuxième étape : une réponse 200 ok est retournée de l’UA de l'appelant dès que la requête BYE est reçue :

SIP/2.0 200 OK Via : SIP/2.0/UDP ps1.cerist.dz:5060 Via : SIP/2.0/UDP station1.cerist.dz:5060 Max-Forwards : 20 To :Fares Guarrech<sip:[email protected]> From :Omar Nouali<sip:[email protected]> Call-Id: [email protected] CSeq: 1 INVITE Contact: [email protected] Content-Type: application/sdp Content-Length:162 v = 0 c = IN IP4 192.190.132.27 m = audio 22220 RTP/AVP 0

BYE sip:[email protected] SIP/2.0 Via : SIP/2.0/UDP station1.cerist.dz:5060 Max-Forwards : 20 To :Fares Guarrech<sip:[email protected]> From :Omar Nouali<sip:[email protected]> Call-Id: [email protected] CSeq: 2 BYE


31

7. Sécurité de SIP

Selon [29, 30, 31] SIP est un protocole difficile à sécuriser du à son utilisation d’intermédiaires, ses relations de confiance multi-faces, son usage prévu entre éléments sans confiance du tout, et son fonctionnement d’usager à usager. Ces vulnérabilités lui font une cible facile à attaquer par les pirates en utilisant plusieurs techniques d’attaque [32]. Dans cette section, on présente quelques exemples d’attaque sur SIP, ainsi que les mécanismes de sécurité disponibles.

7.1. Exemples d’attaques contre SIP

Il existe de nombreuses attaques et menaces possibles contre SIP dont les plus répandues, sont [29, 30, 31] :

Dénis de service (DoS) : Cette attaque rend un élément du réseau indisponible. Un exemple de ce type d’attaque est l’envoies illégitimes de paquets SIP BYE.

Ecoute clandestine en écoutant le trafic de signalisation, dans ce type d’attaque, l’attaquant utilise des outils d’écoute réseau tels que VOMIT (Voice OverMisconfigured Internet Telephone), SiVuS (SIP Vulnerability Scanner), et WireShark.

Détournement du trafic : l’attaquant envoi un message de redirection indiquant que l’appelé s’est déplacé et donne sa propre adresse comme adresse de renvoie, cette technique d’attaque redirige tous les appels destinés à l’utilisateur vers l’attaquant.

Usurpation d’identité : l’attaquant usurpe l’identité de l’expéditeur en modifiant le champ From de l’entête de message SIP.

Vols de services : l’objectif de cette attaque est de faire passer des appels sur le réseau sans avoir payer le fournisseur de service. Le pirate peut emprunter l’identité d’un utilisateur et l’utilise.

SIP/2.0 200 OK Via : SIP/2.0/UDP ps1.cerist.dz:5060 Via : SIP/2.0/UDP station1.cerist.dz:5060 Max-Forwards : 20 To :Fares Guarrech<sip:[email protected]> From :Omar Nouali<sip:[email protected]> Call-Id: [email protected] CSeq: 2 BYE


32

7.2. Mécanismes de sécurisation

Pour établir une bonne sécurité pour le protocole SIP, les services fondamentaux nécessaires consiste à : préserver la confidentialité et l’intégrité de l’échange de messages, empêcher les attaques en répétition ou le détournement de message, fournir les moyens d’authentification et de préservation de la confidentialité des participants, et empêcher les attaques de DoS.

Les corps des massages SIP, quant à eux, exigent les services de confidentialité, d’intégrité, et d’authentification.

Cela dit, plusieurs mécanismes de sécurité sont envisagés pour SIP :

7.2.1. Sécurité physique

Qui consiste à restreindre l’accès aux équipements réseaux (routers,switch,...) et aux serveurs aux seules personnes autorisées. Les solutions choisies pour garantir la sécurité physique dépendent du niveau de sécurité requis (pièces fermées à clefs, lecteurs de cartes, biométrie, gardes,…etc.).

7.2.2. Séparation des adresses logiques

En déployant des éléments de téléphonie IP et d’éléments de données IP sur deux segments logiques IP séparés. Les éléments de VoIP/SIP (serveur proxy, serveur d’enregistrement, terminaux, etc.) devraient être déployés sur leur propre réseau ou sous-réseau IP privé. Idéalement, ces sous-réseaux devraient utiliser un espace d’adresses différent de celui utilisé dans les réseaux de données. Il faudrait, si possible, n’utiliser que des adresses privées (RFC 1918) afin de séparer de manière encore plus forte le réseau de SIP et le réseau de données.

7.2.3. Mise en place des réseaux locaux virtuels

En divisant le trafic SIP du réseau de données traditionnel en utilisant les VLANs. Ces derniers créent une séparation logique des domaines de collisions qui peut s’étendre aux multiples segments du réseau physique, permettant ainsi la limitation de risque des attaques de type DoS ou packet sniffing.

7.2.4. Firewalls

Ces équipements sont implémentés de manière à compartimenter les serveurs SIP face aux accès non autorisés afin de limiter et contrôler les accès depuis le réseau de données au réseau de téléphonie IP. Il faut au minimum qu’un filtrage IP soit implémenté entre les réseaux de donnée/voix pour diminuer la possibilité d’attaques qui pourraient provenir depuis le réseau de données. Les firewalls fournissent les services de sécurité suivants :


33

- Contrôle d’accès qui gère les demandes de connexion, examine la nature de trafic et valide son contenu grâce aux techniques de filtrage (statique ou dynamique).

- Isolation du réseau et authentification des utilisateurs par des relais applicatifs qui contrôlent et relayent toutes les requêtes vers le serveur demandé, puis retransmissent les réponses au client initial.

- Chiffrement des données en utilisant des solutions de chiffrement comme SSL ou GPSS-API pour assurer la confidentialité et l’intégrité des échanges entre les communicants.

7.2.5. Filtrage des appels

Ce filtrage s’effectue par certains serveurs SIP sur la base de plusieurs règles bien précises un peu à la manière d’un firewall. Cela permet, par exemple, d’interdire certaines adresses IP ou URI d’émettent des messages INVITE ou REGISTER.

7.2.6. Sécurisation de la session SIP

Les mécanismes essentiels adoptés pour sécuriser une session SIP sont :

http basic authentication qui transmit le nom d’utilisateur et son mot de passe à l’intérieur de l’entête de la requête SIP, cette technique a été dépréciée par SIP puisque le mot de passe est transmis en claire.

http digest anthentication en utilisant un digest MD5 ou SHA-1 du mot de passe secret et d’une chaine de caractère aléatoire du mot de passe vulnérable uniquement.

Pretty Good Privacy utilisé pour authentifier et optionnellement chiffrer le paquet MIME (Multi purpose Internet Mail Extention) contenu dans les messages SIP, ce mécanisme a été déprécié en faveur de :

Secure MIME qui sécurise les contenus de MIME afin d’assurer l’intégrité et la confidentialité grâce aux types MIME multipart/signed et application/pkcs7-mime.

SIPs URI : en implémentant le protocole de chiffrement TLS sur la couche TCP. IPsec pour protéger les messages SIP au niveau IP en utilisant IPsec ESP

(Encapsulation Security Payload), AH (Authentication Header), ou IKE (Internet Key Exchange).

8. Problématique de la traversée du NAT et les Firewalls

8.1. La traversée du NAT

Comme nous venons de le voir, SIP est un protocole de signalisation de niveau applicatif, qui permet d’établir une communication multimédia entre des postes, à l’aide des différentes adresses IP et numéros de port implantés dans le corps du message SIP.


34

La technique NAT (Network Address Translation) défini dans le RFC 2663 [1], quant à elle, permet d’associer des adresses IP internes qui sont non routables à un ensemble d'adresses publiques (externes) qui sont routables. Ce mécanisme représente un vrai problème pour le protocole SIP et la ToIP en général, ce problème est appelé la traversée du NAT.

Premièrement, le NAT ne permet pas les appels entrants du coté public vers des destinataires dans le réseau privé [4, 33].

Deuxièmement, les NATs ne travaillent pas, en fait, au dessus des couches IP et TCP/UDP (c-à-d la couche 3, et 4) de modèle OSI, et ne modifient que les paramètres situés au niveau de ces couches. Autrement dit, les adresses IP contenues dans les messages SIP ne sont pas modifiées par les équipements NAT. Par conséquent, le destinataire (le client appelé) ne connaîtra que l’adresse privée du client appelant. Or celle-ci n’ayant de sens que dans le réseau privé, car n’est pas routable sur Internet, par conséquent, l’établissement de session de communication n’est pas possible [ 4, 7, 8, 10, 34, 33, 35].

Le schéma suivant (figure 17) explique le problème de NAT avec SIP :

Figure 17 : Exemple d'un problème du NAT avec SIP

Dans ce schéma, Mohamed ne parvient pas à établir une communication avec Anas tant que le serveur IPBX ne pourra pas relayer les réponses SIP de Anas. En effet, ceci est à cause de routeur NAT lors de la translation d'adresse, puisque le routeur NAT ne travaille qu’au niveau des couches 3 et 4, donc seuls l'adresse et le numéro de port contenus dans


35

l'entête du paquet IP sont modifiés (de 192.168.0.9 à 132.1.2.1 voir figure 17), mais l'adresse et le numéro de port contenus dans le corps de la requête INVITE du message SIP (192.168.0.9/5060) ne le sont pas et restés privés.

8.2. Problème des Firewalls

Un pare feu (firewall) est un équipement permettant le filtrage des paquets en provenance de réseau public en vue d’assurer la sécurité d’un site. Cependant, ce mode de fonctionnement (de la plupart des pare-feu) pose un problème pour l’établissement des communications SIP.

En effet, les pare feux rejettent tous les paquets qui ne sont pas destinés à une adresse IP et un port bien définis (connus), ces politiques statiques empêchent le passage de SIP et le flux de données entrant RTP déterminé par SIP qui négocie, lors de l’établissement de session, des numéros du port inconnus pour le pare-feu [4].

Pour bien comprendre la problématique engendrée par les pare feux pour les flux multimédias, voici le schéma d’un scénario d'établissement d'une session où le firewall bloque le contenu multimédia (figures 18, 19).

Figure 18 : La problématique des pare-feu.


36

Figure 19 : Corps de la requête INVITE et sa réponse OK

Dans cet exemple, Mohamed qui est derrière un pare feu utilise une adresse publique dans l'entête de message INVITE 194.214.126.10 (dans ce cas , le problème du NAT ne se pose pas). Mohamed envoie une requête d'invitation INVITE contenant les informations de la session à ouvrir à Anas. Anas répond avec le message 200 OK qui contient les informations supplémentaires sur la session à ouvrir.

Comme on peut le constater, Mohamed et Anas utilisent respectivement les ports 3456 et 5004 pour le flux de données dans la partie de SDP (Session Description Protocol) inclus dans les messages SIP : INVITE et OK. Mohamed dans la requête INVITE a spécifie le port 3456 pour le flux RTP (regarder sur la figure 19, le champs : m=audio 3456), et Anas dans la réponse OK a spécifie le port 5004 (le champs m=audio 5004). Puisque le pare feu a des règles de filtrage strictes et statiques, par conséquent, le contenu multimédia d’Anas sera tout simplement bloqué par le firewall (port 5004 inconnu).

9. Conclusion Le protocole SIP repose sur des bases saines et solides, lui permettant d’être adopté par les plus importants organismes d’internet et la ToIP, il possède des arguments et avantages qui plaident en sa faveur [29, 14, 15, 36] :

SIP dispose de mécanismes d’extensibilité, il hérite du mécanisme PEP (Protocol Extension Protocol) de HTTP permettant de définir des pointeurs documentant des caractéristiques complémentaires.

Un protocole souple, rapide, et bénéficie d’un héritage protocolaire issu du monde Internet. Il s’intègre simplement dans un réseau IP et profite d’une architecture


37

distribuée pour s’adapter facilement à la montée en charge d’utilisateurs au sein d’un réseau.

SIP étend même ses possibilités par de nouveaux protocoles qui s’appuient sur les fonctionnalités de SIP et ses capacités pour de nouvelles applications. C’est le cas du protocole SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) qui utilise SIP pour gérer la messagerie instantanée et la fonctionnalité de présence. SIMPLE est étudié au sein du groupe de travail IMPP (Instant Messaging and Presence Protocol) de l’IETF, et est soutenu par d’importants industriels, tels que Microsoft ou Lotus.

La mobilité est une notion centrale dans SIP : un même utilisateur peut être joint par différents moyens, par exemple à son domicile ou à son lieu de travail, ou encore sur son téléphone fixe, son téléphone portable ou son assistant personnel. En conservant une même identité, le protocole SIP détermine la localisation réelle de l’utilisateur : c’est la notion de personnal mobility.

Pour toutes ces raisons, SIP a aujourd’hui les faveurs des industriels et s’impose progressivement auprès des acteurs de la ToIP. Ainsi, des fournisseurs d’accès ADSL, tels que Free et Neuf Telecom, l’ont choisi pour assurer la signalisation de leur service de téléphonie IP. De même, Microsoft utilise SIP dans son serveur unifié de communications multimédias LCS (Live Communications Server).

Dans ce chapitre, nous avons vu une description du protocole SIP qui est destiné à la signalisation des usagers dans une session multimédia, et nous avons montré la problématique rencontrée avec ce protocole et les NAT/firewalls. Dans le chapitre suivant nous allons présenter les approches et les solutions proposées pour résoudre ce problème de la traversée du NAT.

Chapitre 3 Les solutions de la traversée du NAT

38

Chapitre 3

Les solutions de la traversée du NAT


39

1. Introduction

Face au problème de la traversée du NAT posé par les NATs et les Firewalls, plusieurs solutions ont été proposées. Celles-ci peuvent être regroupées en trois catégories suivant leur fonctionnement : les solutions basées sur le comportement du NAT, les solutions basées sur le contrôle du NAT, et les solutions combinant plusieurs techniques.

La catégorie des solutions basées sur le comportement du NAT englobe :

- Serveur d’application. - Simple Traversal Using UDP for NAT (STUN). - Traversal Using Relay NAT (TURN). - Proxy RTP. - Session Border Controller (SBC).

La deuxième catégorie des solutions ne se base plus sur le comportement du NAT pour faire la traversée des Firewalls ou les routeurs NAT par des flux multimédias, mais le principe adopté est basé sur le contrôle du NAT. Cette catégorie englobe :

- VPN (Virtual Private Network). - RSIP (Realm Specific IP). - MidCom (Middlebox Communications). - UPnP (Universal Plug and Play). - ALG (Application Layer Gateway).

Pour la troisième catégorie combinant plusieurs techniques, on trouve :

- ICE (Interactive Connectivity Establishement) qui combine STUN et TURN. - Le serveur d'application avec agent qui combine le serveur d'application et le VPN.

Ce chapitre est consacré à la présentation de ces différentes solutions, en introduisant d'abord le principe de fonctionnement, suivi par les avantages et les inconvénients de chacune d'elles. Nous avons commencé en premier temps par les solutions basées sur le comportement du NAT.

2. Les solutions basées sur le comportement du NAT

2.1. Serveur d’application

2.1.1. Principe

Le principe de cette solution est d'ajouter dans le réseau un serveur d'application qui sert à faire le relais entre les entités qui désirent communiquer [37]. Le serveur d’application peut être placé soit dans la partie privée de réseau [38] :


40

Figure 020 : Serveur d'application dans un réseau privé [38]

Comme il peut être placé dans la zone démilitarisée DMZ :

Figure 21 : Serveur d'application dans la zone DMZ [38].

2.1.2. Avantages

- Une solution simple. - Solution éprouvée et très utilisée actuellement. - Une solution qui ne demande aucune modification des éléments de réseau, des

applications ou des protocoles de communication.


41

- Cette solution permet la traversée de tous les dispositifs de sécurité et pour toutes les topologies de réseau.

- Pas de modification de la sécurité de réseau.

2.1.3. Inconvénients

- Solution nécessitant le déploiement et la maintenance d’un serveur. - Solution propriétaire et adapté à un protocole donné : le serveur proxy SIP pour le

protocole SIP, ce qui rend son évolution difficile. - Augmentation du temps de latence qui peut amoindrir de manière significative les

performances des applications multimédias.

2.2. Simple Traversal of UDP Through NAT devices (STUN)

2.2.1. Principe

Simple Traversal of UDP Through NAT devices, STUN est un standard développé par l'IETF, et énoncé dans la RFC 3489 [13].

STUN est un protocole permettant la traversée des routeurs NAT, en établissant des connexions UDP d’un poste sur un réseau privé vers un réseau public [39, 40, 41, 42].

L’intérêt de STUN est de découvrir et caractériser le NAT et les différents dispositifs de sécurité situés en aval du poste. Pour faire simple, le poste client situé en réseau privé derrière le NAT va tout d'abord se connecter au serveur STUN situé généralement en réseau public, en lui envoyant des requêtes. Le serveur STUN répond par un message indiquant l’adresse publique et le port de routeur NAT associé au réseau privé du poste client [43, 44, 35]. Le protocole STUN permet donc d’établir une équation logique entre le couple adresse IP/port privé et le couple adresse IP/Port publique [4, 5]. Ainsi, le poste client devient donc capable d'établir une communication multimédia puisqu'il connait les informations essentielles reçues de serveur STUN (l'adresse publique et le port du NAT) [6, 34]. dont il utilisera dans son message SIP envoyé à son interlocuteur afin que ce dernier puisse également les utilisées.


42

Figure 22 : Principe de STUN

Plusieurs problèmes liés à la traversée des NAT peuvent être résolus par ce protocole. Cependant Les seules limites sont la traversée des Firewalls, des routeurs NAT symétriques et des chaines de routeurs NAT [44].

En effet, le comportement des routeurs Nat symétriques est quasi impossible à prédire et empêche également l’ouverture des sessions. Puisque les NATs symétriques établissement un chemin en fonction de l’adresse IP de l'appelant et de son port d’accès mais aussi en fonction de ses mêmes fonctions chez le destinataire appelé, donc le chemin ainsi créé échappe au serveur STUN [37, 40].

De plus, la traversée des Firewalls est impossible car les messages de découverte lancés par STUN sont symétriquement filtrés et alors peuvent être perçus comme des tentatives d’attaque [35].

2.2.2. Avantages

- Protocole standardisé. - Aucune modification de l’architecture de réseau. - Déploiement d’un seul serveur uniquement pour effectuer les requêtes.


- Solution nécessitant l'adaptation des applications au protocole STUN. - Ne permet pas la traversée des firewalls. De plus, les requêtes et les réponses peuvent

être interprétées comme des attaques par les firewalls. - Ne permet pas la traversée des chaines des routeurs NAT.


43

- Ne peut être utilisé en association avec les ALGs car elles modifient les adresses dans les messages SIP.

- Ne fonctionne pas avec les NATs symétriques.

2.3. Traversal Using Relay NAT (TURN).

2.3.1. Principe

Traversal Using Relay Nat, TURN, est une solution proposée par l'IETF (RFC5766) [45] pour résoudre les problèmes de traversée des routeurs NAT symétriques et des Firewalls [4, 5].

Pour pallier au problème des NATs symétriques, il faut utiliser un relais possédant une adresse IP publique situé soit sur une DMZ ou bien sur Internet.

Cette solution permet donc à des clients qui sont dans des réseaux privés utilisant des routeurs NAT d'effectuer des connexions entre eux en passant par un serveur de relais inséré dans le flux des données multimédias et des flux de signalisation [6, 40, 34].

Le protocole TURN se base ainsi sur le protocole STUN par exemple pour le partage de clé de cryptographie et l’authentification du serveur et du client. ensuite, le client SIP envoie un paquet d’exploration au serveur TURN qui va répondre avec l’adresse IP public et le port public du routeur NAT utilisé pour cette session. Le client utilise dès lors ces informations pour communiquer avec le serveur TURN qui lui prend place de relais pour le protocole SIP et le flux Média [38, 35, 41, 46].

L’avantage de cette solution est que l’adresse de destination vue par le routeur NAT ne change pas puisqu’on ne s’adresse jamais directement au destinataire mais toujours au serveur TURN avec lequel on a négocié pour découvrir son mapping. L’adresse révélée reste valable (car on s’adresse toujours à la même machine) et peut ainsi être utilisée avec un NAT symétrique [37, 39].

Le destinataire quant à lui va répondre uniquement au serveur TURN car c'est lui qui prend place de client et relaye les informations. Cependant, cette solution est peu stable puisqu’on rajoute un intermédiaire sur le flux média ce qui créé des temps de latence dans des communications.


44

Figure 23 : Principe de TURN

2.3.2 Avantages

- Technique simple à comprendre et à déployer. - Aucune modification sur le réseau. - L'intégrité de réseau est conservée. - Solution totalement indépendante des protocoles de communication. - La traversée des routeurs NAT symétriques devient possible.


- Nécessite le déploiement et la maintenance d’un serveur. - Nécessite la configuration des postes clients pour qu’ils puissent intégrer TURN. - Impossible de gérer la qualité de service et augmenter la sécurité sur le point d’entrée

car ces informations ne sont pas révélées au serveur TURN par le protocole TURN et qui ne va sûrement pas être adoptée par les fournisseurs d’accès.

- Latence accrue due à la transmission indirecte des données (après un message d'exploration).

- On ne peut pas toujours dialoguer entre utilisateurs situés derrière le même NAT. - Le fait que le destinataire soit situé lui-même derrière un NAT rend toujours la

communication impossible. - Les clients SIP doivent toujours être mis à jour.


45

2.4. Proxy RTP

2.4.1. Principe

Cette solution résout le problème de la traversée du NAT avec SIP en utilisant MGCP comme protocole de commande entre le proxy SIP (dans lequel un agent d'appel MGCP est intégré) et le proxy RTP permettant ainsi le trafic RTP entre les réseaux interconnectés [47]. En terminant toutes les sessions multimédias dans le proxy RTP qui se situe dans une DMZ, et en reliant de ce point les paquets RTP à leurs destinations finales, la figure 24 illustre l'architecture de cette solution.

Figure 24 : Architecture de proxy RTP [47]

Des règles de filtrage de paquets dans les firewalls doivent être ajoutées afin de permettre le passage des paquets UDP destinés au proxy RTP, ainsi que les paquets émis par le proxy RTP de quitter la DMZ.

Le rôle de proxy SIP est de contrôler le proxy RTP en utilisant les messages SIP reçus de telle sorte que tous les ports RTP d’une session multimédia soient ouverts/fermés.

Le proxy RTP quant à lui, quand il reçoit un message SIP de la part de proxy SIP, il analyse la partie SDP et ouvre/ferme les ports correspondants, puis renvoi un nouveau message SDP au proxy SIP contenant les adresses et les ports utilisés par le proxy RTP pour la session actuelle. le proxy SIP copie ce message dans un message SIP et le fait suivre au récepteur correspondant.

L'agent d'appel intégré dans le proxy SIP, et le proxy RTP mettent en application la partie serveur du protocole qui utilise le port de MGCP 2427, et ainsi le proxy SIP pourra


46

copier la partie SDP des messages SIP grâce aux commandes de MGCP envoyées au proxy RTP.

La figure 25 présente un exemple d'ouverture d'une session SIP par cette solution

Figure 0 : Exemple d'invitation à une session SIP [47]

2.4.2. Avantages

- Solution simple à comprendre. - commodité d’utiliser MGCP puisqu’il utilise, juste comme SIP, le SDP en tant que

protocole de description de session.


- Nécessite l'ajout d' un proxy RTP qui doit répondre à des besoins spécifiques. - Cette solution pose des problèmes de sécurité. - Le temps de latence qui augmente.


47

- Nécessite la modification ou l'ajout de quelques règles au niveau des Firewalls.

2.5. Session Border contrôler (SBC)

2.5.1. Principe

Le but d’un contrôleur de session (SBC) est de permettre la communication interactive à travers les frontières de différents réseaux IP. Cet équipement peut travailler soit devant les firewalls et les NATs, soit tout seul. Le SBC traite non seulement le trafic SIP, mais également le trafic média. En plus des fonctions permettant de traverser les NAT, il peut également être comme un contrôleur de sécurisation ou Gateway [48, 49, 50].

La plupart des ISPs (internet service Provider) utilise une sorte de SBC pour effectuer un ensemble de taches liées à leur services SIP, ils peuvent utiliser STUN, TURN, ICE (décrit ultérieurement) pour en faire, en agissant en tant que composant de serveur pour ces protocoles [4, 29, 34].

Du point de vue médias, SBC agit comme 'B2BUA' (Back to Back User Agent), tandis que du point de vue signalisation, il peut aussi agir comme un proxy SIP. En pratique, SBC 'représente' l'utilisateur dans le réseau public en lui fournissant une adresse IP public à travers laquelle il peut l'atteindre, même derrière un NAT [34].

Cependant, SBC peut également utilisé la technologie FENT (far end NAT Traversal) pour la traversée du NAT [43].

La fonction de FENT aide les clients SIP distants en transformant n'importe quel message SIP en réécrivant les information appropriées, et elle maintient, aussi bien, le client accessible sur un réseau situé derrière un NAT.

Typiquement, cette solution (FENT) est mise en application en envoyant d'une manière continue des paquets (factice) via le firewall afin de laisser des trous d'épingle ouverts et permettant ainsi le passage de médias. la FENT peut être également mise en place en demandant au client de se réenregistrer dans des intervalles courts pour maintenir ces ports disponibles [43]. Cette solution fonctionne seulement avec les firewalls qui sont ouverts de l'intérieur, et peut ne pas fonctionner avec tous les équipements et dans tous les scénarios d'appel. FENT est plus adapté pour des mobiles, plutôt qu'à l'endroit fixe où il y a des solutions plus fiables et plus sécurisées.


48

3. Les solutions basées sur le contrôle du NAT

3.1. Tunnel de données

3.1.1. Principe

Cette technique consiste à déployer des réseaux privés virtuels (RPV ou VPN en Anglais) à l’aide des protocoles IPsec, PPTP ou L2TP. Tous les postes concernés par les sessions multimédias se retrouvent au sein d’une même VPN et appartiennent au même réseau logique. Ainsi chacun peut effectuer des communications poste à poste sans contrainte. Cette technique permet aux flux multimédias d’être acheminés dans un tunnel de données (comme en local) afin de traverser les Firewalls et les NATs [37, 38].

Figure 26 : Principe de tunnel de données [38].

3.1.2. Avantages

- Le VPN est une technologie bien connue et largement utilisée. - Peut être utilisée sur tous types d’architecture. - Déploiement sans modification des équipements réseaux. - Facile à déployer sur des réseaux multi-sites.


49


- Apporte une difficulté supplémentaire à certains utilisateurs due à la nécessité de créer un VPN avant toute communication.

- Un niveau de maintenance plus élevé.

3.2. Universal Plug and Play (UPnP)

3.2.1. Principe

Ce nouveau standard de communication est porté et élaboré par un consortium dont font partie Intel et Microsoft. Il est destiné aux petits réseaux d’entreprises ou aux résidentiels (SOHO : Small Office Home Office) [37, 43].

Universal Plug and Play est plus qu’une extension du célèbre Plug and Play destiné aux périphériques [51]. Son principe est de permettre une configuration automatique des différents équipements réseaux et offrir des services à la fois dynamiques et transparents aux postes de travail [9, 34, 42].

De ce fait, les postes de travail détectent automatiquement le Firewall et le routeur NAT de réseau local, et ouvrent dynamiquement des trous d’épingles dans le Firewall ou dans le routeur NAT [52, 53], et cela sans authentification ni validation [54].

Néanmoins, UPnP impose une restriction évidente : Les communications UPnP ne peuvent s’effectuer qu’au sein d’un même réseau local [web-1].

3.2.2. Avantages

- Convivialité et transparente interaction des protocoles. - Transparence pour l’utilisateur. - Standard existant et déployé sur les réseaux SOHO. - Périphériques compatibles UPnP déjà existants sur le marché.


- Nécessite la modification des applications pour permettre un dialogue avec les équipements UPnP.

- Les Firewalls et les routeurs NAT doivent supporter UPnP. - Failles de sécurité créées par les trous dynamiques sans authentification initiées par

UPnP.


50

3.3. Passerelle de couche applicative (ALG Application Layer Gateway)

3.3.1. Principe

Le problème lié aux routeurs NAT est qu’ils ne sont pas en mesure de remonter les couches hautes du modèle OSI, le filtrage est restreint au niveau de la couche 3. C’est pourquoi, une solution au problème, est de les rendre intelligents et capables de filtrer non plus au niveau 3 mais au niveau 7 (couche applicative), et ils auront ainsi la capacité d’interpréter un protocole spécifique. C’est la passerelle de la couche application ou Application Layer Gateway (ALG) qui permet cette analyse des données jusqu’à la couche application [4, 32, 33, 42, 55]. Cette passerelle réalise une inspection complète des données dans le corps du paquet plutôt que de vérifier uniquement l’entête du paquet à traiter [37]. C’est là la principale différence entre la passerelle de la couche application et les routeurs NAT et les Firewalls qui sont pas en mesure de modifier le contenu du message mais modifier simplement l’entête. Par exemple, la passerelle peut vérifier que tout le trafic circulant sur le port 80 est bien le protocole http est non pas une encapsulation sur le port 80.

Les passerelles agissent donc en tant que relais spécialisés pour un protocole précis (SIP par exemple dans notre cas).

En effet, la passerelle va lire le contenu complet du paquet et modifier ses adresses IP et ports inscrits pour le rendre valide dans le réseau public. Ensuite elle sera en mesure de laisser circuler librement les paquets en ouvrant un trou d’épingle permettant des communications sans obstacles [38].

Attention à ne pas confondre serveurs application cités précédemment et passerelles de la couche application :

Une ALG est embarquée sur un routeur NAT ou sur un firewall, souvent, le même dispositif combine des fonctions de firewall/ALG et NAT.

Le filtrage est effectué dans le premier cas par les serveurs d’application alors que dans le second cas, ce sont les pare-feux/routeurs NAT qui se chargent d’effectuer le traitement.


51

Figure 27 : Principe de ALG [38].

3.3.2. Avantages

- Technique simple. - Pas d’élément supplémentaire à gérer. - Solution la plus sécurisante et la plus sécurisée.


- Passerelle limitée et spécifique à un protocole. - nécessite la modification des éléments réseaux : les firewalls et les NATs. - engendre un problème pour l’évolution vers de nouveaux protocoles de communication

car bornée par les ressources limitées des routeurs NAT et les Firewalls. - Consommation des ressources sur les équipements. - Un temps de latence long du à la décapsulation des paquets jusqu’à la couches haute du

modèle OSI.

3.4. Realm Specific IP (RSIP)

3.4.1. Principe

RSIP est un serveur de sécurité qui assure l’intégrité de bout en bout des messages en profitant de son architecture client/serveur. Ce protocole est utilisé également pour caractériser la fonctionnalité d'un ensemble d’adresses privés converti en un ensemble d'adresses publiques, afin de permettre aux équipements d'un réseau interne de communiquer avec l’extérieur, voir les figures 28, 29.


52

Un client RSIP est un nœud dans un réseau privé qui a une adresse dans un ensemble d’adresses externe, ce client assure une transmission bout à bout en se reliant aux serveurs dans ce réseau.

Les serveurs produisent des paquets sur l'une ou l'autre extrémité dans une telle installation qui seraient basés sur les adresses qui sont seules celle du bout à bout dans le réseau externe et n'exigent pas la traduction par un processus intermédiaire. Ces paquets peuvent être lancés par un client RSIP, ou être envoyés vers un client RSIP.

Un serveur de RSIP est un serveur implanté dans un nœud des deux réseaux privés et externes, celui peut faciliter le routage des paquets externes.

Un serveur RSIP peut également être le même nœud qui assigne des adresses externes aux clients RSIP [32]. En effet, Il y a deux variations de RSIP, à savoir IP Realm-Specific Address (RSA-IP) et IP Realm-Specific Address and Port (RSAP-IP) [1].

Figure 28 : Principe de RSIP.

Figure 29 : RSIP tunnel

3.4.2. Avantages

- Solution simple à comprendre et à mettre en place. - RSIP offre la possibilité d’utiliser le chiffrement et l’authentification, ce qui n'est pas

permet pour le NAT, ceci est un avantage qui facilite le passage d’une version SIP à une nouvelle.


53


- RSIP ne dispose pas d’une fonction de test qui permet de valider les messages qui sont correctement formés.

- Cette solution engendre un temps de latence qui augmente.

3.5. Middlebox Communication (MidCom)

3.5.1. Principe

MidCom est un standard qui consiste à rendre les Firewalls et les routeurs NAT intelligents et plus contrôlables [32, 38] en permettant des communications et des flux multimédias à travers un trou d’épingle (pinhole) crée de façon dynamique après une authentification et une validation du client [4, 56, 57].

Figure 30 : Principe de MidCom [38].

Le principe de MidCom est différent de celui des ALG et UPnP. Il diffère de ALG car il ne va pas analyser le protocole de communication jusqu’à la couche application. Il reprend le principe de UPnP mais il en diffère également par la mise en œuvre d'un mécanisme sécurisé d’authentification et de contrôle d’accès avant d’ouvrir un trou d’épingle [58, 59].

Cependant, la limite de cette solution concerne la traversée d’une chaine de firewalls ou de routeurs NAT qui n’est pas enlevée.

3.5.2. Avantages

- MidCom n’est pas lié à un protocole de communication précis. - Pas de lacune de sécurité grâce au mécanisme d'authentification et de contrôle d'accès

des utilisateurs.


54


- MidCom ne permet pas la traversée d'une chaine de Firewalls ou de routeurs NAT. - Nécessite la modification des routeurs NAT et des Firewalls. - Nécessite l'adaptation des protocoles de communication pour les rendre intelligibles

par les équipements MidCom.

4. Les solutions combinant plusieurs techniques

4.1. Interactive Connectivity Establishement (ICE)

4.1.1. Principe

Interactive Connectivity Establishement est une technique (développée par l'IETF) qui consiste à combiner STUN et TURN et les intègre au sein des clients SIP [4, 6, 37]. Le service offert par ICE est la détermination de toutes les connections possible entre 2 postes [43].

Le principe de ICE se déroule en 3 phases:

Tout d’abord, le client, situé dans un réseau privé, envoi des requêtes STUN vers un serveur STUN/TURN. Le serveur génère, par la suite, une liste d’adresses par lesquelles les 2 postes peuvent être contactés. Enfin, le serveur sélectionne la meilleure communication possible entre les 2 postes; si aucune communication directe n’est possible, le serveur se servira des services TURN pour permettre l'établissement de cette communication [34, 39, 40, 35, 41].

ICE permet la traversée de bon nombre d’équipements dans toutes les topologies, même les chaines de routeurs NAT, mais malheureusement, il ne permet pas la traversée des firewalls malgré qu'il peut identifier et caractériser ses règles mises en œuvre.

4.1.2. Avantages

- Aucune modification de l’architecture de réseau. - La politique de sécurité du réseau est conservée. - Le déploiement d’un seul serveur uniquement. - permet la traversée de tous type de NAT.


- Nécessite l'adaptation des applications aux protocoles STUN et TURN. - Le temps de l’établissement et de la communication est long. - Ne permet pas la traversée des Firewalls, et les requêtes et les réponses peuvent être

interprétées comme des attaques par les firewalls.


55

- L'utilisation en association avec des passerelles applicatives n'est pas possible car les ALGs modifient les adresses dans les paquets SIP.

- Les communications STUN et TURN se partagent le même port, ce qui mène à l'utilisation d'un démultiplexeur.

- Nécessite la modification des serveurs et des clients pour le déploiement.

4.2. Serveur d’application avec agent

4.2.1. Principe

Cette solution est combinaison une entre le serveur d'application et le VPN. En effet, elle consiste à reprendre la solution décrite précédemment (serveur d’application) avec l'ajout d'un agent dans le réseau privé [38]. Le serveur d'application est maintenant couplé à un agent, de manière que la communication s’effectue en premier temps entre le poste du réseau privé et l’agent, puis entre l’agent privé et le serveur d’application, et enfin entre le serveur d’application et le poste public.

Le rôle de l’agent et le serveur d’application consiste à créer un tunnel de données (VPN) dans lequel transiteront les différentes communications établies entre postes de travail du réseau public et du réseau privé, à travers une plage de ports prédéfinie et autorisée sur le pare feu et le routeur NAT.

De cette manière, tous les dispositifs de sécurité sont conservés (pare-feu, cône plein, cône restrictif, cône restrictif sur les ports, symétrique) ainsi que toutes les topologies (réseaux public, interne, interne avec accès au réseau public, réseau avec chaîne de pare-feu ou de routeurs NAT) ce qui permet donc d’avoir un modèle polyvalent pour les différents services. Le serveur peut donc être accessible par un grand nombre d’utilisateur tout en offrant le même niveau de sécurité au niveau des réseaux privés [37].

Figure 31 : Principe de serveur d'application avec agent [38].


56

4.2.2. Avantages

- Cette solution permet à un grand nombre d’utilisateurs d'accéder au serveur étant donné qu'il est placé sur le réseau public.

- Cette solution traverse tous les dispositifs de sécurité et toutes les topologies réseaux. - Offre un modèle polyvalent pour les différents services.


- La solution nécessite le déploiement et la maintenance d’un serveur ainsi que : - Le déploiement et la maintenance des agents. - La solution est propriétaire et spécifique à un protocole. - Le temps de latence qui augmente du fait de la multiplication des dispositifs.

5. Synthèse

Plusieurs techniques existent, mais aucune méthode ne s'adapte dans toutes les situations puisque le comportement du NAT n'est pas standardisé. Due à la complexité du problème et la variété de topologies existantes, différentes solutions peuvent être appliquées pour différents cas : par exemple, si le réseau privé doit être isolé, un VPN, fournissant la fonctionnalité NAT et assurant la qualité de service approprié, est l'option la plus simple à déployer.

Beaucoup de techniques parmi ces solutions exigent l'assistance d'un serveur à un adresse IP routable publique. Quelques méthodes utilisent le serveur seulement en établissant la connexion, alors que d'autres l'utilise pour la transmission de toutes les données, ce qui ajoute des coûts de bande passante et augmente la latence, et est nuisible à la voix en temps réel et aux communications visuelles.

STUN fournit un moyen de traversée du NAT pour SIP en permettant à un client SIP d'obtenir une adresse IP publique et un numéro de port qui peuvent être utiles pour la réception des paquets SIP, cependant, ces adresses obtenues peuvent être inutilisables par quelques postes, ces adresses fonctionnent de manière dépendante des conditions de réseau, ainsi STUN ne peut pas fournir une solution complète pour la traversée du NAT. Une solution complémentaire requiert un moyen par lequel un client peut obtenir une adresse routable de ce qu'il peut recevoir des médias de n'importe quel pair qui peut envoyer des paquets à l'Internet public. Ceci peut être réalisé par le relais de données en utilisant un serveur qui réside en réseau public, cette spécification décrit TURN. Ce dernier malgré qu'il fournit souvent la connectivité à un client, mais avec un cout élevé au fournisseur de serveur TURN, c'est pour cette raison, il est désiré d'utiliser TURN seulement comme une dernière issue, en préférant autres mécanismes si possible. Pour accomplir cela, ICE peut être utilisé pour la découverte du moyen optimal de connectivité, mais les points faibles de cette dernière


57

solution résident dans sa complexité, sa latence, et son incapacité de la traversée des pare-feu puisque ses requêtes sont perçus comme des tentatives d'attaque par ces derniers.

La plupart des solutions basées sur le comportement du NAT dévient des politiques de sécurité d'entreprise. Les experts en matière de sécurité d'entreprise préfèrent des techniques qui coopèrent explicitement avec les NATs et les firewalls, et permettant la traversée du NAT tout en imposant des politiques de sécurité d'entreprise. De ce point de vue, les normes d'IETF les plus prometteuses sont RSIP et MidCom vu qu'ils sont plus avantageux par rapport aux autres solutions. Ces deux approches sont caractérisées par leur principe simple, leur capacité de traverser tous les types de routeurs NAT et pare-feu, ne sont pas spécifiques à un protocole de communication précis, et fournissent un niveau de sécurité plus élevé.

Cependant MidCom est plus prometteuse par rapport à RSIP puisqu'elle n'engendre pas un temps de latence long comme il le fait RSIP, mais ne présente pas une solution parfaite étant donné qu'elle ne peut pas effectuer la traversée d'une chaine de routeurs NAT (appelé NAT cascadé) et nécessite une modification au niveau des pare-feu et routeurs NAT, ainsi qu'au niveau des serveurs et des applications.

6. Conclusion

Dans ce présent chapitre, un tour d’horizon est effectué sur les différentes approches déjà mises en place pour pallier à la problématique de traversée des NATs et pare-feu. Ces solutions (dont la liste n'est pas forcément exhaustive) ont été divisé en trois groupes : le premier regroupe celles basées sur le comportement du NAT, tandis que le deuxième englobe celles basées sur le contrôle du NAT, et le dernier regroupe les solutions combinant plusieurs approches.

En conclusion, il n’existe pas de solution parfaite dépourvue d’inconvénients, s'adaptant dans toutes les situations et prenant en compte toutes les contraintes posées, mais simplement diverses bases de travail plus ou moins performantes, nécessitant plus ou moins de développement en fonction des besoins de la ToIP, la topologie du réseau, et les éléments de sécurité.

En définitive, une solution solide et performante doit être : simple, rapide, capable de traverser tous les types du NATs et de Pare-feu même s'ils sont implémentés en cascade, maintient (au moins) ou fournit un niveau de sécurité élevé. La solution, ne doit pas être liée à un protocole précis, ne nécessite pas de grandes modifications des équipements de réseau, et enfin requiert un bas niveau de maintenance.

Dans le chapitre suivant, une présentation détaillée de la solution la plus prometteuse sera effectuée, qui s'agit du protocole NATFW NSLP de la plateforme NSIS.

Chapitre 4 Présentation de la plateforme NSIS et du protocole NATFW NSLP

58

Chapitre 4

Présentation de la plateforme NSIS et du protocole NATFW NSLP


59

1. Introduction

Avec l'augmentation phénoménale du trafic de données en temps réel due à l'utilisation accrue des services multimédias et l'évolution du web, les technologies mises en place dans Internet ont rencontré diverses contraintes. En effet, l’utilisation d’un protocole de signalisation extensible et sécurisé qui peut répondre à ces besoins grandissants dans le temps s’avère nécessaire. Pour cela, la plateforme NSIS constitue une initiative majeure de l'IETF dans cette direction. Il s'agit d'un ensemble d'outils et protocoles de signalisation IP fournissant des moyens pour établir et gérer les états de contrôle du réseau le long d'un chemin de données entre deux nœuds communicants sur Internet.

Après avoir effectué un tour d’horizon sur les solutions développés ainsi que les travaux réalisés pour permettre au protocole SIP de traverser les routeurs NATs et les pare-feu, notre choix s’est porté sur la plateforme NSIS (Next Step In Signaling), au vu des modules qui la constituent et de leurs diverses fonctionnalités (ce sera développé dans la suite du chapitre).

Dans ce chapitre nous allons tout d’abord présenter la plateforme NSIS, et nous enchainerons sur une étude détaillée du protocole NATFW NSLP (NAT FireWall Nsis Signaling Layer Protocol), les deux ayant été développés par le groupe de travail NSIS. Ensuite, nous allons aborder une présentation des menaces auxquelles le protocole NATFW NSLP peut être soumis. Nous effectuerons enfin, un tour d’horizon des travaux déjà réalisés dans ce contexte, en présentant l'objet d'autorisation de session.

2. Le groupe de travail NSIS et la plateforme NSIS

Le protocole Resource Reservation Protocol (RSVP), a été conçu il y a plusieurs années [60] afin de répondre à un besoin de qualité de service (QoS) sur Internet. Il a été développé et appliqué à la réservation de ressources dans les réseaux qui offrent des services intégrés (IntServ), c’est avant tout un protocole de signalisation qui permet de réserver dynamiquement de la bande passante, et de garantir un délai, ce qui le rend particulièrement efficace pour des applications comme la VoIP. Cependant, face à la diversité croissante des services offerts sur Internet, les limitations du protocole RSVP sont apparues comme par exemple, le nombre d’états à maintenir et qui devient conséquent, engendrant la dégradation des performances du réseau, ce qui en fait un protocole adapté plus aux réseaux de petite taille. Afin de pallier à cela et de répondre à l’explosion de la taille des réseaux, la plateforme de signalisation NSIS a été développée.

Le groupe de travail NSIS a été fondé en novembre 2001 en tant que IETF groupe (Internet Engineering Task Force), avec l’objectif principal d'élaborer un standard de signalisation et d’exploiter dans la mesure du possible les mêmes mécanismes de signalisation relatives au protocole RSVP tout en gardant sa simplicité et en prenant en


60

charge ses limitations. La plateforme NSIS a été conçue de façon à devenir un standard pour une prochaine génération de protocoles de signalisation.

Dans le but de supporter la signalisation dans différents contextes (par exemple la QoS, la traversée du NATs et des pare-feu), la plateforme NSIS a été implémentée en une architecture sur deux couches afin que les applications de signalisation et leur transport puissent être séparés.

La première version de l’implémentation de la plateforme NSIS, validée par le groupe de travail NSIS [web-2] a consisté en un protocole de signalisation amélioré et optimisé lié à la QoS [61, 62], qui a été exploité dans diverses situations [web-3, web-4, web-5], d'abord sous le nom de CASP (Cross Application Signaling Protocol) [63], puis rebaptisé GIST [64, 65]. Dans la seconde version de NSIS, un nouveau module est intégré, appelé NATFW NSLP (NAT FireWall Nsis Signaling Layer Protocol) [66] qui consiste en un protocole permettant la traversée des NATs et des pare-feux. La description détaillée de ce protocole fera l’objet de ce chapitre.

2.1. Le modèle en couches de NSIS

Le protocole de signalisation NSIS fonctionne au-dessus de la couche IP, il a été développé sous forme modulaire pour être générique et extensible, et pour cela son architecture est structurée en deux couches :

o La couche application de signalisation (NSLP : NSIS Signaling Layer Protocol) : couche supérieure conçue pour contenir les applications de signalisation et dispose de deux points d'interaction, d'un côté avec la couche NTLP et de l'autre côté avec l'application appropriée, ne faisant pas partie de NSIS. Ainsi, cette couche est chargée d'implémenter et de définir des fonctionnalités spécifiques à l'application de signalisation, telles que les formats de message et des séquences (génération des messages et des requêtes de réservation de ressources ainsi que l'ouverture de trous d'épingle). Il y a eu plusieurs travaux d’application de NSLP avec la QoS NSLP pour la réservation de ressources [62], pour le NATFW NSLP [66] et le Metering Configuration Signaling NSLP [67].

o La couche transport de signalisation (NTLP : NSIS Transport Layer Protocol) : couche inférieure conçue afin d’interagir avec la couche IP d'un côté et avec les différents types de NSLP d'un autre côté. Son rôle est de transporter les messages de signalisation de la couche application entre les nœuds NSIS adjacents en utilisant le protocole GIST (General Internet Signaling Transport) [64]. De plus, cette couche permet l'échange d'autres informations de contrôle, telles que les messages d'erreur et les messages de changement de chemin. GIST constitue le composant de base de cette couche, lorsqu'il reçoit un message de la couche supérieure NSLP, ses principales fonctions consistent à déterminer comment atteindre le nœud NSIS adjacent, comment sélectionner le protocole de transport approprié (UDP, TCP, SCTP ...etc.) et comment


61

transmettre les données au protocole de transport sélectionné. D’autre part, quand GIST reçoit un message de la couche inférieure (sous-jacente), il détermine si le message doit être transmis à la couche NSLP ou bien au prochain nœud. La couche IPLS ( IP Layer Security) correspond à un protocole de sécurité implémenté sur IP, tel que le protocole IPsec.

Une schématisation des composants de la plateforme NSIS est donnée sur la figure 32.

Figure 32 : Les composants de NSIS

2.2. Le concept fondamental de la signalisation de NSIS

2.2.1. La notion d'état des systèmes de signalisation dans les réseaux IP

NSIS a été conçu en vue de supporter différentes applications de signalisation nécessitant d'installer et de manipuler des états au niveau des nœuds du réseau [68]. Ces états appartiennent à un certain flux de données et sont installés et manipulés sur toutes les entités NSIS (NE : NSIS Entity) le long du cheminement de ce flux de données.


62

En général, pour les systèmes de signalisation dans les réseaux IP, deux approches d'état peuvent être identifiées [69] : l'approche état à court terme (soft state) et l'approche état à long terme (hard state).

Dans le cas du soft state, l'état est installé par l'initiateur, puis il est rafraichi périodiquement par des requêtes explicites, sinon l'état est enlevé automatiquement et immédiatement à la fin du délai (timeout) au niveau du porteur de l'état. Cette approche est adoptée par plusieurs protocoles tels que RSVP, SIP, SRM (Scalable Reliable Multicast), IGMP (Internet Group Management Protocol), PIM (Protocol Independant Multicast).

En revanche, dans la deuxième approche (hard state), au contraire, l'initiateur installe et enlève les états avec des messages explicites. Par conséquent, l'état n'est supprimé qu'avec une requête explicite envoyée par l'initiateur aux autres nœuds du réseau et dans ce cas, il n’y a pas la notion de rafraichissement ni de délai pour l'enlèvement des états ; ST-II et Q.2931b sont parmi les protocoles qui ont adopté cette approche [69].

Des résultats [69] comparatifs entre les deux approches, montrent que le soft state améliore la cohérence d'état à l'ajout des messages de signalisation supplémentaires, et que l'ajout des messages explicites fiables de setup/mise à jour/ suppression permettent en outre à l'approche soft state d'atteindre une cohérence comparable si ce n’est meilleure que l'approche hard state.

Dans la plateforme NSIS (GIST, QoS et NATFW NSLP) l'approche état à court terme a été adoptée pour gérer les états dans les différents nœuds. Un état à court terme est créé et actualisé périodiquement par un message de rafraîchissement. Si aucun message de rafraîchissement pour une session n’arrive avant l'expiration du délai, l'état sera automatiquement supprimé, comme il peut l’être par un message de suppression explicite.

2.2.2. Relation entre les nœuds du réseau en présence de la signalisation NSIS

Cette section décrit les entités fondamentales, dans lesquelles la signalisation a lieu, ainsi que les interfaces intermédiaires. Une entité NSIS (NE) est un élément de réseau (hôte ou routeur) qui prend en charge le protocole NSIS et peut jouer l'un des rôles suivants :

Initiateur : l'entité NSIS qui initialise la signalisation (émetteur) et met également en place (et/ou manipule) les états du réseau.

Répondeur : l'entité NSIS où se termine la signalisation (récepteur). Intermédiaire (Forwarder) : l'entité NSIS située entre l'initiateur et le répondeur.

Cette entité permet de propager les messages de signalisation NSIS à travers le réseau depuis l'initiateur vers le répondeur, et dans le sens inverse.


63

Les nœuds adjacents du réseau ne doivent pas être forcément tous des NEs [67] (voir figure 33), dans ce cas, un nœud non NE sera ignoré dans le processus de découverte des pairs, ce processus est déclenché lorsqu'il n'y a pas encore de pairs GIST (ou NSIS).

Figure 33 : Exemple du cheminement des flux de signalisation et de données

La figure 33 montre un exemple de configuration de signalisation basique. Le flux de données dérive d'une application de l'émetteur (initiateur) à travers différents routeurs vers le récepteur (répondeur). Les hôtes (émetteur, récepteur) et les deux routeurs sont des NEs qui échangent des messages de signalisation liés au flux de données. Le routeur R3 n'est pas un NE et ne sert qu’à transmettre les données. L'échange des messages de signalisation est bi-directionnel.

2.2.3. Relation entre les entités NSIS

Le concept de base du protocole NSIS est indépendant de l'application de signalisation. Les nœuds NEs peuvent ne supporter qu’une application de signalisation (exemple la QoS) mais pas forcément toutes les applications de la couche NSLP. On peut distinguer deux types de relations entre les entités NSIS :

- Un pair NSIS/GIST : deux entités NSIS voisines (adjacentes) sont appelées pair NSIS ou pair GIST (voir la figure 34).

- Un pair (NATFW/QoS) NSLP : Deux entités NSIS sont appelées pair NATFW NSLP (ou QoS NSLP) lorsqu'elles supportent la même application de signalisation (NATFW ou QoS).


64

Figure 34 : Relation entre les entités NSIS

2.2.4. Relation et interaction entre la couche NTLP et la couche NSLP

Les fonctionnalités au sein de la couche NTLP n’étant limitées que pour le transport et les opérations relatives à la couche inférieure, d'autres opérations sont alors confiées à la couche application NSLP. Lorsqu'un message de signalisation est créé par la couche NSLP et se trouve prêt à être envoyé, la couche NSLP l’envoie à la couche NTLP avec une information décrivant à quel flux de signalisation il appartient. La couche NTLP se charge par la suite de la façon d'envoyer le message à la couche NTLP analogue du NE suivant, sur le chemin, et de proche en proche jusqu'à la fin du trajet. L'avantage essentiel de la couche NTLP est qu’elle n’a pas connaissance de tous les NEs situés sur le chemin, mais connait seulement ses pairs (adjacents).

Chaque NTLP intermédiaire qui reçoit un message, le transmet directement au nœud NSIS suivant, mais si l'application de signalisation s'exécute localement, elle le passe à la couche NSLP pour un traitement ultérieur.

Après le traitement, la couche NSLP peut utiliser le message d'origine transmis ou bien générer un autre message (de réponse ou d’erreur) pour le transmettre à la couche NTLP. Ainsi s’effectue la transmission du message de bout en bout.

La restriction de la couche NTLP à une relation de pair entre les NEs adjacents, simplifie d'un côté, la gestion et la complexité de la couche transport, mais d'un autre côté, elle augmente la complexité de la couche de signalisation NSLP. Les messages NTLP se composent d'un en-tête commun pour tous les messages, et un nombre variable d'objets TLV (Type-Length-Value). Chacun de ces objets se compose lui même d'un en-tête commun (type et longueur), et d’un corps. Il y a un certain nombre d'objets tels que : MRI (Message Routing


65

Information), SID (Session ID), SP (Stack-Proposal), SCD (Stack-Configuration-Data) et NLI (Network-Layer-Information) [64].

L'objet MRI fournit des informations sur le chemin que la signalisation devrait prendre et inclut un flag pour distinguer entre les deux directions que les messages de signalisation peuvent prendre, appelées "upstream" et "downstream" (respectivement ascendante et descendante). L’objet MRI est utilisé par le protocole NATFW NSLP qui sera détaillé dans les sections suivantes.

2.3. Les règles pour les NATs et les pare-feu

Les règles pour les NATs et les pare-feu sont représentées par un 5-tuple commun : les adresses source et destination, le protocole de transport, le port source et de destination, et une action additionnelle de règle avec la valeur "allow" ou "deny". Une telle règle dans le protocole NATFW NSLP est liée à une session spécifique.

Différemment des autres applications de signalisation où les règles sont rassemblées dans un seul objet, les règles dans le NATFW NSLP contiennent des actions (allow/deny), un identifiant de flux et d'autres informations supplémentaires.

L'information de cheminement du message de NTLP (MRI) porte les spécifications de filtre, mais les informations additionnelles, telles que la durée de vie (life time), l'identifiant de session (SID) ou le numéro de séquence et l'action (spécifique) sont portés dans les objets NSLP (voir les développements détaillés dans la section 3.2.1).

2.4. Introduction au protocole NATFW NSLP

C'est l'un des deux protocoles de la couche NSLP que le groupe de travail avait développé. Sa première version (daft) a été publiée en octobre 2003 par le groupe de travail NSIS [70], elle décrit des scénarios, des problèmes et des solutions pour la signalisation en mode « chemin-couplé » (path-coupled signaling) du NAT et du pare-feu. Le but principal de la signalisation NATFW NSLP est de permettre la communication entre deux nœuds appartenant à des réseaux différents et en présence de NATs et de pare-feux (appelés communément middleboxes).

Tout d'abord, il est supposé que ces NATs et pare-feux sont configurés de telle manière que les messages de signalisation de NATFW NSLP puissent les traverser, dans le cas contraire, la signalisation ne pourra pas fonctionner. Le protocole NATFW NSLP est utilisé pour installer dynamiquement des règles additionnelles dans tous les NATs et pare-feux compatibles le long du chemin de la signalisation. Il permet de configurer, d’une part, les NATs afin de traduire les adresses et établir la liaison, et d’autre part, il fournit les règles aux pare-feux pour permettre la transmission des paquets de données.


66

La figure 35 illustre une architecture générale de NSIS dans le cas du NAT/FW dans laquelle les hôtes d'extrémité sont situés derrière des middleboxes. Dans ce cas, chaque application située derrière un middleboxe et qui va établir une communication avec une application correspondante sur d'autres hôtes d'extrémité doit traverser tous les middleboxes sur le chemin de données.

A cet effet, l'application déclenche l'entité NSIS locale par l'intermédiaire d'un appel API, et ce, pour permettre aux données la traversée du middleboxe sur le chemin prévu. Si l'entité NSIS locale supporte le NATFW NSLP, ce dernier va établir des règles au niveau de tous les middleboxes du chemin; et permettra aux données de circuler de l'émetteur au récepteur en traversant tous les middleboxes intermédiaires.

Figure 35 : Architecture de NSIS dans le cas du NAT/FW

Les NATs et les pare-feux intermédiaires doivent être des NEs (NSIS entités), supporter et exécuter le protocole NATFW NSLP ; ce qui n’est pas le cas des autres nœuds intermédiaires (les routeurs par exemple).

La figure 36 présente une topologie générale du NAT/FW dans les réseaux IP, où les middleboxes sont typiquement placés en bordure des réseaux privés (edge), et combinent généralement les fonctionnalités de NAT et de pare-feu.


67

Figure 36 : Exemple de topologie du NAT/FW dans les réseaux IP

L'initiateur NSLP (NI pour NSLP Initiator) envoie les messages de signalisation NATFW NSLP via le chemin régulier de données au répondeur NSLP appelé NR (NR pour NSLP Responder).

Il est supposé que le NI, le NR et chaque middleboxe intermédiaire supporte et exécute le NATFW NSLP. Les messages de signalisation atteignent différents NEs intermédiaires appelés NFs (NF pour NSLP Forwarder) et chacun de ces nœuds traite les messages de signalisation selon certaines conditions (voir paragraphe 3.1), et si nécessaire, installe des règles supplémentaires pour les paquets suivants.

Comme présenté sur la figure 36, chacun des hôtes d'extrémité est situé derrière un NAT/FW relié au réseau public.

Le NATFW NSLP fonctionne selon plusieurs scénarios dépendants du placement du NAT/FW [66], tels que :

NAT/FW avec deux réseaux privés (NAT/FW cascadés). NAT/FW avec réseau privé du côté émetteur. NAT/FW avec réseau privé du côté récepteur. Les deux hôtes d'extrémité chacun derrière un NAT/FW. IPv4/IPv6 avec deux réseaux privés. Multihomed network avec NAT Multihomed network avec pare-feu ...etc.

Après avoir décrit quelques concepts de base du protocole NATFW NSLP ; dans ce qui suit nous allons effectuer une description plus approfondie du fonctionnement du protocole.


68

3. Description du protocole NATFW NSLP

3.1. Présentation générale

Comme décrit précédemment, le NATFW NSLP est porté par le protocole de couche transport NTLP de la plateforme NSIS [64]. L'interfonctionnement avec la couche NTLP et les autres composants est illustré sur la figure 37. (détails dans la section 4.1).

Les messages NATFW NSLP sont créés et envoyés par le NI (initiateur), ils peuvent être manipulés par le NF (Forwarder) et finalement traités par le répondeur (NR). Par conséquent, il est exigé qu'au moins le NI et le NR exécutent le protocole NATFW NSLP, le NF doit l'exécuter seulement s'il est NAT ou pare-feu, sinon il ne fait que transférer les messages.

Figure 37 : Interfonctionnement de NATFW NSLP [72]

- Le NI génère des messages et les envoie au NR. Le NI ne doit pas nécessairement être l'émetteur de données (appelé DS pour Data Sender), dans certain cas, il peut être le récepteur de données (appelé DR pour Data Receiver).

- Chaque NF exécutant le NATFW NSLP traite le message envoyé, vérifie ses règles locales et le transfère vers le prochain nœud NSIS jusqu'à ce que le message atteigne le NR.

- Le NR vérifie les messages reçus, les traite, génère un message de réponse et les renvoie au NI sur la même suite de NFs ce qui est garanti par le message RMRS (Reverse Message Routing State) établi dans NTLP par GIST. Dans certains scénarios, le NR n'est pas forcément le récepteur de données, par exemple dans un scénario de mode proxy où un NAT de bordure (edge-NAT) termine les messages et répond aux requêtes.


69

- Chaque NF traversé exécutant le NATFW NSLP traite à nouveau les messages de réponse.

- Lorsque le NI reçoit une réponse positive, l'émetteur de données DS peut commencer à envoyer des flux de données vers le récepteur DR.

Ce protocole permet la communication entre les hôtes d'extrémité, supportant et exécutant le protocole NATFW NSLP, mais elle échoue dans le cas contraire. Cependant, le NATFW NSLP prend en charge également ces scénarios en utilisant un mode dit proxy. La fonctionnalité principale du NATFW NSLP consiste à permettre aux flux de données de traverser les pare-feux et les NATs à l'aide de l'ouverture des ports et la création de liaisons de NAT (NAT binding) sur ces middleboxes. Cela est nécessaire vu que les pare-feux dans leur fonctionnement normal ont pour principe de refuser tout (deny-all) en bloquant tout trafic qui ne correspond à aucune règle de filtrage existante. Les NATs bloquent tout trafic qui ne correspond à aucune liaison existante ou à une session configurée ou installée. En revanche, certains scénarios nécessitent une politique de pare-feu permissive (Allow-all), dans laquelle le trafic qui n’est pas explicitement bloqué est autorisé à traverser ces pare-feux.

Comme décrit précédemment ce protocole fonctionne avec les états à court terme de telle sorte que chaque état installé sur les nœuds exécutants le protocole sera désinstallé après une période de temps bien spécifiée. Cependant, ce comportement peut être stoppé seulement par une requête de propagation de session. Afin de supprimer des réservations qui ne deviennent plus nécessaires, le protocole fournit également un mécanisme explicite de suppression d'état.

3.2. Fonctionnement du protocole

Cette section décrit les différentes phases relatives au fonctionnement du protocole NATFW NSLP, on y verra la création de session, sa maintenance et sa suppression. Par ailleurs, on donnera un aperçu sur les mécanismes de réservation d'une adresse externe, la façon de rapporter les événements asynchrones, le calcul de la vie d’une session et l'ordonnancement des messages.

Le NATFW NSLP utilise quatre différents messages :

CREATE : Ce message est le plus important des messages générés par le protocole. Il s'agit d'une requête utilisée pour créer, modifier, actualiser et supprimer des sessions NATFW NSLP.

EXTERNAL : La requête EXTERNAL est utilisée pour réserver, modifier, actualiser ou supprimer les sessions de même type, c-à-d les sessions EXTERNAL NATFW NSLP. Cette requête est envoyée à un NAT/FW de bordure pour permettre aux messages CREATE d'atteindre le NR. De plus, cette requête réserve (au niveau de NAT/FW de bordure) une adresse externe et un numéro de port pour l'hôte dans le réseau privé.


70

NOTIFY : C’est un message asynchrone qui est utilisé pour alerter les pairs NATFW des événements spécifiques, notamment en cas de défaillance.

RESPONSE : ce message est utilisé pour répondre aux messages CREATE et EXTERNAL.

Les principales opérations seront détaillées plus amplement dans les sections suivantes.

3.2.1. Description des composants du message NATFW NSLP

Un message NATFW NSLP est composé d'un entête et d’un ou plusieurs objets qui le suivent. Cet entête est commun à tous les messages NSLP, les objets sont TLV (Type-Length-Value) encodé en utilisant la représentation de données binaires Big Endian.

L'entête NSLP est la première partie du message, il contient deux champs, le type de message et un champ réservé. Les types de messages sont similaires aux quatre types de messages décrits précédemment (CREATE, EXTERNAL ...etc), le champ réservé doit être mis à zéro et est utilisé dans d'autres messages NSLP comme un champ drapeau (flag). La longueur totale de l'entête est de 32 bits (voir figure 38).

Figure 38 : Entête NSLP commun

Chaque objet NATFW NSLP utilise un format d'en-tête d'objet NSLP commun, ce format (voir figure 39), contient deux champs, le type d'objet et sa longueur avec des drapeaux supplémentaires.

Figure 39 : Entête d'objet NSLP commun

La longueur de l'objet (Object Length) est la longueur totale de l'objet sans compter son entête. Les champs marqués avec "r" sont réservés pour une utilisation future.


71

Les deux premiers bits sont utilisés pour signaler le traitement favorisé pour les objets dont leur traitement n'est pas définis dans le cadre actuel de la RFC 5973 [66]. Le NATFW NSLP utilise une partie des catégories qui sont définies dans GIST :

AB = 00 ("obligatoire") : ceci indique que cet objet est obligatoire, donc si le type d'objet ne correspond pas à une valeur spécifique (stipulée dans la RFC5973), l'intégralité du message contenant doit être rejeté avec un message d'erreur.

AB = 01 ("optionnelle") : si l'objet n'est pas compris, il doit être supprimé, puis le reste du message est traité d'une façon normale.

AB = 10 ("Forward") : Si l'objet n'est pas compris, il doit être maintenu inchangé dans tout message transmis comme résultat du traitement des messages, mais pas sauvegardé localement.

AB = 11 ("Refresh") : Ne doit pas être utilisé.

Les objets NATFW NSLP définis dans [66] sont (décrits dans les annexes B et C) :

- Signaling Session Lifetime Object, de longueur 1. - External Address Object, de longueur 2. - External Binding Address Object, de longueur 1+ nombre des adresses ipv4. - Extended Flow Information Object, de longueur 1. - Information Code Object, de longueur 1. - Nonce Object, de longueur 1. - Message Sequence Number Object, de longueur 1. - Data Terminal Information Object (IPv4/IPv6), de longueur variable, maximum 3. - ICMP Types Object, de longueur variable.

3.2.2. La création de session

Le NATFW NSLP utilise la requête CREATE afin d’acheminer le flux de données entre deux hôtes d'extrémité en présence de middleboxes. Par conséquent, le NI génère le message CREATE et le remet à la couche NTLP. Cette dernière, transmet le message vers le NR en se basant sur le MRI (Message Routing Information). Ce transfert s’effectue par saut et est transparent pour les NFs ne supportant pas le NATFW NSLP et les routeurs non NSIS entre les sauts NSLP. Chaque NF (exécutant NATFW NSLP) sur le chemin traite les messages, comme il peut aussi les rejeter en fonction des règles locales. Lorsque le message atteint le NR, celui-ci l'accepte et crée un message de réponse qu’il transmet au NI.

La figure 40 illustre l’échange du flux de messages dans le cas de création de session, le NI est l'émetteur de donnée (le Data Sender , DS) qui se situe derrière un NAT/FW.


72

Figure 40 : Phase de création de session

Le message CREATE n'est pas seulement utilisé pour la création de session, mais combiné avec l'objet « durée de vie » (lifetime object), il peut être utilisé à plusieurs fins, la création, le rafraîchissement, la suppression des sessions, et la modification des règles. Ainsi, les méthodes de traitement du message CREATE dépendent de sa fonction, sa durée de vie et du nœud sur lequel se déroule le traitement.

Le traitement d'une requête CREATE est différent entre les nœuds NATFW NSLP :

NI (l'initiateur) : Le NI génère le message CREATE initial et le remet à la NTLP. Si le NI reçoit un message de réponse alors la session est établie, et le chemin est configuré pour acheminer des messages de données au NR. Dans le cas contraire, c-à-d le NI reçoit un message d'erreur, alors il peut régénérer le message CREATE ou envoyer un rapport d'échec à l'application.

Le NF (Forwarder) : si le NF ne parvient pas à transmettre le message, (NR ou le prochain NF non trouvés), dans ce cas il génère un message d'erreur via une API GIST et le renvoie au NI, sinon le traitement du message CREATE dépend du type de middleboxe, s'il est : o Routeur NAT : le message CREATE peut être reçu des deux côtés du NAT selon

l'emplacement du NI par rapport au NAT : Le message CREATE reçu du côté privé du NAT : dans ce cas, la liaison NAT

(NAT binding) est allouée sans activation, mais si la règle demandée ne peut pas être réservée, un message d'erreur est généré. Le message CREATE est transmis par la suite vers le NR avec une adresse IP source égale à l'adresse externe de NAT.

Le message CREATE reçu du côté public du NAT : une vérification d'une réservation précédente créée avec le message EXTERNAL est faite en comparant


73

le MRI reçu avec le MRI mémorisé. Si la réservation est trouvée, l'adresse du DS (et/ou le port) est sauvegardée comme une partie de l'adresse source de la règle à chargée, puis il transmet le message CREATE vers le NR avec une adresse destination égale à l'adresse de NR (privée). Dans le cas où aucune réservation n’est trouvée, une réponse d'erreur est générée.

o Pare-feu : lorsque le pare-feu reçoit un message CREATE initial, le NSLP rappelle les règles demandées et les alloue, mais ne les installe pas à ce moment. Après cela, le message est transmis au saut suivant. Les règles (mémorisées) seront installées localement lorsque le NF reçoit une réponse positive de la requête. Si la ou les règles demandées ne peuvent pas être allouées, une réponse d'erreur est générée.

o NAT et Pare-feu combinés : le traitement se fait de la même manière que le cas dans lequel le NF est seulement NAT.

Le NR (Responder) : Si le NR reçoit un message CREATE initial, si la demande est acceptée, le NR doit répondre avec un message de succès. Sinon, il doit répondre avec un message d'erreur. Ce message de réponse est renvoyé saut par saut vers le NI, de sorte que chaque NF intermédiaire le traite aussi.

L'activation et l'installation des règles demandées par le NI au niveau des NFs ne se fait qu'à la réception d'une réponse positive auprès de NR avec le même identifiant de session SID, d’où l’avantage de conserver les ressources.

3.2.3. Réservation d'une adresse externe

Le mécanisme relatif au message CREATE fonctionne aussi bien en présence de NAT que du pare-feu sur le chemin si l'émetteur de données DS se trouve derrière un NAT ou un pare-feu. Cependant, si le récepteur de données DR se trouve derrière un NAT ou un pare-feu (comparer figure 41), et qu’il ait besoin de recevoir des flux de données de l'extérieur, le problème est plus contraignant. En effet, les messages de signalisation NSIS, ainsi que les flux de données ultérieures, sont dirigés vers une adresse IP de destination particulière qui doit être connue à l'avance et accessible.

Les récepteurs de données DRs doivent informer les firewalls et les NATs sur les messages de signalisation entrants et les flux de données avant leur réception par ces derniers.

Cependant, pour comprendre les nouvelles procédures de NATFW NSLP, Il est nécessaire de différencier entre les DRs. Il ya ceux qui se situent derrière des NATs et ceux derrière des pare-feu, puisque ces derniers ont déjà des adresses publiques et ils doivent seulement être accessibles pour la signalisation NATFW. Au contraire, les DRs derrière des NATs n'ont pas d'adresses IP publiques, par conséquent, ils ne sont pas accessibles par des entités en dehors de leur domaine d'adressage pour la signalisation NATFW.


74

Le NATFW NSLP résout ce problème en utilisant le message EXTERNAL envoyé par le DR au NAT et au pare-feu afin de réserver une adresse/port publique et permettre au flux suivant de l'atteindre, dans ce cas les rôles des différentes entités est comme suit :

Le récepteur de données DR est l'initiateur NI+ du message EXTERNAL, mais devient le NR du message CREATE suivant.

L'émetteur de données DS est le récepteur NR+ du message EXTERNAL, mais devient le NI du message CREATE suivant.

Il devient nécessaire d'utiliser une adresse de destination de signalisation (SDA pour Signaling Destination Address) comme cible du message EXTERNAL (NR+) si le DR est situé derrière un NAT et l'adresse du DS est inconnue. La SDA est une adresse arbitraire dans le domaine d'adresse externe au NAT (côté public).

Figure 41 : Flux des messages de réservation dans le cas où le DR se trouve derrière un NAT/FW

Le NI+ (DR) envoie le message EXTERNAL en désignant l'adresse du DS (si elle est connue), sinon la SDA. Le message est envoyé vers l'extérieur jusqu'à ce qu'il atteigne le NAT/FW de bordure (edge-NAT ou edge-FW). Le NI+ doit toujours inclure dans ce message l'objet NATFW_DTINFO spécifiant des informations nécessaires utilisées par le NAT de bordure à plusieurs fins : tels que la restriction de passage des messages CREATE pour seulement ceux qui ont une MRI égale à la courante. Le message EXTERNAL crée un état de session à tout NF intermédiaire et assure que le NAT/FW de bordure est découvert. Si le message EXTERNAL atteint le edge-NAT, ce dernier répond par un message incluant un objet de réussite : une adresse IP publique et un numéro de port. Ainsi, il est possible de


75

transmettre le message CREATE par le NI (NR+, DS) vers le NR (NI+, DR), qui se trouve derrière un NAT/FW.

3.2.4. Rafraîchissement de session

Toutes les sessions NATFW NSLP sont maintenues sur une base d'état à court terme (soft state). Cela signifie que ces sessions et les règles, si elles ne sont pas actualisées, seront supprimées automatiquement après un délai bien défini. Chaque état doit être rafraîchi par le même type de message par lequel il a été créé. Par exemple, un état créé par un message CREATE doit être actualisé par CREATE. Les messages de rafraîchissement doivent porter l'exact MRI, l'ID de session comme le message initial, et un objet de durée de vie dont la valeur soit supérieure à zéro. Si les MRIs sont différents, le message est traité comme étant une mise à jour des règles.

Chaque NF recevant le message de rafraîchissement de session doit vérifier la durée de vie avec ses politiques locales s'il peut l'accepter pour cette session. Le NR qui reçoit un tel message de rafraîchissement, doit répondre par un message de réponse et le transmet vers le NI. Donc, les NFs intermédiaires peuvent mettre à jour leur période de rafraîchissement. Dans le paragraphe 3.5, plus de détails sur le calcul de la durée de vie de session ont été effectués. La figure 42 montre un échange de messages de rafraîchissement, avec CREATE comme exemple.

Figure 42 : Echange de rafraichissement de session, avec CREATE

Le traitement des messages de rafraîchissement CREATE ou EXTERNAL est différent pour chaque type de nœud NSIS :


76

L'initiateur : Le NI/NI+ peut générer un message de rafraichissement CREATE/EXTERNAL pour des sessions de signalisation avant l'expiration de leur durée de vie.

le NF : le traitement de ces messages est indépendant du type de middleboxe. Le NR : le NR acceptant un message de rafraîchissement génère une réponse

positive, incluant la valeur de la durée de vie acceptée dans l'objet NATFW_LT.

3.2.5. La suppression de session

Un NI peut supprimer des sessions à tout moment en envoyant un message CREATE ou EXTERNAL avec un objet de durée de vie mise à zéro (voir figure 43). L'utilisation de l'un ou de l'autre (CREATE ou EXTERNAL) dépend de la façon dont la session a été créée. Par conséquent, les sessions créées par le message CREATE ne peuvent être supprimées que par CREATE, ceci est semblable pour les sessions créées par EXTERNAL.

Chaque nœud NATFW NSLP recevant un tel message doit immédiatement supprimer la session spécifiée et les règles associées avec. Ensuite, le message est transféré dans la mesure d'atteindre le NR. Il est considéré qu'un message d'une valeur de durée de vie égale à 0 ne génère aucune réponse. La figure 43 montre un exemple de flux de message de suppression.

Figure 43 : La suppression de session avec CREATE

3.3. Comportement de NATFW NSLP avec SIP

Comme il a été déjà présenté dans le deuxième chapitre, en présence des NATs et pare-feu, le protocole SIP ne parvient pas à établir une communication entre les interlocuteurs. Dans cette section, nous allons présenter comment la solution de protocole NATFW NSLP permet de pallier à ce problème, la figure 44 schématise ce comportement.


77

Figure 44 : Interaction NATFW NSLP et SIP

Dans cette figure (44), un nœud dans un réseau privé essaie d’établir une communication avec un autre situé dans le domaine public en utilisant le protocole de signalisation SIP. Ces deux nœuds ainsi que le NAT/FW supportent le protocole NATFW NSLP :

1. Tout d'abord, le nœud appelant (le DR dans ce cas) envoie le message EXTERNAL vers l'extérieur de son réseau privé.

2. Puisqu'il ya un NAT/FW, il répond avec l'adresse publique allouée, en utilisant un message de réponse NATFW NSLP pour le message EXTERNAL.

3. Maintenant, c'est le comportement normal de SIP qui suit, sauf que l'adresse source dans le paquet INVITE est remplacée par celle fournie par le message de réponse NATFW NSLP.

4. Puis l'envoi de message trying de SIP.

5. Lorsque le DS reçoit le message INVITE de SIP, il suppose qu'il pourrait y avoir des NATS et pare-feu sur le chemin, il tente d'ouvrir un chemin en envoyant un message CREATE à l'adresse fournie dans le paquet INVITE de SIP. Le message CREATE atteint le


78

NAT/FW et demande d'ouvrir un trou d'épingle. Ensuite, le message est transmis à l'intérieur vers le DR.

6. Il envoie également le message OK de SIP.

7. Lorsque le message CREATE atteint le nœud DR, celui-ci envoie un message de réponse (positive) qui va activer l'ouverture du trou d'épingle au niveau du NAT/FW.

8. Ceci est suivi par le message ACK de SIP afin de :

9. Commencer l'envoi de flux de données par RTP.

10. Et de recevoir le flux entrant sans blocage par le pare-feu, et ainsi la communication réussit.

3.4. Rapports des évènements asynchrones

Pour fournir aux NFs et NRs la fonctionnalité de reporter des événements asynchrones aux autres nœuds, en particulier au NI, le protocole NATFW NSLP dispose du message de notification NOTIFY. Les événements asynchrones définis dans [66] sont la fin de session, les changements dans les politiques locales, le changement de chemin de routage et toute autre raison qui indique un changement de l'état de session NATFW.

Les NFs et les NRs peuvent générer des messages NOTIFY sur des événements asynchrones, avec un objet de réponse (NATFW_INFO Object) indiquant la raison de l'événement et un identifiant de la session correspondante.

Ces messages sont envoyés saut par saut vers le NI. Chaque NF recevant le message NOTIFY analyse l'événement annoncé, se comporte selon l'événement rapporté et le transmet enfin vers le NI. Ce dernier, recevant le message NOTIFY analyse lui aussi l'événement notifié et se comporte selon les cas signalés.

3.5. Calcul de la durée de vie de session

Le NATFW NSLP utilise le mécanisme d'état à court terme à l'installation des sessions et des règles appropriées. Une session existe tant que sa durée de vie est valide. Si une session expire et vu qu’il n’y a pas de rafraîchissement provisoire, la session et les règles ainsi que les ressources correspondantes doivent être enlevées ou libérées automatiquement.

Le NR et les NFs ne doivent jamais déclencher le mécanisme de rafraichissement de session, c'est le NI qui est responsable des messages d'extension de la durée de vie de la session et doit choisir une valeur avant d'envoyer n'importe quel message.


79

3.5.1. Critères de calcul

Le calcul de la durée de session est basé sur :

Le nombre de messages de rafraîchissement perdus avec lesquels les NFs doivent faire face.

Le délai de bout en bout entre le NI et le NR. Une vulnérabilité réseau due à un détournement de session NATFW NSLP (ce qui est

facile lorsque le NI ne supprime pas explicitement la session). La durée d'échange de données de l'application de l'utilisateur, en fonction du temps et

des besoins du réseau. Cette durée est modélisée par R qui représente la période de rafraîchissement du message (en secondes).

La charge sur le plan de signalisation, de courtes durées de vie impliquent des messages de signalisation plus fréquents.

Le temps acceptable pour une session d'être présent après qu'il n'est plus vraiment nécessaire. Par exemple, si l'existence de la session de signalisation NATFW NSLP implique un coût financier et le démontage ne peut pas être garanti, des durées de vie plus courtes seraient préférables.

La durée du bail de l'adresse IP de NI qui doit être plus longue que la durée de vie choisie pour la session, sinon, l'adresse IP peut être réaffectée à un autre nœud qui peut recevoir le trafic indésirable, même s'il n'a jamais demandé une configuration NATFW, ce qui pourrait être problématique dans des environnements où des hôtes sont mobiles.

En général, une durée de rafraîchissement de 300 secondes (5 minutes) suffit, à moins que l'application de signalisation au NI demande d'autres exigences (par exemple, les flux durant un temps très court). Cette durée demandée est stockée dans l'objet NATFW_LT_NSLP.

3.5.2. Traitement de la durée de vie demandée

Le NR et les NFs peuvent se comporter comme suit vis à vis de la durée de vie demandée :

- Aucun changement nécessaire si la durée de vie est acceptable, le message est transmis au nœud suivant.

- Si la durée de vie peut être diminuée, ils peuvent également réduire la durée de vie demandée à une valeur acceptable (basée sur leurs politiques locales). Si un NF modifie la valeur de la durée de session, il doit sauvegarder la nouvelle valeur dans l'objet NATFW_LT et le message sera transmis par la suite.

- Si la durée de vie est très élevée ou très faible, ils génèrent une réponse d'erreur.


80

3.5.3. Comportement après le traitement de la durée de vie

Le NF ou NR ne doit pas augmenter la valeur de la durée de session, mais les messages peuvent être rejetés si celle-ci est très élevée, lorsqu’une session est créée ou rafraîchie.

Le NR génère une réponse positive pour le CREATE (ou EXTERNAL) reçu, affecte la valeur de durée de session dans l'objet NATFW_LT à la durée de vie acceptée et renvoie le message vers le NI.

Chaque NF traite le message de réponse, lit et enregistre la valeur de durée de session acceptée. Les NFs doivent accepter la durée de session accordée, si sa valeur est dans la gamme acceptable. La valeur acceptable correspond à la valeur acceptée par le NF lors du traitement de message CREATE ou EXTERNAL.

Pour les valeurs reçues supérieures/inférieures à la valeur acceptable, le NF doit générer un message de réponse d'échec de la session. Ce message inclut l'objet de durée de vie de session qui comporte la durée de vie maximale/minimale acceptable pour ce nœud.

Dans les deux cas, le NF doit également générer et envoyer un message de notification.

La figure 45 montre un exemple de calcul de la durée en utilisant le message CREATE. La requête de NI a une durée de 60 secondes, le NF la modifie à 20 secondes et le NR à 15 secondes. Lorsque le NI reçoit le message de réponse avec la valeur de durée de vie de 15 secondes, il vérifie si cette valeur est inférieure ou égale à la valeur acceptable.

Figure 45 : Exemple de calcul de durée de vie de session

3.6. L'ordonnancement des messages

Un message NATFW NSLP a besoin de transporter un identifiant de telle sorte que tous les nœuds du chemin peuvent distinguer les messages envoyés à des moments différents. Les messages peuvent être perdus, retardés ou dupliqués et tous les nœuds NATFW NSLP devraient être en mesure d'identifier les messages. Pour cela, il est nécessaire de conserver des informations sur les messages déjà reçus, ainsi chaque message doit porter un numéro de séquence (MSN Message Sequence Number).


81

Ce MSN doit être initialisé par le NI et aucun autre nœud ne doit le définir ou le modifier. Le NI génère de façon aléatoire une valeur initiale pour le MSN qui doit être unique seulement pour cette session, et il doit être incrémenté pour chaque message envoyé. Une fois que le MSN atteint la valeur maximale, il reprend à zéro. Le MSN est sauvegardé par le NF et le NR, il est envoyé avec le paquet initial comme valeur de départ, et se trouve rattaché à cette session. Le MSN reçu est mis dans les messages de réponse.

Lorsqu’un nœud NATFW NSLP reçoit une requête, il utilise le MSN donné afin de déterminer dans quelle mesure l'état requis est différent de l'état déjà installé. Si la valeur du MSN reçue est inférieure ou égale à celle sauvegardée, le message sera supprimé car une telle valeur peut indiquer un message dupliqué, retardé ou rejoué. Si la valeur du MSN reçue est supérieure à la valeur mémorisée, le NATFW NSLP doit mettre à jour son état mémorisé si ceci est autorisé (par les règles de sécurité) et par conséquent, doit sauvegarder la valeur du MSN mise à jour.

4. Implémentation du protocole NATFW NSLP

Cette section donne un aperçu général sur la conception du projet, des composantes du logiciel, son interaction avec le protocole GIST développé à l'Université de Goettingen [web-3] ou d'autres logiciels, ainsi que les choix de l'implémentation de NAT/FW.

4.1. Vue générale sur l'implémentation

Le protocole NATFW NSLP a été développé avec le langage C++, son code s'appuie sur celui du protocole GIST, les deux implémentations sont disponibles gratuitement sous la forme d’une version unique appelée NSIS [web-3] pour Linux. En fait, il existe 6 versions dont la dernière : NSIS-0.6.0 développée en 2008.

L’implémentation du NATFW NSLP a nécessité la mise en place d’un automate d'état finis (Finite State Machine ; FSM) [71]. Étant donné le choix de Linux comme plate-forme pour NSIS, le package Netfilter (iptables) [web-6] a été adopté pour le filtrage des paquets dans le pare-feu ainsi que pour le NAT. Netfilter est un standard qui a fait ses preuves et qui est doté d'une excellente réputation ainsi que d’une popularité riche d’une très grande communauté.

GIST offre une API aux applications NSLP pour utiliser ses services de transport génériques via les sockets Unix. Le NATFW NSLP lui aussi offre une API aux couches supérieures pour permettre aux applications de déclencher des flux de signalisation, telles que l'acceptation des connexions entrantes à un pare-feu de bordure (edge). Le mécanisme mis en œuvre consiste en un processus serveur appelé "NatFwServer".

L'implémentation de NATFW NSLP se compose (voir la figure 46), des parties principales suivantes :


82

Figure 46 : Architecture du NATFW NSLP

NatFwServer qui utilise GIST et GIST-API pour envoyer ou recevoir des paquets, gère les Callbacks pour les autres composants, utilise le module FSM pour réagir en fonction des événements et des Callbacks arrivés, utilise les APIs, NAT-API et FW-API pour communiquer avec iptables.

FSM : automate d'état fini qui défini les différents états des nœuds NATFW NSLP. Analyseur et constructeur de messages (message-parser). Table des règles de sécurité (security policy table). APIs de pare-feu et de NAT (FW-API, NAT-API). Un module supplémentaire appelé «NatFwClient" est utilisé pour déclencher des

événements externes, par exemple un CREATE. Ce client est utilisé pour les tests et doit être remplacé par l'application qui souhaite utiliser le NATFW NSLP, par exemple, un téléphone IP. Le NatFwClient utilise également un socket pour communiquer avec le NatFwServer.

Les composants les plus importants dans l'implémentation de ce protocole sont le FSM, les API et les mécanismes permettant de réaliser l'approche d'état à court terme (softstate) d'une manière efficace et flexible. Par conséquent, tous ces composants seront décrits en détail dans les paragraphes suivants.

4.2. Pare-feu : Netfilter/Iptables

Il existe deux approches possibles pour interagir avec le NAT et le pare-feu, la première approche, par le biais de la bibliothèque statique de contrôle iptables qui est 'libiptc', qui est, conçue pour lister et manipuler les règles dans le module iptables rajouté au kernel. Cette approche n'a pas été utilisée due au changement rapide entre les différentes versions.


83

La deuxième approche possible est l'utilisation d'un appel système direct à partir du code avec la commande "system()". Celle-ci transmet une commande au système d'exploitation de la machine qui va s'exécuter en tant que commande externe. Ainsi il a été décidé d'utiliser la commande iptables à l'intérieur de code du NATFW NSLP.

Dès que le Service NatFwServer est activé dans un environnement NAT/FW, il crée automatiquement trois chaînes supplémentaires à l'intérieur de iptables pour le NATFW NSLP : "natfwforward", "natfwinput" et "natfwoutput". A l'étape suivante, ces chaînes sont mappées par les chaînes appropriées d'iptables : "natfwforward" par "FORWARD", "natfwinput" par "INPUT", et "natfwoutput" par "OUTPUT". Si le NAT/FW-API est demandé par le NatFwServer pour ouvrir un trou d'épingle pour un 5-tuple spécifique (les adresses source et de destination, le protocole de transport, le port source et de destination), il vérifie d'abord s’il n'existe pas. Sinon, l'API insère la règle correspondante à la 5-tuple à l'intérieur de la chaîne appropriée et met à jour la table de hachage interne. Si l'API doit supprimer un trou d'épingle, il vérifie d'abord si la règle existe et la supprime de la chaîne appropriée. L'API est divisée en deux parties, un NAT-API et un FW-API.

Le NAT/FW-API gère ici ses propres chaînes en les séparant des chaînes normales d’iptables. Cette approche permet de vérifier à l'intérieur de l'API si une règle existe déjà sans faire un appel système. Par conséquent, les API sauvegardent dans une table de hachage les règles maintenues. En outre, la suppression des règles déjà existantes par l’API est évitée, parce que celle-ci ne peut supprimer que les règles de ses propres chaînes.

Un autre avantage de cette approche est qu'elle permet l'arrêt de NatFwServer et la suppression de toutes les règles existantes assez facilement. L'API ne doit supprimer que les chaînes «natfwforward", "natfwinput", "natfwoutput» et les chaînes changées correspondantes. Pour cela, il peut utiliser la commande iptables "flush", qui supprime toutes les règles d'une chaîne spécifique; ensuite, la chaîne désormais vide peut être supprimée. Si l'API a inséré toutes les règles directement dans les chaînes standards d’iptables, il faudrait supprimer individuellement toutes les règles NATFW appropriées afin d'éviter de supprimer des règles déjà existantes dans le cas d'arrêt de NatFwServer.

Enfin, cette approche permet de purger facilement des chaînes iptables dans un cas d'accident de NatFwServer dû à une mauvaise manipulation.

4.3. L'automate d'état fini (FSM Finite State Machine)

Pour implémenter le NATFW-NSLP, chaque session doit maintenir l'un des trois FSM. Le NI, NF et le NR doivent maintenir respectivement, le NI-FSM, le NF-FSM et le NR-FSM.


84

Les FSMs sont juste une modélisation possible du protocole, D'autres techniques de modélisation peuvent décrire le fonctionnement et générer les mêmes résultats en utilisant des méthodes différentes.

L'automate d'état énumère trois états initiaux possibles [71], un hôte peut être dans un état inactif (IDLE) pour le NI, le NF et le NR. Les trois tableaux suivants présentent les différents états de chacun d'eux.

Entrée Etat Sortie

INITIALIZE DeleteSession(); IDLE CreateSession();

ResetCounter(CREATE);

StartTimer(RESPONSE); WAITRESP StopTimer(RESPONSE);

ResetCounter(CREATE); StartTimer(REFRESH);

SESSION StopTimer(REFRESH); StopTimer(RESPONSE);

Tableau 1 : Différents états de NI : NI-FSM

Au démarrage de NATFW NSLP sur le NI, ce dernier est en état d'initialisation INITIALIZE, après l'initialisation des variables, le NI passe à l'état IDLE (inactif), puis à l'état WAITRESP (attente de réponse) à l'envoie d'un message (par exemple CREATE), s'il reçoit un message de réponse positif, il passe à l’état SESSION (établissement de session), sinon il revient à l'état IDLE.

Le NI peut passer de l'état SESSION à l'état WAITRESP en cas d'envoi d'un message de rafraichissement, comme il peut passer à l'état IDLE en cas de suppression de session.

Entrée Etat Sortie

INITIALIZE

DeleteSession(); IDLE CreateSession();

StartTimer(STATE); CREATE_WAITRESP StopTimer(STATE); StartTimer(EXT); CreateReservations(); NONEDGE_EXT StopTimer(EXT);

DeleteReservations(); StartTimer(EXT); CreateReservations();

EDGE_EXT StopTimer(EXT); DeleteReservations();

StartTimer(CREATE)

CreatePinhole();

CreateBinding();

SESSION StopTimer(RESPONSE); StopTimer(CREATE);

DeletePinhole();DeleteBinding();

Tableau 2 : Différents états de NF : NF-FSM


85

Le NF passe à l’état CREATE_WAITRESP s'il a reçu le message CREATE et il est en train d'attendre le message de réponse positive. A la réception de ce message il passe à l'état SESSION, sinon il revient à l'état IDLE.

Pour les deux autres états EDGE_EXT et NONEDGE_EXT (NF de bordure ou pas), un NF ne peut être qu’à un des deux états à la réception de message EXTERNAL.

Les messages entrants sont traités par GIST et livrés au NATFW NSLP qui décide de les accepter ou les transmettre. Ces messages sont destinés soit juste pour le NAT ou juste pour le pare-feu. La configuration permet de définir des indicateurs si un hôte est un pare-feu, un NAT ou les deux.

Entrée Etat Sortie

INITIALIZE

DeleteSession(); IDLE CreateSession();

ResetCounter(EXT);

StartTimer(RESPONSE);

EXT_WAITRESP StopTimer(RESPONSE);

ResetCounter(EXT);

StartTimer(REFRESH);

EXT StopTimer(RESPONSE);

StopTimer(REFRESH);

StartTimer(STATE); SESSION StopTimer(STATE);

Tableau 3 : Différents états de NR : NR-FSM

Le NR est en état EXT_WAITRESP s'il a envoyé un message EXTERNAL et attend la réponse positive auprès de NF, il passe à l’état EXT s'il l'a reçu, sinon il devient inactif IDLE.

Le NR passe de l'état EXT à l'état SESSION s'il reçoit le CREATE et envoie une réponse positive au NI.

Les transitions sont modélisées comme un ensemble d'états, des événements et des pointeurs de fonction sur l'objet du FSM. Selon un état donné et un événement entrant, une fonction est appelée, cet appel de fonction se fait avec un coût très faible. Les corps des fonctions contiennent tous les codes pertinents qui définissent les fonctionnalités du protocole tels que la manipulation d'état, l'interaction de NAT et pare-feu, l'analyse et la construction des messages.


86

4.4. Gestion d'état

Un aspect important d'un protocole de signalisation est la façon dont l'implémentation traite l'état. Pour toute implémentation NATFW NSLP, il est nécessaire de régler des timers pour des événements spécifiques, par exemple un délai de session (session timeout). Ce délai a une valeur définie communément entre 90 et 180 secondes. Si le timer est expiré (cela signifie que le décompte a atteint zéro), le protocole doit déclencher un événement (généralement géré par une fonction de Callback). Si un message de rafraîchissement d'une session arrive avant l'expiration de la valeur de la durée de vie, le timer pour le délai doit être étendu à la nouvelle valeur de la durée de vie. Si aucun message de rafraîchissement n’est arrivé et le timer de délai de session est expiré, la session sera automatiquement supprimée. Les sessions peuvent également être supprimées par un message explicite.

Ce comportement et cette gestion d'état sont mis en œuvre à l'aide de NSLP-API de GIST [65]. Cette implémentation (de GIST) fournit une puissante NSLP-API, qui peut être utilisé pour définir les états et installer des timers et les connecter à un Callback spécifique lié à un événement. Ces compteurs (timers) peuvent être installés comme étant des timers ponctuels, ce qui signifie qu'ils seront supprimés après expiration du délai. Le NSLP-API permet également la définition des timers périodiques, qui se déclenchent par exemple toutes les 15 secondes.

A l'aide de NSLP-API, le NATFW implémente l'approche d'état à court terme comme suit : Une session est installée avec une valeur de durée de vie spécifique au niveau de NF et NR, par exemple, 180 secondes. Ce timer est ponctuel. La session de NI est installée avec un timer périodique (exemple toutes les 90 secondes), qui est utilisé pour rafraîchir la session. Si le NF et le NR reçoivent un message de rafraîchissement avant l'expiration de la durée de vie et le timer de suppression de la session, ils doivent supprimer le timer de l'ancienne valeur de durée de vie et installer un nouveau timer avec la nouvelle valeur. Cette approche peut également être utilisée pour d'autres timers dans le NATFW NSLP, par exemple, le timer de RESPONSE, et de EXTERNAL.

5. Menaces et mécanismes de sécurité

NSIS a été développé dans le but de supporter différentes situations spécifiques (par exemple la découverte des nœuds adjacents par GIST, la signalisation de la QoS, la signalisation NATFW, etc). Par conséquent, une variété d'entités de signalisation, une série de mécanismes et différentes architectures de réseau peuvent être adoptées, ce qui complique la mise en place des mécanismes de sécurité.


87

5.1. Les menaces

La RFC 4081 [74], fournit une analyse détaillée des menaces de sécurité en rapport avec la suite de protocoles de signalisation NSIS. Elle a permis d’identifier quatre menaces qui sont décrites dans ce qui suit.

5.1.1. L'attaque Man-in-the-Middle

Dans l'attaque Man-in-the-middle, un attaquant est capable de modifier ou d'insérer des messages volontairement entre deux entités sans qu'elles le sachent. Dans ce cas, l'attaquant doit observer et intercepter les informations transmises entre deux entités. Dans NSIS, l'attaque man-in-the-middle pourrait se produire dans deux cas : si les deux parties ne partagent pas encore les associations de sécurité et si les associations de sécurité sont déjà établies (nœud NSIS malveillant voir figure 48).

Ce type d'attaque peut également se produire au cours de la phase de découverte de la topologie du réseau.

Figure 47 : L'attaque Man In the Middle dans NSIS

5.1.2. L'attaque par rejeu des messages de signalisation

Cette attaque consiste à un rejeu des messages de signalisation, un adversaire est capable d'écouter, de recueillir des informations de signalisation puis les rejoue plus tard ou à différents endroits. Il pourrait également rejouer les parties de l'information interceptée d'une manière différente.


88

5.1.3. Injecter, Modifier, Retarder ou rejeter des messages

En l'absence d'authentification et de protection de message de signalisation, un adversaire pourrait injecter des messages de signalisation exigeant un grand nombre de ressources qui entraînent le rejet des autres requêtes. Les messages de signalisation peuvent également être modifiés et conduisent à un dysfonctionnement. L'adversaire pourrait prendre d'autres actions possibles pour violer les procédures de signalisation, telles que la réorganisation, le retard, ou le rejet des messages.

5.1.4. Insécurité de négociation et de l'échange des paramètres

En général, les protocoles utilisés dans plusieurs scénarios pourraient avoir des exigences de sécurité différentes, les différents utilisateurs ou les différentes parties d'un réseau peuvent avoir besoin de différents niveaux de protection. Ainsi, un mécanisme unique ou un ensemble fixe de paramètres de sécurité ne peuvent pas répondre à ces exigences.

Par conséquent, un protocole est nécessaire pour échanger des paramètres ou de négocier des exigences de sécurité. Mais si ce protocole n'est pas sécurisé, un adversaire pourrait affaiblir les mécanismes et pourrait causer la perte des avantages de l'échange de paramètres et de négociation.

5.2. Mécanismes de sécurité du protocole NATFW NSLP

Comme nous l’avons déjà mentionné dans le précédant chapitre, le protocole de la couche NTLP GIST, a été conçu pour utiliser des mécanismes de sécurité déjà existants tels que TLS, et IPsec. Toutefois, ces connexions sécurisées sont limitées seulement pour les nœuds adjacents, elles ne peuvent pas être utilisées pour un chemin sécurisé de bout en bout comme étant établi par les applications de signalisation elles-mêmes (par exemple NATFW NSLP). La sécurité dans NSIS est donc limitée à des mécanismes de sécurité déjà existant comme les canaux TLS ou IPsec, qui sont fournis par la couche NTLP [73]. Afin de gérer les ressources critiques comme l'ouverture des trous d'épingle sur des pare-feu, GIST ne dispose pas de mécanismes appropriés afin de vérifier l'identité d'un hôte donné (authentification), s’il est autorisé à faire usage d'un service particulier (autorisation), et enfin de compter (accounting) son crédit une fois qu'il utilise effectivement ce service (comptabilité) [73, 75]. Sur la base des menaces analysées, il s’avère nécessaire de fournir, entre les nœuds NATFW NSLP voisins, les services suivants :

l'authentification de l'origine des messages, protection contre l'attaque par rejeu de messages, l'intégrité de données, éventuellement, la confidentialité.


89

5.3. L'authentification et l'autorisation

A la réception d'un message de signalisation, le nœud NAT/FW récepteur doit d'abord vérifier si ce message est authentifié et autorisé à effectuer l'action demandée (voir la figure 49). Si un nœud NAT/FW exige plus d'informations que celles fournies, il doit générer une réponse d'erreur indiquant l'échec de l'authentification.

Figure 48 : Principe d'authentification et d'autorisation pour le NATFW NSLP

Une fois que le NI est authentifié, la seconde étape consiste à vérifier si le NI demandeur est autorisé à demander le chargement de la règle et la liaison de NAT pour la session NATFW NSLP. Si la requête échoue, le NF ou NR doivent envoyer une réponse d'erreur : Échec de l'autorisation [66].

6. Travaux précédents en relation

Les mécanismes de sécurité de GIST sont principalement concernés par un transport et un acheminement sécurisés des messages entre les nœuds NTLP adjacents, tandis que la couche supérieure applicative NSLP exige un fort mécanisme d'autorisation [73]. Par conséquent le protocole NATFW NSLP doit disposer de moyens pour l'authentification et l'autorisation de ses messages.

La plupart des travaux dans ce contexte, a été destiné à l'application QoS NSLP, sachant que certains d'eux peuvent être appliqués pour le NATFW NSLP. Dans certains cas [76], une application d'autorisation spéciale est définie avec un chiffrement à clé publique est utilisé pour l'authentification. Ces deux approches sont lourdes dues à l'utilisation d'une backend communication avec les serveurs d'autorisation ainsi que le type de cryptage utilisé


90

pour la vérification de l'authenticité des requêtes. En outre, le contenu du message NSLP n'est pas inclus dans ces contrôles d'authenticité [75].

Dans [77] un mécanisme orienté session a été proposé, basé sur les sauts NTLP, en utilisant une paire temporaire de clés publiques/privées avec l'algorithme Diffie Hellman comme méthode d'échange de ces clés. Cette approche est lourde et moins évolutive en raison de son orientation et les signatures basées sur la cryptographie à clé publique [75].

Dans [75], le mécanisme HMAC est utilisé avec un serveur Kerberos qui génère, à la demande, un jeton à envoyer au NI afin de lui fournir la clé privée, ce jeton est également envoyé au NAT/FW dans le message en créant un autre objet d'autorisation dans un format spécifique de Kerberos. Cette approche, augmente la taille de message, mais l'inconvénient majeur réside dans la clé qui est inclue dans le message NSLP; ainsi un attaquant peut intercepter le message et divulguer cette clé.

6.1. Travaux de la RFC 5981

Cette RFC est un document produit par le groupe de travail : Next Steps in Signaling de l’IETF. Il présente un modèle générique et des formats d'objets d'autorisation de session relatifs aux protocoles de la couche NSLP de NSIS. L'objectif de l'autorisation de la session est de permettre l'échange d'informations entre les éléments de réseau afin d'autoriser l'utilisation des ressources pour un service et à coordonner les actions entre la signalisation et la couche de transport. La RFC 5981 [73] est basée sur la RFC 3520 et la RFC 3521.

L’approche pour fournir une autorisation par session et un fort contrôle d'admission basés sur des règles, nécessite de prévoir et définir un mécanisme qui assure que l'utilisation des ressources par un hôte a été dûment autorisée avant de permettre à l'application de signalisation d'effectuer l'action demandée, (par exemple le NAT : NAT binding). Afin de satisfaire cette exigence, il doit y avoir des informations dans le message NSLP qui peuvent être utilisées pour vérifier la validité de la requête. Ceci peut être réalisé en fournissant à l'hôte initiateur un objet contenant les informations nécessaires; cet objet sera inséré dans le message NSLP et contrôlé par les éléments respectifs de réseau.

Le mécanisme d'autorisation proposé dans cette RFC repose sur la fourniture de jetons d'autorisation par une partie tierce de confiance (un ordonnateur ou Authorizing Entity, AE). Ce dernier fournit des jetons d'authentification qui peuvent être utilisés par les clients pour signer leurs messages et prouver leur authenticité.

L'hôte demandeur (initiateur de la requête) insère les informations d'autorisation récupérées à partir du AE qui génère un PE (Policy Element) pour permettre la vérification de la requête. Les NATs/FWs vérifient la requête et ensuite la traitent selon la politique de sécurité mise en place.


91

Dans la stratégie d'autorisation de session pour le NATFW NSLP, l'opération par défaut consiste à ajouter un seul objet d'autorisation. Mais afin de supporter la signalisation de bout en bout et demander l'autorisation de différents réseaux, le NI peut ajouter plusieurs objets d'autorisation dans le même message.

Dans la section qui suit nous allons décrire l'objet d'autorisation de session (session_auth_object) utilisé pour transmettre les informations d'autorisation pour la requête. Cet objet est générique, vu qu'il est utilisable par toutes les applications de la couche NSLP.

7. Description de l'objet d'autorisation de session

L'objet d'autorisation de session tel que défini dans la RFC 5981 [73], porte des informations, sur l'authentificateur, nécessaires à l'accomplissement et le bon déroulement de cette opération.

7.1. Format de l'objet d'autorisation de session

J. Manner et al [73] a proposé et définit l'objet SESSION_AUTH_OBJECT satisfaisant le transport des informations nécessaires qui devraient être utilisé pour permettre un contrôle d'admission fiable.

L'objet SESSION_AUTH_OBJECT contient une liste de champs qui décrivent la session, avec d'autres attributs. Son en-tête suit celui générique d'un objet NSLP. La figure 50 illustre son format général.

Figure 49 : Format de l'objet d'autorisation de session

Les champs de cet objet sont :

Type : SESSION_AUTH_OBJECT.

Length : variable, contient la longueur de l'objet d'autorisation de session en utilisant comme unité les mots de 32 bits.


92

Session Authorization Attribute List : ce champ est de longueur variable, la liste d'attribut d'autorisation de session est une collection d'objets qui décrivent la session et fournissent d'autres informations nécessaires pour vérifier les requêtes.

7.2. Format des attributs de l'objet d'autorisation de session

Un attribut d'autorisation de session peut contenir une variété d'informations, il a un type et un sous-type. La figure 51 présente le format général des attributs.

Figure 50 : Format général d'un attribut d'autorisation

Chaque attribut contient les champs : Length, X-Type, SubType, et Value.

Length : présenté sur 2 octets et indique en octets la longueur réelle de l'attribut (y compris les champs Length, X-Type, SubType).

X-Type: présenté sur 1 octet et indique le type d'attribut.

SubType : présenté sur 1 octet, sa désignation dépend du champs X-Type, ou chaque X-Type a des sous types spécifiques.

Value : de longueur variable, contient une information spécifique de l'attribut et dépend des champs précédents X-Type et SubType.

7.3. Les types d'attributs

Dans la RFC 5981 [73], 8 types d'attribut sont spécifiés :

AUTH_ENT_ID : L'identifiant unique de l'entité qui a autorisé la session. SESSION_ID : L'identifiant unique pour une session, habituellement créé localement à l'AE. SOURCE_ADDR : cet attribut est défini pour spécifier l'adresse de l'initiateur de la session de signalisation, c-à-d l'adresse source du générateur du message initial de signalisation (le NI). DEST_ADDR : cet attribut est défini pour spécifier l'adresse du nœud de terminaison de la session de signalisation (le NR). START_TIME : Le temps du début de session (la création).


93

END_TIME : Le temps de la fin de session. NSLP_OBJECT_LIST : pour spécifier une liste d'objets NSLP spécifiques. AUTHENTICATION_DATA : Les données d'authentification de l'objet d'autorisation de session.

Ces types d'attributs seront détaillés dans les paragraphes suivants.

7.3.1. L‘attribut AUTH_ENT_ID

L'identifiant de l'AE (AUTH_ENT_ID pour Authorizing Entity Identifier) est utilisé pour identifier l'entité qui a généré le PE (policy element).

Il peut être représenté sous divers formats, son sous-type (SubType) est utilisé pour définir le type de l'ID. Le format de cet attribut est schématisé sur la figure 52 :

Figure 51 : Format de l'attribut AUTH_ENT_ID

Le champ Length indique la longueur de l'attribut.

X-Type : c'est AUTH_ENT_ID

SubType : dix sous-types ont été définis pour cet attribut :

IPV4_ADDRESS, IPV6_ADDRESS, FQDN (Fully Qualified Domain Name), ASCII_DN (ASCII Distinguished name), UNICODE_DN, URI (Universal Resource Identifier),KRB_PRINCIPAL (Fully Qualified Kerberos Principal name), X509_V3_CERT, PGP_CERT (OpenPGP certificate), HMAC_SIGNED.

OctetString : la présence de ce champs dépend de champs SubType, s'il est présent, il contient l'identifiant de l'AE (par exemple son adresse IP).

7.3.2. L‘attribut SESSION_ID

L'identifiant de session est un ID unique utilisé par l'AE pour identifier la requête (différent de l'ID de la session de GIST). Il peut être utilisé à plusieurs fins, y compris la détection d’attaques par rejeu du message, ou pour corréler cette requête avec une entrée de


94

décision faite par l'AE. Par exemple, le SESSION_ID peut être basé sur des numéros de séquence simples ou sur un timestamp NTP standard.

Le format de cet attribut est équivalent à celui de l'attribut précédent (AUTH_ENT_ID) où :

Length : est la longueur de l'attribut.

X-Type : SESSION_ID.

SubType : ce champ doit être égale à 0 (c-à-d sans sous type).

OctetString : contient l'ID de session (la valeur).

7.3.3. L‘attribut SOURCE_ADDR

Cet attribut est utilisé pour définir l'adresse source de l’initiateur de la session à autoriser. Il peut être utile dans quelques scénarios afin d'assurer que la requête ait été autorisée pour cette adresse source (et/ou port) particuliers. Généralement, elle correspond à la source de signalisation, par exemple, l'adresse source du paquet GIST, ou du flux, ou l'adresse de destination du flux, respectivement, qui sont contenus dans l'objet MRI de GIST.

Cet attribut suit le même format que les précédents, et contient les champs suivants:

Length : Longueur de l'attribut.

X-Type : SOURCE_ADDR

SubType : 4 sous types sont définis : IPV4_ADDRESS, IPV6_ADDRESS, UDP_PORT_LIST, TCP_PORT_LIST, SPI (Security Parameter Index).

OctetString : contient la valeur de sous type (s) spécifié (s) (par exemple, l'adresse IPv4 source et le port UDP ).

7.3.4. L‘attribut DEST_ADDR

Cet attribut est utilisé pour spécifier l'adresse de destination de la session à autoriser. Il peut être utile dans quelques scénarios afin d'assurer que la requête a été autorisée pour cette particulière adresse de destination (et/ou port).

Cet attribut a le même format et les mêmes champs que le précédent attribut SOURCE_ADDR.


95

7.3.5. L‘attribut START_TIME

L'attribut start_time est utilisé pour spécifier le temps de départ de la session à autoriser dans le but d'empêcher les attaques de rejoue. Si l'objet SESSION_AUTH_OBJECT est présenté dans une requête, le réseau devrait rejeter le message s'il n'est pas reçu dans les délais impartis.

Cet attribut suit le même format que les précédents :


X-Type : START_TIME

SubType : NTP_TIMESTAMP son format est défini dans la RFC5905.

OctetString : contient la valeur de ce temps de départ.

7.3.6. L‘attribut END_TIME

Cet attribut est utilisé pour spécifier le temps de fin de la session à autoriser, dans le but de limiter la période d'exploitation des ressources.

Cet attribut suit le même format et a les mêmes champs que l'attribut START_TIME.

7.3.7. L‘attribut NSLP_OBJECT_LIST

Cet attribut contient une liste de tous les types d'objet NSLP utilisés dans le calcul de hachage (keyed-hash computation) dont le résultat est donné dans l'attribut AUTHENTICATION_DATA. Ceci permet une protection d'intégrité des messages NSLP.

Le générateur de cet attribut (liste) énumère chaque type d'objet dont son objet a été inclus dans le calcul de hachage. Le hachage doit suivre l'ordre des types d'objet comme indiqué dans la liste.

Le récepteur peut vérifier l'intégrité de message NSLP en calculant un hachage de tous les objets NSLP énumérés dans cet attribut (dans l'ordre donné), y compris tous les attributs de l'objet d'autorisation.

Le format de cet attribut est décrit dans la figure 53 :


96

Figure 52 : Format de l'attribut NSLP_OBJ_LIST


X-Type : NSLP_OBJECT_LIST

SubType : Cet attribut n'a aucun sous-type, donc ce champ est rempli par des 0 et sera ignoré à la réception.

# of signed NSLP objects : indique le nombre n de types d'objet NSLP qui suivent.

rsv : 4 bits réservés; égale à 0 et sera ignoré à la réception, ce champs précède chaque :

NSLP object type (i) : ce champs identifie l'objet qui a été inclus dans le calcul de hachage (sur 12 bits).

padding : le padding est ajouté si le nombre d'objets NSLP est pair, ce champs est sur 16 bits de valeur 0 et son contenu sera ignoré à la réception.

7.3.8. L‘attribut AUTHENTICATION_DATA

Celui-ci contient les données d'authentification de l'objet SESSION_AUTH_OBJECT et signe (hash) toutes les données dans l'objet jusqu'à l'attribut AUTHENTICATION_DATA qui doit être le dernier attribut dans la liste. L'algorithme de calcul des données d'authentification dépend du champ SubType de l'attribut AUTH_ENT_ID.

Le format de cet attribut est similaire au format des précédents attributs (sauf NSLP_OBJ_TYPE), et contient les champs :


X-Type : AUTHENTICATION_DATA.


97

SubType : cet attribut est sans sous-type, ce champs est remplis par 0 et sera ignoré à la réception.

OctetString : une valeur contient les données d'authentification de SESSION_AUTH_OBJECT.

8. Composants de l’architecture utilisée dans la RFC 5981

La RFC 5981 [73] se réfère à différents scénarios de cas d'utilisation qui peuvent être appliquées pour assurer l'authentification des messages NSLP ainsi que leur intégrité, qui sont notamment : l'approche symétrique, l'approche asymétrique (X.509, PGP), Kerberos, et HMAC.

Le concept de base de l'autorisation de session défini dans la RFC 5981 est illustré sur la figure 54 :

Figure 53 : Architecture proposée dans la RFC5981

Le AE (Authorizing Entity) est responsable d'authentifier le NI et lui fournissant un jeton (PE Policy Element) pour qu'il puisse générer sa requête, tandis que le PDP (Policy Decision Point) a comme rôle de vérifier la requête reçu de la part de NAT/FW.

Comme illustré sur le diagramme (figure 55), l'échange de messages se fait comme suit :


98

Figure 54 : Diagramme d’échange de messages entre les nœuds

1. Un NATFW NSLP Initiateur (NI) demande une décision (Policy Decision) de l'AE (étape 1).

2. L'AE (étape 2) génère une réponse qui contient le PE et l'envoie au NI.

3. Lorsque le NI reçoit la réponse de l'AE, il crée l'objet SESSION_AUTH en copiant le PE reçu à son emplacement approprié dans l'objet, et enfin ajoute l'objet à la fin du message.

4. Le NI envoie le message (requête, par exemple CREATE) contenant le PE (étape 4) vers le NAT/FW.

5. A la réception de la requête par le NAT/FW (NF), ce dernier communique avec le PDP afin qu'il vérifie la requête reçue.

6. Le PDP extrait l'objet d'autorisation de session, vérifie son intégrité, prend une décision.

7. Le PDP envoie sa réponse (décision) au NAT/FW; dans le cas d'une réponse positive, c-à-d la requête est autorisée et acceptée, elle sera traitée plus loin par le NAT/FW, sinon elle sera rejetée en signalant au NI que l'autorisation a échouée.

Dans cette architecture, les performances en termes de temps d'exécution du mécanisme d'authentification sont considérablement affectées. En effet, cela est causé, d'une part, par la communication backend entre le NI et l’AE à chaque requête ( voir les messages 1, 2 sur le diagramme), et d'autre part, entre le NAT/FW et le PDP à chaque réception de la requête par le NAT/FW (5, 7).


99

9. Conclusion

Au cours de ce chapitre, une présentation générale de la plateforme NSIS a été effectuée dans un premier temps et par la suite, une étude détaillée a été consacré au protocole NATFW NSLP. Ainsi, nous avons introduit son principe de base, son fonctionnement et ses principales opérations telles que la création de session, la réservation d'adresse externe, et le rafraichissement de session. La suite a été consacrée à son implémentation en présentant ses principaux modules et leur interaction avec les autres applications externes, ainsi qu’avec le module système Iptables (Netfilter). Le reste du chapitre a présenté les menaces auxquelles le protocole NATFW NSLP peut être soumis, avec un tour d’horizon des travaux déjà mis en place pour sécurisé ce protocole, en décrivant l'objet d'autorisation de session utilisé dans ce contexte.

Une étude de performance de ce protocole NATFW NSLP a été faite par N. Steinleitner et al [72], cette étude a montré sa faisabilité, sa scalabilité et sa capacité à supporter jusqu'à des dizaines de milliers de flux de signalisation en parallèle. La puissance de ce protocole réside dans sa souplesse et son adaptabilité de fonctionner avec toutes les topologies réseau (tous types de NAT/FW possibles) avec un temps de réponse très acceptable [72].

Afin de répondre aux contraintes liées à la sécurité relative à tout nouveau protocole de signalisation, le groupe de travail NSIS a étudié et analysé les failles ainsi que les menaces éventuelles. Cependant, l'implémentation de NSIS et ses modules ne dispose pas des mécanismes d'authentification et d'autorisation requis pour les nœuds demandeurs. Cette problématique fera l’objet de notre contribution qui sera développée dans le chapitre suivant.

Chapitre 5 Intégration des mécanismes d'authentification dans NATFW NSLP

100

Chapitre 5

Intégration des mécanismes d'authentification dans NATFW NSLP


101

1. Introduction

Nous avons présenté dans le chapitre précédent comment le protocole de signalisation NATFW NSLP a été développé afin de permettre la configuration dynamique des routeurs NATs et des pare-feu pour assurer la traversée du protocole de signalisation SIP (voir figure 47). Le principe étant l'ouverture d'un trou d'épingle à un flux bien précis afin qu’il soit acheminé au travers de l’infrastructure réseau justement sécurisée par ces dispositifs de sécurité mis en place. Cette opération assez délicate, fragilise l'objectif principal de ces dispositifs et comporte un risque du point de vue authentification afin d’éviter tout accès non autorisé.

Figure 55 : Configuration de NAT/FW (CREATE, RESPONSE)

La suite de notre travail s’articule autour d’un double objectif qui consiste en premier lieu à proposer un mécanisme d'authentification et d'autorisation permettant au dispositif NAT/FW de ne pas accepter la requête d'un initiateur NI qui ne soit pas authentifié, ni d’exécuter l'action qu’il a demandée. En second lieu, la solution proposée doit préserver les performances des protocoles de signalisation NATFW NSLP et SIP.

Dans nos contributions, nous avons porté un intérêt particulier à la RFC5981 [73] dont nous nous sommes inspirés. Cette RFC, assez récente, regroupe la majorité des mécanismes d'authentification possibles à l'usage dans la couche NSLP, y compris le protocole NATFW.

En effet, cette RFC décrit l’utilisation des mécanismes d'authentification, en définissant l’objet d'autorisation spécifié qui sert au transport des informations nécessaires à identifier le NI et le NAT/FW; ainsi que l'architecture adoptée. Cette approche, nous facilitera la description détaillée des mécanismes d'authentification et d'autorisation que nous avons adoptés et dans le cadre de l'architecture proposée. Par ailleurs, une analyse de nos mécanismes sera faite en montrant leurs capacités et points forts ainsi que leurs limitations.


102

2. Premier mécanisme d'authentification adopté

Parmi les mécanismes d'authentification disponibles qui sont cités dans la RFC 5981 [73], nous nous sommes intéressés au mécanisme HMAC, et ce choix est justifié par :

Les contraintes du flux VoIP et le protocole de signalisation SIP qui requièrent une courte durée pour l'établissement des sessions. Doter le protocole NATFW NSLP d’un mécanisme d'authentification léger et rapide serait plus avantageux à ce type de communications.

L'authentification basée sur MAC est souvent considérée plus efficace que les signatures [78].

La simplicité d'utilisation et de déploiement. Ce mécanisme permet d’assurer l’authenticité du paquet et de garantir son intégrité.

2.1. Fonctionnement du mécanisme HMAC

La technique HMAC (keyed-Hash Message Authentication Code) est un type de code d'authentification de message MAC (Message Authentication Code), calculé en utilisant une fonction de hachage cryptographique en combinaison avec une clé secrète [79]. Ce MAC (hash ou condensé) peut être utilisé pour vérifier à la fois l'intégrité des données et l'authenticité d'un message. N'importe quelle fonction itérative de hachage, comme SHA-1, peut être utilisée dans le calcul d'un HMAC; le nom de l'algorithme résultant est HMAC-SHA-1. La qualité cryptographique du HMAC dépend de la qualité cryptographique de la fonction de hachage, de la taille et la qualité de la clé.

Une fonction itérative de hachage découpe un message en blocs de taille fixe et itère dessus avec une fonction de compression. Par exemple, SHA-1 opèrent sur des blocs de 512 bits. La taille de la sortie HMAC est la même que celle de la fonction de hachage (160 bits dans SHA-1), bien qu'elle puisse être tronquée si nécessaire.

La fonction HMAC est définie comme suit :

HMACK (m) = h ((K ⊕ opad) || h ((K ⊕ ipad) || m))

avec :

h : une fonction de hachage itérative, par exemple SHA-1. K : la clé secrète complétée avec des zéros pour qu'elle atteigne la taille de bloc de la fonction h, m : le message à authentifier, "||" désigne une concaténation, et "⊕" un "ou" exclusif, ipad et opad, chacune de la taille d'un bloc, sont définies par : ipad = 0x363636...3636 et opad = 0x5c5c5c...5c5c. Donc, si la taille de bloc de la fonction de hachage est 512, ipad et opad sont 64 répétitions des octets, respectivement, 0x36 et 0x5c.


103

La figure 56 représente le déroulement de calcul de HMAC :

Figure 56 : Déroulement du hachage avec HMAC [79]

Après le calcul du MAC, le message est envoyé au destinataire en joignant son MAC calculé (voir figure 57), à la réception, le destinataire recalcule le MAC du message (avec la même fonction de hachage et la même clé secrète partagée), et le compare au MAC reçu, l'égalité assure l'authenticité, sinon le message est altéré.

Figure 57 : Vérification d'authenticité avec le MAC


104

Dans le contexte d'authentification des messages de protocole NATFW NSLP, le MAC est porté par l'objet d'autorisation de session, qui sera joint au message à envoyer au NAT/FW. Cependant, afin que le NAT/FW puisse recalculer le MAC, des informations sont nécessaires, comme la clé, l'algorithme de hachage, les parties de message subissant le hachage ...etc.

Pour cela, dans la section suivante, nous allons décrire l'objet d'autorisation et les informations qu'il transporte (dans ses attributs) dans le cas du mécanisme HMAC.

2.2. L'objet SESSION_AUTH_OBJECT en utilisant le mécanisme HMAC

Un objet SESSION_AUTH_OBJECT, qui porte l'attribut AUTH_ENT_ID avec le sous type HMAC_SIGNED, est utilisé afin de garantir l'intégrité des messages NSLP. Dans ce cas, l'objet SESSION_AUTH_OBJECT doit contenir les attributs suivants :

SOURCE_ADDR : l'adresse source de l'entité qui a créé l'objet SESSION_ AUTH et qui a calculé le MAC. Il permet de lier l'objet d'autorisation au message NSLP correspondant. START_TIME : c'est l'estampille temporelle, timestamp, où le condensé a été calculé. Celui-ci doit être différent dans les deux messages en séquence afin d'empêcher les attaques par rejeu. NSLP_OBJECT_LIST : cet attribut liste (énumère) tous les objets NSLP inclus dans le calcul du HMAC. AUTHENTICATION_DATA : cet attribut contient l'identifiant de la clé utilisée dans le calcul de HMAC aussi bien que le MAC.

Afin de spécifier le type d'algorithme de hachage utilisé, l'objet le spécifie par le champ "Transform ID" (donné comme Transform type 3 de registre IKEv2 [80]) situé dans l'attribut AUTH_ENT_ID, où chaque algorithme défini dispose d’un identifiant spécifique [81, 82]. Cela permet une adaptation et une évolutivité des nouveaux algorithmes de hachage plus efficace [75].

Le sous type HMAC_SIGNED de l'attribut AUTH_ENT_ID indique que l'attribut AUTHENTICATION_DATA contient un MAC. Le hachage se fait sur tous les objets NSLP données dans l'attribut NSLP_OBJECT_LIST qui doit également être présent.

Les objets de base de GIST tels que le SESSION_ID, le NSLPID, et le MRI doivent être toujours inclus dans le hachage qui permet de détecter s’ils ont été modifiés par un attaquant. En effet, comme ils ne sont pas portés dans le NSLP lui-même, mais seulement dans GIST, ils doivent être inclus dans le calcul de hachage et livrés via l'API de GIST.


105

La figure 58 présente le format complet d'un objet SESSION_AUTH_OBJECT utilisé pour assurer l'authentification et l'intégrité des messages NSLP avec le mécanisme de hachage HMAC.

Figure 58 : Description de l’objet SESSION_AUTH_OBJECT

Les flags A et B, dans cet objet sont obligatoirement mis respectivement à 1et à 0 (voir figure 58), afin d’informer le récepteur (c-à-d le NAT/FW) que le message reçu doit inclure cet objet et s'il ne peut pas l'identifier ou identifier l'un de ses attributs, la totalité du message NSLP sera rejetée.


106

3. Description des procédures d'authentification et d'autorisation

3.1. L'architecture proposée

Puisque le mécanisme HMAC fonctionne en utilisant une fonction de hachage cryptographique en combinaison avec une clé secrète, la gestion des clés est un problème à part entière, qui se révèle parfois aussi complexe que la détermination des procédés d'authentification et d’intégrité. L'utilisation des clés partagées nécessite la mise en place d’un moyen d’échange, de stockage, et de contrôle sécurisés. Par conséquent, aucune partie non autorisée ne peut détenir la clé.

Afin d'éviter la communication backend additionnelle entre le NI et l’AE d’un côté , et entre le NAT/FW et le PDP de l’autre côté, à chaque message (cf. section 5), l'exigence suivante doit être posée : le NI assume la génération de l'objet d'autorisation ainsi que la totalité de la requête quant au NAT/FW, il est chargé de la vérification, de l'authentification et de l'autorisation, sans faire appel à une tierce partie. Il s’ensuit qu'ils doivent partager une clé pour qu'ils puissent hacher leurs messages.

Dans l'objet d'autorisation, l'identifiant de la clé dans AUTHENTICATION_DATA (KEY_ID) permet la référence à la clé appropriée. La taille de la clé doit être assez grande (conséquente) afin de supporter les attaques de type brute-force pendant la période de sa validité.

En général, l'échange des clés entre les nœuds dans un réseau, peut être réalisé par le biais de diverses façons [83]. Les méthodes possibles sont :

Méthode 1 : L'un des deux nœuds génère la clé et la délivre physiquement à l'autre. Méthode 2 : Une entité tierce calcule la clé et la distribue manuellement aux autres nœuds. l'avantage de ces deux premières méthodes est que les données sont échangées seulement avec le partenaire. Leurs inconvénients sont : (i) dans un grand système distribué, il est difficile et lent de transmettre manuellement un grand nombre de clés. (ii) dans un réseau contributif, la collecte manuelle des clés augmente la complexité de l'ensemble du système. (iii) Des millions de clés peuvent être nécessaires au niveau de nœud (applications, utilisateurs, processus). Méthode 3 : Dans l'établissement d'une session sécurisée, l'un des deux nœuds chiffre une nouvelle clé avec la vieille clé et la livre à l'autre. Les avantages de cette méthode sont : (i) La transmission manuelle devient limitée. (ii) Possibilité de distribution d'un grand nombre de clés au niveau de nœud ainsi qu'au niveau applications. Ses inconvénients sont : (i)


107

Si un attaquant est capable de deviner une clé, il peut facilement évaluer les clés suivantes. (ii) Une distribution initiale des millions de clés persiste. Méthode 4 : Chacun des deux nœuds a une connexion sécurisée avec une entité tierce qui distribue la clé en toute sécurité. Les avantages de cette méthode : (i) : Une clé principale unique pour chaque système ou utilisateur d'extrémité. (ii) Une clé de session unique pour chaque session ultérieure. (iii) La durée de distribution de clés dans une session peut être facilement manipulée dans des protocoles orientés connexion. Ses inconvénients sont : (i) La distribution de la clé principale est physique. (ii) Dans les protocoles non orientés connexion, des millions de clés doivent être générées d'une manière rapide, sinon ceci peut exposer le système aux attaques.

En faisant cette analyse des méthodes de distribution des clés, il est évident que la dernière méthode est la plus avantageuse vu qu'elle s'adapte mieux au protocole NATFW NSLP. De plus, cette architecture est la plus conseillée par les chercheurs de sécurité, et est adopté dans plusieurs protocoles de sécurisation pour la gestion de clés symétrique (appelés TTP : Trusted Third Party Based Protocols) [83].

De ce fait, nous avons proposé l'utilisation de serveur Diameter qui fournit les mécanismes de base pour établir un transport fiable, délivrer les message et gérer les erreurs ainsi que les services de sécurité que toutes les implémentations doivent supporter. Diameter a repris les principales fonctions et en a rajouté de nouvelles pour s’adapter aux nouvelles technologies (IPv4 Mobile, par exemple) et plus particulièrement offrir des services aux applications mobiles. Il est extensible et peut donc offrir des services d’authentification pour les nouvelles technologies sans fils, cellulaire, VPN ...etc. Diameter permet de réaliser des négociations, faire de la notification d’erreurs, fournir les services de bases nécessaires aux applications comme la prise en charge des sessions des utilisateurs.

Ainsi, l'architecture réseau proposée, où le processus d'authentification se déroule, est illustrée sur la figure 59.


108

Figure 59 : L'architecture proposée pour l'authentification et l'autorisation

Dans cette architecture, nous avons les trois entités suivantes :

Le NI : l'initiateur qui génère la requête d'ouverture de trou d'épingle et le NAT binding, mais également l'objet d'autorisation de session.

Le NAT/FW (NF) : le récepteur de la requête, qu’il authentifie et autorise et enfin se charge de l'exécution de l'action demandée.

Le serveur Diameter qui se charge de la distribution de la clé partagée entre le NI et le NAT/FW, cette clé sera utilisée par le NI dans l'opération de hachage lors de la génération de l'objet d'autorisation et la requête, et par le NAT/FW pour vérifier l'authenticité d'émetteur et à l'autorisation. La liaison entre le serveur est les deux entités (NI et NATFW) se fait à travers d’un canal sécurisé grâce au protocole Diameter [84].

Le déroulement du mécanisme d'authentification et d'autorisation dans cette architecture se fait selon les étapes suivantes illustrées sur la figure 59 :

- L'étape (ou les étapes) de distribution de la clé privée kp par le serveur entre le NI et le NAT/FW (A, B, C, D), ne s'établissent qu'à la demande de NI ou du NAT/FW et pas à chaque requête, ce qui justifie leur indication (en lettres A, B, C, D) différemment des autres étapes (en chiffres 1, 2, 3).


109

- L'étape de génération du message (incluant l'objet d'autorisation de session) par le NI (1).

- L'étape d'envoi du message (2). - Et enfin, l'étape de vérification d'authenticité et l'autorisation (3).

Ces étapes sont illustrées sur le diagramme donné sur la figure 60, et seront détaillées dans la section suivante.

Figure 60 : Diagramme d'échange des messages dans l'architecture proposée

3.2. Déroulement de la procédure d'authentification et d'autorisation

3.2.1. Distribution de la clé partagée

La distribution de la clé est déclenchée à la demande d'un client NI, qui envoie une requête au serveur Diameter. Cette requête doit contenir les « credentials » nécessaires pour que le serveur puisse authentifier le client. Le type de communication que nous adoptons dans ces canaux, entre le serveur et les clients, est basé sur une approche asymétrique (chiffrement asymétrique).

La réponse du serveur doit contenir, en plus de la clé, un identifiant de cette clé, une date de début et une date de fin utilisées pour vérifier sa validité, ainsi qu’un identifiant de l'algorithme à utiliser dans le hachage. En outre, la réponse devrait également être envoyée au NAT/FW, à la demande, qui va partager cette clé avec le NI demandeur. Lorsque le NI reçoit la réponse de serveur, il sauvegarde l'identifiant de la clé, sa période de validité et l'identifiant de l'algorithme de hachage ainsi que la clé elle même dans une table dédiée.


110

3.2.2. Génération du message

Lorsqu'un message NATFW NSLP (par exemple CREATE) est créé par l'émetteur NI, avant l'envoi d'un tel message, l'objet SESSION_AUTH_OBJECT doit être ajouté :

Le NI, avant la création du l'objet d'autorisation, vérifie la validité de la clé (date de fin d'utilisation dépassée), sinon il envoie une requête au serveur pour avoir une nouvelle clé. Dans le cas où celle-ci est encore valide, le NI procède à la génération de l'objet d'autorisation SESSION_AUTH_OBJECT, il calcul le MAC, l'insère dans l'attribut AUTHENTICATION_DATA de l'objet, insère l'objet à la fin du message, et enfin envoie le message au NAT/FW.

3.2.3. Traitement du message reçu par le NAT/FW

A la réception de la requête par le NAT/FW, ce dernier avant d'exécuter l'action demandée, il doit d'abord extraire l'objet SESSION_AUTH_OBJECT inclus, et vérifier ses attributs :

- AUTH_ENT_ID : la vérification de cet attribut a pour but de voir si le NAT/FW supporte l'algorithme spécifié dans les champs (HMAC_SIGNED, Transform ID), et dans ce cas, l'attribut suivant qui doit être vérifié est :

- START_TIME : la vérification de cet attribut permet de garantir que la requête n'est pas rejouée.

- NSLP_OBJECT_LIST : l'extraction de cet attribut permet au NAT/FW d'identifier les objets de la requête qui devraient être inclus dans le calcul.

- AUTHENTICATION_DATA : le NAT/FW extrait l'identifiant de la clé (key_id) à utiliser dans le calcul de hachage, et recherche la clé ayant cet identifiant dans une table sauvegardée localement contenant les clés partagées (envoyées par le serveur) avec les clients NIs. Si l'identifiant n'est pas trouvé, il envoie une requête au serveur de la même façon que le NI.

Le NAT/FW calcul le MAC en utilisant l'algorithme HMAC, et la clé partagée, sur les objets spécifiés. Ce MAC calculé est ensuite comparé avec celui reçu, ce qui permet de continuer le traitement de la requête. Une fois l'intégrité, l'authenticité et la validité de la requête de service ont été vérifiées, le NAT/FW doit consulter sa politique d'autorisation afin de déterminer si la requête spécifiée est autorisée en vérifiant que le service demandé n'est pas occupé.

3.2.4. La signalisation d'erreurs

Le NAT/FW rejette la requête et refuse de la traiter dans les cas suivants :

- Si l'algorithme de hachage n'est pas supporté.


111

- Si l'estampille temporelle "timestamp" fournie dans l'attribut START_TIME n'est pas récente, ce qui indique que le message reçu a été rejoué, par conséquent il doit être rejeté.

- Si l'identifiant de la clé n'est pas trouvé localement. - Et si le MAC calculé ne correspond pas à celui reçu dans la requête, ceci indique

que la requête a été modifiée ou altérée lors de son transit.

Lorsque le NAT/FW ne vérifie pas l'objet SESSION_AUTH_OBJECT, ou lorsque l'un des cas de rejet de la requête est posé, le NATFW NSLP envoie un message d'erreur indiquant que l'autorisation a échouée.

4. Analyse de mécanisme et de l'architecture adoptés

Le mécanisme adopté dans l'architecture proposée se caractérise par les points forts et les avantages suivants :

L'efficacité du mécanisme HMAC

Le mécanisme HMAC est connu par sa rapidité et son extrême efficacité dans le processus d'authentification, il a été retenu par l'IETF dans le protocole IPsec et ce qui l’a fait adopter par plusieurs protocoles et applications [78]. L'utilisation de ce mécanisme dans la sécurisation du protocole NATFW NSLP garantit l'authenticité des messages, ainsi, l'ouverture de trous d'épingle, par exemple, à un utilisateur illégitime est évitée. Ainsi les NATs et pare-feu gardent leur objectif principal.

Architecture et gestion de clé plus appropriées

L'architecture réseau proposée est appropriée et adaptable au protocole NATFW NSLP, puisqu'elle le décharge de la gestion de clés partagées entres ses nœuds, et lui permet ainsi de s'exécuter rapidement avec un mécanisme d'authentification efficace qui conserve les performances de ce protocole.

Garantie d'intégrité des messages NSLP

L'objet d'autorisation utilisé assure l'intégrité de tous les échanges de signalisation NATFW NSLP (requêtes et réponses). L'émetteur crée l'objet SESSION_AUTH_OBJECT, puis avec la clé partagée il génère un hash de tous les objets NSLP qu’il énumère dans l'attribut NSLP_OBJECT_LIST. Par l'inclusion de cet objet dans le message NSLP, le récepteur de ce message peut vérifier son intégrité. N'importe quelle réponse adressée à l'émetteur devrait également être protégée par l'inclusion de l'objet afin d'empêcher un attaquant d’usurper l’identité du NAT/FW. Basé sur cette authentification, le NAT/FW peut


112

appliquer les politiques d'autorisation aux actions telles que l'ouverture des trous d'épingle demandés.

L'intégrité de l'objet d'autorisation lui même

L'intégrité de l'objet d'autorisation est préservée car l'intégrité de tous les objets NSLP listés dans NSLP_OBJECT_LIST est vérifiée, y compris les composants de l'objet SESSION_AUTH_OBJECT.

L'empêchement des attaques par rejeu

L'objet SESSION_AUTH_OBJECT doit inclure le champ START_TIME, ce temps de départ (timestamp) est utilisé comme moyen pour vérifier que la requête n'est pas rejouée. Si le timestamp fourni dans l'attribut START_TIME n'est pas assez récent, le message est négligé et une erreur générée.

Le NAT/FW ainsi que les NIs doivent supporter le protocole NTP pour assurer une synchronisation appropriée de leur horloge sinon, les attaques par rejeu peuvent se produire.

Minimisation de la taille de l'objet

Le mécanisme adopté fonctionne avec une clé secrète, l'utilisation de clés secrètes avec le HMAC garde la taille de l'objet d'autorisation à un minimum strict, car la taille du MAC calculé dépend de l'algorithme de hachage utilisé.

Cependant, malgré ces points forts de ce mécanisme adopté dans l'architecture proposé, quelques limitations dans le cadre de sécurité peuvent être signalées, en particulier, ce mécanisme ne permet pas clairement d'assurer la confidentialité des messages NSLP. Par ailleurs, il ne permet pas de garantir la non-répudiation des émetteurs. En effet, il est admis que cette dernière propriété (la non-répudiation) peut être atteinte seulement en utilisant la technologie du certificat numérique signé par une Autorité de Certification.

Néanmoins, la confidentialité des messages peut être atteinte par un algorithme de cryptage effectuant un chiffrement de message à envoyer avant son émission, puis le déchiffre lors de sa réception. Ce mécanisme de chiffrement assure l'intégrité de données envoyées ainsi que l'authentification de l'émetteur (relativement). Dans les sections suivantes un nouveau mécanisme sera présenté qui assure, en plus, la confidentialité.

5. Description de deuxième mécanisme adopté E-MAC

Dans la construction des canaux sécurisés en cryptographie, il existe deux approches principales : une approche dédiée et une approche générique. L'approche dédiée consiste en un algorithme de chiffrement conçu pour réaliser un système autonome de chiffrement et d'authentification [85]. Dans l'approche générique, une fonction de hachage est combinée


113

avec un algorithme de chiffrement. Cette dernière approche peut être construite de trois manières différentes (voir figure 61) : chiffrement puis hachage (EtA : Encrypt-then-Authenticate), hachage puis chiffrement (AtE : Authenticate-then-Encrypt), chiffrement et hachage en parallèle (E&A : Encrypt and Authenticate).

(a) (b) (c)

Figure 61 : Les modes : EtA (a), AtE (b) et E&A (c)

La composition dans l'approche générique possède plusieurs avantages de conception et d'analyse, par rapport à l'approche dédiée, en raison de sa modularité, et le fait que les systèmes de chiffrement et d'authentification peuvent être conçus, analysés et implémentés indépendamment l'un de l'autre [86]. De plus, et le plus important, les compositions génériques peuvent conduire à des implémentations plus rapides lorsque les algorithmes de chiffrement rapide (tels que stream ciphers, les chiffrements de flux), sont combinés avec les MACs rapides, comme les fonctions de hachage universelles (UMACs).

Cependant, EtA est le mode le plus recommandé par la plupart des chercheurs, puisque généralement, il est plus facile de prouver sa robustesse. Ferguson et Bruce Schneier, dans leur livre "Practical Cryptography" [87], ont soutenu le contraire : AtE est de l'ordre «naturel», EtA est trop complexe, et peut être fait incorrectement : en décrivant une attaque sur une instance de IPsec dont le mode est EtA.

B. Alomair et al [88] ont étudié les différents modes de composition générique, et ont proposé une nouvelle approche (E-MACs) qui peut être utilisée dans les modes AtE et E&A afin d'augmenter leur efficacité et leur niveau de sécurité dans le processus d'établissement des canaux sécurisés. La fonction de hachage utilisée est de la famille UMAC, mais avec moins d'opérations de calcul qu'exige cette famille, et elle s'effectue également sans crypter l'image compressée. Par ailleurs, elle profite des avantages des structures particulières des modes E&A et AtE pour améliorer la sécurité du processus d'authentification et de confidentialité. Finalement, elle pourrait être protégée contre l'attaque Key Recovery, auxquels les UMACs standards se sont avérés vulnérables [89].

Le mécanisme E-MACs proposé diffère de la primitive de chiffrement authentifié (l'approche dédiée) qui est conçue pour fonctionner comme un système autonome. Ce nouveau mécanisme consiste en un MAC à usage spécial bénéficiant d'un algorithme de cryptage, afin de construire des systèmes génériques efficaces. La structure de ces systèmes dans les deux modes ne nécessite pas d'employer des familles de fonctions pseudo-aléatoires,


114

ce qui augmente la vitesse de construction du MAC et permet de réduire le nombre des clés partagées requises.

5.1. E-MAC dans la composition AtE

La structure de ce mode est illustrée sur la figure 62 :

Figure 62 : Structure de AtE avec E-MAC

Dans ce mode, une image compressée du message est tout d'abord calculée selon l’expression (1) par E-MAC et une clé privée partagée kE-MAC. L'image est ensuite concaténée au message (en clair), le résultat est crypté par un algorithme de chiffrement (dont la clé est kE). La sortie est transmise au destinataire prévu.

L'image du message est calculée par E-MAC comme suit :

σ = 푘 m modp(1)

où :

- σ est l'image calculée de taille N. - ki dénote le bloc numéro i de la clé utilisée dans le calcul, - mi le bloc numéro i du message M. En effet, le message M ainsi que la clé partagée (KE-MAC) sont divisés en blocs :

o Le message M||1 = m1||m2||......||mL; L est le nombre de blocs du message M, où : L = [|M|/N] et |mi|= N pour tout bloc sauf mL (|mi| dénote la longueur en bits du bloc mi);

o La clé KE-MAC= (K1; K2;.....; KB); B est le nombre de blocs de la clé, tel que B >= L+1; o La relation entre N, B et la taille maximale acceptable du message M est donnée par :

MaxLen = (N*B)-1, la condition réside dans la longueur du message qui ne doit pas être supérieure à (N*B)-1.

- p est le plus grand nombre premier inférieur à 2N, (par exemple pour N = 32, p = 232 - 5).


115

5.2. E-MAC dans la composition E&A

La structure de ce mode est illustrée sur la figure 63 :

Figure 63 : Structure de E&A avec E-MAC

Un nombre premier aléatoire r (un nonce) est concaténé au message M en clair. Le résultat (M||r) est compressé selon l’expression (2) et en même temps crypté par un algorithme de chiffrement. Les deux sorties sont ensuite concaténées et transmises au destinataire prévu. L'image du message est calculée par E-MAC comme suit :

τ = 푘 m + 푘 rmodp(2)

Dans ce cas L <= B, MaxLen = (N*(B-1))-1

6. Le mécanisme E-MAC dans le NATFW NSLP Le mécanisme E-MAC dans les modes (E&A et AtE) s’adapte bien au protocole NATFW NSLP vu la possibilité d'exploiter l'objets d'autorisation pour transporter les informations nécessaires dans l'opération d'authentification et d'autorisation. De plus, dans le mode E&A, ce mécanisme s'exécute en parallèle avec l'algorithme de chiffrement, ce qui permet d'accélérer le processus de traitement. Cependant, ceci n'est pas garanti dans le mode AtE vu qu'il s'exécute en série, mais son avantage, par rapport au premier mode, est que le MAC calculé est également chiffré par l'algorithme de cryptage.

Au préalable, le NI détermine la taille N de MAC à calculer, et par conséquent le nombre p à partir de ce N. Il génère également un nonce r, décompose le message M en L blocs (en utilisant N), et la clé KE-MAC en B blocs. Tous ces paramètres, ainsi que les clés de hachage KE-MAC et de cryptage KE, doivent être fournis au récepteur du message (NAT/FW) pour qu'il puisse effectuer sa vérification d'authenticité de la requête et (après) le déchiffrement. De ce fait, nous proposons d'effectuer les adaptations suivantes, en respectant les conditions exigées :


116

Le nonce r est généré au préalable par le NI avec la condition qu'il soit un nombre premier. Ce paramètre peut être inclus dans l'objet d'autorisation.

Le paramètre B permet la décomposition de la clé KE-MAC en blocs uniformes, il peut être inclus aussi dans l'objet.

Les clés KE-MAC et KE (de cryptage), ainsi que le paramètre N, doivent être fournis par un autre moyen que l'objet (serveur Diameter).

Pour que le message réponde aux conditions |M|<=MaxLen et que B >= L (ou L+1); La clé KE-MAC doit être assez longue, si N=32, |KE-MAC|=256 bits avec B=32 blocs et |ki|=8 bits, les conditions restent valides pour une longueur de message égale à 120 octets, puisque dans ce cas L=[|M|/N]=30<B, et MaxLen=(N*(B-1))-1=991 bits>960 bits (120 octets).

6.1. L'objet d'autorisation en utilisant E-MAC

L’adaptation du mécanisme E-MAC au protocole NATFW NSLP se fera au niveau de l'objet d'autorisation de session. Par rapport au mécanisme HMAC, nous proposons d’effectuer les changements des attributs suivants:

1- Dans l'attribut AUTH_ENT_ID, nous remplaçons le sous type HMAC_ SIGNED par UMAC_SIGNED car E-MAC appartient à ce genre de fonctions universelles.

2- Nous supprimons l'attribut NSLP_OBJECT_LIST vu que la totalité du message est cryptée et compressée.

3- Nous remplaçons le KEY_ID dans l'attribut AUTH_DATA par le nonce r qui doit être ajouté à la fin du message,

4- Pour l'identifiant de la clé utilisée dans le calcul de MAC par E-MAC ainsi que le nombre de ses blocs, nous proposons d’ajouter un nouvel attribut : le SESSION_ID (voir section 4.3.2, et à ne pas confondre avec l'identifiant de session GIST). Le champ OctetString de cet attribut est divisé en deux sous champs : un pour le nombre de blocs de clé (B_BLOCKS sur 8 bits) et l'identifiant de clé Ke-mac (KEY_ID sur 24 bits).

5- Dans le mode AtE, le nonce r n'existe pas, par conséquent, le champs OctetSring de l'attribut AUTH_DATA contient uniquement le MAC :

6- Le MAC issu est concaténé à la fin de l'objet (et du message), mais après le cryptage dans le mode A&E.


117

Nous illustrons sur la figure 64 le nouveau format de l'objet d'autorisation de session que nous proposons avec le mécanisme E-MAC :

Figure 64 : Nouveau format de l'objet d'autorisation de session

Noter ici, sur la figure 64, que dans le mode AtE, le champs r_nonce n'est pas présent dans l'objet, l'attribut AUTH_DATA ne contient que le MAC (voir l'expression (1)).

6.2. Déroulement de la procédure d'authentification par E-MAC

6.2.1. Distribution des clés partagées

Nous gardons l'architecture précédente (voir section 7.1 et figure 59) dans laquelle la distribution des clés de cryptage et de hachage, se déclenche également à la demande d'un client NI, comme décrit auparavant. Cependant dans ce cas, en plus des clés, la longueur N du MAC qui est déterminé par le NI et envoyé au serveur Diameter afin qu'il l'achemine au NF lorsqu'il demande les clés. En outre, nous supposons ici que le NI utilise la même longueur N du MAC pendant la période de validité des deux clés qui doivent être distribuées et renouvelées ensembles.


118

6.2.2. Génération du message

Après la création du message, le NI, vérifie la validité des clés (il les demande en envoyant une requête au serveur Diameter, si la validité est expirée), puis il crée l'objet d'autorisation de session (voir figure 64) en ajoutant tous ses attributs; ensuite, il entame le calcul du MAC selon l'une des expressions :

(1) de mode AtE, dans ce cas, le r_nonce n'est pas présent et le MAC calculé est ajouté directement à l'objet. Après la construction de la totalité du message (y compris l'objet d'autorisation), le NI applique l'algorithme de cryptage afin de le chiffrer, et enfin l'envoyer.

(2) de mode E&A, dans ce cas le r_nonce est présent, et l'encryptions s'effectue en même temps avec le calcul du MAC; le message crypté et le MAC calculé sont concaténés, par la suite, puis envoyés au NF (voir figure 63).

A noter ici que le message et la clé de hachage sont divisés en L et B blocs, respectivement, en respectant les conditions décrites ci-dessus (B>=L+1, MaxLen=>|M|).

L'algorithme de cryptage que nous proposons est de type Stream Ciphers, par exemple Rabbit [90], ce type de algorithme est efficace et considéré le plus rapide [91].

Voici l'algorithme de hachage dans cette étape :

6.2.3. Traitement du message reçu par le NAT/FW

Tout d'abord, le NAT/FW décrypte le message reçu en utilisant l'algorithme de déchiffrement et sa clé, si cette dernière n'est pas valide, le NAT/FW sollicite le serveur avec l'autre clé de E-MAC (KE-MAC) ainsi que la longueur N de MAC, ce N est utilisé pour :

- Différencier entre la partie crypté et le MAC (dans le mode E&A).

- Déterminer le nombre p (voir les expression (1) et (2)).

- Diviser le message M en L blocs.

Algorithme S(K, M, r) Début Si |M| > MaxLen alors Fin Diviser K en B blocs uniformes k1||k2||.... ||kB; M = M||1; Diviser M en L blocs m1||m2||.....||mL; Calculer le MAC Fin


119

Après le déchiffrement, le NAT/FW peut extraire les attributs de l'objet d'autorisation (qui sont maintenant en texte clair, c-à-d décryptés ) afin de les vérifier comme décrit dans la partie 7.2.3 (sauf pour NSLP_OBJECT_LIST qui n'est pas inclus dans ce cas). Par ailleurs, il extrait le paramètre B (du champ B_BLOCKS voir Figure 64) utilisé lors de la décomposition de la clé KE-MAC.

Le NAT/FW recalcule le MAC du message et le compare avec celui reçu, pour vérifier l'authenticité.

Dans cette étape, l'algorithme de vérification V, est le suivant :

6.3. Performances de E-MAC

Le mécanisme E-MAC proposé peut assurer les avantages de mécanisme précédent HMAC tels que l'intégrité des message, la protection contre l'attaque par rejeu de messages...etc. De plus, il se caractérise par :

La rapidité extrême

Les fonctions de hachage universelles (UMACs) sont considérées les plus rapides dans la construction des MACs (0.34 cycles/octet [88]); différemment à celles-ci, le hachage dans E-MAC est conçu sans la nécessité d'appliquer des opérations cryptographiques sur l'image compressée (chiffrement), parce que cela est remplacé par l'algorithme de chiffrement. De plus ce mécanisme calcul le MAC en moins d'opérations que nécessitent les UMACs standards, ces opérations se résument en quelques (peu) d'opérations d'addition et de multiplication.

Protection contre l'attaque de récupération de clé

Afin de contrer l'attaque de récupération de la clé de hachage (Key Recovery), E-MAC peut être protégé, dans le mode E&A, en ajoutant une chaîne aléatoire (le nonce r) à la fin du message en clair, et au lieu d'utiliser souvent l'expression (2), une nouvelle (3) est définie :

τ = (푘 ⊕ r)m + 푘 rmodp(3)

Algorithme V(K, M, r, MAC) Début Diviser K en B blocs uniformes k1||k2||.... ||kB; Diviser M en L blocs m1 ||m2 ||.....||mL; Recalculer le MAC Comparer le MAC calculé et le MACreçu

Si égalité Alors message authentifié Sinon Erreur Fin


120

Dans cette expression, le nonce r est utilisé dans le but de randomiser les clé KE-MAC, et ainsi une collision ne peut pas conduire à la divulgation de la clé.

Amélioration de l'efficacité et la sécurité de processus d'authentification

Par rapport au mécanisme HMAC où son MAC n'est pas chiffré, le mécanisme E-MAC augmente le niveau de sécurité puisque le MAC est crypté par l'algorithme de chiffrement utilisé dans le mode AtE. Ce niveau est également atteint par la structure des systèmes (modes) où il se déroule.

Confidentialité

La confidentialité assurée par l'algorithme de chiffrement utilisé avec E-MAC constitue la raison essentielle de notre intérêt pour ce mécanisme. Cependant, ceci peut augmenter le temps relatif au processus d'authentification, et afin de palier à cela nous avons proposé le type stream ciphers, et en particulier Rabbit qui est, considéré comme l'algorithme le plus rapide avec une efficacité extrême.

7. Conclusion

Ce chapitre a été principalement consacré à la présentation et l'explication des mécanismes d'authentification et d'autorisation adoptés pour le protocole NATFW NSLP, qui sont : le mécanisme HMAC, et E-MAC, avec un serveur chargé de la distribution, à la demande, des clés partagées entre l'initiateur du message et le NAT/FW pour les deux mécanismes. L'implémentation et l'évaluation des performances seront présentées dans le chapitre suivant.

Chapitre 6 Evaluation des performances

121

Chapitre 6

Evaluation des performances


122

1. Introduction

Dans le chapitre précédent, nous avons présenté les solutions d'authentification de protocole NATFW NSLP avec le mécanisme HMAC et E-MAC, dans une architecture qui comporte, en plus du NI, du NR, et du NF, un serveur Diameter distribuant les clés partagées entres eux.

Dans ce chapitre, nous présentons tout d’abord la méthode d'implémentation de l'objet d'autorisation de session décrit dans le chapitre précédent, ainsi que la plateforme et les techniques de test. Ensuite, nous consacrons le reste du chapitre à l’évaluation de la solution proposée par le biais des différentes métriques de performances.

2. Implémentation de l'objet d'autorisation

Pour créer l'objet d'autorisation de session (SESSION_AUTH_OBJECT) et ses attributs, nous avons besoin des classes principales NatFwSessionAuthAttr et NatFwSessionAuthObject. Cette dernière, représente l'ensemble de l'objet SESSION_AUTH_OBJECT qui se compose de plusieurs attributs avec un entête commun d'objet et suit la structure générale de la classe NatFwMessage. Quant à la classe NatFwSessionAuthAttr , elle représente un attribut de l'objet et suit la structure générale des autres classes d'objets. Ces deux classes principales héritent de la classe GenericObject.

La classe NatFwSessionAuthObject n'a pas de variables d'attributs. Le paramètre length spécifie la longueur de l'objet à créer, qui dans la plupart des cas, est initié à 0. Le constructeur construit l'entête commun de l'objet avec ObjectLength égale à la valeur donnée par le paramètre length. Initialement, au moment de la construction, il n'y a pas d'attributs (de l'objet), cela crée un besoin d'inclure une fonction qui ajoute chaque attribut à l'objet avec le bon ajustement de la longueur de l'objet dans l'entête (ObjectLength).

Cet objet d'autorisation est créé avec les autres objets de la classe NatFwMessage (de message). Ici, chaque attribut est créé séparément, puis ajouté à l'objet en ajustant la longueur de l'entête.

Pour générer le hachage assorti des objets NATFW NSLP spécifiés, y compris l'objet d'autorisation, nous avons choisi la fonction de hachage SHA-1 (Secure Hash Algorithme) pour le calcul de MAC de chaque message. SHA-1 produit des MACs de 160 bits en sortie en travaillant les données par blocs de 512 bits. cette fonctions est fourni par OpenSSL qui est déjà nécessaire pour l'exécution de NSIS.

OpenSSL est une « boîte à outils » de chiffrement comportant les bibliothèques suivantes : une bibliothèque de cryptographie générale et une bibliothèque implémentant le protocole SSL/TLS. OpenSSL offre les fonctionnalités suivantes :

• La création de clés RSA, DSA (signature).


123

• La création de certificats X509. • Le calcul d’empreintes (MD5, SHA, RIPEMD160, ...). • Le chiffrement et déchiffrement (RSA, DES, IDEA, RC2, RC4, etc...). • La réalisation de tests de clients et serveurs SSL/TLS. • La signature et le chiffrement de courriers (S/MIME).

3. Plateforme de test Nous avons utilisé dans la plateforme de test (voir figure 65) des PCs standards avec le système Linux Debian (Kernel 2.6.18), avec les caractéristiques suivantes :

- CPU, Pentium 4 3.6 GHz - Carte réseau, Realtek RTL8169/8110 - 1 Go DDRAM - 40 Go de disque dur

Figure 65 : Plateforme de test

La plateforme de test est constituée du :

NI : un PC dont l'adresse est privée.

NR : un PC dont l'adresse est publique.

Un routeur NAT/FW : qui s'agit d'un PC équipé de deux interfaces réseaux, la première (eth0) coté NR avec une adresse publique, la seconde (eth1) coté NI ayant une adresse privée. L'implémentation du NAT et du FW, sur ce PC, est faite par Netfilter (Règles iptables) dont les principales règles sont :

# Mise en œuvre du routage echo 1 > /proc/sys/net/ipv4/ip_forward # Politique du pare-feu iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP # Politique du NAT iptables -t nat -P PREROUTING ACCEPT iptables -t nat -P POSTROUTING ACCEPT iptables -t nat -P OUTPUT ACCEPT


124

# Activation du NAT (translation/masquerade) iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Autorisation des paquets du protocole NSIS/NATFW NSLP iptables -A INPUT -p udp --dport 4 -j ACCEPT iptables -A OUTPUT -p udp --dport 4 -j ACCEPT iptables -A FORWARD -p udp --dport 4 -j ACCEPT

Pour l'établissement des sessions il faut autoriser les paquets NSIS qui utilisent le port UDP numéro 4 (regarder les trois dernières règles).

Nous avons déployé et activé le protocole NATFW NSLP sur les trois nœuds, le NI, le NF (NAT/FW), et le NR, en ajustant le fichier de configuration pour chacun d'eux (voir annexe D).

Cependant, nous n'avons pas, par manque de temps, intégré le serveur Diameter (qui distribue les clés partagées) dans la plateforme de test, néanmoins les clés ont été partagé manuellement.

3.1. Techniques utilisées

Au préalable, nous avons effectué le scénario d'établissement de session par le protocole NATFW NSLP sans le mécanisme d'authentification par HMAC, puis nous avons relevé l’évolution des métriques de performance du protocole en fonction du nombre de sessions établies. Nous avons mesuré les mêmes métriques effectuées par Steinletner dans [72] pour ce protocole. Ces métriques sont : le temps de traitement, le temps d'établissement de session, la consommation de CPU et de mémoire que nous avons relevé de la manière suivante:

Pour calculer le temps d'établissement de session (SST Session Setup Time), des timestamps ont été insérés directement dans le code source, et un simple script nous calcule le temps entre les deux timestamps correspondants à une session.

Une approche similaire est utilisée pour calculer le temps de traitement des requêtes CREATE.

Un script (bash) est utilisé pour surveiller la consommation du CPU et de la mémoire.

4. Résultats et analyse

Dans cette partie, nous allons présenter les résultats des expériences réalisées afin de tester les facteurs qui nous informent sur les performances de protocole doté du mécanisme d'authentification HMAC adopté, par rapport aux mesures effectuées pour le même protocole sans mécanisme d'authentification, ceci face au nombre croissant de sessions établies (scalabilité). Les tests sont effectués en utilisant l'application de test "NatFwClient" décrite dans le chapitre 4 (voir section 4.1 ). L'application est exécutée sur le NI et crée une nouvelle session NATFW NSLP tous les quart de seconde en lançant une requête CREATE.


125

Chaque session créée appartient aux mêmes NI et NR mais avec différents ports (source et destination). Ainsi nous pouvons assurer que le NAT/FW crée un nouveau trou d'épingle pour chaque session. Tous les tests commencent avec zéro session et génèrent jusqu'à 50 000 sessions entre le NI et le NR sans suppression des sessions pendant les essais.

Au niveau du NAT/FW, le traitement des règles iptables par le firewall Netfilter représente un goulot d'étranglement pendant les tests et augmente le temps et le taux de consommation des ressources. Nous avons soustrait le temps de traitement et d'installation des règles iptables dans tous les tests, puisque les performances de Netfilter n'est pas notre intérêt dans ces expériences, mais juste le protocole NATFW NSLP avec et sans le mécanisme d'authentification. Les résultats obtenus représentent la moyenne de plusieurs essais, ceci en vue de garantir les précisions de mesures.

4.1. Temps de traitement

Le temps de traitement a été mesuré sur le NI (générateur de requête), ainsi que sur le NAT/FW (le vérificateur), la figure 66 montre les résultats de ces tests sur le NI.

Comme on peut le voir, le temps de traitement, pour les deux cas de protocole, est presque linéaire jusqu'à 20 000 sessions, puis il augmente légèrement en atteignant 47 ms pour le protocole avec HMAC, la différence entre les deux expériences (NATFW NSLP sans et avec HMAC) est légère : elle atteint environ 5% pour 5 000 sessions, puis 8% pour 25 000 sessions, et 16% pour 50 000 sessions. Le maximum de 50 000 sessions établies dans les tests est dû au Netfilter (responsable du goulot d'étranglement).

Figure 66 : Temps de traitement (NI)

0

10

20

30

40

50

60

5000 10000 15000 20000 25000 30000 35000 40000 45000 50000

Tem

ps d

e tr

aite

men

t (m

s)

Sessions

NATFW NSLP

NATFW NSLP (HMAC)


126

La figure 67 illustre les résultats des relevés du temps de traitement sur le NF, de la même manière que ceux obtenus pour le NI. On note que le temps de traitement, du protocole avec HMAC augmente progressivement et s'élève à près de 56 ms pour 50 000 sessions, le taux d'augmentation de temps entre les deux cas de protocole est : 4,5% pour 5000 sessions, 10% pour 25 000 sessions, et 18 % pour 50 000 sessions.

Le temps de traitement sur le NF est un plus long que sur le NI puisque celui ci traite aussi les réponses du NR afin d'activer les règles d'iptables. De plus, il recalcule le MAC et effectue la comparaison pour chaque requête.

Figure 67 : Temps de traitement (NF)

4.2. Temps d'établissement de session

Le second relevé de performance est consacré au temps d'établissement de session NATFW NSLP, qui représente le temps nécessaire pour établir une session entre le NI et le NR.

La figure 68 illustre les résultats relevés avec le même nombre de sessions effectués pour le temps de traitement. La première constatation est que le temps est moins de 220 ms pour le maximum nombre possible de sessions; l'augmentation du temps d'établissement de session est lente avec une différence de 6% pour 5 000 sessions (entre les deux cas de protocole), 15% pour 25 000 sessions, et presque 23% pour 50 000 sessions. noter ici que nous n'avons pas pris en compte le temps de traitement de Netfilter.

0

10

20

30

40

50

60

5000 10000 15000 20000 25000 30000 35000 40000 45000 50000

Tem

ps d

e tr

aite

men

t (m

s)

Sessions

NATFW NSLP

NATFW NSLP (HMAC)


127

Figure 68 : Temps d'établissement de session

4.3. Consommation du CPU

Dans ce cas, nous nous sommes intéressés à relever la consommation du CPU lors de l’utilisation du protocole NATFW NSLP dans les deux cas. La figure 69 montre la charge CPU du NI avec le nombre de sessions. Nous constatons que la charge CPU augmente plus rapidement face à plus de 25 000 sessions, mais ne dépasse pas un taux de 17.5% pour le protocole avec HMAC lorsque le nombre de 50 000 sessions est atteint. La différence, entre les deux cas (avec et sans HMAC) est de 12%. Par conséquent, nous pouvons déduire que le protocole n'introduit pas de gros coûts, et donc le nombre maximum de 50 000 sessions dépend (en plus de Netfilter ) aussi du protocole GIST.

Figure 69 : Consommation de CPU (NI)

0

50

100

150

200

250Te

mps

d'é

tabl

isse

men

t de

sess

ions

(m

s)

Sessions

NATFW NSLP

NATFW NSLP (HMAC)

02468

101214161820

5000 10000 15000 20000 25000 30000 35000 40000 45000 50000

Cons

omm

atio

n de

CPU

(%)

Sessions

NATFW NSLP

NATFW NSLP (HMAC)


128

La figure 70 illustre la charge CPU du NF, à partir de laquelle on peut constater que les graphes (de NI figure 69, et de NF figure 70) sont pratiquement similaires, mais avec une légère différence entre les valeurs, due aux traitements supplémentaires tel que le recalcule du MAC. Le taux de consommation du CPU de NF est de 18% pour le maximum nombre de sessions. La différence entre les deux cas de protocole est de : 4 % pour 5 000 sessions, 8% pour 25 000 sessions, et de 14 % pour 50 000 sessions. Ceci affirme un petit rapport de consommation de CPU entre les deux cas de protocole.

Figure 70 : Consommation de CPU (NF)

4.4. Consommation de la mémoire

Le dernier relevé, consiste à mesurer la consommation de mémoire. La figure 71 illustre sur le NI , l'impact du nombre de sessions sur l'utilisation de la mémoire pour les deux cas de protocole NATFW NSLP sans et avec HMAC.

L'utilisation de la mémoire par le NATFW NSLP avec HMAC augmente presque linéaire, mais plus lentement. La différence entre les deux cas de protocole est également petite : 6% pour 5 000 sessions, 8% pour 25 000 sessions, et 12,7% pour 50 000 sessions. Ces chiffres confirment que le protocole NATFW NSLP avec HMAC n'a qu'une petite influence sur la consommation de mémoire par rapport au cas sans HMAC.

0

2

4

6

8

10

12

14

16

18

20

5000 10000 15000 20000 25000 30000 35000 40000 45000 50000

Cons

omm

atio

n de

CPU

(%)

Sessions

NATFW NSLP

NATFW NSLP (HMAC)


129

Figure 71 : Consommation de mémoire (NI)

La figure 72 présente les résultats des relevés de l'utilisation de la mémoire sur le NF, la différence entre les deux cas de protocole, maintenant, est un peu plus grand que sur le NI, ceci puisque le NF recalcule aussi le MAC à la réception de chaque requête CREATE. Nous avons enregistré les différences suivantes : presque 6,9% pour 5 000 sessions, 9% pour 25000 sessions, et 15% pour 50 000 sessions.

Figure 72 : Consommation de mémoire (NF)

0

20

40

60

80

100

120

5000 100001500020000250003000035000400004500050000

Cons

omm

atio

n de

mém

oire

(MB)

Sessions

NATFW NSLP

NATFW NSLP (HMAC)

0

20

40

60

80

100

120

5000 100001500020000250003000035000400004500050000

Cons

omm

atio

n de

mém

oire

(MB)

Sessions

NATFW NSLP

NATFW NSLP (HMAC)


130

5. Conclusion

Ce chapitre a été consacré à l’implémentation du protocole NATFW NSLP avec et sans le mécanisme d'authentification HMAC et l'évaluation des performances. En effet, nous avons testé le temps d'établissement de session entre le NI et le NR, le temps de traitement des requêtes CREATE par le NI et le NF, et la consommation de CPU et de mémoire. Les résultats des relevés effectués ont démontré que le NATFW NSLP doté de HMAC peut traiter un grand nombre de sessions (jusqu'à 50 000 sessions) avec des performances très acceptables, le temps d'établissement de session reste faible et moins de 220 ms, la consommation de CPU (ainsi que de la mémoire) reste basse pour le protocole avec HMAC. La limitation du nombre de sessions est dû au protocole GIST mais surtout à Netfilter sur le NAT/FW. L'utilisation d'un autre outil d'implémentation moins gourmand est envisageable et peut augmenter le nombre de sessions à établir. En outre des résultats meilleurs peuvent être obtenus sur des plateformes dans des environnements plus puissants que ceux utilisés.

131

Conclusion Générale

Dans ce travail, nous avons effectué un tour d'horizon sur les solutions mises en place afin de pallier au problème de la traversée des routeurs NAT et des par-feu par le protocole SIP. Notre intérêt s'est porté sur le protocole NATFW NSLP de la plate forme NSIS, la robustesse et la souplesse de ce protocole sont prouvées mais son principe de base nécessite d’être sécurisé.

Notre travail s’est focalisé sur l’intégration de mécanismes de sécurité au protocole NATFW NSLP, afin de garantir à la fois une authentification efficace tout en préservant ses performances. Dans un premier temps, nous avons adopté le mécanisme HMAC reconnu pour son efficacité et surtout sa rapidité. En effet, cette approche est beaucoup plus légère et beaucoup moins coûteuse que la signature numérique.

L’idée de base du mécanisme HMAC est de fournir un authentifiant de petite taille, qui sera rajouté au message à envoyer, afin d’assurer l'authenticité du message auprès du destinataire qui sera ainsi autorisé à réaliser son objectif. L'intégration de ce mécanisme dans le protocole a nécessité des clés partagées entre l'émetteur et le récepteur. A cet effet, la gestion de ces clés a constitué une préoccupation puisqu'elle augmente la complexité de la procédure d'authentification et également le temps d'établissement. De ce fait, un serveur dédié a été spécifié pour la génération et la distribution des clés privées. De part sa simplicité, le mécanisme HMAC assure, aussi bien que l'authentification, l'intégrité de messages, et la protection contre les attaques par rejeu des messages.

L’objectif du deuxième mécanisme proposé E-MAC, est d'assurer, en plus de l’authenticité, la confidentialité des messages. Ainsi, ce mécanisme très rapide est associé à un algorithme de chiffrement est prouvé d’augmenter l'efficacité et la performance de l'opération d'authentification.

L’intégration de notre schéma d’authentification HMAC dans le protocole NATFW NSLP a permis aux nœuds initiateurs de s'authentifier auprès du NAT et du pare-feu de façon simple mais sûre. En effet, les premiers résultats de l’intégration du mécanisme HMAC adopté sont satisfaisants. Les évaluations des performances montrent que le protocole NATFW NSLP sécurisé offre de bonnes performances en termes de coût et de temps d'exécution. D’autre part, nous avons répondu à la problématique du protocole SIP lors de sa traversée des middleboxes, car l'établissement de la session de communication entre les nœuds distants s’effectue, tout en garantissant un bon niveau de sécurité. Le second mécanisme E-MAC proposé permet d’augmenter l'efficacité et de renforcer la robustesse de protocole NATFW NSLP en termes de confidentialité.

Le travail effectué dans ce mémoire nous ouvre les perspectives d’étendre les mécanismes adoptés comme suit :

132

Implémenter et évaluer le mécanisme E-MAC, et la comparer avec HMAC.

Intégrer le serveur Diameter aux solutions adoptées.

Etendre les mécanismes pour qu'ils s'effectuent dans une communications de bout en bout (entre le NR et le NF, par exemple).

Evaluer les mécanismes d'authentification de point de vue sécurité, par exemple contre l'attaque par rejeu des messages.

Par ailleurs, la convergence des différents réseaux hétérogènes fixes et mobiles s’appuie sur une nouvelle architecture basée sur la technologie Ip Multimedia Subsystem (IMS) qui permet de diversifier les applications accessibles via une multitude de technologies, ce qui rend plus accrues les exigences en termes de sécurité et de QoS. L’architecture du réseau multimédia IMS s’appuie sur le protocole SIP.

Enfin, comme perspectives à ce travail, à long terme, il serait intéressant d’envisager l’intégration de notre travail dans le contexte d’une architecture IMS et d’évaluer la QoS en plus de la sécurité qui sera évaluée avec le mécanisme E-MAC et dans un environnement plus adéquat (serveur Diameter, ..).

133

REFERENCES

[1] P. Srisuresh, M. Holdrege, " Terminologie et considérations sur les traducteurs d'adresse réseau (NAT) IP", RFC 2663, Lucent Technologies, août 1999.

[2] NOKIA, "A Practical Look at Network Address Translation", A Nokia Horizon Manager White Paper, November 2003.

[3] CCNA Study Guide, "Network Address Translation (NAT)".

[4] M. Constantinescu, D. Cernaianu, V. Croitoru, "NATFirewall Traversal for SIP: Issues and Solutions", 0-7803-9029-6, IEEE , 2005.

[5] V. Paulsamy, "Network Convergence and the NAT/Firewall Problems", IEEE, 2003.

[6] H. Sinnreich, B. Johnston, "Internet communication using SIP", ISBN-13: 978-0-471-77657-4, Canada, 2006.

[7] A. Balashov, "Demystifying SIP NAT Traversal", Evariste Systems LLC, 2009.

[8] F. Atout, "NATFirewall traversal Issues and solutions", TKK T-110.5290 Seminar on Network Security, 2006.

[9] R. Kolic, P. Iyer, "The Advantages of the UPnP Internet Gateway Device", Intel corporation, 2002.

[10] J. Rosenberg, "Getting SIP through Firewalls and NATs," Internet Draft, Internet Engineering Task Force, Feb. 2000.

[11] W. Cheswick, S. Bellovin, "Firewalls and Internet Security: Repelling the Wily Hakker", Addison-Wesley, 1994, ISBN 0-201-63357-4.

[12] E. D. Zwicky, S. Cooper, D. B. Chapman, "Building Internet Firewalls (2nd Edition)", O’Reilly & Associates, ISBN 1-56592-871-7, 2000.

[13] J. Rosenberg et al, "STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, 2003.

[14] T. Abbasi, S. Prasad, N. Seddigh, "A comparative study of the sip and iax voip protocols", CCECE/CCGEI, Saskatoon, IEEE, may 2005.

[15] P. Montoro, E. Casilari, "A Comparative Study of VoIP Standards with Asterisk", DOI 10.1109/ICDT, IEEE, 2009.

134

[16] J. Rosenberg, et al, "SIP : Session Initiation Protocol", RFC 3261, Juin 2002.

[17] L. Ouakil, G. Pujolle, "Téléphonie sur IP", ÉDITIONS EYROLLES, 61, bd Saint-Germain 75240 Paris Cedex, 2005.

[18] RADVision Confidential, "SIP Overview", 2001.

[19] T. Russell, "Session Initiation Protocol (SIP)", McGraw-Hill Companies, 2008.

[20] S. ZNATY,J L. DAUPHIN, "SIP : Session Initiation Protocol", EFORT, 2005.

[21] N. Thi Hoang Lan, D. Quang Vu, "Comparaison de la technologie de la norme H.323 et la technologie de SIP pour l'application au service de la voix sur IP(VOIP)", TIPE, Ha Noi, Juillet 2005.

[22] M. T. Bennise, "Transmission média sur les réseaux IP en utilisant les protocoles SIP et IAX", MONTRÉAL, 2009.

[23] Alan B. Johnston, "SIP : understanding Session Initiation Protocol", second edition. Artech house, Boston London. 2004.

[24] S. Garcia, "Administration Systèmes et Réseaux", Université D'Evry Val d'Essone, 2004, 2005.

[25] B. Xavier, S. Franck, "La téléphonie sur IP : qui fait quoi, pour qui et comment?", M2 SIR, 2004,2005.

[26] P. Kadionik, "Le projet HomeSIP : la domotique avec le protocole SIP", l'ENSEIRB, Mars 2006.

[27] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC2279, 1998.

[28] J. Briffaut, A. Martin, "VoIP : Les protocoles : SIP, SCCP et H.323".

[29] A. Doswald, J. Ehrensberger, X. Hahn, "Best Practices for VoIP/SIP Security", HES.SO, 2007.

[30] D. Geneiatakis, C. Lambrinoudakis, G. Kambourakis ,"An ontology-based policy for deploying secure SIP-based VoIP services", Elsevier, 2008.

[31] R. Dantu, S. Fahmy, H. Schulzrinne, "Issues and challenges in securing VoIP", 0167-40482009 Elsevier. 2009.

135

[32] M. Boucadair , "Etude des problèmes de sécurité liés au protocole SIP (Session Initiation Protocol)", GRESMarrakech, , Décembre 2001.

[33] J. C Han,W. Hyun,S. O Park, "An Application Level Gateway for Traversal of SIP", ICA0T, Feb. 20-22, 2006.

[34] W. Chen,Y. Huang, H. Chao,"NAT Traversing Solutions for SIP Applications", EURASIP, 2008.

[35] Y. C Chen, W. K Jia, "Challenge and solutions of NAT traversal for ubiquitous and pervasive applications on the Internet", Elsevier, 2009.

[36] A. Fessi, H. Niedermayer, H. Kinkelin , "A Cooperative SIP Infrastructure for Highly Reliable Telecommunication Services ", IPTCOMM’07, New York, USA, ACM, 2007.

[37] C. Vigoda, R. Lahoche, "FIREWALLS applicatifs aux protocoles multimédias", exposé FI, 2005.

[38] RADVision Confidential, "Traversal of IP Voice and Video Data through Firewalls and NATs", 2001.

[39] J. Maenpaa, V. Andersson, G. Camarillo, "Impact of Network Address Translator Traversal on Delays in Peer-to-Peer Session Initiation Protocol", IEEE, 2010.

[40] Q. Wang, L. Wei, D. Liu, "A P2P –Grid Model for Traversing NAT in SIP Communication", IEEE, 2009.

[41] M. Guewouri, A. Mellouk, "CDCS: a New Case-Based Method for Transparent NAT Traversals of the SIP Protocol", LISSI/SCTIC, University of Paris XII-Val de Marne, France, 2007.

[42] Z. Hu, "NAT Traversal Techniques and Peer-to-Peer Applications", HUT T-110.551 Seminar on Internetworking, 2005.

[43] Ditech Networks, "Practical Far-End NAT Traversal for VoIP", mars 2006.

[44] M. V. Moraru, D. Xuan Sang, "Le protocole STUN pour des connexions filtrées par des pare feux", rapport pour TIPE, Institut de la Francophonie pour l’Informatique, 2006.

[45] R. Mahy, P. Matthews, J. Rosenberg," TURN Traversal Using Relays around NAT", RFC 5766, October 2010.

[46] M. Guezouri, A. Blaha, M. Keche, "Adaptation of TURN protocol to SIP protocol", UST, Algérie, 2010.

136

[47] M. Boucadair, "Proposition des solutions aux problèmes de sécurité SIP", France Telecom.

[48] C. Tian, Z. Wen-an, M. Fei,, "A novel Intra-domain Mobility Management Solution in Heterogeneous Networks using SIP", MUE, IEEE, 2009.

[49] Y. Yeryomin, F. Evers, J. Seitz, "Solving the Firewall and NAT Traversal Issues for SIP-based VoIP", IEEE, 2008.

[50] S. Salsano, L. Veltri, G. Martiniello, "Seamless vertical handover of VoIP calls based on SIP Session Border Controllers", International Conference on Communications, IEEE, 2006.

[51] A. Vilei, G. Convertino, F. Crudo, "A New UPnP Architecture for Distributed Video Voice over IP", MUM, ACM, Stanford, CA, USA, 2006.

[52] M. Haque, "UPnP Networking: Architecture and Security Issues", TKK Seminar on Network Security, 2007.

[53] T. Sales, H. Almeida, A. Perkusich, "Enabling User Authentication and Authorization to Support Context-Aware UPnP Applications", WebMedia’09, October 5–7, 2009ACM , Fortaleza, CE, Brazil.

[54] A. Hemel , "Abusing Universal Plug and Play", November 2008.

[55] P. Xuena, S. Jinshan, Z. Hong, "An ALG-based NAT Traversal Solution for SIP-based VoIP", IEEE, 2009.

[56] M. Martin, M. Brunner, M. Stiemerling,"Path-coupled signaling for NAT/Firewall traversal", NEC Europe Ltd, 2005.

[57] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, "Middlebox Communication Architecture and Framework", RFC 3303 (Informational), August 2002.

[58] R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox Communications (MIDCOM) Protocol Requirements", RFC 3304 (Informational), August 2002.

[59] M. Stiemerling, J. Quittek, T. Taylor, "Middlebox Communication (MIDCOM) Protocol Semantics", RFC 3989 (Informational), February 2005.

[60] B. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, Septembre 1997.

[61] J. Manner, G. Karagiannis, A. McDonald, S. Van den Bosch, "NSLP for Quality of-Service signalling", Internet draft (draft-ietf-nsis-qos-nslp-08), Octobre 2005.

137

[62] J. Manner, G. Karagiannis, A. McDonald, "NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling", RFC 5974, Octobre 2010.

[63] H. Schulzrinne, H. Tschofenig, X. Fu, A. McDonald, "CASP - Cross-Application Signaling Protocol", Internet draft (draft-schulzrinne-nsis-casp-01), Mars 2003.

[64] H. Schulzrinne, R. Hancock, "GIST: General Internet Signaling Transport", RFC 5971, Octobre 2010.

[65] C. Dickmann, "An Implementation and Evaluation of the General Internet Signaling Transport (GIST) Protocol", thèse de BAC, Université de Goettingen, 2005.

[66] M. Stiemerling, H. Tschofenig, C. Aoun, "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP) ", RFC 5973, Octobre 2010.

[67] A. Fessi, F. Dressler, G. Carle, "Metering Configuration Signaling NSLP", draft-dressler-nsis-metering-nslp-05.txt, mars 2007.

[68] X. Fu, H. Schulzrinne, A Bader, "NSIS: A New Extensible IP Signaling Protocol Suite", IEEE Communications Magazine, Octobre 2005.

[69] J. Ping, G. Zihui, J. Kurose, D. Towsley, "A Comparison of Hard-state and Soft-State Signaling Protocols", Proceedings of SIGCOMM’03, Karlsruhe, Germany, 2003.

[70] M. Stiemerling, H. Tschofenig, M. Martin , "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)draft-ietf-nsis-nslp-natfw-00", WG NSIS, Internet-Draft, October 2003.

[71] C. Werner, X. Fu, C. Aoun, "NSLP NAT/FW State Machine", draft-werner-nsis-natfw-nslp-statemachine, 2007.

[72] N. Steinleitner, H. Peters, X. Fu, "Implementation and Performance Study of a New NAT/Firewall Signaling Protocol", institut d'informatique, université de Geottingen, Allmagne, 0-7695-2541-5 /06, 2006 IEEE.

[73] J. Manner, M. Stiemerling, "Authorization for NSIS Signaling Layer Protocols", RFC5189, 02.2011.

[74] H. Tschofenig, D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, Siemens, June 2005.

[75] R. Bless, R. Martin, "Secure Signaling in Next Generation Networks with NSIS", Institute of Telematics, University Karlsruhe (TH), Zirkel 2, D–76128 Karlsruhe, Germany.

138

[76] S. G. Polito and H. Schulzrinne, "Authentication and Authorization Method in Multi-domain, Multi-provider Networks", Next Generation Internet Networks, 3rd EuroNGI Conference on, pp. 174–181, May 2007.

[77] S. Felis and M. Stiemerling, "Securing a Path-Coupled NAT/Firewall Signaling Protocol", in IPOM 2007, Springer, 2007.

[78] E. Bresson, "Cryptographie : authentification et échange de clés", SGDN/DCSSI Laboratoire de cryptographie, université de Paris.

[79] D. L. Evans, P. J. Bond, A. L. Bement, "The keyed-hash message authentication code (hmac)", FIPS pub 198-1, Gaithersburg, MD 20899-8900, 2008.

[80] C. Kaufman, P. Hoffman, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC5996, septembre 2010.

[81] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC2403, Novembre 1998.

[82] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC2404, Novembre 1998.

[83] A. Kumar, A. Aggarwal, A. Charu, "Survey and taxonomy of key management protocols for wired and wireless networks", International Journal of Network Security & Its Applications (IJNSA), May 2012.

[84] C. Schulze, "Diameter et ses Applications : Principes, Architecture et Services", EFORT, 2010. [85] B. Alomair, "Authenticated Encryption: How Reordering Can Impact Performance", Proc. 10th Int’l Conf. Applied Cryptography and Network Security, 2012.

[86] H. Krawczyk, "The Order of Encryption and Authentication for Protecting Communications", Proc. 21st Ann. Int’l Cryptology Conf. 2001.

[87] N. Ferguson, B. Schneier, "Practical Cryptography", John Wiley & Sons, 2003.

[88] B. Alomair and R. Poovendran "E-MACs: Toward More Secure and More Efficient Constructions of Secure Channels", IEEE transactions on computers, January 2014.

[89] H. Handschuh and B. Preneel, "Key-Recovery Attacks on Universal Hash Function Based MAC Algorithms", Proc. 28th Ann. Int’l Cryptology Conf. 2008.

[90] M. Boesgaard, M. Vesterager, T. Pedersen "Rabbit: A New High-Performance Stream Cipher", International Association for Cryptologic Research 2003.

139

[91] Rukhin et Al, "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications", NIST Special Publication 800-22-1a, April 2010.

140

WEBOGRAPHIE

[web-1] http://www.upnp.org consulté le 30.09.2012.

[web-2] "Charter of the NSIS Working Group",

http://datatracker.ietf.org/wg/NSIS/charter/ consulté le 15.06.2013.

[web-3] "An Implementation of the Next Steps in Signaling (NSIS) Protocol Suite at the University of Goettingen",

http://user.informatik.uni-goettingen.de/~nsis/ consulté le 15.06.2013.

[web-4] "GoCASP: An Implementation of the Cross-Application Signaling Protocol at University of Goettingen",

http://user.informatik.uni-goettingen.de/~casp/ consulté le 15.06.2013.

[web-5] "An Implementation of QoS NSLP at the University of Goettingen",

http://user.informatik.uni-goettingen.de/~qos consulté le 15.06.2013.

[web-6] "Netfilter, firewalling, NAT, and packet mangling for Linux",

http://www.netfilter.org. consulté le 25.09.2013.

141

ANNEXE A Problématique de la traversée des NAT/FW par le protocole SIP

Cette annexe permettra d’illustrer par des relevés Wireshark la problématique du protocole SIP lors de sa traversée de routeurs NAT et pare-feu.

Le scénario comporte :

Un appelant situé dans un réseau privé ayant l'adresse 192.168.1.10.

Un appelé situé dans le réseau public ayant l'adresse 193.168.1.11

Un routeur NAT/FW dont l’interface coté privé est : 192.168.1.1, et l’interface coté public 193.168.1.1

Capture au niveau de l'appelant

Cette capture montre que l'appelant a envoyé (plusieurs fois) la requête INVITE sans recevoir de réponse de l'appelé, malgré l'autorisation des paquets SIP au niveau de NAT/FW.

142

Capture au niveau du routeur NAT/FW

Cette capture montre que le NAT/FW a bien reçu les réponses de l'appelé (Trying, Ringing, Ok) mais il ne les a pas acheminées à l'appelant.

Capture au niveau de l'appelé

L'appelé n'a reçu que les requêtes INVITE de l'appelant.

143

ANNEXE B Les messages NATFW NSLP Tous les messages NATFW NSLP ont un en-tête commun :

Description de contenu (les objets) des messages NATFW NSLP :

• 0x1: CREATE : o Signaling Session Lifetime object (Obligatoire) o Extended flow information object (Ob) o Message sequence number object (Ob) o Nonce object (Ob) si P égale à 1 dans l'en-tête NSLP, sinon (Optionnel) o ICMP Types Object (Op) • 0x2: EXTERNAL o Signaling Session Lifetime object (Ob) o Message sequence number object (Ob) o Extended flow information object (Ob) o Data terminal information object (Ob) o Nonce object (Ob) si P égale à 1 dans l'en-tête NSLP, sinon (Op) o ICMP Types Object (Op) o External binding address object (Op) • 0x3: RESPONSE Le message RESPONSE dans le cas de succès ’Success’ contient ces objets: o Signaling Session Lifetime object (Ob) o Message sequence number object (Ob) o Information code object (Ob) o External address object (Op) o External binding address object (Op) Dans les autres cas, le message RESPONSE contient les objets : o Message sequence number object (Ob) o Information code object (Ob) o Signaling Session Lifetime object (Op) • 0x4: NOTIFY o Information code object (Ob)

144

ANNEXE C Les objets NATFW NSLP Tous les objets ont un en-tête commun :

Les objets NATFW NSLP sont : Signaling Session Lifetime object (0x00C)

External address object (0x00D)

External binding address object (0x00E)

Extended flow information object (0x00F)

Le champs rule action peut être : (0x0001) Allow, ou (0x0002) Deny Information code object (0x010)

Nonce object (0x011)

145

Message Sequence Number object (0x012)

Data Terminal Information object (0x013)

ICMP Types Object (0x014)

146

ANNEXE D Installation et configuration de NSIS et NATFW NSLP

1.Téléchargement du package NSIS à partir du site de l'université de Goettingen : http://user.informatik.uni-goettingen.de/~nsis

2. Après la décompression, accéder dans le répertoire nsis et exécuter la commande :

# ./configure

Cette commande permet de diagnostiquer le système et vérifier l'existence des composants et packages nécessaires tels que :

. g++ , gcc, (GNU) Make , libssl, libssl-dev

3. Compiler nsis:

# make

Cela crée un certain nombre de fichiers binaires dans nsis/bin : nsis, nsis-ping, nsis-qos, nsis-qosd, nsis-natfw, nsis-natfwd, nsis-diag, nsis-diagd

4. Avant d'exécuter NSIS, le fichier de configuration (nsis/bin/nsis.conf) doit être ajusté renseigné selon l’utilisation (application) . Dans ce fichier, on spécifie les applications NSLPs à lancer avec GIST (le NATFW NSLP, dans notre cas), les adresses IP locales et une table de routage indiquant à NSIS l'adresse utilisée pour les messages sortants.

5. Afin de lancer NSIS daemon (dans bin/), utiliser la commande suivante en mode root :

# ./nsis

Cette commande lance les applications spécifiées dans le fichier de configuration nsis.conf (y compris NATFW NSLP).

6. Maintenant, on peut lancer des requêtes NATFW NSLP. la requête CREATE pourra se lancer comme suit (en mode root) :

# ./nsis-natfw --create -s, --source=SRCADDR -d, --destination=DESTADDR

--sport=SRCPORT --dport=DESTPORT

Dans cette commande, on spécifie par SRCADDR l'adresse source de la requête, par DESTADDR l'adresse destination, par SRCPORT le port source, et par DESTPORT le port destination (port source et destination sont optionnels).

147

Voici des captures Wireshark sur les nœuds NI , NF et NR en lançant une requête à partir de NI (@ source est 192.168.1.10, @ destination est 193.168.1.11)

Capture sur le NI

Capture sur le NF (interface coté NI)

Capture sur le NF (interface coté NR)

Capture sur le NR

ecole nationale supérieure d’informatique oued –...

Documents