Etude des problèmes de sécurité liés au protocole SIP (Session Initiation Protocol)

Transcription

1 Etude des problèmes de sécurité liés au protocole SIP (Session Initiation Protocol) Boucadair Mohamed France Télécom R&D- DMI/SIR 42 rue des Coutures, Caen Cedex, France. RÉSUMÉ Le protocole SIP (Session Initiation Protocol) s impose parmi les protocoles de signalisation dédiés à la téléphonie sur IP. Mais SIP souffre de quelques lacunes dont la sécurité. La norme a fait seulement signe au chiffrement des données, mais en aucun cas à la sécurisation des flux média ou de signalisation. Dans le cadre de cette étude, on présentera les options de sécurité offertes par la norme SIP ainsi que les défaillances qui peuvent être origines d attaques de fraude ou de déni de service. ABSTRACT SIP (Session Initiation Protoco) is an emerging VoIP (Voice Over IP) protocol used for setting up conferencing, telephony, multimedia and other types of communication sessions on the Internet. But this protocol has some difficulties with setting a secure communication. This paper identifies those threats. MOTS-CLÉS : pare-feu, NAT, SIP, Sécurité, RSIP, IP, IPSec, Chiffrement, DOS, VoIP, Facturation. KEYWORDS: Firewalls, NAT, SIP, Security, RSIP, IP, IPSec, Encryption, DOS, VoIP, Billing

2 2 GRES, Décembre 2001, Marrakech. 1. Etude des besoins de sécurité pour déployer SIP L étude des problèmes de sécurité liés à un protocole tel que le protocole SIP(Session Initiation Protocol), dont les impacts financiers sont estimés en millions de dollars, est sensiblement importante. Une telle étude devra couvrir tous les aspects de l établissement de l appel et la sécurisation des entités utilisées dans un réseau SIP. Mais compte tenu du jeune âge de ce protocole, les constructeurs ne disposent pas de documents normatifs dans le domaine de la sécurité du protocole SIP. C est ainsi qu on a constaté des difficultés lors de la connexion d un proxy SIP avec un serveur d authentification tel qu'un serveur RADIUS; ces problèmes ne se posent pas si on a opté pour un seul constructeur mais la facture est parfois lourde! Une étude portant sur la sécurité d'un mécanisme de communication devrait répondre aux questions suivantes : Déterminer les risques de sécurité. Déterminer les besoins de sécurité. Etudier la sécurité des systèmes actuels. Etablir le plan d action. S interroger sur la manière d intégrer les solutions aux besoins identifiés dans les systèmes actuels. Dans ce qui suit, on s'intéressera seulement aux trois premières questions, alors que les deux autres points sont traités dans (Boucadair2, 2001) Cette étude, se structure autour de deux grands axes : Niveau architectural : qui englobe toutes les entités physiques, les fichiers de configuration et les services offerts par les éléments SIP à savoir les Proxy Server, Location Server et les Redirect Server. Niveau protocolaire : à ce niveau, on fera le point sur l efficacité et la pertinence des choix du protocole SIP pour palier aux problèmes de sécurité en l occurrence les vulnérabilités de l établissement des appels. 1.1 Etat des systèmes SIP actuels SIP utilise une multitude de méthodes de sécurité telles que l authentification et le chiffrement des données. SIP offre aussi la possibilité de cacher le chemin utilisé par certains messages puisque l adresse est parfois ajoutée dans les champs VIA et les proxies intermédiaires Le chiffrement Le chiffrement des données peut être utilisé de bout en bout ou de nœud à nœud entre les entités SIP. Le chiffrement nœud à nœud chiffre tout le message et il est proposé que ce mode fonctionne au niveau transport. Le protocole Ipsec(IP

