SIP ALG

Fonctionnement sip alg

Il existe deux types de trafic SIP, la signalisation et le flux multimédia. Le trafic de signalisation SIP consiste en messages de requête et de réponse entre le client et le serveur et utilise des protocoles de transport tels que UDP ou TCP. Le flux multimédia transporte les données (données audio, par exemple) à l’aide de protocoles de transport.

Depuis Junos OS version 12.3X48-D25 et Junos OS version 17.3R1, le SIP ALG prend en charge TCP. La prise en charge TCP sur l’ALG SIP réduit le trafic vers le serveur en éliminant le besoin de réenregistrer ou d’actualiser le serveur fréquemment.

Par défaut, Junos OS prend en charge les messages de signalisation SIP sur le port 5060. Vous pouvez configurer le port en créant une stratégie autorisant le service SIP, et le logiciel filtre le trafic de signalisation SIP comme n’importe quel autre type de trafic, ce qui le permet ou le refuse. Le flux multimédia utilise toutefois des numéros de port affectés de façon dynamique qui peuvent changer plusieurs fois au cours d’un appel. Sans ports fixes, il est insécurisé de créer une stratégie statique de contrôle du trafic multimédia. Dans ce cas, l’unité appelle le protocole ALG SIP. Les ports de transport de l’équipement utilisés pour les sessions multimédias ne sont pas connus à l’avance ; cependant, les ports utilisés pour la négociation SIP sont bien connus (ou prédéfinis). L’ALG enregistre un intérêt pour les paquets de la session de contrôle, qu’il peut facilement distinguer des autres paquets, et inspecte les négociations concernant les informations de transport utilisées pour la session multimédia (adresses IP et ports).

L’ALG SIP surveille les transactions SIP et crée et gère dynamiquement les trous d’épingle en fonction des informations qu’il extrait de ces transactions. L’ALG SIP de Juniper Networks prend en charge toutes les méthodes et réponses SIP. Vous pouvez autoriser les transactions SIP à traverser le pare-feu Juniper Networks en créant une stratégie statique autorisant le service SIP. Si la stratégie est configurée pour inspecter le trafic SIP (ou, plus précisément, si la stratégie envoie un certain trafic à l’ALG SIP pour inspection), les actions autorisées doivent autoriser le trafic (auquel cas les trous d’épingle appropriés sont ouverts) ou refuser le trafic.

L’ALG SIP intercepte les messages SIP qui contiennent SDP et, à l’aide d’un analyseur, extrait les informations dont il a besoin pour créer des trous d’épingle. L’ALG SIP examine la partie SDP du paquet et un parser extrait des informations telles que les adresses IP et les numéros de port, que le SIP ALG enregistre dans une table de trou d’épingle. L’ALG SIP utilise les adresses IP et les numéros de ports enregistrés dans la table de trou d’épingle pour ouvrir les trous d’épingle et permettre aux flux multimédias de traverser l’équipement.

Les produits SIP NEC sont pris en charge sous condition.

Descriptions des sessions SDP

Une description de session SDP est un format bien défini qui permet de transmettre suffisamment d’informations pour découvrir et participer à une session multimédia. Une session est décrite par une série de paires attribut/valeur, une par ligne. Les attributs sont des caractères uniques, suivis de =et d’une valeur. Les valeurs facultatives sont spécifiées avec =*. Les valeurs sont soit une chaîne ASCII, soit une séquence de types spécifiques séparés par des espaces. Les noms d’attributs ne sont uniques qu’au sein de la structure syntaxique associée, par exemple au sein de la session, du temps ou du support uniquement.

Parmi les nombreux champs de la description SDP, deux sont particulièrement utiles pour le protocole SIP ALG, car ils contiennent des informations sur la couche transport.

• c= pour les informations de connexion

  Ce champ peut s’afficher au niveau de la session ou du média. Il apparaît dans ce format :

  c=<><adresse><connexion>

  Junos OS prend uniquement en charge « IN » (pour Internet) comme type de réseau, « IPv4 » comme type d’adresse, et une adresse IP unicast ou un nom de domaine comme adresse IP de destination (connexion). À partir de Junos OS version 15.1X49-D40 et de Junos OS version 17.3R1, le type d’adresse « IPv6 » est également pris en charge.

  Si l’adresse IP de destination est une adresse IP unicast, le SIP ALG crée des trous d’épingle à l’aide de l’adresse IP et des numéros de port spécifiés dans le champ de description multimédia m=.

