Cours reseau ouya

Faculté de génieGénie électrique et génie informatique

ARCHITECTURE DE GESTION

DE TRAVERSÉE DE PROTOCOLES AU TRAVERS

DES PARE-FEU ET DES ROUTEURS NAT

Définition du projet de rechercheSpécialité : génie électrique

Joel Bao-Lan TRAN

Sherbrooke (Québec) Canada Septembre 2003

TABLE DES MATIÈRES i

TABLE DES MATIÈRES

1 Introduction 1

2 Architecture des réseaux 2

2.1 Réseau client/serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 Réseau poste à poste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Le nouveau paradigme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Principe de fonctionnement des pare-feu et des routeurs NAT 5

3.1 Les pare-feu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2 Les routeurs à translation d’adresse . . . . . . . . . . . . . . . . . . . . . . . 5

3.3 Utilisation des pare-feu et des routeurs NAT dans les réseaux . . . . . . . . . 7

4 SIP : Un service poste à poste versatile 10

4.1 Architecture de SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.1.1 Agents utilisateurs (User agents) . . . . . . . . . . . . . . . . . . . . 10

4.1.2 Serveur SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2 Problématique de la traversée du protocole SIP au travers des dispositifs desécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2.1 Problématique engendrée par SIP avec les pare-feu . . . . . . . . . . 14

4.2.2 Problématique engendrée par SIP avec les routeurs NAT . . . . . . . 14

5 Approche pour une gestion de traversée de protocoles à travers des pare-feu et des routeurs NAT 16

5.1 Utilisation d’un relais permettant la traversée des pare-feu et des routeurs NAT 16

5.1.1 Serveur d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1.2 Serveur d’application avec agent . . . . . . . . . . . . . . . . . . . . . 18

5.1.3 Passerelle de la couche application (ALG) . . . . . . . . . . . . . . . 19

5.1.4 Traversal Using Relay NAT (TURN) . . . . . . . . . . . . . . . . . . 21

5.2 Utilisation d’une communication directe permettant la traversée des pare-feuet des routeurs NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

TABLE DES MATIÈRES ii

5.2.1 Tunnel de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2.2 Universal Plug and Play . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.3 Midcom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2.4 Simple Traversal of UDP Through Network Address Translators (STUN) 26

5.2.5 Interactive Connectivity Establishment(ICE) . . . . . . . . . . . . . . 27

5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6 Définition et objectif du problème 31

7 Méthodologie 32

A Appendix 33

A.1 Lexique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

BIBLIOGRAPHIE 34

LISTE DES FIGURES iii

LISTE DES FIGURES

1 Architecture client/serveur. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Architecture client/serveur avec pare-feu. . . . . . . . . . . . . . . . . . . . . 2

3 Architecture client/serveur avec routeur NAT. . . . . . . . . . . . . . . . . . 3

4 Architecture poste à poste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

5 Les pare-feu filtrent les données afin de laisser passer seulement les donnéesautorisées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

6 Fonctionnement des routeurs NAT. Du réseau public, seul le routeur est visible. 6

7 Réseau interne et réseau public . . . . . . . . . . . . . . . . . . . . . . . . . 7

8 Réseau interne avec un accès au réseau public . . . . . . . . . . . . . . . . . 8

9 Réseau avec une chaîne de pare-feu ou de routeurs NAT . . . . . . . . . . . . 8

10 Réseau avec une zone démilitarisée . . . . . . . . . . . . . . . . . . . . . . . 9

11 Établissement et terminaison d’une session SIP entre deux agents utilisateurs. 11

12 Établissement d’une session SIP avec l’utilisation d’un serveur proxy SIP. . . 11

13 Établissement d’une session SIP avec l’utilisation d’un serveur de redirectionSIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

14 Enregistrement de la localisation d’un usager auprès d’un serveur de redirec-tion SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

15 Un serveur d’application dans un domaine privé utilisé en tant que relais àune communication poste à poste. . . . . . . . . . . . . . . . . . . . . . . . . 16

16 Un serveur d’application dans un domaine démilitarisé sert de relais à unecommunication poste à poste. . . . . . . . . . . . . . . . . . . . . . . . . . . 17

17 Décomposition du serveur d’application avec agent. . . . . . . . . . . . . . . 18

18 Une passerelle de la couche application utilisée en tant que relais à une com-munication poste à poste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

19 Traversal Using Relay NAT (TURN) utilisé en tant que relais à une commu-nication poste à poste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

20 Les différents postes reliés par PPTP sont situés dans un même domaine. Unecommunication directe est possible. . . . . . . . . . . . . . . . . . . . . . . . 22

21 Simple Traversal of UDP Through Network Address (STUN) sert à découvrirles caractéristiques de dispositifs de sécurité par des requêtes au serveur STUN. 26

LISTE DES FIGURES iv

22 Interactive Connectivity Establishment (ICE) (ICE) consiste à intégrer STUNet TURN à SIP afin d’offrir une connectivité. . . . . . . . . . . . . . . . . . 27

LISTE DES TABLEAUX v

LISTE DES TABLEAUX

1 Message d’invitation SIP (INVITE) . . . . . . . . . . . . . . . . . . . . . . . 13

2 Message de réponse SIP (OK) . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Périphériques traversés par un serveur d’application. . . . . . . . . . . . . . . 17

4 Topologies traversées en utilisant des périphériques traversés par un serveurd’application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Périphériques traversés par un serveur d’application avec l’utilisation d’un agent. 18

6 Topologies traversées en utilisant des périphériques traversés par un serveurd’application avec l’utilisation d’un agent. . . . . . . . . . . . . . . . . . . . 19

7 Périphériques traversés par une passerelle de couche application. . . . . . . . 20

8 Topologies traversées en utilisant des périphériques traversés par une passerellede couche application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

9 Périphériques traversés par TURN. . . . . . . . . . . . . . . . . . . . . . . . 21

10 Topologies traversées en utilisant des périphériques traversés par TURN. . . 22

11 Périphériques traversés par un tunnel. . . . . . . . . . . . . . . . . . . . . . . 23

12 Topologies traversées en utilisant des périphériques traversés par un tunnel. . 23

13 Périphériques traversés par UPNP. . . . . . . . . . . . . . . . . . . . . . . . 24

14 Topologies traversées en utilisant des périphériques traversés par UPNP. . . . 24

15 Périphériques traversés par Midcom. . . . . . . . . . . . . . . . . . . . . . . 25

16 Topologies traversées en utilisant des périphériques traversés par Midcom. . . 25

17 Périphériques traversés par STUN. . . . . . . . . . . . . . . . . . . . . . . . 26

18 Topologies traversées en utilisant des périphériques traversés par STUN. . . . 27

19 Périphériques traversés par ICE. . . . . . . . . . . . . . . . . . . . . . . . . . 28

20 Topologies traversées en utilisant des périphériques traversés par ICE. . . . . 28

21 Tableau récapitulatif des différentes techniques permettant la traversée despare-feu et des routeurs NAT. . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1 INTRODUCTION 1

1 Introduction

Au cours de dernières décennies, les télécommunications ont su remodeler nos façons de faireet de voir les choses. Lire ses courriels, naviguer sur l’Internet ou télécharger de la musiquefont maintenant partie intégrante de nos habitudes de vie. En effet, le nombre de ménagesayant accès à Internet a doublé entre 1997 et 2001 pour se situer à 60,2% selon StatistiquesCanada [1].

Avec l’avènement des connexions à haute vitesse et une utilisation accrue de l’Internet par lapopulation, de nouveaux besoins se sont créés et de nouveaux services ont vu le jour. Parmiceux-ci, on dénombre des applications riches en multimédia telles que la téléphonie IP, latéléconférence, la vidéoconférence, la vidéo sur demande et l’échange de fichiers de personneà personne. Tous ces services offrent une valeur ajoutée aux réseaux numériques et prônentune migration des réseaux conventionnels vers un réseau unique de type IP qui achemineratoute l’information : l’Internet, le téléphone et la câblodistribution.

Cette convergence ne se fait pas sans heurt. En effet, au fil des années, ces nouveaux typesde services se sont butés à plusieurs problèmes tels que la vitesse de transmission trop lenteou encore des technologies de compression numérique inadaptées. Quelques unes de ces si-tuations sont maintenant résolues. Par exemple, en 2001, 75% de la population Canadiennehabitait dans une zone desservie par un lien Internet haute vitesse[3]. Sur le plan technolo-gique, plusieurs avancements ont été effectués au cours des dernières années. En effet, avec lesnouvelles méthodes de compression numérique audio et vidéo, la qualité du son et de l’imageest meilleure que jamais. Tous ces éléments font en sorte qu’une convergence prochaine versun réseau unique de type IP est possible. Cependant, lors du déploiement de ces technolo-gies dans les réseaux actuels, plusieurs nouvelles problématiques ont apparu notamment auniveau des dispositifs de sécurité tel que les pare-feu et les routeurs NAT. En effet, dansles réseaux actuels, les dispositifs de sécurité déployés n’ont pas été conçus dans l’optiqued’offrir les nouveaux services décrits précédemment. Afin d’offrir ceux-ci, il est donc primor-dial de développer un mécanisme qui consiste en un mécanisme de gestion de traversée desprotocoles au travers des pare-feu et des routeurs NAT.