3 Etude des problèmes de sécurité SIP 3 Security) est un candidat pour remplir ce rôle. Alors que le chiffrement de bout en bout est utilisé entre les deux applications clientes qui doivent respecter les conditions suivantes : Tous les champs doivent être chiffrés de telle sorte que les entités intermédiaires ne les «comprennent» pas. Tous les champs non chiffrés doivent précéder les champs chiffrés Il n est pas nécessaire de chiffrer aucune en-tête SIP La réponse à un message chiffré doit être chiffrée par une clef donnée dans le champs Response-Key-Header, si aucune clef est spécifiée, le message est non chiffré Les en-têtes qui sont chiffrées dans le message "demande" doit l être dans le message" réponse" Authentification Si l utilisateur a opté pour authentifier ses messages, alors il doit signer les messages qu il envoie. La signature englobe tout le message mais non pas toutes les en-têtes SIP. Ces en-têtes qui ne sont pas incluses sont celles qui changent entre les entités intermédiaires comme le champ VIA. Si un calcul d intégrité est choisi, un message d erreur est produit pour avertir le récepteur de ce changement d information Cacher le chemin utilisé (Hide-Route) Hide-Route est un mécanisme employé par SIP pour ne pas avancer quant aux chemins utilisés par les paquets SIP. Si ce mécanisme est activé, les proxies intermédiaires chiffrent le champs VIA Résumé Comme dans le cas de la téléphonie traditionnelle à savoir le cas du RTC ou du RNIS, où deux canaux sont à protéger : les données de signalisation qui sont véhiculées via le réseau sémaphore (SS7) et les données (voix et data) qui sont transportées dans les files, le protocole SIP utilise cette notion de flux média et de données de signalisation même s il n s occupe que de la partie signalisation ( car les flux sont gérés par RTP (Real Time Protocol), et de plus c est SIP qui initialise, modifie et termine une session) La norme n a pas prévu de protéger toutes ces données. Le tableau suivant résume la manière avec laquelle, SIP résout ces problèmes de sécurité : Besoin Signalisation Flux média Authentification De bout en bout Non prévue Nœud à nœud Intégrité De bout en bout Non prévue Nœud à nœud Non-répudiation Non prévue Non prévue Confidentialité De bout en bout De bout en bout

4 4 GRES, Décembre 2001, Marrakech. Nœud à nœud Nœud à nœud Contrôle d accès Non prévue Non prévue Tableau.Sec 1 : Solutions aux problèmes de sécurité prévues par SIP Une lecture en diagonal de ce tableau permet de voir les lacunes de sécurité dont souffre SIP. Remédier à ces problèmes passe par les identifier et les comparer aux menaces existantes pour utiliser des solutions existantes. 1.2 Risques de sécurité Risques de la téléphonie traditionnelle Un appel téléphonique produit deux types d'information (données et signalisation) qui devraient être gardés en tant que confidentielles et mises à jour pour assurer l'intimité des appelants et des appelés. Le fournisseur de service doit rassembler les informations statistiques pour des buts de comptabilisation et de facturation, donc on est amené à protéger ces informations par un accès restreint et protégé. Voilà quelques menaces qui pourraient se produire: 1. Perturbation de l appelé: en recevant des appels téléphoniques non désirés 2. Appeler gratuitement en utilisant le numéro de téléphone de quelqu'un d autre. 3. Déni de service Comparaison entre les risques de la téléphonie classique et le SIP L étude des aspects sécurité des protocoles de la voix sur IP (Internet Protocol) passe par celle de la téléphonie classique dont voici quelques points de divergence et de parallèle : o Dans la VoIP, et étant donné que les paquets ne sont pas chiffrés, tout ce que un attaquant a besoin est de prendre les paquets appropriés avec un sniffer de paquets. Ce sniffer de paquets peut être un ordinateur attaché, par exemple, au réseau local de l entreprise. En téléphonie traditionnelle, la téléphonie mobile est exclue, l attaquant doit avoir un dispositif spécial, qui doit être physiquement relié à un fil, qui est utilisé pendant un appel. o Internet est largement considéré comme peu sûr. Les réseaux avec commutation à circuit ne sont pas entièrement sûrs mais les personnes ne s inquiètent pas trop à ce sujet Catégories de risques Divers sont les risques de sécurité qu on est mené à rencontrer dans le domaine de la téléphonie sur IP. Des risques qu on peut d ores et déjà classer dans les catégories suivantes : vol de service si existence d un modèle de taxation (modèle de Billing ), disponibilité de service, l intégrité des messages et l usurpation d'identité