• m= à l’annonce de la presse

  Ce champ s’affiche au niveau des médias et contient la description des médias. Il apparaît dans ce format :

  m=liste <media><port><transport><fmt>

  Actuellement, Junos OS prend en charge « RTP » en tant que protocole de transport de la couche applicative. Le numéro de port indique le port de destination du flux multimédia (l’origine est attribuée par l’UA distant). La liste des formats (liste fmt) fournit des informations sur le protocole Application Layer utilisé par le support.

  Le logiciel ouvre uniquement les ports pour RTP et RTCP (Real-Time Control Protocol). Chaque session RTP comporte une session RTCP correspondante. Par conséquent, chaque fois qu’un flux multimédia utilise RTP, le SIP ALG doit réserver des ports (créer des trous d’épingle) pour le trafic RTP et RTCP. Par défaut, le numéro de port rtcp est supérieur à celui du port RTP.

Création de trou d’épingle

Chaque trou d’épingle (un pour le trafic RTP et l’autre pour le trafic RTCP) partagent la même adresse IP de destination. L’adresse IP provient du champ c= dans la description de session SDP. Comme le champ c= peut s’afficher au niveau de la session ou au niveau multimédia de la description de session SDP, l’analyseur détermine l’adresse IP en fonction des règles suivantes (conformément aux conventions SDP) :

• Tout d’abord, le parser SIP ALG recherche un champ c= contenant une adresse IP au niveau multimédia. S’il y a un tel champ, l’analyseur extrait cette adresse IP, et le SIP ALG utilise cette adresse pour créer un trou d’épingle pour le support.

• S’il n’y a pas de champ c= au niveau du support, l’analyseur SIP ALG extrait l’adresse IP du champ c= au niveau de la session, et l’ALG SIP utilise cette adresse IP pour créer un trou d’épingle pour le support. Si la description de la session ne contient pas de champ c= dans les deux niveaux, cela indique une erreur dans la pile de protocoles, et l’équipement abandonne le paquet et consigne l’événement.

L’ALG SIP ouvre également des trous d’épingle pour le trafic de signal. Ces trous d’épingle de signal sont utiles après le délai d’expiration de session de signal précédent, et ils sont également utiles pour le trafic de signal envoyé à une adresse tierce qui ne correspond pas à la session de signal précédente. Les trous d’épingles du signal ALG SIP ne vieillissent jamais, contrairement aux trous d’épingle RTP ou RTCP, où seuls les ports IP de destination et de destination sont spécifiés.

L’ALG SIP ouvre des trous d’épingles de signal pour les en-têtes suivants, si nécessaire :

• Via

• CONTACT

• ROUTAGE

• ROUTAGE D’ENREGISTREMENT

Le SIP ALG a besoin des informations suivantes pour créer un trou d’épingle. Ces informations proviennent de la description de session SDP ou des en-têtes SIP (tels que répertoriés ci-dessus).

• Protocole :UDP ou TCP.

• IP source : inconnue.

• Port source : inconnu.

• ADRESSE IP de destination : l’analyseur extrait l’adresse IP de destination du champ c= au niveau du support ou de la session.

• Port de destination : le parser extrait le numéro de port de destination pour RTP du champ m= du niveau multimédia et calcule le numéro de port de destination pour RTCP à l’aide de la formule suivante :

  Numéro de port RTP + un

• Durée de vie : cette valeur indique la durée (en secondes) pendant laquelle un trou d’épingle est ouvert pour laisser passer un paquet. Un paquet doit traverser le trou d’épingle avant l’expiration de sa durée de vie. Lorsque la durée de vie expire, l’ALG SIP retire le trou d’épingle.

  Lorsqu’un paquet traverse le trou d’épingle au cours de la période de vie, immédiatement après quoi le ALG SIP retire le trou d’épingle pour déterminer la direction à partir de laquelle le paquet est venu.

  La figure 1 décrit une configuration d’appel entre deux clients SIP et la façon dont le SIP ALG crée des trous d’épingle pour autoriser le trafic RTP et RTCP. L’illustration part du principe que l’équipement dispose d’une stratégie autorisant le protocole SIP, ouvrant ainsi le port 5060 pour les messages de signalisation SIP.

  Figure 1 : Configuration des appels SIP ALG

