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

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,
14066 Caen Cedex, France.
[email protected]
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.
RÉSUMÉ
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
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.
1.1.1 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
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"
1.1.2 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.
1.1.3 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
1.1.4 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
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é
1.2.1 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
1.2.2 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.
1.2.3 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é
Etude des problèmes de sécurité SIP
5
1.2.4 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
1.2.5 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
GRES, Décembre 2001, Marrakech.
ii. Utilisation des logiciels de contrôle à distance
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
o
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
Etude des problèmes de sécurité SIP
o
7
Conclusions
i. Protection de la couche transport
ii. Protection des données de signalisation
1.2.6 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
1.2.7 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
GRES, Décembre 2001, Marrakech.
7.
8.
Les failles du protocole de routage inter domaine : TRIP
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é
1.3.1 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
1.3.2 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
1.3.3 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.
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
1.3.4 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é
1.3.5 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
1.3.6 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
1.3.7 Résumé
On résume dans le tableau suivant les points discutés ci-dessus :
Besoin
Confidentialité
Intégrité
Authentificatio
n
Contrôle
d’accès
Nonrépudiation
Objectif
Assurer l’intimité des appelés et les
appelant
Assurer l’exactitude des informations
de contrôle (taxation, facturation,
routage…)
S’assurer de l’identité des parties
communicantes
Cible
Données de contrôle
Flux média
Données de contrôle
Flux de contrôle
Les composants du
réseau SIP
Le système PKI
Les composants du
réseau SIP
Qui est autorisé à accéder au
système ?
Quelle partie du système ?
Mécanisme de relation entre utilisateur Données de contrôle
et fournisseur d’accès
PKI
Les composants du
réseau SIP
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 IJKLM MON
o PHQ'R0ST*UWVX!S*TZY
[\ ]9^ V[0_`T*Y.^ba>c V%_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£ ¥œ!¸s©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&(%<%
19B !/- "49$1C$%D<9" EF%$-&(01C@9+3&)9+%-.- )%GB40H1=@*!#)I"4-=D<%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).
Etude des problèmes de sécurité SIP
11
3. Etude du problème NAT & SIP
3.1 Problèmes posés par le NAT
V W XY[ZR\(W*]P^2_`ab^ c`aaW*def]dhg'ijZlk mPnopq rSs5ntvuws5pt?ns5xywns[t?s5z{s[x |}~€‚ƒ/„S…,†‡4ˆj‰(†IŠ8‹Œ†I~/Ž
ˆ.~#Š(4‘…’…,(‰(}ŠŽM“N”N•N”–
‚—˜}‡4ˆG~/Ž ‡  ‡4ˆ5Œ˜†I™Fš›‚,ƒS„'~/—œŠŒ*‰(}—ˆ5˜ž~/—›‹…,†—‹›Ÿ 5ƒ¡—›‹}‡4Ž8‰(†ˆH’Ž Š
†š¢…'‡—Œœ™M*ŠˆS4w‰(}ŠŽ/ˆ}~#Šš–£H†I‡ˆ/™M*ŠˆS4w‰(}ŠŽ/ˆ.‰(Œš*‡4¤‡4Œ3‹†—ˆS4ˆ2…ˆˆ5†I¥ˆ2Ÿ 5ƒS–#Ÿ 5ƒRˆ
ˆ*ŠŽS‹ˆ2*Š*Š*~#ŠˆS‡—†ššˆˆf‡4¦4ˆ€‹§ [¨S£€ƒ©—'ŠŒ*‰(}—ˆh†I~#ª«‹…†—‹ˆj‹¬Ž Š†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?+N OPRQ&SUTWVX
YZ"[J\ T] PR^ ]Q_ YZ"[a`Z"[J[ Xb Z"[Jcd S2]P Z S2e Z _^gf"^ T Z PRXT3hi&jkalm"n&jo m"l/j m"p"kJqrs7t5k$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&€Umm"lj=ouRpm"|"m"pBkJlae‹lyp€2m
p"ƒ7o m"l/eŒpm"kJl3ƒoyp†Ž6w"lmRy=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)
3.2.1 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
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).
3.2.2 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.
3.2.3 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
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.