C’est précisément cette problématique qui va être analysée et solutionnée par une nouvelleméthodologie. Pour ce faire, dans un premier temps, les différentes architectures des réseaux.Dans un deuxième temps, le fonctionnement des pare-feu et des routeurs NAT sera décrit.Dans un troisième temps, la problématique engendrée par l’utilisation du protocole SIP autravers des pare-feu et des routeurs NAT sera abordée. Dans un quatrième temps, les dif-férentes approches afin de permettre la traversée des pare-feu et des routeurs NAT serontexposées. Dans un cinquième temps, une analyse d’une problématique persistante sera ef-fectuée. Dans un dernier temps, une méthodologie afin de résoudre cette problématique seraproposée.

2 ARCHITECTURE DES RÉSEAUX 2

2 Architecture des réseaux

Avec la venue de nouveaux types de services tels que la téléphonie IP et la vidéoconférencesur l’Internet, un nouveau paradigme a vu le jour. Historiquement, tous les services offerts surl’Internet étaient développés selon le modèle de réseau client/serveur alors que les nouveauxservices sont développés selon le modèle de réseau poste à poste. Ces deux architecturesétant disparates, une multitude de problèmes surgissent et font en sorte que plusieurs deces nouveaux services ne peuvent être utilisés. Afin de bien comprendre la problématiquequ’engendre ce changement d’architecture, une présentation de ces deux architectures vaêtre effectuée afin d’introduire le nouveau paradigme créé par les nouveaux services.

2.1 Réseau client/serveur

Figure 1 – Architecture client/serveur.

Dans d’un réseau de type client/serveur (voir figure 1) les postes de travail (les clients), seconnectent à un serveur qui offre différents services tels que HTTP, FTP et courriel. Lesclients ouvrent une communication vers le serveur en effectuant une requête et celui-ci leurrépond en envoyant une réponse. Comme on peut le constater, dans ce modèle, toutes lescommunications sont orientées d’un point spécifique à un autre point spécifique : des clientsvers le serveur.

Figure 2 – Architecture client/serveur avec pare-feu.

Dans un modèle de réseau client/serveur, il est donc facile de sécuriser les communications etles diverses entitées du réseau. Par exemple, ces diverses entitées peuvent être sécurisées pardes dispositifs tels que des pare-feu ou des routeurs à translation d’adresse (communémentappelé routeur NAT) qui agissent en tant qu’agent de sécurité. Il suffit de les placer aux


Figure 3 – Architecture client/serveur avec routeur NAT.

divers points d’accès du serveur et des clients tel qu’illustré par la figure 2 et la figure 3. Cestypes de dispositifs seront discutés plus en détail dans la section 3.

2.2 Réseau poste à poste

Figure 4 – Architecture poste à poste.

Dans un modèle de réseau poste à poste (voir figure 4), il n’y a aucun serveur. Chaqueposte est à la fois serveur et client. Chaque poste décide de partager les ressources qui luiconviennent au moment qui lui convient et peuvent effectuer et recevoir des connexions pourdes services quelconques. Dans ce modèle, les communications ne sont plus orientées vers unseul point unique, elles sont réparties sur tous les clients. Par conséquent, tous les clientspeuvent effectuer des connexions vers d’autres clients et tous les clients peuvent recevoir desconnexions de tous les clients. Dans ce modèle, il est donc impossible de prédire quel servicesou protocoles seront utilisés ou offerts par les clients. Par conséquent, il est donc difficile dedéfinir des règles auprès des pare-feu et des routeurs NAT.

2.3 Le nouveau paradigme

Comme décrit tout au long de la présente section, les nouveaux types de services redéfinissentun nouveau paradigme pour les réseaux en prônant l’utilisation d’une architecture de réseaude type poste à poste contrairement à un réseau de type client/serveur. Ce nouveau para-digme fait en sorte que plusieurs problèmes surgissent au niveau des dispositifs de sécuritéd’un réseau. En effet, l’utilisation de dispositifs de sécurité au sein des réseaux empêche le dé-ploiement des nouveaux services pour diverses raisons qui vont être abordées dans la section3. Cependant, pour un administrateur réseau, il est inconcevable de retirer ces dispositifs.En effet, ceux-ci permettent de restreindre l’accès au réseau aux seuls utilisateurs autorisés.Enlever ces dispositifs se résumerait à rendre vulnérable un réseau aux diverses attaques. Les


administrateurs réseaux exigent donc que ces dispositifs de sécurité soient présents sur leursréseaux. Afin de mieux comprendre la problématique engendrée par l’emploi d’un réseau detype poste à poste où des dispositifs de sécurité sont présents, la problématique de SIP seraétudiée dans la section 4.

Afin de permettre l’utilisation des nouveaux services, il faut donc créer un mécanisme degestion de traversée des éléments de sécurité d’un réseau (i.e. pare-feu routeur NAT) pourpermettre une communication poste à poste entre les réseaux actuels.

3 PRINCIPE DE FONCTIONNEMENT DES PARE-FEU ET DES ROUTEURS NAT 5

3 Principe de fonctionnement des pare-feu et des rou-teurs NAT

Dans les réseaux, il existe plusieurs dispositifs de sécurité tels que des éléments réseaux, desleurres et des systèmes de détection d’intrusion. Dans le cas de la problématique engendréepar une communication poste à poste, seuls les éléments réseaux posent des problèmes.Nous allons donc analyser les éléments réseaux étant donné que ceux-ci sont au centre de laproblématique créée par les nouveaux services.

3.1 Les pare-feu

Figure 5 – Les pare-feu filtrent les données afin de laisser passer seulement les donnéesautorisées.

Un pare-feu est un dispositif informatique qui permet le passage sélectif des flux d’informationentre deux réseaux, ainsi que la neutralisation des tentatives de pénétration en provenancedu réseau public.[4] En effet, les pare-feu sont généralement des dispositifs déployés au niveaudes périphériques ou logiciels et utilisent des politiques de filtrage qui empêchent tous lespaquets qui ne proviennent pas ou qui ne sont pas destinés à une adresse IP et à un port défini(voir figure 5). Par exemple, à l’aide d’un pare-feu, il est possible de limiter les connectionsaux services Web et interdire les connexions FTP sur un réseau.

3.2 Les routeurs à translation d’adresse

Un routeur à translation d’adresse (routeur NAT) est un routeur qui est utilisé dans desréseaux où l’on veut limiter l’accès au réseau interne du réseau public ou partager uneconnexion Internet en utilisant une seule adresse IP publique. Par conséquent, du réseaupublic, seul le routeur est visible et toutes les requêtes semblent provenir du routeur. Lespostes de travail situés dans le réseau interne ne sont pas visibles et donc protégés contredes attaques provenant du réseau public.

Le fonctionnement général des routeurs NAT est bien simple. Un routeur NAT est un dis-positif actif ayant accès au réseau public et au réseau privé tel qu’illustré dans la figure 6.Le routeur NAT inspecte tous les paquets qui circulent dans un réseau interne. Lorsqu’il


Figure 6 – Fonctionnement des routeurs NAT. Du réseau public, seul le routeur est visible.

détecte qu’un paquet est destiné au réseau public, il prend celui-ci et le modifie en rempla-çant l’adresse IP source de l’entête du paquet par l’adresse IP publique du routeur NATpour ensuite l’acheminer sur le réseau public. Lorsque le routeur NAT reçoit une réponsedu réseau public à une requête, il détermine à quel poste la réponse est destinée et modifiel’entête de celui-ci en remplaçant l’adresse de destination par l’adresse IP privé du posteauquel le paquet est destiné.

Il existe plusieurs variantes des routeurs NAT. Étant donné que ceux-ci font partie inté-grante de notre problématique, il est donc intéressant de s’y attarder. Voici donc une brèvedescription des caractéristiques de divers routeurs NAT tel que décrit par Takeda[16] etCordell[2].

Cône plein La technique utilisant le cône plein est une technique très simple. À chaquenouvelle demande de connexion vers le réseau public, le routeur NAT va remplacer l’adressed’origine et le numéro de port du paquet par celle du routeur NAT. Lorsque le routeur NATreçoit des paquets, une simple vérification afin de savoir si celui-ci est destiné au poste quia ouvert la communications est effectuée. Aucune vérification sur l’origine du paquet n’esteffectuée. Le poste ayant envoyé des paquets destinés au réseau public peut donc recevoirdes réponses provenant de tous les postes sur le réseau public sans que le poste n’ait effectuéde requêtes à ceux-ci.

Cône restrictif La technique utilisant le cône restrictif est une technique plus restrictivesur les paquets que celle utilisée dans le cas d’un cône plein. Dans le cas d’une connexionsortante, le même mécanisme que dans le cas d’un cône plein est utilisé. La seule différenceentre cette technique et celle du cône plein est que seuls les paquets provenant des postesadressés dans le réseau public par les connexions sortantes vont être acceptées. Aucunevérification sur les ports n’est effectuée.

