Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA Claire VIGODA Romain LAHOCHE Co

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 FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA 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. 1 ERE 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. 2 EME 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 30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 2/20 FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA 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 30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 3/20 FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA 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. 30/09/2004 VIGODA/LAHOCHE (exposé FI2005) Firewalls applicatifs aux protocoles multimédias 4/20 FIREWALLS APPLICATIFS AUX PROTOCOLES MULTIMEDIA 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 uploads/Ingenierie_Lourd/ les-protocoles-voip.pdf