5 Etude des problèmes de sécurité SIP Modalités Réaliser un scénario de fraude passe par différentes modalités qu on résume dans la liste suivante : Les messages interceptés : o Récupérer le CALL-ID : qu on peut insérer dans un faux paquet. o Récupérer le CALL-LEG (TO-FROM-SUBJECT) Les faux messages : o Le faux BYE, ayant pour résultat l'arrêt de l'appel. o Le faux CANCEL (spoofing) ayant pour résultat l'arrêt de INVITE o Le faux ACK (Spoofing ) permettant le détournement de l'appel (hijacking) Des messages incorrects répétés indéfiniment : o Déni de service et le flooding o Attaques de la mémoire tampon (overrun/stack) Média intercepté o Récupérer les informations sur le port RTP(Real Time Protocol)utilisé o Récupérer l adresse IP, numéro du port o Récupérer le contenu de la charge utile. Médias non-désirés ou faux Exemples de scénarii Dans cette partie, on recensera quelques scénarii de fraude ou d utilisation malpropre des possibilités offertes par le protocole SIP. Dans la suite, on supposera que A et B sont deux personnes qui veulent communiquer via le protocole SIP et que C est une autre personne qui perturbe la communication. C est ainsi qu on peut avoir des cas de figure non prévus par la norme : 1 A appelle B prétendant être C. 2 A appelle B, et dés que l appel est établi C envoie un message BYE à A ou à B. 3 A appelle B; au moment d attente de la sonnerie, C envoie un message CANCEL à B; 4 A appelle B; B envoie alors un message ACK; C envoie aussi un faux ACK avec son propre adresse IP/numéro de port; quand A envoie à son tours ACK, il est ignoré par B et C fait partie de la conversation 5 C, envoie des faux INVITE causant un déni de service, le téléphone sonne toujours 6 Un faux proxy, envoie un OK mais efface l enregistrement lors d un enregistrement multicast, et alors l utilisateur ne reçoit plus d appels. Examinons maintenant quelques cas d attaques : 1. Exemples d attaques sur le téléphone SIP o Condition préliminaire : accéder au LAN o Déni de service : i. Dépassement de la pile par l envoi de longues demandes «GET»

6 6 GRES, Décembre 2001, Marrakech. ii. Utilisation des logiciels de contrôle à distance o Attaques : i. Hijacking d une session TCP vers le téléphone IP ceci étant possible si une des conditions suivantes est vérifiée : 1. L algorithme de génération de CALL-ID est cryptographiquement faible. 2. Si la session de gestion n est pas suffisamment protégée ii. La brute force pour accéder au mot de passe de l administration o Conclusion : le téléphone IP doit être protéger contre ce genre d attaques. 2. Exemples d attaques contre le proxy o Condition préliminaire : accéder au LAN o Déni de service : i. SYN-flooding ii. Enregistrement périodique des utilisateurs o Attaques : i. Modification des données d enregistrement 1. Effacer des enregistrements 2. Enregistrer un utilisateur avec une nouvelle adresse IP eu une nouvelles URL 3. Redirection d un utilisateur vers une autre adresse 4. Enregistrement illégal i. Enregistre un utilisateur avec une fausse adresse ii. Rediriger tous les appels dont le destinataire est choisi vers une autre adresse o Conclusions i. Les proxies ne testent pas suffisamment ii. Nécessité de définition des polices de sécurité bien poussée iii. Le proxies doivent réagir comme une DMZ 3. Exemples d attaques pour accéder au réseau SIP et faire partie de la communication o Condition préliminaire : accéder au LAN o Déni de service : SYN-floding o Attaques : i. Ecoute des paquets RTP 1. Ecouter les paquets UDP(User Datagram Protocol), identifier les paquets RTP 2. Analyser ces paquets et émettre vers le destinataire 3. Utilisation de logiciels de type «sniffer» ii. Modification des données de signalisation 1. Re-direction des paquets 2. Modification des données audio 3. Détecter les ports RTP et envoyer des vidéos profanes