• Comprendre la prise en charge d’IPv6 pour SIP ALG
• Understanding Scaling Busy Lamp Field Support for the UDP-Based SIP ALG
• Comprendre les méthodes de demande d’ALG SIP
• Présentation de la configuration SIP ALG
• Comprendre la protection contre les attaques par doS SIP ALG
• Comprendre les types de messages INCONNUS SIP ALG
• Comprendre la durée et les délais d’expiration des appels SIP ALG

Conserver les ressources de maintenez le protocole SIP ALG (procédure CLI)

Pour prendre en charge les flux d’appels SIP propriétaires :

Appels sortants

Lorsqu’un appel SIP est lancé avec un message de requête SIP de l’interne vers le réseau externe, nat remplace les adresses IP et les numéros de port dans le SDP et lie les adresses IP et les numéros de port au pare-feu Juniper Networks. Si elles sont présentes, les champs d’en-tête SIP Via, Contact, Route et Record-Route sont également liés à l’adresse IP du pare-feu. L’ALG stocke ces mappages pour les utiliser dans les retransmissions et pour les messages de réponse SIP.

L’ALG SIP ouvre ensuite des trous d’épingle dans le pare-feu afin d’autoriser le support via l’équipement sur les ports affectés dynamiquement, négociés en fonction des informations contenues dans les champs d’en-tête Via, Contact et Record-Route. Les trous d’épingle permettent également aux paquets entrants d’atteindre les adresses ET ports Contact, Via et Record-Route. Lors du traitement du trafic de retour, l’ALG réentère les champs SIP d’origine Contact, Via, Route et Record-Route dans les paquets.

Appels entrants

Les appels entrants sont lancés à partir du réseau public vers des adresses NAT statiques publiques ou vers des adresses IP d’interface sur l’équipement. Les NAT statiques sont des adresses IP à configuration statique qui pointent vers les hôtes internes ; les adresses IP d’interface sont enregistrées de manière dynamique par l’ALG, qui surveille les messages REGISTER envoyés par les hôtes internes au registrar SIP. Lorsque l’équipement reçoit un paquet SIP entrant, il définit une session et transfère la charge utile du paquet vers l’ALG SIP.

L’ALG examine le message de requête SIP (initialement une INVITATION) et, en fonction des informations du SDP, ouvre des portes pour les contenus multimédias sortants. Lorsqu’un message de réponse 200 OK arrive, le protocole SIP ALG exécute la règle NAT sur les adresses IP et les ports, puis ouvre des trous d’épingle dans la direction sortante. (Les portes ouvertes ont un temps de mise en service court et ils ont un temps d’ouverture si un message de réponse DE 200 OK n’est pas reçu rapidement.)

Lorsqu’une réponse 200 OK arrive, le proxy SIP examine les informations SDP et lit les adresses IP et les numéros de port pour chaque session multimédia. L’ALG SIP de l’unité exécute la fonction NAT sur les adresses et les numéros de ports, ouvre des trous d’épingle pour le trafic sortant et actualise le délai d’expiration pour les portes dans la direction entrante.

Lorsque l’ACK arrive pour le 200 OK, il passe également par l’ALG SIP. Si le message contient des informations SDP, l’ALG SIP s’assure que les adresses IP et les numéros de port ne sont pas modifiés par rapport à l’INVITATION précédente. Le cas échéant, l’ALG supprime les anciens trous d’épingle et crée de nouveaux trous d’épingle pour permettre au support de passer. L’ALG surveille également les champs SIP Via, Contact et Record-Route et ouvre de nouveaux trous d’épingle s’il détermine que ces champs ont changé.

Appels transféré