Cône restrictif sur les ports La technique utilisant le cône restrictif sur les ports estune légère variante de la technique utilisée dans les cônes restrictifs. Les cônes restrictifspermettent des connexions entrantes sur tous les ports dans l’éventualité où un port duposte a été adressé au préalable par une communication sortante. Dans le cas des cônes


restrictifs sur les ports, seuls les connexions provenant des postes et des ports adressés aupréalable sont acceptées.

Symétrique La technique des routeurs NAT symétrique diffère des autres techniques énu-mérées précédemment dans la façon dont elle traite les paquets sortant. En effet, à chaquedemande de communication vers le réseau externe, l’adresse du routeur NAT et un port assi-gné aléatoirement vont être assignés aux paquets sortants. En ce qui concerne les connexionsentrantes, ce type de routeurs NAT agit comme un cône restrictif sur les ports.

3.3 Utilisation des pare-feu et des routeurs NAT dans les réseaux

Les différents dispositifs tels que les pare-feu et les routeurs NAT comme décrits ci-dessussont déployés dans les réseaux ayant diverses topologies. Afin de fournir les connaissancesde base sur le déploiement et l’utilisation de ces dispositifs, ces topologies vont être décritesdans la présente section.

Figure 7 – Réseau interne et réseau public

Réseau public Un réseau public (i.e. l’Internet) est un réseau où tous les dispositifs duréseau sont en mesure de communiquer entres eux(voir figure 7).

Réseau interne Un réseau interne ou privé (i.e. Intranet) est un réseau où les communi-cations entre les dispositifs sont limitées aux éléments d’un réseau défini. Un réseau interneest indépendant et isolé du réseau public (voir figure 7). Il y a donc aucune communicationentre le réseau interne et le réseau public.

Réseau interne avec un accès au réseau public Afin de relier un réseau interne àl’Internet sans compromettre l’intégrité, la confidentialité et la sécurité du réseau interne,on peut utiliser des dispositifs de sécurité tels ques de pare-feu ou des routeurs NAT qui


Figure 8 – Réseau interne avec un accès au réseau public

vont servir de passerelle du réseau interne vers le réseau externe lorsqu’ils sont disposés àl’extrémité d’un réseau tel qu’illustré dans la figure 8. Ceux-ci vont permettre que seules lescommunications autorisées vont être permises entre les deux réseaux.

Intranet

1

Routeur NAT

Pare-feu

Routeur NAT

Pare-feu

Intranet

2Internet

Réseau privé 1 Réseau privé 2 Réseau public

Figure 9 – Réseau avec une chaîne de pare-feu ou de routeurs NAT

Réseau avec une chaîne de pare-feu ou de routeurs NAT Pour diverses raisonsd’ordre économique, de sécurité ou de manque d’adresse IP publique, les réseaux privés sontparfois disposés en chaîne tel qu’illustré dans la figure 9. Dans ce cas, les postes du premierréseau privé sont en mesure d’accéder aux postes du deuxième réseau privé, mais l’inverseest prohibé. Les postes dans le premier et deuxième réseau interne sont en mesure d’accéderaux postes sur l’Internet, mais l’inverse est prohibé.

Réseau avec une zone démilitarisée (DMZ) Une zone démilitarisée est une zone in-termédiaire entre un réseau privé et un réseau public telle qu’illustrée dans la figure 10. Cettezone intermédiaire sert à déployer des serveurs afin d’offrir des services qui sont partagés auniveau du réseau privé et public. Elle est protégée par des dispositifs de sécurité qui peuventavoir des politiques différentes.


Réseau démilitarisé

Intranet

Réseau privé Réseau public

Routeur NAT

Pare-feu

Routeur NAT

Pare-feu

Routeur NAT

Pare-feu

Réseau

démilitarisé

Internet

Figure 10 – Réseau avec une zone démilitarisée

4 SIP : UN SERVICE POSTE À POSTE VERSATILE 10

4 SIP : Un service poste à poste versatile

Session Initiation Protocol (SIP) est un protocole standard décrit dans le RFC3261[5]. Celui-ci permet l’établissement, la terminaison et le changement de session au niveau poste à posteet client/serveur. Il est présentement l’un des protocoles les plus prometteurs afin d’offrir lesnouveaux services en émergence par son mécanisme de localisation des utilisateurs et sonextensibilité.

SIP permet de localiser des utilisateurs au sein d’un réseau étant donné que son fonctionne-ment est basé sur l’enregistrement d’un usager auprès d’un serveur SIP qui est en mesure delocaliser l’usager. Par exemple, un usager ([email protected]) s’enregistre à un serveurSIP en effectuant une requête. Celui-ci va être en mesure de déterminer l’adresse du posteoù l’utilisateur se situe (poste.gel.usherb.ca). La localisation de l’usager étant connue ([email protected]), différentes sessions offrant divers services pourront être ouvertesavec cet usager. En effet, SIP permet à un usager ([email protected]), indépendammentde sa localisation d’être accessible (dans ce cas, à l’adresse [email protected]) dansun réseau.

SIP est un protocole qui a la caractéristique d’être extensible. Cette extensibilité lui permetde transporter une charge utile arbitraire. En effet, SIP peut être combiné à d’autres pro-tocoles de communication, codecs ou encore formats de fichiers afin d’offrir des nouveauxservices au travers de sessions SIP. Par exemple, deux usagers peuvent clavarder pour en-suite décider d’ouvrir une session téléphonique IP afin de converser ensemble. Lors de cetteconversation, des fichiers ou des photos peuvent être échangés en temps réel. En conséquent,SIP, par son architecture extensible, permet une interaction intégrée de plusieurs médiasentre usagers distants.

4.1 Architecture de SIP

L’architecture de SIP comporte deux entités principales : les agents SIP et les serveursSIP. Ces entités interagissent entres elles afin de localiser un usager au sein d’un réseau etpermettre des services qui sont définis dans les extensions de SIP.

4.1.1 Agents utilisateurs (User agents)

Il existe plusieurs types d’agents utilisateurs. Ceux-ci peuvent être des périphériques ouencore des logiciels interagissant ensemble afin de fournir des services tels que la vidéocon-férence, la téléphonie IP, les jeux interactifs ou encore les échanges de fichiers. Ces agentsutilisateurs (User Agents (UA)) sont dénommés UA client ou UA serveur selon qu’ils ef-fectuent ou qu’ils reçoivent une requête d’ouverture de session. Lors d’une ouverture d’unesession, une requête est effectuée du UA client au UA serveur (voir figure 11). Une sessionposte à poste peut donc être ouverte entre deux utilisateurs utilisant SIP.


Figure 11 – Établissement et terminaison d’une session SIP entre deux agents utilisateurs.

4.1.2 Serveur SIP

Il existe quelques types de serveur SIP : Serveur Proxy SIP, serveur de redirection SIP etserveur d’enregistrement. Ces trois types de serveur effectuent diverses tâches au sein d’unréseau tel que décrit dans l’article « SIP : Protocol Overview »[7].

Figure 12 – Établissement d’une session SIP avec l’utilisation d’un serveur proxy SIP.

Serveur Proxy SIP Tel que décrit dans le RFC3261[5], ce type de serveur est un élémentqui transfère les requêtes SIP à un agent utilisateur serveur et les réponses SIP à un agentutilisateur client (voir figure 12). Une requête peut traverser quelques serveurs Proxy SIP afind’être acheminé vers un client. Chacun de ces serveurs vont appliquer les règles de routage


ainsi qu’effectuer les modifications nécessaire aux diverses requêtes avant de le transférer auprochain élément. Les réponses vont être réacheminer au travers des divers éléments suivantle chemin inverse de la requête.

Figure 13 – Établissement d’une session SIP avec l’utilisation d’un serveur de redirectionSIP.

Serveur de redirection SIP Un serveur de redirection est un serveur qui transfère versle client l’information concernant le routage de la requête (voir figure 13) afin que celui-cieffectue les requêtes sans passer par le serveur. En faisant de sorte, le serveur n’est plusimpliqué dans les échanges futures de messages entre un agent utilisateur client et serveur.

Serveur d’enregistrement Un serveur d’enregistrement est un serveur qui traite les re-quêtes d’enregistrement (REGISTRER) afin de mettre à jour la localisation de l’usager dansla base de données, grâce aux informations fournies lors de la requête (voir figure 14).

4.2 Problématique de la traversée du protocole SIP au travers desdispositifs de sécurité

SIP, par son fonctionnement interne qui permet la localisation des utilisateurs au sein d’unréseau et l’extensibilité d’échanges de divers contenus multimédia, ne fonctionne pas dansl’architecture des réseaux actuels. En effet, dans l’architecture de SIP, plusieurs informa-tions critiques tel que l’adresse IP ainsi que le port à utiliser sont contenu dans les messagesSIP. Afin de bien comprendre la problématique engendrée par les dispositifs de sécurité, les


Figure 14 – Enregistrement de la localisation d’un usager auprès d’un serveur de redirectionSIP.