7 Etude des problèmes de sécurité SIP 7 o Conclusions i. Protection de la couche transport ii. Protection des données de signalisation Causes identifiées Il y a diverses causes de fraude ou d utilisation mal- seine du protocole SIP. Identités non authentifiées dans le champs " FROM " Non-protection des messages de signalisation (texte en clair) Messages non authentifiés (BYE, CANCEL, ACK) La signalisation n'indique pas l'émetteur des médias De plus une des attaques les plus difficiles à prévenir est celle par DOS (Deny Of Service) dont les causes peuvent être résumé en : 1. INVITE : a pour effet le non-établissement de l appel ou le changement de la session 2. INVITE avec une temporisation : qui a pour effet le time-out de la session 3. BYE : rend la session interminable 4. CANCEL : empêche la sonnerie du téléphone 5. OPTIONS : n affecte pas l appel 6. REGSTER : induit la non réception des appels Problèmes de sécurité SIP Dans ce qui suit, on résumera quelques problèmes de sécurité rencontrés en utilisant SIP : 1. Le forking : le forking est une situation où A appelle B et la demande d'invitation d'appel est envoyée à B1 et à B2, qui sont de différents terminaux que l'utilisateur utilise. Le résultats devrait être que les terminaux B1 et B2 doivent sonner. Le mécanisme de Handshacke utilisé dans le SIP ne fonctionne pas avec le forking, seulement B1 sonne dans les cas où le Handshacke est utilisé. L'utilisation des demandes signées sans Handshacke peut résoudre le problème mais ceci exigerait l'utilisation de PKI. Les attaques par rejeu peuvent être réaliser en mémorisant les Call-IDs. 2. Attaque par réflexion peut se produire en utilisant l'authentification pour la demande et la réponse. Si le même secret partagé est utilisé dans les deux directions, un attaquant peut obtenir des qualifications en reflétant un défi dans une réponse répondant ainsi à une demande. L'utilisation de différents secrets dans chaque direction élimine l'attaque. Ce genre d'attaque n'est pas un problème quand le PGP est utilisé pour l'authentification. 3. L authentification par multiple proxies : il faut que chaque proxy garde les traces des premiers secrets dits créances; le mécanisme est le suivant : 4. Problèmes de REGISTER le seul message qui donne la possibilité d écrire, on peut alors remplir la base de données par des CGI,.. 5. Problème de CANCEL : les proxies peuvent générer des messages CANCEL, et donc peuvent mettre fin à une communication 6. Des proxies non authentifiés dans un réseau SIP

8 8 GRES, Décembre 2001, Marrakech. 7. Les failles du protocole de routage inter domaine : TRIP 8. La norme SIP prévoit l utilisation des modes d authentification dont le mode HTTP-Digest, mais ce mode n est pas compatible avec le mode d authentification des serveurs RADIUS 9. L authentification prévue par la RFC2617 qui traite de SIP et celle de RADIUS (RFC 2138) utilisent MD5 avec des formats de messages différents. 10. Compte tenu du fait que le protocole SIP fonctionne sous RTP, une des menaces est le SPAM RTP. 11. La traversée des firewalls : qui pose des problèmes d écriture des règles de sécurité. 12. La traversée des NAT( ) 1.3 Besoins de sécurité Confidentialité Tous les flux média doivent être protégés contre les écoutes mal seines du réseau, ceci peut être réserver aux données mais les données de signalisation peuvent l être aussi. Pour une communication SIP, cette exigence est un peu difficile vue que la StartLine de l invitation ne peut pas être cachée et donc envoyée en clair. Notons, que cette exigence est primordiale pour les utilisateurs. Risque : eavesdrooinp Intégrité Tous les messages de signalisation, et les flux média doivent être incorruptibles. Notons aussi que les clefs de chiffrement et les tables de routage doivent être protégées aussi. Sans cette garantie, le doute s installera d un côté entre l utilisateur et son fournisseur d accès qui doit prouver que c est bien la personne qui a consommé un tel service, et d un autre côté on doit protéger l utilisateur des fraudeurs. De plus, si un proxy n est pas sûr, on peut recueillir les données qui transitent par ce dernier. La modification de la table de routage a par contre l effet de forcer le passage des paquets par une route spécifiée. Risque : attaque par rejeu, attaque par réflexion, hijacking Authentification Il est nécessaire de prévoir de l authentification d un utilisateur ou une machine faisant partie d'une conférence pour décliner leurs identités. C est un des besoins les plus exigeant du protocole SIP car sans ce mécanisme, personne ne peut garantir celui qu il prétend être, et on peut pas remédier aux problèmes de la nonrépudiation.