Un appel transféré est, par exemple, lorsque l’utilisateur A à l’extérieur du réseau appelle l’utilisateur B à l’intérieur du réseau, et l’utilisateur B transfère l’appel à l’utilisateur C à l’extérieur du réseau. Le SIP ALG traite l’INVITATION de l’utilisateur A comme un appel entrant normal. Mais lorsque l’ALG examine l’appel transféré de B à C à l’extérieur du réseau et remarque que B et C sont atteints à l’aide de la même interface, il n’ouvre pas de trous d’épingle dans le pare-feu, car le support circule directement entre l’utilisateur A et l’utilisateur C.

Terminaison d’appel

Le message BYE met fin à un appel. Lorsque l’équipement reçoit un message BYE, il traduit les champs d’en-tête comme il le fait pour n’importe quel autre message. Mais comme un message BYE doit être reconnu par le destinataire avec un 200 OK, l’appel ALG retarde pendant 5 secondes pour laisser le temps de transmission du 200 OK.

Messages de re-INVITE d’appel

Les messages de nouvelle INVITATION ajoutent de nouvelles sessions multimédias à un appel et suppriment les sessions multimédias existantes. Lorsque de nouvelles sessions multimédias sont ajoutées à un appel, de nouveaux trous d’épingle sont ouverts dans le pare-feu et de nouvelles liaisons d’adresses sont créées. Le processus est identique à la configuration d’appel d’origine. Lorsque toutes les sessions multimédias ou points d’épingle multimédia sont retirés d’un appel, l’appel est supprimé lors de la réception d’un message BYE.

Timers de session d’appel

Par mesure de précaution, l’ALG SIP utilise des valeurs de délai d’expiration difficiles pour définir la durée maximale d’un appel. Cela garantit la protection de l’équipement si l’un des événements suivants se produit :

• Les systèmes finaux se bloquent lors d’un appel et un message BYE n’est pas reçu.

• Les utilisateurs malveillants n’envoient jamais un BYE pour tenter d’attaquer un ALG SIP.

• Les implémentations médiocres du proxy SIP ne parviennent pas à traiter Record-Route et n’envoient jamais de message BYE.

• Les pannes réseau empêchent la réception d’un message BYE.

Annulation d’appel

Chaque partie peut annuler un appel en envoyant un message CANCEL. Une fois le message CANCEL reçu, le ALG SIP ferme les trous d’épingle par le pare-feu (le cas échéant) et met à jour les liaisons d’adresses. Avant de publier les ressources, l’ALG retarde l’âge du canal de contrôle pendant environ 5 secondes pour laisser passer le 200 OK final. L’appel est interrompu lorsque le délai d’expiration de 5 secondes expire, qu’une réponse 487 ou non soit arrivée.

Bifurquer

Forking permet à un proxy SIP d’envoyer simultanément un message d’INVITATION à plusieurs destinations. Lorsque les 200 messages de réponse OK multiples arrivent pour l’appel unique, l’analyse ALG SIP, mais met à jour les informations d’appel avec les 200 premiers messages OK qu’il reçoit.

SIP Messages

Le format du message SIP se compose d’une section d’en-tête SIP et du corps sip. Dans les messages de demande, la première ligne de la section d’en-tête est la ligne de requête, qui comprend le type de méthode, l’URI de requête et la version du protocole. Dans les messages de réponse, la première ligne est la ligne d’état, qui contient un code d’état. Les en-têtes SIP contiennent des adresses IP et des numéros de port utilisés pour la signalisation. Le corps SIP, séparé de la section d’en-tête par une ligne blanche, est réservé aux informations de description de session, ce qui est facultatif. Junos OS prend actuellement en charge le SDP uniquement. Le corps SIP contient les adresses IP et les numéros de ports utilisés pour transporter le support.

En-têtes SIP

Dans l’exemple de message de requête SIP suivant, nat remplace les adresses IP dans les champs d’en-tête pour les masquer du réseau externe.

La traduction d’adresse IP est effectuée en fonction du type et de la direction du message. Un message peut être l’un des éléments suivants :

• Requête entrante

• Réponse sortante

• Requête sortante

• Réponse entrante

