Cours reseau ouya

Faculté de génie
Génie électrique et génie informatique
ARCHITECTURE DE GESTION
DE TRAVERSÉE DE PROTOCOLES AU TRAVERS
DES PARE-FEU ET DES ROUTEURS NAT
Déﬁnition du projet de recherche
Spé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 de
sé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-feu
et 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éﬁnition 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ées
autorisé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 redirection
SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 à une
communication 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. Une
communication directe est possible. . . . . . . . . . . . . . . . . . . . . . . . 22
21 Simple Traversal of UDP Through Network Address (STUN) sert à découvrir
les 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 STUN
et TURN à SIP aﬁn d’oﬀrir 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 serveur
d’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 serveur
d’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 passerelle
de 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 diﬀérentes techniques permettant la traversée des
pare-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 faire
et de voir les choses. Lire ses courriels, naviguer sur l’Internet ou télécharger de la musique
font maintenant partie intégrante de nos habitudes de vie. En effet, le nombre de ménages
ayant accès à Internet a doublé entre 1997 et 2001 pour se situer à 60,2% selon Statistiques
Canada [1].
Avec l’avènement des connexions à haute vitesse et une utilisation accrue de l’Internet par la
population, de nouveaux besoins se sont créés et de nouveaux services ont vu le jour. Parmi
ceux-ci, on dénombre des applications riches en multimédia telles que la téléphonie IP, la
té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ônent
une migration des réseaux conventionnels vers un réseau unique de type IP qui acheminera
toute 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 types
de services se sont butés à plusieurs problèmes tels que la vitesse de transmission trop lente
ou 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 Canadienne
habitait 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 les
nouvelles méthodes de compression numérique audio et vidéo, la qualité du son et de l’image
est meilleure que jamais. Tous ces éléments font en sorte qu’une convergence prochaine vers
un 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 au
niveau des dispositifs de sécurité tel que les pare-feu et les routeurs NAT. En effet, dans
les réseaux actuels, les dispositifs de sécurité déployés n’ont pas été conçus dans l’optique
d’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 des
protocoles 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 nouvelle
mé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 au
travers 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 seront
exposé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 sera
proposé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érence
sur l’Internet, un nouveau paradigme a vu le jour. Historiquement, tous les services offerts sur
l’Internet étaient développés selon le modèle de réseau client/serveur alors que les nouveaux
services 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 de
ces nouveaux services ne peuvent être utilisés. Afin de bien comprendre la problématique
qu’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), se
connectent à un serveur qui offre différents services tels que HTTP, FTP et courriel. Les
clients ouvrent une communication vers le serveur en effectuant une requête et celui-ci leur
répond en envoyant une réponse. Comme on peut le constater, dans ce modèle, toutes les
communications sont orientées d’un point spécifique à un autre point spécifique : des clients
vers 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 et
les diverses entitées du réseau. Par exemple, ces diverses entitées peuvent être sécurisées par
des dispositifs tels que des pare-feu ou des routeurs à translation d’adresse (communément
appelé 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. Ces
types 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. Chaque
poste est à la fois serveur et client. Chaque poste décide de partager les ressources qui lui
conviennent au moment qui lui convient et peuvent effectuer et recevoir des connexions pour
des services quelconques. Dans ce modèle, les communications ne sont plus orientées vers un
seul point unique, elles sont réparties sur tous les clients. Par conséquent, tous les clients
peuvent effectuer des connexions vers d’autres clients et tous les clients peuvent recevoir des
connexions de tous les clients. Dans ce modèle, il est donc impossible de prédire quel services
ou protocoles seront utilisés ou offerts par les clients. Par conséquent, il est donc difficile de
dé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éfinissent
un nouveau paradigme pour les réseaux en prônant l’utilisation d’une architecture de réseau
de 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 section
3. 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 leurs
réseaux. Aﬁn de mieux comprendre la problématique engendrée par l’emploi d’un réseau de
type poste à poste où des dispositifs de sécurité sont présents, la problématique de SIP sera
étudiée dans la section 4.
Aﬁn de permettre l’utilisation des nouveaux services, il faut donc créer un mécanisme de
gestion de traversée des éléments de sécurité d’un réseau (i.e. pare-feu routeur NAT) pour
permettre 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, des
leurres et des systèmes de détection d’intrusion. Dans le cas de la problématique engendrée
par 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 la
problé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ées
autorisées.
Un pare-feu est un dispositif informatique qui permet le passage sélectif des flux d’information
entre deux réseaux, ainsi que la neutralisation des tentatives de pénétration en provenance
du réseau public.[4] En effet, les pare-feu sont généralement des dispositifs déployés au niveau
des périphériques ou logiciels et utilisent des politiques de filtrage qui empêchent tous les
paquets 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 connections
aux 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 des
réseaux où l’on veut limiter l’accès au réseau interne du réseau public ou partager une
connexion Internet en utilisant une seule adresse IP publique. Par conséquent, du réseau
public, seul le routeur est visible et toutes les requêtes semblent provenir du routeur. Les
postes de travail situés dans le réseau interne ne sont pas visibles et donc protégés contre
des 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 NAT
pour ensuite l’acheminer sur le réseau public. Lorsque le routeur NAT reçoit une réponse
du réseau public à une requête, il détermine à quel poste la réponse est destinée et modifie
l’entête de celui-ci en remplaçant l’adresse de destination par l’adresse IP privé du poste
auquel 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ève
description des caractéristiques de divers routeurs NAT tel que décrit par Takeda[16] et
Cordell[2].
Cône plein La technique utilisant le cône plein est une technique très simple. À chaque
nouvelle demande de connexion vers le réseau public, le routeur NAT va remplacer l’adresse
d’origine et le numéro de port du paquet par celle du routeur NAT. Lorsque le routeur NAT
reçoit des paquets, une simple vérification afin de savoir si celui-ci est destiné au poste qui
a ouvert la communications est effectuée. Aucune vérification sur l’origine du paquet n’est
effectuée. Le poste ayant envoyé des paquets destinés au réseau public peut donc recevoir
des 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 restrictive
sur les paquets que celle utilisée dans le cas d’un cône plein. Dans le cas d’une connexion
sortante, le même mécanisme que dans le cas d’un cône plein est utilisé. La seule différence
entre cette technique et celle du cône plein est que seuls les paquets provenant des postes
adressés dans le réseau public par les connexions sortantes vont être acceptées. Aucune
vérification sur les ports n’est effectuée.
Cône restrictif sur les ports La technique utilisant le cône restrictif sur les ports est
une légère variante de la technique utilisée dans les cônes restrictifs. Les cônes restrictifs
permettent des connexions entrantes sur tous les ports dans l’éventualité où un port du
poste 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 au
pré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, à chaque
demande 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 connexions
entrantes, 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-dessus
sont déployés dans les réseaux ayant diverses topologies. Afin de fournir les connaissances
de base sur le déploiement et l’utilisation de ces dispositifs, ces topologies vont être décrites
dans 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 du
ré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 interne
est indépendant et isolé du réseau public (voir figure 7). Il y a donc aucune communication
entre 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 les
communications autorisées vont être permises entre les deux réseaux.
Intranet
1
Routeur NAT
Pare-feu
Routeur NAT
Pare-feu
Intranet
2
Internet
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 raisons
d’ordre économique, de sécurité ou de manque d’adresse IP publique, les réseaux privés sont
parfois disposés en chaîne tel qu’illustré dans la figure 9. Dans ce cas, les postes du premier
réseau privé sont en mesure d’accéder aux postes du deuxième réseau privé, mais l’inverse
est prohibé. Les postes dans le premier et deuxième réseau interne sont en mesure d’accéder
aux 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. Cette
zone intermédiaire sert à déployer des serveurs afin d’offrir des services qui sont partagés au
niveau du réseau privé et public. Elle est protégée par des dispositifs de sécurité qui peuvent
avoir 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 à poste
et client/serveur. Il est présentement l’un des protocoles les plus prometteurs afin d’offrir les
nouveaux services en émergence par son mécanisme de localisation des utilisateurs et son
extensibilité.
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 de
localiser l’usager. Par exemple, un usager (caroline@gel.usherb.ca) s’enregistre à un serveur
SIP en effectuant une requête. Celui-ci va être en mesure de déterminer l’adresse du poste
où l’utilisateur se situe (poste.gel.usherb.ca). La localisation de l’usager étant connue (caro-
line@poste.gel.usherb.ca), différentes sessions offrant divers services pourront être ouvertes
avec cet usager. En effet, SIP permet à un usager (caroline@gel.usherb.ca), indépendamment
de sa localisation d’être accessible (dans ce cas, à l’adresse caroline@poste.gel.usherb.ca) dans
un réseau.
SIP est un protocole qui a la caractéristique d’être extensible. Cette extensibilité lui permet
de 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 nouveaux
services 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 cette
conversation, 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édias
entre usagers distants.
4.1 Architecture de SIP
L’architecture de SIP comporte deux entités principales : les agents SIP et les serveurs
SIP. Ces entités interagissent entres elles afin de localiser un usager au sein d’un réseau et
permettre 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 ou
encore 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 agents
utilisateurs (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’une
session, une requête est effectuée du UA client au UA serveur (voir figure 11). Une session
poste à 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 et
serveur d’enregistrement. Ces trois types de serveur effectuent diverses tâches au sein d’un
ré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ément
qui transfère les requêtes SIP à un agent utilisateur serveur et les réponses SIP à un agent
utilisateur client (voir figure 12). Une requête peut traverser quelques serveurs Proxy SIP afin
d’ê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 au
prochain élément. Les réponses vont être réacheminer au travers des divers éléments suivant
le chemin inverse de la requête.
Figure 13 – Établissement d’une session SIP avec l’utilisation d’un serveur de redirection
SIP.
Serveur de redirection SIP Un serveur de redirection est un serveur qui transfère vers
le client l’information concernant le routage de la requête (voir figure 13) afin que celui-ci
effectue les requêtes sans passer par le serveur. En faisant de sorte, le serveur n’est plus
impliqué 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 dans
la 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 des
dispositifs de sécurité
SIP, par son fonctionnement interne qui permet la localisation des utilisateurs au sein d’un
réseau et l’extensibilité d’échanges de divers contenus multimédia, ne fonctionne pas dans
l’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 messages
SIP. 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 redirection
SIP.
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 caroline@gel.usherb.ca
invite l’utilisateur melanie@poste.home.com afin de discuter de leur fin de semaine. Caroline
envoit donc une requête d’invitation INVITE (voire tableau 1) contenant des informations
concernant 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émentaires
sur la session à ouvrir. Comme on peut le constater, l’adresse ainsi que le port à utiliser lors
de 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 :melanie@poste.home.com 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 :caroline@gel.usherb.ca> Utilisateur appelant.
To : Mélanie <sip :melanie@poste.home.com> Utilisateur appelé.
Call-ID : 3948204395@gel.usherb.ca 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 et
le 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 connection
M=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 :caroline@gel.usherb.ca> Copie de la requête.
To : Mélanie <sip :mela-
nie@poste.home.com> ;tag=14523
Copie de la requête. Incluant une étiquette conte-
nant un identifiant unique.
Call-ID : 3948204395@gel.usherb.ca 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 et
le 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 que
ceux-ci sont généralement déployés en utilisant des politiques de filtrage qui empêchent tous
les paquets qui ne proviennent pas ou qui ne sont pas destinés à une adresse IP et un port
défini. Ces politiques, qui sont généralement statiques, ne permettent pas la traversée d’un
flux de données à des protocoles comme SIP qui négocient de façon dynamique l’adresse IP
et 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 des
pare-feu, l’analyse du contenu des messages SIP est nécessaire. En effet, comme on peut
le constater dans l’exemple d’établissement de session énoncé dans la section 4.2, le port
utilisé par le protocole de communication afin d’établir un lien audio est déterminé de façon
dynamique 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 le
constater, 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 étant
donné que ceux-ci ont généralement des règles de filtrage strictes et statiques. Le contenu
multimé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 du
fait que ceux-ci effectuent une translation d’adresse afin d’acheminer les paquets du réseau
privé au réseau public. Lors de cette translation, l’adresse et le port utilisés changent selon le
type de routeurs NAT (voir section 3.3). Étant donné que les routeurs NAT sont seulement
en mesure de changer l’entête des paquets de type IP, les informations concernant l’adresse
et le port d’origine contenus dans les requêtes SIP ne sont pas modifiés. L’utilisation du
protocole 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 comprendre
cette 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 la
requête appartenant à un réseau privé n’est pas accessible par les postes situés dans le réseau
public. Par conséquent, dans notre exemple, Mélanie ne pourra établir de communication
avec 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 le
numéro de port contenus dans l’entête sont modifiés. L’adresse et le numéro de port contenus
dans le corps de la requête sont laissés intactes. Comme on peut le constater dans l’exemple
d’établissement de session énoncé dans la section 4.2, le port et l’adresse de l’origine de la
requête sont contenus dans le corps de la requête INVITE (voir tableau 1). Ce port et cette
adresse est cependant non-valide pour Mélanie. Caroline pourra donc effectuer l’appel et
envoyer 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 être
contacté. En effet, du réseau public, aucun poste du réseau privé n’est visible. Il est donc
impossible d’initier une session avec un poste se situant dans le réseau privé à partir du
ré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 de
type UDP dans un réseau sécurisé par des pare-feu et des routeurs NAT, plusieurs solutions
ont été proposées. Celles-ci peuvent être regroupées en deux catégories : les solutions utilisant
un relais et les solutions utilisant une communication directe afin de traverser les pare-feu et
les routeurs NAT.
5.1 Utilisation d’un relais permettant la traversée des pare-feu et
des routeurs NAT
Les solutions présentées ci-dessous sont des solutions utilisant un dispositif de relais afin
d’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 à une
communication poste à poste.
La technique utilisant des serveurs d’application est une technique qui consiste à déployer
dans 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. Ces
serveurs effectue un relais entre des postes désirant communiquer ensemble. Cette solution
réside cependant en une solution propriétaire qui cible des protocoles et des produits bien
précis. Par exemple, dans le cas de SIP, un serveur d’application SIP est un serveur Proxy
SIP ou un serveur de redirection SIP[12] qui est localisé dans un réseau interne ou encore
dans le réseau démilitarisé et qui effectue la tâche de relais entre un poste dans le domaine
privé et un poste dans un domaine public. L’utilisation de cette technique permet la traversée
de tous les dispositifs de sécurité ainsi que toutes les topologies comme on peut le constater
dans 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 à une
communication 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écessite
le déploiement et la maintenance d’un serveur. Deuxièmement, l’utilisation d’un serveur
d’application réside en une solution propriétaire et spéciﬁque à un protocole en particulier. En
consé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 diversiﬁer et à prendre de l’expansion.
Finalement, étant donné que cette solution réside en un relais, le temps le latence est donc
accrue 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 serveur
d’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 serveur
d’application dans un réseau public ou démilitarisé qui sera combiné avec l’utilisation d’un
agent 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 tunnel
entre un poste et le serveur d’application. Les communications entre l’agent et le serveur
s’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 un
serveur de relais à des clients n’ayant pas ou peu de contrôle sur les éléments et les topologies
du réseau.
Comme on peut le remarquer dans les tableaux 5 et 6, la solution utilisant un serveur
d’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ées
sont 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 serveurs
d’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 offrant
le 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 serveur
d’application avec l’utilisation d’un agent.
Les désavantages de cette technique sont semblables aux désavantages reliés aux serveurs
d’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’une
telle solution, elle est accrue étant donné que le nombre de dispositifs nécessaires au sein
du 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 de
dispositifs.
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 Layer
Gateways » - ALG) est une technique qui consiste à rendre « intelligent » les pare-feu et les
routeurs NAT afin qu’ils soient en mesure d’interpréter un protocole spécifique. Plutôt que
de simplement déterminer l’action à effectuer à l’aide de l’entête d’un paquet, les passerelles
vont faire une inspection complète des données dans le corps du paquet[13]. Elles agissent
donc en tant que relais spécialisés pour un protocole précis et traitant les données au niveau
application 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’application
puisque le traitement est effectué dans les pare-feu ou les routeurs NAT dans le cas de
la 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 routeurs
NAT 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’acheminer
des paquets vers un réseau public, la passerelle va lire le contenu complet du paquet afin de
modifier l’adresse IP et le port d’origine dans le paquet pour le rendre valide dans le réseau
public. Ensuite, la passerelle sera en mesure d’ouvrir un trou d’épingle afin de laisser ces
paquets circuler librement. Dans le cas des pare-feu et des routeurs NAT normaux, ceux-ci
inspectent 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 la
passerelle de la couche application, tous les dispositifs et les topologies peuvent être traversés
par 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 passerelle
de couche application.
Les passerelles de la couche application ont donc l’avantage indéniable d’être une technique
simple et très sécuritaire. En effet, celles-ci augmentent la sécurité du réseau en examinant
toutes 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 et
routeurs 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 services
sont offerts. Troisièmement, comme mentionné dans le RFC2663[15] les passerelles de couche
application 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 le
temps de latence étant donné que chaque paquet est traité et inspecté individuellement par
la 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 en
voie de standardisation en tant que serveurs de relais[6]. Ce protocole permet à des clients
qui sont dans des réseaux utilisant des routeurs NAT ou encore des pare-feu d’effectuer des
connexions entre eux en passant par un serveur de relais. Cette technique se distingue des
techniques des serveurs d’application (voir section 5.1.1), des serveurs d’application avec
agent (voir section 5.1.2) et des passerelles de la couche application (voir section 5.1.3) par
son 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 protocole
de communication utilisé. Son fonctionnement est basé sur l’utilisation d’un serveur TURN
situé dans un réseau accessible par les postes désirant communiquer ensemble. Ce serveur
servira de relais aux diverses communications entres les deux postes. L’utilisation de cette
technique solutionne le paradigme créée par les nouveaux services comme on peut le voir
dans 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 est
une technique simple à comprendre et à déployer. Deuxièmement, cette technique ne requiert
aucune 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 standardisation
offre 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 en
tant que relais, une modification des programmes est nécessaire afin que ceux-ci intègre le
protocole TURN. Finalement, étant donné que cette solution réside en un relais entre les
postes, 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 des
routeurs NAT consiste à modifier les protocoles de communication ou les éléments réseaux
afin de permettre une communication poste à poste sans l’utilisation d’un relais, tout en
permettant la traversée des protocoles de communication au travers des pare-feu et des
routeurs 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. Une
communication 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 existants
tels que PPTP, L2TP et IPSec. La fonction du RPV est de mettre les postes autorisés sur
un 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 de
communiquer 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 des
sessions poste à poste au travers de tous les dispositifs de sécurité tels que des pare-feu et
des 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, cette
technique consiste à utiliser des protocoles existants et largement utilisés afin de permettre
une communication virtuellement directe entre deux postes. Deuxièmement, cette technique
ne nécessite aucune modification tant au niveau des éléments réseaux que des applications
utilisées. Finalement, cette solution peut être facilement déployée pour une compagnie ayant
des 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 Home
Office), 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és
pour 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ériques
d’un réseau de se configurer automatiquement, d’offrir des services de façon dynamique et
transparente. Dans notre problématique, ceci signifie que les pare-feu ainsi que les routeurs
NAT sont détectés par les postes de travail de façon automatique et que ces postes sont en
mesure d’ouvrir, au besoin, des trous d’épingle sur les routeurs NAT et les pare-feu de façon
dynamique.
Comme on peut le constater dans les tableaux 13 et 14, les périphériques UPnP peuvent être
traversés par tous les protocoles dans toutes les topologies sauf dans le cas des chaînes de
pare-feu ou de routeurs NAT. En effet, les communications entre dispositifs UPnP s’effectuent
seulement entre deux dispositifs au sein d’un même sous réseau. Les chaînes de pare-feu et
de routeurs NAT n’étant pas dans le même sous réseau, les dispositifs ne peuvent donc pas
communiquer 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 en
permettant une interaction de façon transparente afin de permettre la traversée des protocoles
de communication au travers des pare-feu et des routeurs NAT. Deuxièmement, UPnP est
un standard existant et déployé dans les réseaux SOHO. Finalement, plusieurs périphériques
UPnP 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-feu
et 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 et
les 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 routeur
NAT et rendre un réseau vulnérable. Cette solution ne peut donc pas être utilisée dans des
ré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 travers
d’un trou d’épingle dynamiquement créé. Il diffère de la technique des passerelles de la
couche application (voir section 5.1.3) étant donné que Midcom n’est pas lié à un protocole
de communication. En effet, Midcom ne va pas décortiquer les protocoles de communication
jusqu’au niveau application comme le fait les passerelles. Midcom se contente d’ouvrir un
trou d’épingle dans les pare-feu ou les routeurs NAT suite à une authentification et une
validation des autorisations de l’usager. Midcom diffère de UPnP en comblant les lacunes de
celui-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-feu
et 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 de
routeurs 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 solution
est une solution en voie de standardisation. Deuxièmement, n’étant pas liée à un protocole
de 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 pour
effectuer un trous d’épingle au travers des dispositifs de sécurités.
Midcom comporte cependant aussi quelques désavantages. Premièrement, étant donné que
cette 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 les
différents réseaux. Troisièmement, les différents protocoles de communication ou serveur
doivent ê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 les
caractéristiques de dispositifs de sécurité par des requêtes au serveur STUN.
« Simple Traversal of UDP Through Network Address Translators » (STUN) est un protocole
simple é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 les
capacités d’un poste à effectuer une communication de type UDP avec un réseau public. Il
détermine l’adresse IP et le port public utilisés par un poste situé dans un réseau privé. Pour
ce faire, une série de requêtes à un serveur STUN est effectuée et les réponses provenant de
celui-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 utilisant
cette technique. Le cas des pare-feu ne peut être traité étant donné que les paquets sont
filtrés systématiquement par le pare-feu. En conséquent, il est donc impossible d’effectuer
l’ouverture d’une session. En ce qui concerne les routeurs NAT de type symétrique, il est
impossible de caractériser ce type de routeurs afin de prédire son comportement au moment
de 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 par
STUN sont utilisés dans celles-ci. Il reste cependant la problématique créée par les chaînes
de 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 et
le 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êtes
afin 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 aucune
modification 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 les
réponses pour caractériser la communication peuvent être interprétées comme une attaque
par les dispositifs de sécurité. Troisièmement, elle ne permet pas la traversée de tous les
pare-feu et les routeurs NAT. Quatrièmement, cette technique ne peut être déployée dans
des 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 de
déterminer l’adresse à utiliser correctement lors de communication à l’intérieur d’un réseau
interne 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 STUN
et 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éseau
public 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ù aucune
communication directe est possible entre deux postes, ICE utilisera les services d’un serveur
TURN afin de permettre cette communication.
Comme on peut le constater dans les tableaux 19 et 20, ICE permet la traversée de tous les
dispositifs et de toutes les topologies sauf dans l’éventualité où des pare-feu sont utilisés. ICE
ne permet pas cette traversée étant donné que les pare-feu sont des dispositifs qui filtrent les
paquets selon des règles statiques. ICE est en mesure de caractériser et d’identifier ces règles
sur 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 STUN
et 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 le
cas où des pare-feu sont utilisés. Deuxièmement, elle ne nécessite aucune modification dans
les dispositifs de sécurité présents sur un réseau. Finalement, elle nécessite seulement le
déploiement d’un serveur combiné STUN/TURN dans un réseau.
ICE comporte aussi quelques désavantages. Premièrement, étant donné que cette technique
consiste à caractériser toutes les communications possible entre un poste et un réseau public
et 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 à un
poste situé dans un réseau privé. Troisièmement, cette technique force un serveur à utiliser
quelques ports seulement pour les diverses transmissions de média. Quatrièmement, il faut
avoir 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éployer
ICE. 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 et
des routeurs NAT a été solutionné en utilisant plusieurs techniques qui sont résumées dans
le tableau 21. Comme on peut le constater, les approches utilisant un serveur de relais ont
quelques désavantages en commun. Premièrement, ces approches augmentent le temps de
latence du réseau. Deuxièmement, étant donné que toutes les données doivent transiger par
le 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 elles
permettent une expansion plus facile des réseaux en n’étant pas liées à un protocole de
communication. En contrepartie, ces techniques nécessitent généralement une modification
des 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 pas
un relais, elle n’a donc pas les désavantages liés aux relais. Comparativement au tunnel
de données, elle demande un niveau de maintenance et d’opération moindre. En effet, afin
d’utiliser la technique du tunnel de données, l’utilisateur doit créer celui-ci avant d’établir une
communication. 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 authentification
et une validation est nécessaire. Comparativement à STUN, Midcom permet la traversée
de 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 qui
peuvent nuire à son adoption future en tant que standard. Premièrement, cette solution
est encore à l’étape d’élaboration. Deuxièmement, cette solution exige une modification des
applications, serveurs, pare-feu et des routeurs NAT au sein des réseau. Finalement, cette
solution 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 et
utilisée.
• Aucune modification des éléments ré-
seaux, des applications ou des protocoles
de 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
utilisée.
• Aucune modification nécessaire des élé-
ments réseaux, des applications ou des
protocoles 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.
Passerelle de la couche application
utilisé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.
TURN
• Technique simple.
seaux nécessaire.
• Serveur de relais en cours de standardi-
sation.
• Fonctionne avec tous les protocoles de
communication.
• Technique peu utilisée et déployée.
• Modifications des applications néces-
saires.
Tunnel de données (RPV)
• Technique simple à comprendre.
seaux et des applications.
• Peut être facilement déployée en per-
manence dans un réseau multisite d’une
compagnie.
• Établissement d’un RPV nécessaire
avant 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éseaux
SOHO.
• Plusieurs périphériques disponibles sur
le 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înes
de pare-feu ou de routeurs NAT
STUN
• Technique standardisée.
• Peu d’infrastructure nécessaire.
seaux nécessaire.
• Caractérisation parfois interprétée
comme une attaque au sein d’un réseau.
• Modifications des applications/serveurs
nécessaires.
• Ne permet pas la traversée des routeurs
NAT de type symétrique.
• Ne permet pas de déterminer l’adresse à
utiliser correctement dans les chaînes ou
les appels dans le même domaine.
ICE
• Combine des techniques déjà utilisées.
• Peu d’infrastructure nécessaire.
seaux nécessaire.
• Caractérisation parfois interprétée
comme 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/serveurs
nécessaires.
Tableau 21 – Tableau récapitulatif des différentes techniques permettant la traversée des
pare-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 nouveau
paradigme au sein du réseau actuel. En effet, les protocoles de communication, tel que SIP, ne
peuvent ê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 tous
les protocoles de communication, sa latence réduite comparée aux solutions utilisant un relais
et son utilisation possible dans des réseaux en pleine expansion. Cette solution comporte
trois lacunes majeures telles que mentionnées précédemment. Premièrement, cette solution
est encore à l’étape d’élaboration. Deuxièmement, cette solution implique la modification
des différents pare-feu et des routeurs NAT au sein des réseau. Finalement, cette solution ne
pré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 de
permettre la traversée des chaînes de pare-feu et de routeurs NAT. Ainsi, toutes les topologies
ainsi 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 ensuite
permettre 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. Pour
ce faire, une intégration des diverses techniques de découverte de topologies et de dispositifs
existant devra être effectuée.
Dans une deuxième étape, une architecture d’un système devra être mis en oeuvre afin
de permettre une communication entre les différents dispositifs Midcom se situant dans la
chaîne. Pour ce faire, un arbre décisionnel et des scénarios devront être développés afin de
hié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înes
de pare-feu ou de routeurs NAT contenant des dispositifs Midcom et non-Midcom. Ceci
permettra de développer une base de connaissance afin de permettre aux différents protocoles
de communication de traverser de telles topologies.
Suite à ces étapes, les différents protocoles de communication devront être en mesure de
traverser les chaînes de pare-feu et de routeurs NAT Midcom. Midcom sera alors une solution
polyvalente, 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 du
problè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 2003
Cette é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érents
protocoles 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, elle
permettra de cibler les lacunes de cette technique pour ensuite proposer de traiter cette
problématique.
Spécification d’un design préliminaire permettant à SIP de traverser une chaîne
de pare-feu et de routeurs NAT dans les divers scénarios.
1er octobre au 5 Janvier 2004
Cette é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 routeurs
NAT 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 des
pare-feu et des routeurs NAT.
6 janvier 2004 au 30 avril 2004
Suivant la proposition de l’extension de Midcom, une implémentation réelle sera effectuée afin
de valider celle-ci. Lors de cette étape, une intégration de Midcom incluant l’extension sera
effectuée dans tous les dispositifs nécessaires tels que les pare-feu, routeurs NAT, serveurs
SIP et applications SIP.
Évaluation expérimentale de la solution de la traversée du protocole SIP au
travers des pare-feu et des routeurs NAT.
1er Mai au 30 Août 2004
Cette étape permettra de valider l’extension de Midcom en permettant de caractériser le
comportement 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 usager
autorisé à effectuer des opérations.
ALG - (Application Layer Gateway) Passerelle de la couche application
L2TP - (Layer 2 Tunneling Protocol) Protocole de communication permettant la création
d’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ées
transmises entre un réseau privé et un réseau public.
PPTP - (Point-to-point Tunnuling protocol Protocole de communication permettant la
cré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 et
qui 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 dynamique
afin 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’infrastructure
et des services de télécommunications de pointe. Conseil de la radiodiffusion et de
té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 Network
Address 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. White
paper, 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.

Cours reseau ouya

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (16)

En vedette

En vedette (20)

Similaire à Cours reseau ouya

Similaire à Cours reseau ouya (20)

Cours reseau ouya