firewalls applicatifs aux - wapiti.telecom-lille.fr · en 1997, l'ietf conçoit un système de...

FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA

Claire VIGODA

Romain LAHOCHE

Coordonnée par Ahmed MEDDAHI

25 septembre 2004

FI2005

FIREWALLS applicatifs aux

protocoles multimédias

30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 1/20


SOMMAIRE

LES PROTOCOLES MULTIMEDIA ................................................................................................................................................................ 3 1. POURQUOI DES PROTOCOLES MULTIMEDIA ............................................................................................................................................. 3

1.1. Les exigences du transfert de la voix .............................................................................................................................................. 3 1.2. Les limites du réseau IP ................................................................................................................................................................. 3 1.3. Le besoin en QoS ............................................................................................................................................................................. 3

2. LES STRUCTURES DE NORMALISATION .................................................................................................................................................... 4 2.1. Historique des normes..................................................................................................................................................................... 5 2.2. La norme H323................................................................................................................................................................................ 5 2.3. La norme SIP ................................................................................................................................................................................... 5 2.4. Les normes MGCP et MEGACO................................................................................................................................................... 6

LES FIREWALLS APPLICATIFS..................................................................................................................................................................... 6 1. LIMITES DES FIREWALL ET NAT.............................................................................................................................................................. 6

1.1. Firewall............................................................................................................................................................................................ 6 1.2. Nat.................................................................................................................................................................................................... 7 1.3. Protocoles et ports utilisés par H323, SIP et MGCP ................................................................................................................... 10

2. 1ERE SOLUTION : LES RELAIS ................................................................................................................................................................... 11 2.1. Serveur d’application .................................................................................................................................................................... 12 2.2. 2.2.2. Serveur d’application avec agent : ..................................................................................................................................... 13 2.3. 2.2.3. Passerelle de la couche d’application (ALG) :................................................................................................................... 14 2.4. 2.2.4 Traversal Using Relay NAT (TURN) ................................................................................................................................... 15

3. 2EME SOLUTION : LA COMMUNICATION DIRECTE .................................................................................................................................... 16 3.1. Tunnel de données ......................................................................................................................................................................... 16 3.2. Universal Plug and Play (UPnP).................................................................................................................................................. 16 3.3. Midcom .......................................................................................................................................................................................... 17 3.4. Simple Traversal of UDP Through Network Address Translation devices (STUN) ........................................................ 17 3.5. Interactive Connectivity Establishment(ICE).......................................................................................................................... 18

4. CONCLUSION PROTOCOLAIRE ................................................................................................................................................................ 18 4.1. Avantages des solutions de communication directes .................................................................................................................... 18 4.2. Avantages de la solution Midcom ................................................................................................................................................. 19

L’ETAT DE L’ART ............................................................................................................................................................................................ 19

REFERENCES..................................................................................................................................................................................................... 19



Ce document est une base pour la compréhension des problèmes que rencontrent les protocoles multimédias face aux

réseaux IP d'aujourd’hui.

Ce document présente les difficultés que doivent affronter les flux multimédias : H.323, Media Gateway Control Protocol

(MGCP), Session Initiation Protocol (SIP), Real-Time Transport Protocol (RTP) and RTP Control Protocol (RTCP) pour