9 Etude des problèmes de sécurité SIP 9 Signalons que ce n est pas seulement les machines de bout qui doivent être authentifiées mais toutes les entités qui interviennent dans la communication à savoir les proxies, les serveurs de re-direction et les serveurs de localisation. Risque : spoofing Contrôle d accès Cette exigence peut se traduire par la permission d utilisation de services à des gens précis. Risque : accès non autorisé Non-répudiation Ce besoin est bi-directionnel; l utilisateur ne doit pas pouvoir nier l utilisation d un service en participant à une communication et doit encore avoir la certitude de ne payer que ce qui il a consommé. Risque : fraude Disponibilité Une chose qu on peut traduire par la disponibilité du service quand l utilisateur le souhaite et sans aucun retard. En d autres termes, les fournisseurs d accès doivent minimiser les risques des attaques par DOS, chose non pas toujours facile. Risque : DOS Résumé On résume dans le tableau suivant les points discutés ci-dessus : Besoin Objectif Cible Confidentialité Assurer l intimité des appelés et les appelant Données de contrôle Flux média Intégrité Assurer l exactitude des informations Données de contrôle de contrôle (taxation, facturation, routage ) Authentificatio n S assurer de l identité des parties communicantes Flux de contrôle Les composants du réseau SIP Contrôle d accès Nonrépudiation Qui est autorisé à accéder au système? Quelle partie du système? Mécanisme de relation entre utilisateur et fournisseur d accès Le système PKI Les composants du réseau SIP Données de contrôle PKI Les composants du réseau SIP

10 10 GRES, Décembre 2001, Marrakech. Tableau.Sec 2: Besoins de sécurité pour le protocole SIP 2 Etude du problème Firewall & SIP 2.1 Problèmes posés par les firewalls dans une communication SIP SIP utilise un port bien défini (5060) ce qui ne posera pas normalement de problèmes pour administrer les règles de passage dans les firewalls, mais ceci n étant pas vrai puisque SIP fait appel au protocole RTP pour le transport des médias. Notons que le fait que RTP soit basé sur UDP et le fait que il n existe pas de port fixe associé à ce protocole induit l impossibilité de définir des règles statiques qui peuvent permettre le passage des flux RTP sans engendrer le passage des protocoles non désirés. 2.2 Etude de quelques solutions! #"%$& '& (*)"%$,+! -$.$*$,/0$.) 1& "%)020$,314"$.*576%*20&#(*8*$.)19/*(*:%:;0(*)06 <*5='/>@?ACBDFEHG I JKLM MON o PHQ'R0ST*UWV X!S*TZY[\ ]9^ V [0_`T*Y.^ba>cV%_0d!\ ]4STZa>Q_0Y,\%T*YfegV S*T!hiQj\ \%YWa>T*Ylk@PHmon k@r0r0\ V%d*Qp^ V%[0_ZPHT!qrT!\ m=q^t!hsqut*vxw o yhz {>}!~># % * 7} ƒ. ~ % 0ˆ0 Š* 0 7 =} }*ƒ Œ}!# 0 % Ž *} {>zˆ0ƒ % zjžš* % }*Š* ~4Ž*} {>}, Cš (MiddleBox Communication) œ* ž9ÿ>œ Ÿ> * % 9 = 0 4 rœ* j Zª0 * 0ž 0«* %œ Ÿ>œ «* 0 7 = p 0Ÿ0œ ª: > Wª:œ! =œ*žž œ 9 j 9ž *œ Ÿ* % ª: 0 %ž % ±ž ²*ª0 %³ 9œ* 7œ* 0ž 0œ=œ* 0ž %ž =Ÿ0œ= 0 j. ž % 0 µ Ÿ0œ «* 0 0ž %œ! : %œ*, g œ!ş j % 0žœ! * 7 *Ÿ % u *œ* ¹ º œ* ZŸ>œ! 4»¼. 9ž % 0 0.½ ¾@ HÀÁœ*žÃÂ Ä ÅÆ,ÇÈ,ÉÊ!ËOÌ Í Ê*Î0Ï Ð>Ê*ÑZÒ Ì%Ñ.Ê*ÑsÓÕÔ Ö 4ØÙÐ>Ê*ÑZÚgÌ ØÊ!ÛsÜjÝ Ý ÑZÊ*Ï@ÑÖ0Î0Ï Ð0Ö0Î0Þ:ß:ÜÑ,ÏÖ 9Ô Ö 4Ø*Ñß:Ö0ÑÑÌ%àÝ Ê*Ñ.á o âfã`ä å*æç èç%é*ê7ë è.æì íä ç%æ0îlë*èä ï>ë`ä åãjðrë!å*èë!å`ñ*ë*èò#ó ô õö pø ø ùúfûbü*ý ýǜ þ.ÿ 9ý %ÿ ü*þ.ý *ü*þ.þ *ü ÿ 0ü*þ!#" $ %'&(%*)+,% -.-.% $ -/&(012!/$ %,+3"415%,687 9!#) :#; % 1 <= >?"1 < %@ %,- A &(%< % 19 B!/- "49 $ 1C$ %D<9 " EF% $ - &(01C@ 9 +3& ) 9 +% -.- 1J=!#" &(% +,% $ -.1K-9!/-L% 9 $ 1%*)*EM0$ -NB4% 1O@ 0I) 0@ -.=*)*"1- "4!P% 1Q<!R-.% +3&(1M) = %*BS<%(B4T 0I& & B "4@ 0U- "49 $ : Cette troisième solution, sera introduite dans notre banc de test dans la limite de trouver les composants logiciels et matériels nécessaires (tels que les proxies Agent).