tableaux 1 et 2 exposent le contenu des messages échangés par deux postes lors de l’établisse-ment d’une communication voix. Dans cet exemple, l’utilisateur SIP [email protected] l’utilisateur [email protected] afin de discuter de leur fin de semaine. Carolineenvoit donc une requête d’invitation INVITE (voire tableau 1) contenant des informationsconcernant la session à ouvrir (Session Description Protocol - SDP) à Mélanie. Celle-ci ré-pond avec le message 200 OK (voir tableau 2) contenant des informations supplémentairessur la session à ouvrir. Comme on peut le constater, l’adresse ainsi que le port à utiliser lorsde l’ouverture de la session audio sont contenues dans le corps des messages INVITE et OK.Ces deux informations servent à l’établissement du lien audio entre Caroline et Mélanie.

Message de requête Description

INVITE sip :[email protected] SIP/2.0 Requête de service : mode, URI (l’adresse de l’uti-lisateur SIP), version de SIP.

Via : SIP/2.0/UDP gel.usherb.ca Adresse du dernier relais.From : Caroline G. <sip :[email protected]> Utilisateur appelant.To : Mélanie <sip :[email protected]> Utilisateur appelé.Call-ID : [email protected] Identificateur unique d’appel.CSeq : 1 INVITE Séquence de commande.Subject : Fin de semaine Nature de l’appel.Content-Type : application/SDP Type de données (SDP dans ce cas).Content-Length : 119 Nombre d’octets de données.

Ligne vide afin d’indiquer la fin de l’entête SIP etle début du corps.

v=0 version de SDP.o=caroline 5544354 5544354 IN IP4 132.210.3.5 Source, identificateur de session, session, version,

type d’adresse et adresse.s=Fin de semaine Sujet de la session.c=IN IP4 gel.usherb.ca Information sur la connectionM=audio 3456 RTP/AVP 0 3 4 5 Description du média : Type, port, format accepté

par l’appelant.

Tableau 1 – Message d’invitation SIP (INVITE)


Message de requête Description

SIP/2.0 200 OK Statu du service : version de SIP, code de réponse,raison.

Via : SIP/2.0/UDP gel.usherb.ca Copie de la requête.From : Caroline G. <sip :[email protected]> Copie de la requête.To : Mélanie <sip :[email protected]> ;tag=14523

Copie de la requête. Incluant une étiquette conte-nant un identifiant unique.

Call-ID : [email protected] Copie de la requête.CSeq : 1 INVITE Copie de la requête.Content-Type : application/SDP Type de données - SDP dans ce cas.Content-Length : 114 Nombre d’octets de données.

Ligne vide afin d’indiquer la fin de l’entête SIP etle début des données.

v=0 Version of SDP.o=Mélanie 5544354 5544354 IN IP4 191.4.2.5 Source, identificateur de session, session, version,

type adresse, adresse.s=Fin de semaine Sujet de la session.c=IN IP4 poste.home.com Information sur la connexion.m=audio 5004 RTP/AVP 0 3 Description des types de flux de données accepté

par l’appelant.

Tableau 2 – Message de réponse SIP (OK)

4.2.1 Problématique engendrée par SIP avec les pare-feu

La problématique engendrée par l’utilisation de SIP au travers des pare-feu vient du fait queceux-ci sont généralement déployés en utilisant des politiques de filtrage qui empêchent tousles paquets qui ne proviennent pas ou qui ne sont pas destinés à une adresse IP et un portdéfini. Ces politiques, qui sont généralement statiques, ne permettent pas la traversée d’unflux de données à des protocoles comme SIP qui négocient de façon dynamique l’adresse IPet le numéro du port utilisé sur un poste[10].

Afin de bien comprendre la problématique de la traversée du protocole SIP au travers despare-feu, l’analyse du contenu des messages SIP est nécessaire. En effet, comme on peutle constater dans l’exemple d’établissement de session énoncé dans la section 4.2, le portutilisé par le protocole de communication afin d’établir un lien audio est déterminé de façondynamique dans la charge utile (SDP) de la requête SIP. Dans le cas de notre exemple,Caroline et Mélanie utilisent respectivement les ports 3456 et 5004. Comme on peut leconstater, il est donc difficile de prédire quel port sera utilisé par les différents services SIP.En conséquent, les différents services ne pourront fonctionner de pair avec pare-feu étantdonné que ceux-ci ont généralement des règles de filtrage strictes et statiques. Le contenumultimédia sera donc tout simplement filtré par les pare-feu.

4.2.2 Problématique engendrée par SIP avec les routeurs NAT

La problématique engendrée par l’utilisation de SIP au travers des routeurs NAT vient dufait que ceux-ci effectuent une translation d’adresse afin d’acheminer les paquets du réseauprivé au réseau public. Lors de cette translation, l’adresse et le port utilisés changent selon letype de routeurs NAT (voir section 3.3). Étant donné que les routeurs NAT sont seulementen mesure de changer l’entête des paquets de type IP, les informations concernant l’adresseet le port d’origine contenus dans les requêtes SIP ne sont pas modifiés. L’utilisation duprotocole SIP dans des réseaux utilisant des routeurs NAT pose une double problématique


selon que le routeur est situé au niveau de l’appelant ou de l’appelé. Afin de bien comprendrecette problématique concernant la traversée du protocole SIP au travers des routeurs NAT,une analyse du contenu des messages SIP est nécessaire.

Lorsqu’un routeur NAT est situé au niveau de l’appelant, l’adresse du poste effectuant larequête appartenant à un réseau privé n’est pas accessible par les postes situés dans le réseaupublic. Par conséquent, dans notre exemple, Mélanie ne pourra établir de communicationavec Caroline étant donné que pour Mélanie, l’adresse du poste de Caroline est non-valide.En effet, lors de la translation d’adresse effectuée par le routeur NAT, seuls l’adresse et lenuméro de port contenus dans l’entête sont modifiés. L’adresse et le numéro de port contenusdans le corps de la requête sont laissés intactes. Comme on peut le constater dans l’exempled’établissement de session énoncé dans la section 4.2, le port et l’adresse de l’origine de larequête sont contenus dans le corps de la requête INVITE (voir tableau 1). Ce port et cetteadresse est cependant non-valide pour Mélanie. Caroline pourra donc effectuer l’appel etenvoyer des données, mais ne sera pas en mesure de recevoir des données.

Lorsqu’un routeur NAT est situé au niveau du réseau de l’appelé, celui-ci ne pourra êtrecontacté. En effet, du réseau public, aucun poste du réseau privé n’est visible. Il est doncimpossible d’initier une session avec un poste se situant dans le réseau privé à partir duréseau public.

5 APPROCHE POUR UNE GESTION DE TRAVERSÉE DE PROTOCOLES ÀTRAVERS DES PARE-FEU ET DES ROUTEURS NAT 16

5 Approche pour une gestion de traversée de protocolesà travers des pare-feu et des routeurs NAT

Afin de faire face au nouveau paradigme qu’engendrent les communication poste à poste detype UDP dans un réseau sécurisé par des pare-feu et des routeurs NAT, plusieurs solutionsont été proposées. Celles-ci peuvent être regroupées en deux catégories : les solutions utilisantun relais et les solutions utilisant une communication directe afin de traverser les pare-feu etles routeurs NAT.

5.1 Utilisation d’un relais permettant la traversée des pare-feu etdes routeurs NAT

Les solutions présentées ci-dessous sont des solutions utilisant un dispositif de relais afind’acheminer l’information entre deux entités effectuant une communication poste à poste.

5.1.1 Serveur d’application

Figure 15 – Un serveur d’application dans un domaine privé utilisé en tant que relais à unecommunication poste à poste.

La technique utilisant des serveurs d’application est une technique qui consiste à déployerdans un réseau des serveurs dans un domaine privé ou encore dans un domaine neutre(Demilitarised Zone - DMZ) telle qu’illustrée respectivement par les figures 15 et 16. Cesserveurs effectue un relais entre des postes désirant communiquer ensemble. Cette solutionréside cependant en une solution propriétaire qui cible des protocoles et des produits bienprécis. Par exemple, dans le cas de SIP, un serveur d’application SIP est un serveur ProxySIP ou un serveur de redirection SIP[12] qui est localisé dans un réseau interne ou encoredans le réseau démilitarisé et qui effectue la tâche de relais entre un poste dans le domaineprivé et un poste dans un domaine public. L’utilisation de cette technique permet la traverséede tous les dispositifs de sécurité ainsi que toutes les topologies comme on peut le constaterdans le tableau 3 et 4.

L’utilisation de cette technique offre plusieurs avantages. Premièrement, elle est simple,éprouvée, déployée et utilisée. Deuxièmement, cette technique ne requiert aucune modifica-


Figure 16 – Un serveur d’application dans un domaine démilitarisé sert de relais à unecommunication poste à poste.

Dispositifs Appel sortant Appel entrant

Pare-feu • •

Cône plein • •

Cône restrictif • •

Cône restrictif sur les ports • •

Symétrique • •

Tableau 3 – Périphériques traversés par un serveur d’application.

tion des éléments réseau, des applications ou des protocoles de communication. Finalement,la sécurité du réseau n’est pas compromise.