traverser les firewalls et les autres processus de sécurité des réseaux tels que les Network Adress Translation (NAT's).

Les Protocoles multimédia

1. Pourquoi des protocoles multimédia 1.1. Les exigences du transfert de la voix

Une conversation entre deux personnes respecte deux principes : intelligibilité et interactivité. L’interactivité, assurée par le fait

que deux interlocuteurs peuvent parler en même temps, est assuré par une conversation full duplex.

Au niveau téléphonique, cette interactivité implique des notions de délais. Les mesures effectuées montrent qu’un temps de

transit de la voix inférieur à 150 ms garantit un dialogue actif. Tant qu’on ne dépasse pas 400 ms le dialogue reste tout de

même assez réactif. Au-delà de cette limite l’interlocuteur aura l’impression de parler dans le vide.

Une communication téléphonique, en plus d’assurer le transport de la voix, doit prendre en compte l’établissement et la rupture

de la communication. Ces fonctions sont assurées en téléphonie traditionnelle par des « signaux de service » : « signalling

flows » que s’échangent les postes téléphoniques et les différents centraux traversés par la communication.

1.2. Les limites du réseau IP

Le réseau IP est un ensemble de réseaux interconnectés qui achemine les données par commutation de paquets en mode non

connecté. En d’autres termes aucun chemin n’est alloué pour transférer les paquets de données jusqu’à leur destinataire.

Bien qu’il s’agit d’un protocole simple, ce protocole ne met pas en œuvre de contrôle d’erreur. Le transfert de données sur

Internet suit la politique du « best effort ». En d’autres termes lorsque deux machines sont en relation, le contrôle des données

se fait uniquement par le récepteur. Si on admet que la donnée reçue est mauvaise alors il faut retransmettre cette information.

Enfin, le protocole IP est d’autant plus simple qu’il ne met pas en oeuvre de Qualité de Services (QoS). Bien que chaque paquet

possède un champ « type de services », ce champ est encore peu utilisé par les routeurs durant la transmission.

Le réseau IP est donc un réseau asynchrone, c’est-à-dire qui transmet un paquet émis vers son récepteur sans aucune

contrainte. Les termes : délai, variation de délai, priorité, temps réel lui sont inconnus.

1.3. Le besoin en QoS

Afin de bien percevoir les difficultés associées au transport de la voix sur IP, le schéma ci-dessous présente un comparatif entre

la commutation de circuits des télécoms qui utilise X25 et la commutation de paquets d’IP : Transmission sur réseau IP et sur

réseau X25



Figure 1 : Différence réseau IP et réseau X25

Les approches IP et télécoms sont pratiquement opposées. Où IP est simple et débrouillard, les télécoms sont complexes

et figés. Les deux principales causes des limites associées à la VoIP (Voice Over IP) restent :

• Le Délai : par l’absence de QoS, quantifier le délai sur le réseau de manière fiable est quasi impossible, car il y a trop

d'inconnues : table de routage, congestion, files d'attente… Cependant le temps de transmission d'un paquet doit

rester inférieur à 400 ms pour respecter les contraintes d'une conversation interactive.

• Les Pertes : par l’absence de contrôle d’erreur, la disparition de paquets au cours de la communication fait partie de

la transmission IP. Suivant le nombre de paquets perdus, la qualité sonore en bout de ligne peut s'en ressentir.

Toutes ces défauts liés à IP sont les fondements des difficultés rencontrées par le concept VoIP :

Figure 2 : Difficulté d’une transmission sous IP

Pour pallier au problème d’absence de QoS sur IP il faut à la fois bien dimensionner les caractéristiques de bande passante

mais aussi améliorer le transfert. Ceci est réalisable grâce à des protocoles qui permettent d'obtenir une QoS plus favorable. Les différents protocoles utilisés sont détaillés ci-dessous :

2. Les structures de normalisation Les services multimédias temps réel sur IP sont gérés par des protocoles de signalisation. On entend par signalisation

l'ensemble des informations échangées par les terminaux, les passerelles et tous les éléments assurant l'établissement, le

contrôle et la rupture d'une connexion temps réel. Ces informations sont élaborées sur la couche Application et doivent être

définies par des procédures communes entre les différents fournisseurs de produits.

Les organismes participant aux travaux de signalisation sont : l'ITU (Union Internationale des Télécommunications), l'IETF, les

consortiums industriels et les opérateurs de télécommunication.



2.1. Historique des normes En 1996, une trentaine de logiciels de téléphonie ou visioconférence sur IP existaient. Chacun ayant une signalisation

propriétaire, les applications n'étaient évidemment pas compatibles entre elles.

Milieu 1996, Microsoft lance le logiciel de visioconférence : Netmeeting. Cependant, Netscape le concurrent du moment impose

le logiciel CoolTalk comme fédérateur des logiciels de téléphonie sur IP : les deux technologies étant bien entendu

incompatibles. Pour riposter, Microsoft décide de s’orienter vers une standardisation des protocoles de signalisation et s'investit

donc dans les groupes travail de standardisation ITU et IETF. C’est ainsi que le standard de signalisation H.323 est créé.

En 1997, l'IETF conçoit un système de signalisation SIP (Session Initiation Protocol) adapté à la philosophie IP, contrairement à

H.323 qui s'inspire des circuits télécoms.

2.2. La norme H323

2.2.1. Le standard

La norme, recommandation de l’ITU, propose des bases pour le transport de la voix, de la vidéo et des données sur des

réseaux IP. H.323 est issue de la norme H.320 (visiophonie sur RNIS), et répond aux problèmes liés à IP (pas de garantie de

délais). H.323 fonctionne en mode non connecté et sans garantie de QoS selon une stratégie bout à bout qui lui confère une

transparence vis-à-vis des évolutions du réseau. H323 s’appuie sur des protocoles de communication (RTP, RTCP, …), mais

également sur des codecs audio (G.711,G723.1, G.728,…) et des codecs vidéo (H.261 et H.263).

2.2.2. Les fonctions offertes

Les composants majeurs qui interagissent avec un réseau IP sont les suivants : la gateway, le gatekeeper, les MCU (Multi

Control Unit) et les terminaux classiques et IP.

Les fonctions dédiées à H.323 sont les suivantes :

• Contrôle de la procédure d'appel : requête, établissement et suivi de l'appel.

• Gestion des flux multimédias : liste de codecs recommandés ou obligatoires.

• Gestion des conférences multipoint : modèle de conférence géré par une entité centrale.

• Gestion de la bande passante : le gatekeeper devient un centre de contrôle et a les moyens de limiter les

connexions et d'allouer la bande passante disponible.

• Interconnexion à d'autres réseaux : ATM, RNIS, RTC.

2.2.3. Les interactions avec les autres protocoles

La signalisation qu’elle nécessite se fait avec d’autres protocoles tel que : le protocole RAS qui gère l’admission et l’état des

communications, le protocole Q.931 qui gère les appels et le raccrochage déjà en place sur le réseau RNIS et, le protocole H.245 qui gère l’utilisation des canaux et de leur capacités.

2.3. La norme SIP

2.3.1. Le standard

SIP (Session Initiation Protocol) est un protocole d'ouverture de session destiné à être utilisé sur des PABX-IP, des intranets, …

pour devenir le standard des communications unifiées (voix, vidéo et e-mail) en temps réel dans le monde IP.

SIP est un protocole sorti directement de l’Internet contrairement à H.323 issu de la téléphonie et de l’UIT. Il a été spécifié par

l'IETF et a été conçu pour favoriser la tenue de téléconférences multimédias sur Internet. En d’autres termes, SIP est un

protocole de signalisation de niveau applicatif qui établit, modifie et termine des sessions multimédias interactives sur IP entre

des terminaux.



2.3.2. Des fonctionnalités offertes

Le protocole client-serveur de type textuel permet d’être utilisé par des localisateurs universels de ressources (URL) pour

l'adressage, comme l’est HTTP. Cette origine facilite son intégration aux réseaux IP d'entreprise et permet d’activer quelques

services tels que la réponse vocale interactive Web : une page Web s'affiche pour compléter le message vocal.

2.3.3. Des fonctionnalités manquées

Bien que lancé avec une offensive marketing forte et armé d’un socle de fonctionnalités porteuses de nouveaux services

réseaux, le protocole SIP n'a pas percé dans la téléphonie IP, face à H.323.

En d’autres termes, SIP ne prend pas encore en compte de nombreux services actuellement utilisés dans les réseaux

téléphoniques pour pouvoir remplacer le protocole H.323. Il ne gère encore la récupération des données de taxation du réseau

téléphonique public commuté, ou les touches DTMF utilisées par les services vocaux interactifs (touches * ou #).

2.3.4. Un espoir

Cependant, sous réserve de séduire les industriels, de bousculer H.323, et d'être enrichi de fonctionnalités encore manquantes,

SIP pourrait être à l'origine d'une profonde évolution des services téléphoniques, mettant à profit tout le potentiel des

technologies de l'Internet : On pense déjà à la combinaison de la voix avec des services IP, telle la téléconférence sur le web.

(Un tel outil qui associerait des outils de gestion Web, des participants et des partages d’applications).

2.4. Les normes MGCP et MEGACO

MGCP (Media Gateway Control Protocol), contrairement à H.323 qui couvre toutes les couches supérieures à IP, se contente

d'assurer un service fiable et rapide au niveau des couches 3 et 4.

Cependant, pour faire converger ce protocole avec un projet de norme équivalente commune à UIT-T et IETF, MEGACO a été

adopté et n’est qu’une évolution MGCP. Son protocole définit les échanges entre passerelle et MGC (Media Gateway

Controler) pour proposer des services indépendants de la passerelle utilisée et de son contrôleur.

Cette approche a permis la construction de terminaux simples et bons marché : on la retrouve aujourd’hui dans la Freebox, offre

proposée par le fournisseur d’accès Internet Free dans les zones dégroupées. Outre ses fonctions locales (modem, routeur, set

top box, …) elle inclut une simple passerelle entre le poste téléphonique et le réseau Internet localisant l’intelligence dans le

réseau.

Les Firewalls applicatifs

1. Limites des firewall et NAT 1.1. Firewall

1.1.1. Définition

Avec la croissance rapide de l’Internet, la sécurité des réseaux est un souci important. Quand on relie un réseau privé à

l'Internet, on relie physiquement ce réseau à une quantité d’autres réseaux inconnus. Bien que cela permet de partager

beaucoup d’informations, la plupart des réseaux privés contiennent des informations qui ne devraient pas être partagées avec

les utilisateurs extérieurs sur l'Internet.



Un pare-feu ou firewall est un point de défense entre deux réseaux. Il protège un réseau contre l'autre grâce à un principe de

filtrage des paquets entrants et sortants du réseau privé de l’entreprise sur lequel il a été installé. Il analyse chaque paquet

entrant ou sortant du réseau privé suivant la politique de sécurité qui a été définie sur le réseau. Cette politique est constituée

d’un ensemble de règles, appelées access list (ACL), qui autorise ou interdit le trafic en fonction d’un certain nombre de

paramètres : réseau source/destination, protocoles utilisés (IP, UDP, TCP, …) et ports source/ destination. Tout paquet entrant

ou sortant est soumis à chacune des règles dans l’ordre où elles apparaissent dans le fichier de configuration du firewall. Dès

que le paquet correspond à une règle, on la lui applique et ce paquet est ignoré des règles suivantes. Par contre, si ce paquet

ne correspond à aucune des règles définies dans le fichier de configuration, le paquet est détruit.

Exemple de règles :

!

access-list 101 deny ip any 195.51.150.0 0.0.0.255

access-list 101 permit ip any any

!

Ordre des règles :

1. On refuse l’accès des paquets ip allant de n’importe quel réseau vers le

réseau 195.51.150.0

2. On autorise tous les autres paquets IP allant de n’importe quel réseau

vers n’importe quel réseau

1.1.2. Limites

Un firewall respecte quelques principes :

Il reconnaît les réseaux internes et externes, il permet aux paquets de transiter de l’intérieur vers l’extérieur, il permet aux flux

externes de rentrer s’ils sont déjà raccordés avec l’intérieur, il interdit aux paquets externes de rentrer vers l’intérieur et enfin,

beaucoup d’entre eux ne travaillent qu’avec des trafics entrants basés sur des ports standards connus (=WELL-KOWN PORTS

compris entre 0-1024).

Les deux derniers points sont des obstacles importants pour le transit des flux multimédias entre les réseaux internes et les

réseaux externes d’une entreprise. En effet, si l’on prend les flux médias de la voix « RTP/UDP », il est asymétrique et il utilise

aléatoirement des ports compris entre 16384 et 32767 qui n’appartiennent pas aux Well-Kown ports. Par conséquent le firewall

filtrera ces flux multimédias qui sont pourtant indispensables à une communication basée sur le protocole H 323.

Le schéma ci-dessous illustre comment le firewall bloque les flux VoIP en bloquant simplement le protocole RTP :

figure 3 : problème firewall

1.2. Nat

1.2.1. Définition

Un routeur Network Translation Adresse (NAT : RFC1631) est un routeur qui est utilisé dans des réseaux où l'on veut limiter

l'accès de l’Internet au réseau interne ou partager une connexion Internet en utilisant une seule @IP publique. Par conséquent,

de l’Internet seul l’équipement NAT est visible et toutes les requêtes semblent provenir de lui. Les stations situées dans le

réseau interne ne sont donc pas visibles et sont ainsi protégées contre des attaques provenant de l’Internet.

Il existe plusieurs types de NAT :



CONE PLEIN : cette méthode consiste, à chaque nouvelle demande de connexion vers l’Internet, à remplacer l’@ip source et le

numéro de port du paquet par celle du routeur NAT. Lorsque le routeur NAT reçoit des paquets, il les envoie au poste qui a

précédemment ouvert la connexion, aucune vérification sur l’origine du paquet n’est effectuée. La machine peut recevoir une

réponse de n’importe quel poste de l’Internet.

Cela est particulièrement utile lorsqu’une application doit être accessible de l’extérieur du réseau interne tel qu’un serveur de

mail, Web, DNS, etc…Ainsi si un serveur derrière le NAT envoie un paquet avec le couple {adresse :port} {A :B}, le NAT traduit

{A :B} en {X :Y}. Tous les paquets entrants destinés à {X :Y} seront donc transmis à {A :B} quelque soit l’adresse source ou le

numéro de port de ce paquet.

figure 4 : Cône plein

CONE RESTRICTIF : cette méthode est quasiment identique à la précédente sauf que lors de la réception du paquet par le

routeur NAT il y a vérification du poste source. Seuls les paquets provenant des postes adressés de l’Internet par les

connexions sortantes vont être acceptés. La même chose peut être effectuée en faisant une restriction non plus sur les postes

adressés mais sur les ports adressés. Ainsi si un serveur derrière le NAT envoie un paquet avec le couple {adresse :port} {A :B}, le NAT traduit {A :B} en {X :Y}. Seuls

les paquets entrants destinés à {X :Y} ayant pour adresses sources celles des postes adressés seront transmis à {A :B}.

figure 5 : Cône restrictif

CONE SYMETRIQUE : cette méthode diffère des techniques ci-dessus dans la manière de traiter les paquets sortants. Il s’agit

ici d’assigner l’@IP du routeur NAT et un port aléatoirement à chaque demande sortante. En ce qui concerne les connexions

entrantes, ce type de NAT agit comme les cônes restrictifs sur les ports.

figure 6 : Cône symétrique

1.2.2. Limites

Le processus de NAT représente un problème au transit des flux multimédias entre le réseau interne et externe de l’entreprise.

En effet, quand les équipements multimédias ouvrent des canaux de contrôle, de signalisation et de communication média, ils

utilisent des @IP et de numéros de ports source et destination qu’ils inclus dans l’entête des PDU (Protocol Data Unit) de

niveau 4 du modèle TCP/IP (couche 5 à 7 modèle OSI). Ces infos se retrouvent alors incluses dans le champ données du

datagramme IP qui ne seront pas utilisées par le NAT qui intervient au niveau de l’entête IP du datagramme IP. Cela pose donc

des problèmes de cheminement de bout en bout entre les points finaux.



figure 7: NAT problème

Figure 8: NAT casse la communication de bout en bout des flux médias

Pour conclure, les obstacles au passage des flux multimédias à travers les firewalls et les NAT sont le fait que :

• Les firewalls et les NAT travaillent nativement sur la couche 3 du modèle OSI et que les protocoles applicatifs travaillent

sur la couche 4 et au-dessus.

• Les firewalls filtrent les paquets entrants et n’hésitent pas à les détruire si aucune communication n’a été établie au

préalable, et sous certaines conditions, avec le réseau interne.

• Le processus de NAT cache les @IP et les numéros de ports des connexions sortantes du réseau sur lequel il a été

installé.

• Les applications multimédias sont constituées d’une multitude de protocoles : SIP, MGCP, H323 pour le signalement ;

SDP, H225 et h245 pour la capacité d’échange et RTP/RTCP pour le contrôle et les flux audio/média.

• Enfin, il reste le fait que certains protocoles utilisent des ports dynamiques supérieurs aux Well-Kown ports.



1.3. Protocoles et ports utilisés par H323, SIP et MGCP

1.3.1. La norme H323

Système de contrôle& interfaceutilisateur

Applications auxdonnées utilisateurs

T.120

E/S EquipementsAudio

E/S EquipementsVidéo

H245contrôle

H225.0RAS contrôle

H225.0contrôle appel

H261 H263Codec Vidéo

G711 G722G723

G723.1G728 G729Codec Audio

Receive path delay

Couche H225.0

Pile LAN

Figure 9 : Pile de protocoles utilisés pour H323 Figure 10 : Flux de signalisation d’un appel avec H323

Figure 11 : Requêtes H323 qui inclus @IP et port

1.3.2. La norme SIP

Figure 12 : Pile de protocoles utilisés pour SIP Figure 13 : Flux de signalisation d’un appel avec SIP




1.3.3. La norme MGCP

Figure 15 : Pile de protocoles utilisés pour MGCP Figure 16 : Flux de signalisation d’un appel avec MGCP


2. 1ère solution : les relais Face aux problèmes que pose les firewalls et les NAT, plusieurs solutions ont été proposées. Celles-ci peuvent être regroupées

en deux catégories : les solutions utilisant un relais que nous verrons dans cette partie, et les solutions utilisant une

communication directe que nous verrons dans la partie suivante.



Dans cette partie, nous présentons des solutions utilisant un dispositif de relais afin d’acheminer l’information entre deux entités

effectuant une communication poste à poste.

2.1. Serveur d’application Cette technique utilisant un serveur d’application consiste à le déployer :

soit dans un domaine privé :

soit dans une zone démilitarizée (DMZ, domaine neutre) :

Dans ces deux cas, le serveur joue le rôle de relais entre des postes désireux de communiquer ensemble.

L’utilisation de cette technique permet la traversée de tous les dispositifs de sécurité et de toutes les topologies :

Dispositif Appel sortant Appel entrant

Pare-feu • •

Cône plein • •

Cône restrictif • •

Cône restrictif sur les ports • •

Symétrique • •

Topologie • •

Réseau public • •

Réseau interne • •

Réseau interne avec un accès au

réseau public • •

Réseau avec un chaîne de pare-feu • •



ou de routeurs NAT

Cette technique présente aussi bien des avantages que des inconvénients :

Avantages Inconvénients

Technique simple, éprouvée, déployée et utilisée Déploiement et maintenance d’un serveur

Aucune modification des éléments du réseau, des applications

ou des protocoles de communication

Utilisation d’un serveur d’application

=> solution propriétaire et spécifique à un protocole

Sécurité du réseau non compromise

En conclusion, il s’agit d’une solution simple mais peu polyvalente et donc non adaptée aux besoins en services multimédias

diversifiés, appelés à prendre de l’expansion. De plus, étant donné que cette solution réside en un relais, les temps de latence

peuvent amoindrir de manière significative les performances des applications multimédias.

2.2. 2.2.2. Serveur d’application avec agent : Cette technique consiste à reprendre la solution précédente (serveur d’application dans un réseau public ou démilitarisé) en y

ajoutant un agent, situé à l’intérieur du réseau privé :

Les deux entités (serveur et agent) vont permettre de créer un tunnel d’informations, dans lequel transiteront les différentes

communications établies entre postes de travail du réseau public et du réseau privé. Les communications s’effectuent par des

ports prédéfinis et autorisés auprès des firewalls et des routeurs NAT.

Cette solution offre à des clients de profiter d’un serveur de relais, et ce, en ayant peu ou pas de contrôle sur les éléments et les

topologies du réseau.

Comme pour la solution précédente, celle-ci traverse tous les dispositifs de sécurité (pare-feu, cône plein, cône restrictif, cône

restrictif sur les ports, symétrique) ainsi que toutes les typologies (réseaux public, interne, interne avec accès au réseau public,

réseau avec chaîne de pare-feu ou de routeurs NAT).



En terme d’avantages, en plus de ceux cités précédemment on peut 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’utilisateurs tout en offrant le même niveau de sécurité au niveau des réseaux privés.

Les désanvantages restent les mêmes que pour la solution avec un simple serveur d’application si ce n’est que la maintenance

d’une telle technique risque d’être accrue ainsi que les temps de latence augmentés du fait de la multiplication des dispositifs.

2.3. 2.2.3. Passerelle de la couche d’application (ALG) :

La technique de la passerelle d’application va faire de simple firewall/Routeur NAT, des firewalls et routeurs NAT « intelligents »

c’est-à-dire capables de filtrer non plus au niveau 3 mais au niveau 7 (couche applicative). Ils seront ainsi capables d’interpréter

un protocole spécifique. Plutôt que de vérifier uniquement l’entête du paquet à traiter, les passerelles réalisent une inspection

complète des données dans le corps du paquet. Les passerelles agissent donc en tant que relais spécialisé pour un protocole

précis (SIP par ex.) :

1. Pare-f

Pas

Couche physique

Couche liaison donn

Couche réseau

Couche transpor

Couche session

Couche présentati

Couche applicatio

Attention à ne pas conf

« filtrage » est effectué d

routeurs NAT qui se cha

Ainsi dans le cas d’un r

contenu complet du paq

réseau public. Suite à ce

Dans ce modèle, et com

librement.

30/09/2004 VIGODA/LAH

serelle de la couche « Application » utilisée en tant que relais

Couche physique

Couche liaison données

Couche réseau

Couche transport

Couche session

Couche présentation

Couche

Couche physique

Couche liaison données

Couche réseau

Couche transport

Couche session

Couche présentation

Couche

ées

t

on

n

ondre serveurs application (§ 2.2.1.) et passerelles de la couche application. En effet,

ans le premier cas par les serveurs d’application alors que dans le second cas, ce sont le

rgent d’effectuer le traitement.

éseau privé utilisant une passerelle de la couche application « SIP », le firewall/routeur N

uet, va modifier adresse IP et port inscrits dans le paquet afin de pouvoir transmettre le pa

la, le firewall/routeur NAT ouvrira un « trou d’épingle » afin que la communication ait lieu li

me dans les autres précédemment cités, dispositifs techniques et topologies peuvent êt

OCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias

eu/Routeur NAT

le travail de

s pare-feux /

AT va lire le

quet dans le

brement.

re traversées

14/20



Technique simple. Modification des éléments réseaux

(pare-feu et routeurs NAT).

Sécurité accrue. Adaptabilité difficile (1 passerelle = 1 application)

Ressources limitées des pare-feu et routeurs NAT qui limitent

par la même le nombre d’utilisateurs simultanés du service.

Temps de latence importants dû au traitement complet et

individuel des paquets.

2.4. 2.2.4 Traversal Using Relay NAT (TURN)

Principe de TURN

TURN est un protocole en cours développement et de standardisation auprès de l’IETF, il s’agit en fait d’un serveur de relais : il

permet à des clients situés dans des réseaux équipés de firewalls et de routeurs NAT de communiquer ensemble en passant

par un serveur de relais.

A l’inverse des solutions précédemment citées, TURN est complètement indépendant vis-à-vis des protocoles de

communication utilisés. C’est ce qui fait son point fort.

Développé après STUN (cf § correspondant), TURN comble certains manques de celui-ci : il permet à des postes de

communiquer entre eux indépendamment de la topologie utilisée, des éléments de sécurité déployés et du protocole de

communication employé.


Technique simple à comprendre et à déployer Technique encore en cours de développement

Aucune modification sur le réseau Peu répandu

Conservation de l’intégrité du réseau Modification des programmes nécessaire pour qu’il puissent

intégrer TURN

TURN n’est lié à aucun protocole de communication Latence accrue car les données ne transigent plus directement



3. 2ème solution : la communication directe La technique utilisant une communication directe permet de traverser les firewalls et les processus de NAT pour établir une

communication entre postes en modifiant les protocoles de communication ou les éléments réseaux mais sans utilisation de

relais. Il existe 5 grandes catégories de communication directe : tunnel de données, UPnP, STUN, Midcom et ICE.

3.1. Tunnel de données Cette technique consiste à créer un tunnel de données grâce à un Réseau Virtuel Privé (RVP) utilisant des protocoles de

communication standards et existants tels que PPTP, L2TP et IPSec. Le RPV va mettre les postes dans un même domaine

privé pour ensuite acheminer tous les paquets nécessaires vers tous les postes.

Figure 18 : Principe du tunnel de données

Cette technique permet de traverser tous les dispositifs de sécurité tels que les firewalls et tous les différents types de NAT et

sur toutes les topologies réseaux : réseau interne, réseau interne avec un accès public, réseau public, et réseau avec une

chaîne de firewalls et de routeurs NAT.

Avantages Désavantages

Utilisation de protocoles existants et largement utilisés pour

permettre une communication virtuelle.

Aucune modification des éléments réseaux ou applications.

Déploiement facile pour une entreprise multisites.

Besoin d’établissement d’un RPV entre deux postes avant

toute communication.

Niveau de maintenance élevé.

3.2. Universal Plug and Play (UPnP) UPnP est un nouveau standard de communication soutenu par Microsoft Corporation et Intel. Il a été développé pour des

petites entreprises et des réseaux résidentiels (SOHO - Small Office HomeOffice) dans l'optique d'être un standard convivial et

flexible aux réseaux non gérés.

UPnP est plus qu'une simple extension du standard de périphériques Plug and Play. Cela signifie que les firewalls et les

équipements NAT sont détectés par les stations de travail de façon automatique et que ces postes peuvent ouvrir, au besoin,

des trous sur les routeurs NAT et les firewalls de façon dynamique. Ce standard, contrairement à la technique précédente, permet de traverser tous les dispositifs de sécurité tels que les firewalls

et les NAT mais pas dans la topologie où le réseau est constitué d’une chaîne de firewalls et 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 firewall et de dispositifs NAT n'étant pas dans le même sous réseau, les dispositifs ne peuvent donc pas

communiquer entres eux.


Convivial et interaction transparente des protocoles.

Standard existant dans les réseau SOHO.

Plusieurs dispositifs UPnP déjà présents sur le marché.

Modification des applications afin de communiquer avec des

équipements UpnP.

Firewalls et équipements NAT doivent supporter le UpnP.

Problème de sécurité : UPnP peut créer des brèches dans le

réseau par ces trous générés sans authentification.

3.3. Midcom Midcom est un standard en cours de développement rendant « intelligents » les firewalls et les équipements NAT pour créer

dynamiquement des trous. Il diffère de la technique des passerelles de la couche application et du standard UPnp vu

précédemment. En effet, Midcom n'est pas lié à un protocole de communication, il ne va pas décortiquer les protocoles de

communication jusqu'au niveau application comme le fait les passerelles. De plus, il se contente d'ouvrir des trous mais suite à

une authentification ou un contrôle d’accès de l'usager.

Comme UPnP, il ne peut exister sur les réseau dont la topologie met en œuvre une chaîne de firewalls et d’équipements NAT.


En voie de standardisation.

Traverse tous les protocoles de communication.

Authentification.

Aucun réseau MIDCOM actuellement.

Communication adaptée aux dispositifs MIDCOM.

3.4. Simple Traversal of UDP Through Network Address Translation devices (STUN) STUN est un protocole énoncé dans la RFC3489 et développé par le groupe de travail de MIDCOM. Il permet de traverser les

routeurs NAT en affectant une @IP et un numéro de port public à un poste situé dans le réseau privé pour effectuer une

communication de type UDP avec un réseau public. Pour ce faire, une série de requêtes à un serveur STUN est effectuée et

les réponses du serveur servent à caractériser l’@ip et le numéro de port d'un poste à communiquer.

Figure 19 : Principe STUN : il ne gère pas les flux de signalisation ni de média.



Ce protocole va permettre aux protocoles multimédias de traverser tous les types de NAT sauf le NAT de type symétrique et les

firewalls. En effet, les firewalls filtrants systématiquement tous les paquets, cela empêche toutes ouvertures de session. De

plus, le caractère aléatoire du NAT symétrique empêche de prévoir le comportement de la translation et donc empêche

également d’ouvrir une session.

Ce protocole s’adapte à un grand nombre de topologie de réseaux. Cependant il ne permet pas de traverser les chaînes

d’équipements NAT car il n’arrive pas à déterminer l’@IP à utiliser avec les utilisateurs situés entre le réseau de l’appelant et

l’Internet. Il détermine uniquement l’@IP du domaine public.


Protocole standardisé.

Peu d’infrastructure : seul 1 serveur doit être déployé pour

effectuer les requêtes.

Aucune modification de l’architecture réseau.

Adaptation des programmes existants.

Requêtes/réponses pouvant être vus comme des attaques par

firewalls…

Ne traverse pas tous les firewalls et dispositifs de NAT.

Ne peut pas être cumulé à des passerelles applicatives.

@IP mal déterminée lors de communications en interne.

3.5. Interactive Connectivity Establishment(ICE) ICE est une technologie en cours de développement qui consiste à intégrer STUN et TURN au sein des clients SIP pour

déterminer toutes les connections possibles entre deux postes.

Ce protocole caractérise les transmissions de média entre les postes et le réseau public par des requêtes STUN à un serveur

combinant STUN/TURN. Ensuite, il gère une liste d'@IP par lesquelles chaque poste peut être contacté et détermine enfin la

meilleure communication possible entre deux postes. Si aucune communication directe n’est possible entre deux postes, ICE

utilise alors les services d'un serveur TURN pour générer la communication. Contrairement à l’utilisation de STUN tout seul, ICE permet de traverser tous types de dispositifs NAT et n’importe quel type de

topologie de réseaux : qu’il y ait ou non des chaînes de firewall et NAT. Cependant ICE ne gère pas les communications s’il faut

traverser des firewalls.


ICE en cours de standardisation.

STUN est standardisé.

Traverser de toutes types de dispositifs et de topologie

réseaux sauf les firewalls.

Aucune modification de la politique de sécurité réseau.

Peu de déploiement : un serveur STUN/TURN uniquement.

Temps d’établissement d’un appel long.

Les échanges pour caractériser les communications peuvent

être perçues comme des attaques.

Besoin de démultiplexeur car les flux STUN & TURN se

partagent le même port.

Modification des serveurs et clients pour le déploiement.

4. Conclusion protocolaire Plusieurs solutions ont donc été créées pour permettre aux protocoles multimédias de traverser les firewalls et les dispositifs de

NAT.

4.1. Avantages des solutions de communication directes Les solutions dites de « communication par relais » ont montré quelques désavantages comme l’augmentation du temps de

latence du réseaux, ou la spécificité de chaque relais à un protocole particulier : SIP, H323, MGCP, etc…

Les solutions dites de « communication directes » sont rapidement apparues pour limiter ces lacunes. Elles ont notamment

permis de diminuer les temps de latence, ou d’étendre plus facilement les réseaux n’étant plus liés à un protocole en particulier.



4.2. Avantages de la solution Midcom Comparativement, bien que pas encore déployée, la solution Midcom présente la technique théorique la plus avantageuse. Elle

présente tout d’abord l’avantage de ne pas être une solution relais. Ensuite, face à la méthode de « tunnel de données » elle

nécessite des coûts de maintenance et d’opération moins élevés. Face à la solution « UpnP », Midcom offre davantage de

sécurité en apportant un niveau d’authentification lors de la création des trous de communication. Face à « STUN », Midcom

gère la traversée des NAT de type symétrique. Enfin, face à la technologie « ICE », Midcom traverse les firewalls car il n’est

pas perçu par les firewalls comme des attaques de sécurité.

Cependant, il ne faut pas oublier que Midcom présente quelques inconvénients qui peuvent le freiner à son déploiement dans

les réseaux. Il s’agit notamment du fait qu’il ne soit pas encore reconnus comme un standard (étant encore en phase

d’élaboration), qu’il ne traverse pas les chaînes de dispositifs NAT ou bien qu’il exige des modifications des équipements du

réseau (serveurs, firewalls, etc…).

L’état de l’art Les constructeurs de firewalls ont, depuis peu, accentué leur recherche quant au support de la VoIP dans leur matériel.

Depuis quelques mois maintenant, les principaux fournisseurs de firewall ont inondé le segment H323 tandis que les solutions

liées au protocole SIP devraient véritablement apparaître courant 2006.

Nous pouvons cependant vous donner une liste non exhaustive de matériels capables de supporter les protocoles multimédias :

- la société Netrake (http://www.netrake.com/index.asp) produit des « Session Contrôler » qui sont des nouveaux

matériels réseaux éxecutant les fonctions requises pour des communications en temps réels .

Ils sont une combinaison des sous-fonctions suivantes :

- Signaux :

- SIP Proxy

- H323

- MGCP proxy

- Security :

- Firewall

- NAT

- Dos Protection

- …

- la société suédoise Intertex (www.intertex.se) produit trois sortes de firewalls supportant SIP. Ce sont des firewalls

incluant un serveur SIP (avec un proxy SIP et un registre SIP) qui contrôlent en temps réel les besoins en ouverture de ports.

Commercialisés sous le nom de IX66, ils présentent des fonctionnalités avancées et ce, pour un prix équivalent à un firewall

classique.

Références

Requests For Comments : 1918 adressage privé public; 3489 STUN; 1631 NAT

www.ietf.org


http://www.netrake.com/index.asp

http://www.intertex.se/

http://www.ietf.org/rfc/rfc1918.txt?number=1918


Généralistes VoIP

www.guillnet.com

www.commentcamarche.net

Généralités NAT

www.cisco.com/warp/public/556/nat-cisco.shtml

Problème NAT et firewall:

CISCO : www.cisco.com/warp/public/788/voip/voip-nat.html#topic3

Newport NETWORK : www.newport-networks.com/whitepapers/nat-traversal.html

TERENA Cookbook : www.terena.nl/tech/IPtel/

Darmstadt UNIVERSITY of Technology : ww.iptel.org/2000/pr/H323FW.PDF

INSTITUTE for Open Communication Systems : www.iptel.org/~jiri/students/tu/2004-june-tu.pdf

UNIVERSITY of Sherbrooke : ww.iro.umontreal.ca/~jaumard/Research_Projects/Mitacs_Project2/Publications/Report1.pdf

DYNAMIC soft : www.dynamicsoft.com/news/presentations/springvon2002_sip-nat-frwl.pdf

Etat de l’art:

techupdate.zdnet.com/techupdate/stories/main/0,14179,2914709,00.html?tag=tu.tk.6587.f3


http://www.guillnet.com/

http://www.commentcamarche.net/

http://www.cisco.com/warp/public/556/nat-cisco.shtml

http://www.cisco.com/warp/public/788/voip/voip-nat.html

http://www.newport-networks.com/whitepapers/nat-traversal.html

http://www.terena.nl/tech/IPtel/

http://www.iptel.org/2000/pr/H323FW.PDF

http://www.iptel.org/~jiri/students/tu/2004-june-tu.pdf

http://www.iro.umontreal.ca/~jaumard/Research_Projects/Mitacs_Project2/Publications/Report1.pdf

http://www.dynamicsoft.com/news/presentations/springvon2002_sip-nat-frwl.pdf

http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2914709,00.html?tag=tu.tk.6587.f3

firewalls applicatifs aux - wapiti.telecom-lille.fr · en 1997, l'ietf conçoit un système de...

Documents