11 Etude des problèmes de sécurité SIP Etude du problème NAT & SIP 3.1 Problèmes posés par le NAT V WXY[ZR\(W*]P^2_` a b ^ c` a a W*def]dhg'ijZlk mpnop qrss5ntvuws5p t?ns5xywns[t?s5z{s[x } ~ ƒ/ S, 4ĵ ( IŠ8 Œ I~/Ž ˆ.~#Š( 4, ( (} Š ŽM N N N } 4Ĝ~/Ž 4ˆ5Œ I F š,ƒs '~/ œš Œ* (} ˆ5 ž~/, Ÿ5ƒ } 4Ž8 ( Ĥ Ž Š š ' Œ œ M *Š Ŝ 4 w (} ŠŽ/ˆ} ~#Š š H I ˆ/ M *Š Ŝ 4 w (} ŠŽ/ˆ. (Œ š* 4 4Œ3 Ŝ 4 ˆ2 ˆˆ5 I ˆ2Ÿ5ƒS #Ÿ5ƒRˆ ˆ *Š ŽS ˆ2 *Š*Š *~#Š Ŝ š š ˆˆf 4 4 ˆ [ S ƒ 'ŠŒ* (} ˆ h I~#ª«ĵ Ž Š U ˆ 3 4ˆˆf 4} # ˆ, ˆ5ˆ I ˆ2 ', 'ˆ5} Ž/ 4Ž ~/ * 4 Ž/ F} Œ ˆ2ˆ.~#ŠO 4 3. [ {±².³µ * ¹ º»'¼,½ * *¾M * và( * /Á À ¹ ¹* * ÃÀ 4ÄUÅ * à 4 ÃÀ(Æ ÁvÇ È½Æ # Å ÉÇ ÈÅ Ê ÄË / ÉÌ.Í[Î{ÏÐ.ÑSÒ ÓÔ Õ(Ö4 Ø, Õ5ÕÓIÙ ÚµÛhÖ4Ü Ý Õ Þ ß Óàá/ Èâ?ã äå.æç è(é*êpë3ì í î ê/ë.é*ïñð4é òhï ì*è(î ó ò5é ò8òì*è(ôiïì õ,é ó ë.öw êøòùê/ú ê/ó éèï ì*è(î ó òéûó éüò5é*ï ô è(ôò8ôí ùêøëë.ì éüé ó êpë ø ð øòôó ëvðéûõý õ,éló ê/õ,ì*ïîžþé è(î ï ë.ÿ [ ó é ë ïô Fé*ï ò5é*ï ô'è(ôò ó î ïõ,ôð4é õ,é ó ë(ê/ó é ë énø é*ï ôiø4ëê/ó é [,ö "!#$!%"!&(' )+*-,/. 0#1 ""%"!&23#546' 7*98 :;$<=<$>?+@(AB;$<=CED=>FHGI>?J@KLD=?+GM?JCE?+NO PRQ&SUTWVX YZ"[J\ T] PR^ ]Q_ YZ"[a`Z"[J[ X b Z"[Jcd S2]P Z S2e Z _^gf"^ T Z PRX T3h i&jkal m"n&jo m"l/j m"p"kjqr s7t5k$urv"wjhxjpzy{ l3 &m3p"kkjp~}+t p"oyp"kruri&m"o$k o j y jkjv"kruri& Umay{ v"w" l3ƒ&b p p"k hxy 2 ˆ Uy=o jˆ7v" "jl3kqšap"wj uri& Um m"l j=ourpm" "m"pbkjlae l yp 2m p"ƒ7o m"l/eœpm"kjl3ƒo yp Ž 6w"l mry=p"kll3 "m"p"kkjp"klkiƒo ˆi "jhxjv"p"kq Le SIP met les URL dans le champs CONTACT, TO et FROM, qui signalent les adresses utilisées. Ces URL peuvent contenir des adresses IP ou des noms de domaine dans la partie de port du URL. Ceux-ci peuvent ne pas être valides une fois qu'ils traversent un NAT. Comme alternative à une SIP_ALG, le SIP supporte un serveur proxy qui pourrait co-résider avec NAT. Un tel proxy aurait une configuration locale. 3.2 Etude de quelques solutions (ALG, RSIP, MidCom) RSIP: Realm Specific IP RSIP est employé pour caractériser la fonctionnalité d'un ensemble d adresse privé converti en un ensemble public, chose qui permet au réseau interne de communiquer avec l extérieur. Un client RSIP est un hôte dans un réseau privé qui a une adresse dans un ensemble d adresses externe en se reliant aux serveurs dans ce réseau pour assurer une transmission bout à bout. Des paquets produits par des serveurs sur l'une ou l'autre extrémité dans une telle installation seraient basés sur les adresses qui sont seules celle du bout à bout dans le réseau externe et n'exigent pas la traduction par un processus intermédiaire.

12 12 GRES, Décembre 2001, Marrakech. Un serveur de RSIP est serveur un résidant dans un nœud des deux réseaux privés et externes, celui peut faciliter le routage des paquets externes. Ces paquets ont pu avoir été lancés par un client RSIP ou avoir été dirigés vers un client RSIP. Un serveur RSIP peut également être le même nœud qui assigne des adresses externes aux clients RSIP. Il y a deux variations de RSIP, à savoir IP Realm-specific Address (RSA-IP) et IP Realm-specific Address and port (RSAP-IP) ALG: Application Level Gateway Non toutes les applications traversent facilement les dispositifs de NAT, et particulièrement celles qui incluent des adresses IP et des ports TCP/UDP dans leurs charges utiles. Les ALG sont des agents spécifiques de traduction d'application qui permettent à une application résidant dans un réseau donné de se relier à d autres applications fonctionnant sur serveur tournant dans un réseau différent d'une manière transparente. Les ALG et les proxies facilitent la transmission d'application entre les clients et les serveurs. Les proxies emploient un protocole spécial pour faire communiquer les clients avec les serveurs et vice versa. À la différence des proxies, les ALG n'emploient pas un protocole spécial pour communiquer avec l'application et n'exigent pas des changements concernant les clients MidCom: MiddleBox Communication Middlebox est un dispositif intermédiaire qui exige l'intelligence des applications pour son exécution. Les dispositifs intermédiaires implémentant la politique de filtrage de paquets, détection d'intrusion, équilibrage de chargement, sécurité IPsec et les fonctions NAT sont tous les exemples d un middlebox. Un middlebox peut mettre en oeuvre une ou plusieurs de ces fonctions. 4. Etude du problème routage & SIP 4.1 Le protocole TRIP Le protocole de routage utilisé dans le domaine de la téléphonie sur IP est le protocole TRIP (Telephony Routing Information Protocol). Dans la présente étude, on ne tardera pas sur l étude du protocole, et on se contentera de faire la remarque suivante : le protocole peut être un point d entrée pour modifier les informations de routage et ainsi forcer le passage du trafic par des entités étrangères et mettre ainsi en péril les opérations d enregistrement et de routage d appels. 4.2 Problèmes du multicast

13 Etude des problèmes de sécurité SIP 13 Pour une requête multicast, on confond une réponse d' une requête au début d une session.