Le tableau 1 illustre l’exécution de la traduction d’adresses réseau (NAT) dans chacun de ces cas. Notez que pour plusieurs des champs d’en-tête, l’ALG détermine plus que simplement si les messages viennent de l’intérieur ou de l’extérieur du réseau. Il doit également déterminer le client qui a lancé l’appel et s’il s’agit d’une requête ou d’une réponse.

Corps SIP

Les informations SDP du corps SIP incluent des adresses IP que l’ALG utilise pour créer des canaux pour le flux multimédia. La traduction de la section SDP alloue également les ressources, c’est-à-dire les numéros de port à envoyer et à recevoir le support.

Les extraits suivants d’un exemple de section SDP affichent les champs traduits pour l’allocation des ressources.

Les messages SIP peuvent contenir plusieurs flux multimédias. Le concept est similaire à la connexion de plusieurs fichiers à un message électronique. Par exemple, un message INVITE envoyé d’un client SIP à un serveur SIP peut comporter les champs suivants :

Junos OS prend en charge jusqu’à 6 canaux SDP négociés pour chaque direction, pour un total de 12 canaux par appel. Pour plus d’informations, consultez Understanding the SIP ALG.

Scénario NAT SIP

Les figures 2 et 3 affichent une INVITATION d’appel SIP et 200 OK. Sur la Figure 2, le ph1 envoie un message SIP INVITE au ph2. Notez la manière dont les adresses IP des champs d’en-tête (indiquées dans la police en gras) sont traduites par l’équipement.

La section SDP du message INVITE indique où l’appelant est disposé à recevoir des contenus multimédias. Notez que le trou d’épingle multimédia contient deux numéros de port, 52002 et 52003, pour RTCP et RTP. Le trou d’épingle Via/Contact fournit le port 5060 pour la signalisation SIP.

Observez comment, dans le message de réponse 200 OK de la figure 3, les traductions effectuées dans le message INVITE sont inversées. Les adresses IP de ce message, étant publiques, ne sont pas traduites, mais des passerelles sont ouvertes pour permettre au flux multimédia d’accéder au réseau privé.

Figure 2 : NAT SIP Scénario 1

Figure 3 : NAT SIP Scénario 2

Classes de réponses SIP

Les réponses SIP fournissent des informations sur l’état des transactions SIP et incluent un code de réponse et une expression de raison. Les réponses SIP sont regroupées dans les classes suivantes :

• Information (100 à 199) : demande reçue, suite au traitement de la demande.

• Réussite (200 à 299) : action reçue, comprise et acceptée avec succès.

• Redirection (300 à 399) : actions supplémentaires requises pour terminer la demande.

• Erreur client (400 à 499) : la requête contient une syntaxe incorrecte ou ne peut pas être satisfaite sur ce serveur.

• Erreur de serveur (500 à 599) : le serveur n’a pas répondu à une demande apparemment valide.

• Échec global (600 à 699) : la demande ne peut être satisfaite sur aucun serveur.

Le tableau 2 fournit une liste complète des réponses SIP actuelles.

Mode NAT en mode IPv6 pur (NAT66) pour SIP ALG IPv6

L’ALG SIP IPv6 prend en charge NAT66 tout comme NAT44. Le NAT66 (NAT IPv6) fournit des fonctions NAT source et NAT statiques similaires à NAT44 (NAT IPv4).

NAT-PT

La traduction des adresses réseau (NAT-PT) (RFC 2766) est un mécanisme de traduction de protocole qui permet la communication entre les nœuds IPv6 uniquement et les nœuds IPv4 uniquement par le biais de la traduction indépendante du protocole des datagrammes IPv4 et IPv6, ne nécessitant aucune information d’état pour la session.

Nat-PT est implémenté par NAT normal d’une adresse IPv6 à une adresse IPv4 et vice versa. L’ALG SIP traite les traductions d’adresses dans la charge utile tout comme les adresses sont traitées dans un NAT normal.

Nat-PT lie les adresses du réseau IPv6 avec les adresses du réseau IPv4, et vice versa pour fournir un routage transparent pour les datagrammes traversant les domaines d’adresses.