Cette technique comporte cependant plusieurs désavantages. Premièrement, elle nécessitele déploiement et la maintenance d’un serveur. Deuxièmement, l’utilisation d’un serveurd’application réside en une solution propriétaire et spécifique à un protocole en particulier. Enconséquent, cette solution est donc peu polyvalente et n’est pas conseillée dans l’éventualitéoù les besoins en services multimédias sont appelé à se diversifier et à prendre de l’expansion.Finalement, étant donné que cette solution réside en un relais, le temps le latence est doncaccrue puisque les données ne se transigent plus directement.

Topologie Appel sortant Appel entrant

Réseau public • •

Réseau interne • •

Réseau interne avec un accès au réseau public • •

Réseau avec une chaîne de pare-feu ou de routeurs NAT • •

Tableau 4 – Topologies traversées en utilisant des périphériques traversés par un serveurd’application.


5.1.2 Serveur d’application avec agent

Figure 17 – Décomposition du serveur d’application avec agent.

La technique utilisant un serveur d’application avec agent consiste à déployer un serveurd’application dans un réseau public ou démilitarisé qui sera combiné avec l’utilisation d’unagent situé à l’intérieur du réseau privé (voir figure 17). Ces deux entités (serveur et agent)servent de relais aux différentes communications en multiplexant ou en créant un tunnelentre un poste et le serveur d’application. Les communications entre l’agent et le serveurs’effectuent par des ports prédéfinis et autorisés auprès des pare-feu et des routeurs NAT.Cette solution a été développée afin de permettre à des fournisseurs de services d’offrir unserveur de relais à des clients n’ayant pas ou peu de contrôle sur les éléments et les topologiesdu réseau.

Comme on peut le remarquer dans les tableaux 5 et 6, la solution utilisant un serveurd’application avec agent traverse tous les dispositifs de sécurité ainsi que toutes les topologies.En effet, grâce à l’utilisation d’un agent relais et du serveur d’application, toutes les donnéessont transmises sur des ports prédéfinie et autorisés.


Pare-feu • •

Cône plein • •



Symétrique • •

Tableau 5 – Périphériques traversés par un serveur d’application avec l’utilisation d’un agent.

Les avantages de cette technique incluent tous les avantages de la technique des serveursd’application(voir section 5.1.1), en plus d’ajouter un modèle plus polyvalent pour les diffé-rents services étant donné que le serveur est normalement déployé dans le domaine public.Le serveur peut donc être accessible par un plus grand nombre d’utilisateur tout en offrantle même niveau de sécurité au niveau des réseaux privés.







Tableau 6 – Topologies traversées en utilisant des périphériques traversés par un serveurd’application avec l’utilisation d’un agent.

Les désavantages de cette technique sont semblables aux désavantages reliés aux serveursd’application étant donné que cette solution réside en une solution propriétaire et spécifiqueà un protocole en particulier. En ce qui concerne le déploiement et la maintenance d’unetelle solution, elle est accrue étant donné que le nombre de dispositifs nécessaires au seindu réseau est plus grand. Par le fait même, la latence du réseau risque d’être encore plusélevée que celui du serveur d’application étant donné que les données transigent par plus dedispositifs.

5.1.3 Passerelle de la couche application (ALG)

Figure 18 – Une passerelle de la couche application utilisée en tant que relais à une commu-nication poste à poste.

L’utilisation de la technique d’une passerelle de la couche application (« Application LayerGateways » - ALG) est une technique qui consiste à rendre « intelligent » les pare-feu et lesrouteurs NAT afin qu’ils soient en mesure d’interpréter un protocole spécifique. Plutôt quede simplement déterminer l’action à effectuer à l’aide de l’entête d’un paquet, les passerellesvont faire une inspection complète des données dans le corps du paquet[13]. Elles agissentdonc en tant que relais spécialisés pour un protocole précis et traitant les données au niveauapplication tel qu’illustré dans la figure 18.

Il ne faut pas confondre serveurs d’application (voir section 5.1.1) et passerelles de la couche


application. Les passerelles de la couche application diffèrent des serveurs d’applicationpuisque le traitement est effectué dans les pare-feu ou les routeurs NAT dans le cas dela passerelle alors qu’il est effectué dans un serveur dans le cas des serveurs d’application.Les passerelles de la couche application sont, en quelque sorte, des pare-feu et des routeursNAT spécialisés qui sont capables de traiter spécifiquement un protocole donné. Par exemple,dans un réseau privé utilisant une passerelle de la couche application SIP afin d’acheminerdes paquets vers un réseau public, la passerelle va lire le contenu complet du paquet afin demodifier l’adresse IP et le port d’origine dans le paquet pour le rendre valide dans le réseaupublic. Ensuite, la passerelle sera en mesure d’ouvrir un trou d’épingle afin de laisser cespaquets circuler librement. Dans le cas des pare-feu et des routeurs NAT normaux, ceux-ciinspectent et modifient seulement l’entête d’un paquet et non son contenu.

Comme on peut le constater dans les tableaux 7 et 8, avec l’utilisation de la technique de lapasserelle de la couche application, tous les dispositifs et les topologies peuvent être traverséspar les nouveaux services.


Pare-feu • •

Cône plein • •



Symétrique • •

Tableau 7 – Périphériques traversés par une passerelle de couche application.






Tableau 8 – Topologies traversées en utilisant des périphériques traversés par une passerellede couche application.

Les passerelles de la couche application ont donc l’avantage indéniable d’être une techniquesimple et très sécuritaire. En effet, celles-ci augmentent la sécurité du réseau en examinanttoutes les couches de transmission et réalisent les opérations nécessaires correspondantes.[17]

Cette sécurité n’est cependant pas sans contrecoups. Premièrement, la technique de la pas-serelle de la couche application nécessite une modification des éléments réseaux (pare-feu etrouteurs NAT). Deuxièmement, les passerelles étant liées à un protocole de communication,cette technique est donc très difficile à adapter dans l’éventualité où des nouveaux servicessont offerts. Troisièmement, comme mentionné dans le RFC2663[15] les passerelles de coucheapplication sont des programmes qui s’exécutent dans des pare-feu ou des routeurs NAT.Cette méthode n’est donc pas extensible et utilisable dans l’éventualité où plusieurs utili-sateurs doivent utiliser plusieurs services étant donné que les pare-feu et les routeurs NAT


sont des dispositifs ayant des ressources limitées. Finalement, cette technique augmente letemps de latence étant donné que chaque paquet est traité et inspecté individuellement parla passerelle.

5.1.4 Traversal Using Relay NAT (TURN)

Figure 19 – Traversal Using Relay NAT (TURN) utilisé en tant que relais à une communi-cation poste à poste.

« Traversal Using Relay NAT » (TURN) est un protocole en cours de développement et envoie de standardisation en tant que serveurs de relais[6]. Ce protocole permet à des clientsqui sont dans des réseaux utilisant des routeurs NAT ou encore des pare-feu d’effectuer desconnexions entre eux en passant par un serveur de relais. Cette technique se distingue destechniques des serveurs d’application (voir section 5.1.1), des serveurs d’application avecagent (voir section 5.1.2) et des passerelles de la couche application (voir section 5.1.3) parson indépendance face aux protocoles de communication.

TURN a été développé afin de pallier aux lacunes du protocole STUN(voir section 5.2.4).En effet, ce protocole a été conçu afin que des postes puissent communiquer entre eux et ce,indépendamment de la topologie du réseau, des éléments de sécurité déployés et du protocolede communication utilisé. Son fonctionnement est basé sur l’utilisation d’un serveur TURNsitué dans un réseau accessible par les postes désirant communiquer ensemble. Ce serveurservira de relais aux diverses communications entres les deux postes. L’utilisation de cettetechnique solutionne le paradigme créée par les nouveaux services comme on peut le voirdans les tableaux 9 et 10.


Pare-feu ◦ ◦

Cône plein • •



Symétrique • •

Tableau 9 – Périphériques traversés par TURN.







Tableau 10 – Topologies traversées en utilisant des périphériques traversés par TURN.

L’utilisation de cette technique offre plusieurs avantages. Premièrement, cette technique estune technique simple à comprendre et à déployer. Deuxièmement, cette technique ne requiertaucune modification du réseau et préserve son intégrité. Troisièmement, TURN n’est pas lié àaucun protocole de communication. Finalement, ce protocole en instance de standardisationoffre un niveau de standardisation dans les serveurs de relais.

L’utilisation de cette technique comporte cependant plusieurs désavantages. Premièrement,cette technique est encore en cours de développement et peu de serveur TURN sont présen-tement déployé dans les réseaux actuels. Deuxièmement, afin d’utiliser le serveur TURN entant que relais, une modification des programmes est nécessaire afin que ceux-ci intègre leprotocole TURN. Finalement, étant donné que cette solution réside en un relais entre lespostes, la latence est donc accrue puisque les données ne transigent plus directement.

5.2 Utilisation d’une communication directe permettant la traver-sée des pare-feu et des routeurs NAT

La technique utilisant une communication directe permettant la traversée des pare-feu et desrouteurs NAT consiste à modifier les protocoles de communication ou les éléments réseauxafin de permettre une communication poste à poste sans l’utilisation d’un relais, tout enpermettant la traversée des protocoles de communication au travers des pare-feu et desrouteurs NAT.

5.2.1 Tunnel de données

Figure 20 – Les différents postes reliés par PPTP sont situés dans un même domaine. Unecommunication directe est possible.

La technique du tunnel de données consiste à créer un tunnel de données grâce à un réseau


Réseau Privé Virtuel (RPV) utilisant des protocoles de communication standards et existantstels que PPTP, L2TP et IPSec. La fonction du RPV est de mettre les postes autorisés surun même domaine pour ensuite acheminer tous les paquets nécessaires vers tous les postes(voir figure 20). Tous les postes étant sur un même domaine, ceux-ci sont donc en mesure decommuniquer librement entre eux afin d’effectuer une communication poste à poste.

Comme on peut le constater dans les tableaux 11 et 12, cette technique permet d’établir dessessions poste à poste au travers de tous les dispositifs de sécurité tels que des pare-feu etdes routeurs NAT et dans toutes les topologies.


Pare-feu • •

Cône plein • •



Symétrique • •

Tableau 11 – Périphériques traversés par un tunnel.






Tableau 12 – Topologies traversées en utilisant des périphériques traversés par un tunnel.

L’utilisation de la technique du tunnel comporte plusieurs avantages. Premièrement, cettetechnique consiste à utiliser des protocoles existants et largement utilisés afin de permettreune communication virtuellement directe entre deux postes. Deuxièmement, cette techniquene nécessite aucune modification tant au niveau des éléments réseaux que des applicationsutilisées. Finalement, cette solution peut être facilement déployée pour une compagnie ayantdes bureaux multisites désirant offrir des nouveaux services dans son réseau interne.

L’utilisation de la technique du tunnel comporte aussi deux désavantages. Premièrement,il faut établir un RPV entre les postes avant toute communication, ce qui nécessite desétapes supplémentaires qui peuvent être problématiques à certain usager. Deuxièmement,cette technique requiert un niveau de maintenance du réseau plus élevé.

5.2.2 Universal Plug and Play

Universal Plug and Play (UPnP) est un nouveau standard de communication entre périphé-riques, pour les petites entreprises ou les réseaux résidentiels (SOHO - Small Office HomeOffice), développé par un consortium dont fait partie Intel et Microsoft. Il a été développédans l’optique d’être un standard convivial et flexible pour des réseaux ad-hoc ou non géréspour des résidences, des petits bureaux, des endroits publics.[9] UPnP est plus qu’une simple


extension du standard de périphériques Plug and Play. Il permet aux différents périphériquesd’un réseau de se configurer automatiquement, d’offrir des services de façon dynamique ettransparente. Dans notre problématique, ceci signifie que les pare-feu ainsi que les routeursNAT sont détectés par les postes de travail de façon automatique et que ces postes sont enmesure d’ouvrir, au besoin, des trous d’épingle sur les routeurs NAT et les pare-feu de façondynamique.

Comme on peut le constater dans les tableaux 13 et 14, les périphériques UPnP peuvent êtretraversés par tous les protocoles dans toutes les topologies sauf dans le cas des chaînes depare-feu ou de routeurs NAT. En effet, les communications entre dispositifs UPnP s’effectuentseulement entre deux dispositifs au sein d’un même sous réseau. Les chaînes de pare-feu etde routeurs NAT n’étant pas dans le même sous réseau, les dispositifs ne peuvent donc pascommuniquer entres eux.


Pare-feu • •

Cône plein • •



Symétrique • •

Tableau 13 – Périphériques traversés par UPNP.





Réseau avec une chaîne de pare-feu ou de routeurs NAT ◦ ◦

Tableau 14 – Topologies traversées en utilisant des périphériques traversés par UPNP.

UPnP est une solution qui offre plusieurs avantages. Premièrement, UPnP est convivial enpermettant une interaction de façon transparente afin de permettre la traversée des protocolesde communication au travers des pare-feu et des routeurs NAT. Deuxièmement, UPnP estun standard existant et déployé dans les réseaux SOHO. Finalement, plusieurs périphériquesUPnP sont déjà disponibles sur le marché.

UPnP est une solution qui comporte aussi quelques désavantages. Premièrement, une modi-fication est nécessaire au sein des applications afin de permettre aux applications de com-muniquer avec les dispositifs UPnP. Deuxièmement, les périphériques tels que les pare-feuet les routeurs NAT doivent être remplacés par des dispositifs équivalents supportant UPnP.Finalement, UPnP peut créer une brèche dans un réseau. En effet, tous les programmes etles dispositifs UPnP peuvent ouvrir des trous d’épingle sans authentification ou validation.En résumé, un programme illicite pourrait ouvrir des portes sur un pare-feu ou un routeurNAT et rendre un réseau vulnérable. Cette solution ne peut donc pas être utilisée dans desréseaux d’entreprises ou dans de larges réseaux privés.


5.2.3 Midcom

Midcom est un standard en cours de développement[8] qui consiste à rendre « intelligents »les pare-feu et les routeurs NAT en permettant une quelconque communication au traversd’un trou d’épingle dynamiquement créé. Il diffère de la technique des passerelles de lacouche application (voir section 5.1.3) étant donné que Midcom n’est pas lié à un protocolede communication. En effet, Midcom ne va pas décortiquer les protocoles de communicationjusqu’au niveau application comme le fait les passerelles. Midcom se contente d’ouvrir untrou d’épingle dans les pare-feu ou les routeurs NAT suite à une authentification et unevalidation des autorisations de l’usager. Midcom diffère de UPnP en comblant les lacunes decelui-ci par un mécanisme d’authentification et de contrôle d’accès.

Comme on peut le constater dans les tableaux 15 et 16, des dispositifs tels que des pare-feuet des routeurs NAT où Midcom est implémentés peuvent être traversés dans la majoritédes cas. Seule la problématique créée par les réseaux contenant une chaîne de pare-feu ou derouteurs NAT persiste.


Pare-feu • •

Cône plein • •



Symétrique • •

Tableau 15 – Périphériques traversés par Midcom.






Tableau 16 – Topologies traversées en utilisant des périphériques traversés par Midcom.

La solution proposée par Midcom comporte plusieurs avantages. Premièrement, cette solutionest une solution en voie de standardisation. Deuxièmement, n’étant pas liée à un protocolede communication, elle permet la traversée de tous les protocoles de communication. Finale-ment, Midcom ne comporte pas de lacune au niveau de la sécurité d’un réseau étant donnéqu’une authentification et une validation des autorisations de l’usager est effectuées poureffectuer un trous d’épingle au travers des dispositifs de sécurités.

Midcom comporte cependant aussi quelques désavantages. Premièrement, étant donné quecette solution est en élaboration, il n’y a aucun réseau Midcom présentement déployé. Deuxiè-mement, cette solution nécessite une modification des pare-feu et des routeurs NAT sur lesdifférents réseaux. Troisièmement, les différents protocoles de communication ou serveurdoivent être adaptés afin de pouvoir communiquer avec les dispositifs Midcom. Finalement,cette solution ne traite pas le cas où des chaînes de pare-feu ou de routeurs NAT sont présents.


5.2.4 Simple Traversal of UDP Through Network Address Translators (STUN)

Figure 21 – Simple Traversal of UDP Through Network Address (STUN) sert à découvrir lescaractéristiques de dispositifs de sécurité par des requêtes au serveur STUN.

« Simple Traversal of UDP Through Network Address Translators » (STUN) est un protocolesimple énoncé dans le RFC3489[11]. Il a été développé par le groupe de travail de Midcom(voir section 5.2.3) afin de permettre la traversée de routeurs NAT en caractérisant lescapacités d’un poste à effectuer une communication de type UDP avec un réseau public. Ildétermine l’adresse IP et le port public utilisés par un poste situé dans un réseau privé. Pource faire, une série de requêtes à un serveur STUN est effectuée et les réponses provenant decelui-ci serviront à caractériser les capacités d’un poste à communiquer.

Avec l’utilisation de STUN, plusieurs problèmes reliés aux routeurs NAT peuvent être so-lutionnés. En effet, combinant STUN à des protocoles tel que SIP, plusieurs cas peuventêtre solutionnés comme on peut le voir dans les tableaux 17 et 18. Seuls les cas où des rou-teurs NAT de type symétrique ou des pare-feu sont utilisés ne peut être traités en utilisantcette technique. Le cas des pare-feu ne peut être traité étant donné que les paquets sontfiltrés systématiquement par le pare-feu. En conséquent, il est donc impossible d’effectuerl’ouverture d’une session. En ce qui concerne les routeurs NAT de type symétrique, il estimpossible de caractériser ce type de routeurs afin de prédire son comportement au momentde la translation. Il est donc impossible d’ouvrir une session avec un tel type de routeurs.


Pare-feu ◦ ◦

Cône plein • •



Symétrique ◦ ◦

Tableau 17 – Périphériques traversés par STUN.

Une majorité de topologies peuvent être traversées lorsque des périphériques traversés parSTUN sont utilisés dans celles-ci. Il reste cependant la problématique créée par les chaînesde routeurs NAT qui n’est pas solutionnée par STUN. En effet, STUN ne permet pas de







Tableau 18 – Topologies traversées en utilisant des périphériques traversés par STUN.

déterminer l’adresse IP à utiliser avec des utilisateurs situés entre le réseau de l’appelant etle réseau public. STUN permet seulement de déterminer l’adresse IP du domaine public.