L’avantage principal de NAT-PT est que les équipements finaux et les réseaux peuvent exécuter des adresses IPv4 ou IPv6 et le trafic peut être démarré de n’importe quel côté.

NAT64

Le nat64 est un mécanisme permettant aux hôtes IPv6 de communiquer avec les serveurs IPv4. La règle NAT64 est requise pour conserver le mappage d’adresses IPv6/IPv4. Ce mappage d’adresses est soit configuré de manière statique par l’administrateur système (traduction sans état), soit plus fréquemment, créé automatiquement lorsque le premier paquet du réseau IPv6 atteint le NAT64 pour être traduit (dynamique).

LE NAT64 est implémenté sur les équipements à l’aide d’un NAT persistant. Lorsque le premier message de requête SIP (le premier paquet doit être uniquement issu d’IPv6) transverse le DUT, la liaison d’adresse est créée, puis les paquets peuvent circuler dans les deux directions.

Le mécanisme NAT64 traduit les paquets IPv6 en paquets IPv4 et vice versa, ce qui permet aux clients IPv6 de contacter les serveurs IPv4 à l’aide d’UDP, TCP ou ICMP unicast. Les comportements NAT-PT et NAT64 semblent similaires, mais ces mécanismes sont implémentés différemment.

Lorsque NAT64 avec NAT persistant est implémenté, la prise en charge de SIP ALG avec IPv6 ajoute la traduction NAT à la table de liaison NAT persistante si nat est configuré sur l’adresse d’enregistrement. Étant donné que la traduction NAT persistante ne peut pas faire double emploi avec l’adresse configurée, la coexistence des nat66 et NAT64 configurés sur la même adresse n’est pas prise en charge.

Une seule liaison est créée pour la même adresse IP source.

STUN et SIP ALG

Session Traversal Utilities for NAT (STUN) est une solution permettant de faire fonctionner la VoIP via la traduction d’adresses réseau (NAT) et le pare-feu.

Auparavant, STUN fonctionnait sans le SIP ALG. Cela signifie que l’ALG SIP n’était pas impliqué lors de la configuration NAT persistante.

STUN peut coexister avec le SIP ALG et l’ALG SIP est impliqué lorsque la traduction d’adresses réseau (NAT) persistante est configurée.

Understanding Incoming SIP ALG Call Support Using the SIP Registrar and NAT

L’enregistrement SIP (Session Initiation Protocol) permet aux proxys SIP et aux serveurs de localisation d’identifier l’emplacement ou les emplacements auxquels les utilisateurs souhaitent être contactés. Un utilisateur enregistre un ou plusieurs sites de contact en envoyant un message REGISTER au registrar. Les champs To et Contact du message REGISTER contiennent l’adresse d’enregistrement URI (Uniform Resource Identifier) et un ou plusieurs URI de contact, comme illustré sur la figure 4. L’enregistrement crée des liaisons dans un service de localisation qui associe l’adresse d’enregistrement à l’adresse ou à l’adresse de contact.

L’équipement surveille les messages REGISTER sortants, effectue la traduction des adresses réseau (NAT) sur ces adresses et stocke les informations dans une table NAT entrante. Ensuite, lorsqu’un message d’INVITATION est reçu de l’extérieur du réseau, l’équipement utilise la table NAT entrante pour identifier l’hôte interne auquel acheminer le message INVITE. Vous pouvez tirer parti du service d’enregistrement de proxy SIP pour autoriser les appels entrants en configurant les pools NAT source de l’interface ou NAT sur l’interface de sortie de l’équipement. La fonction NAT source de l’interface est suffisante pour gérer les appels entrants dans un petit bureau, alors que nous recommandons de configurer des pools NAT source pour les réseaux plus grands ou un environnement d’entreprise.

Note:

La prise en charge des appels entrants à l’aide d’un NAT source d’interface ou d’un pool NAT source est prise en charge uniquement pour les services SIP et H.323. Pour les appels entrants, Junos OS prend actuellement en charge les protocoles UDP et TCP uniquement. La résolution des noms de domaine n’est pas prise en charge à l’heure actuelle. par conséquent, les URI doivent contenir des adresses IP, comme illustré sur la figure 4.

Figure 4 : Utilisation du registrar SIP