Les avantages de l’utilisation de cette technique sont multiples. Premièrement, cette tech-nique est une technique standardisée. Deuxièmement, peu d’infrastructures sont nécessairesà son implémentation et son déploiement. Seul un serveur servant à effectuer les requêtesafin de déterminer l’adresse public ainsi que les caractéristiques des capacités à communi-quer aux différents postes doit être déployé. Finalement, cette technique ne requiert aucunemodification de l’architecture du réseau présent.

La solution utilisant STUN a cependant quelques désavantages. Premièrement, cette tech-nique requiert une adaptation des programmes existants. Deuxièmement, les requêtes et lesréponses pour caractériser la communication peuvent être interprétées comme une attaquepar les dispositifs de sécurité. Troisièmement, elle ne permet pas la traversée de tous lespare-feu et les routeurs NAT. Quatrièmement, cette technique ne peut être déployée dansdes réseaux utilisant des passerelles de la couche application étant donné que celles-ci mo-difient les adresses dans les paquets SIP. Finalement, cette technique ne permet pas dedéterminer l’adresse à utiliser correctement lors de communication à l’intérieur d’un réseauinterne ou encore entre un sous réseau interne et un réseau interne.

5.2.5 Interactive Connectivity Establishment(ICE)

Figure 22 – Interactive Connectivity Establishment (ICE) (ICE) consiste à intégrer STUNet TURN à SIP afin d’offrir une connectivité.

Interactive Connectivity Establishment (ICE) est une technique en cours de développe-ment[14] qui consiste à intégrer STUN et TURN au sein des clients SIP. Par cette intégration,cette technique permet de déterminer toutes les connections possibles entre deux postes. Pour


ce faire, ICE caractérise premièrement les transmissions de média entre les postes et le réseaupublic en effectuant des requêtes STUN à un serveur qui combine STUN/TURN. Deuxiè-mement, une liste d’adresses IP par lesquelles chaque poste peut être contacté est générée.Troisièmement, une caractérisation des transmissions de média entres deux postes est effec-tuée afin de déterminer la meilleure communication possible. Dans l’éventualité où aucunecommunication directe est possible entre deux postes, ICE utilisera les services d’un serveurTURN afin de permettre cette communication.

Comme on peut le constater dans les tableaux 19 et 20, ICE permet la traversée de tous lesdispositifs et de toutes les topologies sauf dans l’éventualité où des pare-feu sont utilisés. ICEne permet pas cette traversée étant donné que les pare-feu sont des dispositifs qui filtrent lespaquets selon des règles statiques. ICE est en mesure de caractériser et d’identifier ces règlessur les pare-feu mais ne permettra pas de sa traversée.


Pare-feu ◦ ◦

Cône plein • •



Symétrique • •

Tableau 19 – Périphériques traversés par ICE.






Tableau 20 – Topologies traversées en utilisant des périphériques traversés par ICE.

Les avantages de cette technique sont multiples. Premièrement, cette technique intègre STUNet TURN qui sont standardisés et non liés à un protocole de communication. En conséquent,elle permet la traversée de toutes les topologies et de tous les périphériques sauf dans lecas où des pare-feu sont utilisés. Deuxièmement, elle ne nécessite aucune modification dansles dispositifs de sécurité présents sur un réseau. Finalement, elle nécessite seulement ledéploiement d’un serveur combiné STUN/TURN dans un réseau.

ICE comporte aussi quelques désavantages. Premièrement, étant donné que cette techniqueconsiste à caractériser toutes les communications possible entre un poste et un réseau publicet entres deux postes, elle augmente le temps d’établissement d’un appel. Deuxièmement,tout comme dans le cas de STUN, la caractérisation de la communication peut être in-terprétée par les dispositifs de sécurité comme étant une attaque mené d’un serveur à unposte situé dans un réseau privé. Troisièmement, cette technique force un serveur à utiliserquelques ports seulement pour les diverses transmissions de média. Quatrièmement, il fautavoir un démultiplexeur en mesure de différencier les paquets de média et les paquets destinés


à STUN étant donné que les paquets de média et les paquets STUN se partage le même port.Cinquièmement, une modification des serveurs et des clients sont nécessaire afin de déployerICE. Finalement, ICE est une technique en cours de standardisation.

5.3 Conclusion

Le paradigme de la traversée des protocoles de communication au travers des pare-feu etdes routeurs NAT a été solutionné en utilisant plusieurs techniques qui sont résumées dansle tableau 21. Comme on peut le constater, les approches utilisant un serveur de relais ontquelques désavantages en commun. Premièrement, ces approches augmentent le temps delatence du réseau. Deuxièmement, étant donné que toutes les données doivent transiger parle relais, ces techniques ne peuvent être utilisées dans un réseau voué à prendre de l’expansion.Finalement, ces techniques sont généralement liées à un protocole de communication.

Les approches utilisant une communication directe afin de permettre la traversée des pare-feu et des routeurs NAT solutionnent les lacunes de l’approche utilisant des relais. En effet,elles éliminent le temps de latence supplémentaire lors du traitement des données et ellespermettent une expansion plus facile des réseaux en n’étant pas liées à un protocole decommunication. En contrepartie, ces techniques nécessitent généralement une modificationdes applications ou des serveurs.

L’approche permettant la traversée des protocoles de communication au travers des pare-feu et des routeurs NAT la plus prometteuse est l’approche Midcom. En effet, n’étant pasun relais, elle n’a donc pas les désavantages liés aux relais. Comparativement au tunnelde données, elle demande un niveau de maintenance et d’opération moindre. En effet, afind’utiliser la technique du tunnel de données, l’utilisateur doit créer celui-ci avant d’établir unecommunication. Comparativement à UPnP, Midcom offre un niveau de sécurité plus élevéétant donné que la création de trou d’épingle se fait par un mécanisme où une authentificationet une validation est nécessaire. Comparativement à STUN, Midcom permet la traverséede tous les pare-feu et des routeurs NAT incluant les routeurs NAT de type symétrique.Comparativement à ICE, Midcom permet la traversée des pare-feu et n’est pas interprétépar les dispositifs de sécurité comme étant une attaque auprès d’un réseau.

Midcom, tel qu’il est proposé présentement, comporte cependant trois lacunes majeures quipeuvent nuire à son adoption future en tant que standard. Premièrement, cette solutionest encore à l’étape d’élaboration. Deuxièmement, cette solution exige une modification desapplications, serveurs, pare-feu et des routeurs NAT au sein des réseau. Finalement, cettesolution ne prévoit pas la traversée des chaînes de routeurs NAT.


Techniques Avantages Désavantages

Serveur d’application• Technique simple, éprouvée, déployée etutilisée.• Aucune modification des éléments ré-seaux, des applications ou des protocolesde communication nécessaire.• Sécurité du réseau maintenue.

• Déploiement et maintenance d’un ser-veur nécessaires.• Solution propriétaire.• Solution liée au protocole de communi-cation.• Temps de latence accru.

Serveur d’application avec agent• Technique simple, éprouvée, déployée etutilisée.• Aucune modification nécessaire des élé-ments réseaux, des applications ou desprotocoles de communication.• Sécurité du réseau maintenue.

• Déploiement et maintenance d’un ser-veur et d’un agent nécessaires.• Solution propriétaire.• Solution liée au protocole de communi-cation.• Temps de latence accru.

Passerelle de la couche application• Technique simple, éprouvée, déployée etutilisée.• Niveau de sécurité accru par l’inspec-tion complète des paquets.

• Modifications des pare-feu et des rou-teurs NAT nécessaires.• Solution liée à un protocole de commu-nication.• Solution peu envisageable dans un ré-seau en pleine expansion.• Temps de latence accru.

TURN• Technique simple.• Aucune modification des éléments ré-seaux nécessaire.• Serveur de relais en cours de standardi-sation.• Fonctionne avec tous les protocoles decommunication.

• Technique peu utilisée et déployée.• Modifications des applications néces-saires.• Temps de latence accru.

Tunnel de données (RPV)

• Technique simple à comprendre.• Aucune modification des éléments ré-seaux et des applications.• Peut être facilement déployée en per-manence dans un réseau multisite d’unecompagnie.

• Établissement d’un RPV nécessaireavant l’établissement d’une communica-tion.• Requiert un niveau de maintenanceélevé.

Universal Plug and Play (UPNP)

• Solution conviviale.• Technique déployée dans des réseauxSOHO.• Plusieurs périphériques disponibles surle marché.

• Modifications des applications et deséléments réseaux nécessaires.• Lacunes au niveau de la sécurité.

Midcom• Permet la traversée de tous les proto-coles de communication.• Niveau de sécurité maintenu dans le ré-seau.• Solution en voie de standardisation.

• Aucun réseau Midcom déployé.• Nécessite une modification des applica-tions/serveurs et des éléments réseaux.• Ne permet pas la traversée les chaînesde pare-feu ou de routeurs NAT

STUN• Technique standardisée.• Peu d’infrastructure nécessaire.• Aucune modification des éléments ré-seaux nécessaire.

• Caractérisation parfois interprétéecomme une attaque au sein d’un réseau.• Modifications des applications/serveursnécessaires.• Ne permet pas la traversée des routeursNAT de type symétrique.• Ne permet pas de déterminer l’adresse àutiliser correctement dans les chaînes oules appels dans le même domaine.

ICE• Combine des techniques déjà utilisées.• Peu d’infrastructure nécessaire.• Aucune modification des éléments ré-seaux nécessaire.

• Caractérisation parfois interprétéecomme une attaque au sein des réseaux.• Augmentation du temps d’établisse-ment d’un appel.• Force l’utilisation de quelques ports pré-définis.• Nécessite un démultiplexeur afin de dif-férencier les paquets de média et les pa-quets STUN reçus sur un port.• Modifications des applications/serveursnécessaires.

Tableau 21 – Tableau récapitulatif des différentes techniques permettant la traversée despare-feu et des routeurs NAT.

6 DÉFINITION ET OBJECTIF DU PROBLÈME 31

6 Définition et objectif du problème

Les nouveaux services orientés vers une communication poste à poste créent un nouveauparadigme au sein du réseau actuel. En effet, les protocoles de communication, tel que SIP, nepeuvent être traversés par des pare-feu ou des routeurs NAT. Afin de remédier à ce problème,plusieurs techniques ont été mises en oeuvre. Parmi toutes ces techniques, Midcom sembleêtre la technique la plus prometteuse par sa polyvalence qui permet son utilisation avec tousles protocoles de communication, sa latence réduite comparée aux solutions utilisant un relaiset son utilisation possible dans des réseaux en pleine expansion. Cette solution comportetrois lacunes majeures telles que mentionnées précédemment. Premièrement, cette solutionest encore à l’étape d’élaboration. Deuxièmement, cette solution implique la modificationdes différents pare-feu et des routeurs NAT au sein des réseau. Finalement, cette solution neprévoit aucun scénario pour traverser des chaînes de routeurs NAT.

Afin de pallier à cette problématique, une extension à Midcom va être proposée afin depermettre la traversée des chaînes de pare-feu et de routeurs NAT. Ainsi, toutes les topologiesainsi que tous les dispositifs vont pouvoir être traversés en utilisant Midcom. Pour ce faire,cette extension à Midcom devra permettre la découverte de la topologie utilisée pour ensuitepermettre une communication entre les différents dispositifs Midcom.

Dans une première étape, afin de permettre le bon fonctionnement des dispositifs Midcom,une découverte de la topologie dans laquelle les dispositifs sont utilisés est nécessaire. Pource faire, une intégration des diverses techniques de découverte de topologies et de dispositifsexistant devra être effectuée.

Dans une deuxième étape, une architecture d’un système devra être mis en oeuvre afinde permettre une communication entre les différents dispositifs Midcom se situant dans lachaîne. Pour ce faire, un arbre décisionnel et des scénarios devront être développés afin dehiérarchiser et organiser les communications entre les dispositifs Midcom.

Dans une troisième étape, les scénarios devront être développés afin de caractériser les chaînesde pare-feu ou de routeurs NAT contenant des dispositifs Midcom et non-Midcom. Cecipermettra de développer une base de connaissance afin de permettre aux différents protocolesde communication de traverser de telles topologies.

Suite à ces étapes, les différents protocoles de communication devront être en mesure detraverser les chaînes de pare-feu et de routeurs NAT Midcom. Midcom sera alors une solutionpolyvalente, performante et fonctionnant dans tous les scénarios.

7 MÉTHODOLOGIE 32

7 Méthodologie

Afin de mener à terme le projet tel que décrit dans la section définition et objectif duproblème (voir section 6), voici les différentes étapes qui devront être franchies.

Recherche littéraire des diverses techniques et solutions afin de permettre la tra-versée de SIP au travers des pare-feu et des routeurs NAT.1er avril au 30 septembre 2003Cette étape consiste à faire une recherche bibliographique afin de se familiariser, de com-prendre et de caractériser les différentes techniques qui permettent la traversée des différentsprotocoles tel que SIP au travers des pare-feu et des routeurs NAT. Elle permettra de dé-terminer une solution prometteuse pour ensuite analyser ces caractéristiques. Enfin, ellepermettra de cibler les lacunes de cette technique pour ensuite proposer de traiter cetteproblématique.

Spécification d’un design préliminaire permettant à SIP de traverser une chaînede pare-feu et de routeurs NAT dans les divers scénarios.1er octobre au 5 Janvier 2004Cette étape consiste à dresser une liste des différents scénarios possible afin de déterminer, ca-ractériser et de valider la problématique engendrée par une chaîne de pare-feu ou de routeursNAT Midcom, non-Midcom et mixte (chaîne ayant des dispositifs Midcom et non-Midcom).Suite à cette étape, une proposition d’une extension à Midcom pourra être effectuée.

Développement d’un exemple d’implémentation du mécanisme de traversée despare-feu et des routeurs NAT.6 janvier 2004 au 30 avril 2004Suivant la proposition de l’extension de Midcom, une implémentation réelle sera effectuée afinde valider celle-ci. Lors de cette étape, une intégration de Midcom incluant l’extension seraeffectuée dans tous les dispositifs nécessaires tels que les pare-feu, routeurs NAT, serveursSIP et applications SIP.

Évaluation expérimentale de la solution de la traversée du protocole SIP autravers des pare-feu et des routeurs NAT.1er Mai au 30 Août 2004Cette étape permettra de valider l’extension de Midcom en permettant de caractériser lecomportement et les performances du système.

A APPENDIX 33

A Appendix

A.1 Lexique

ACL - (Access Control List) Liste de contrôle d’accès qui permet seulement aux usagerautorisé à effectuer des opérations.

ALG - (Application Layer Gateway) Passerelle de la couche application

L2TP - (Layer 2 Tunneling Protocol) Protocole de communication permettant la créationd’un réseau privé virtuel utilisant la couche lien de données.

Pare-feu - Dispositifs déployé aux extrémités d’un réseau privé afin de filtrer les donnéestransmises entre un réseau privé et un réseau public.

PPTP - (Point-to-point Tunnuling protocol Protocole de communication permettant lacréation d’un réseau privé virtuel utilisant la couche réseau.

Réseau Ad-Hoc - Un réseau parallèle, indépendant et spécialité

Routeur NAT - (Network Adress Translation Router) Routeur à translation d’adresse.Dispositif déployé aux extrémités d’un réseau privé utilisant des adresses IP privés etqui agit en tant que passerelle entre le réseau privé et le réseau public.

RPV - Réseau privé virtuel

SDP - Session Description Protocol

SIP - (Session Initiation Protocol) Protocole de communication

SOHO - (Small Office Home Office) Petit réseau conçu pour un bureau ou un réseau rési-dentiel.

Trou d’épingle - (Pin hole) Trou effectué dans un dispositif de sécurité de façon dynamiqueafin de permettre un flux de données précis.

BIBLIOGRAPHIE 34

BIBLIOGRAPHIE

[1] Statistique Canada. tableau 358-0002 et produit no 56F0004MIF au catalogue. CANSIM.[2] P. Cordell. SPAN Discussion Issues. Internet Engineering Task Force, August 2002.[3] CRTC. Rapport à la gouverneire en conseil - État de la concurrence dans les marchés

des télécommunications au Canada, mise en place et accessibilité de l’infrastructureet des services de télécommunications de pointe. Conseil de la radiodiffusion et detélécommunications canadiennes, 2001.

[4] Office de la langue française. Définition de pare-feu. Office de la langue française, 2003.[5] J. Rosenberg et al. SIP : Session Initiation Protocol. Internet Engineering Task Force,

June 2002.[6] J. Rosenberg et al. Traversal Using Relay NAT (TURN). IETF Internet Draft, 2003.[7] M. Stiemerling et al. SIP : Protocol Overview. Radvision, 2001.[8] P. Srisuresh et al. Middlebox communication architecture and framework. Internet En-

gineering Task Force, August 2002.[9] UPnP Forum. UPnP Device Architecture 1.0. UPnP Forum, May 2003.

[10] M. Holredge and P. Srisureh. RFC3027 - Protocol Complications with the IP NetworkAddress Translator. Internet Engineering Task Force, January 2001.

[11] C. Huitema R. Mahy J. Rosenberg, J. Weinberger. STUN - Simple Traversal of User Da-tagram Protocol (UDP)Through Network Address Translators (NATs). IETF Stan-dards Track, 2003.

[12] RADVision. Traversal of IP Voice and Video Data through Firewalls and NATs. Whitepaper, 2001.

[13] Wainhouse Research. Traversing Firewalls and NATs with Voice and Video Over IP.White paper, 2002.

[14] J. Rosenberg. Interactive Connectivity Establishment (ICE) : A Methodology for Net-work Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP).Internet Engineering Task Force, June 2003.

[15] P. Srisuresh. IP Network Address Translator (NAT) Terminology and Considerations.IEFT Informational, 1999.

[16] Y. Takeda. Symmetric NAT Traversal using STUN. Internet Engineering Task Force,June 2003.

[17] SofaWare Technologies. Stateful Inspection Firewall Technology. White paper.

Documents

Cours reseau ouya