Lors de nos différents articles relatifs aux solutions de traversée de NAT, nous avons détaillés les approches proposées par l’IETF (received/rport, SIP-OUTBOUND, STUN, TURN, ICE) et étant par conséquent normalisées. Ces protocoles, s’ils offrent ensemble une approche complète, efficace et évolutive, sont malheureusement pour la plupart très récents : les acteurs de l’industrie (opérateurs, intégrateurs, …) ont dû trouver des solutions qui leur ouvraient l’utilisation de SIP/RTP dans le cadre de la voix sur IP. Plusieurs solutions existent à ce niveau, mais la plus commune à l’heure actuelle est caractérisée par les ALG (Application Level Gateways) et, de manière plus spécifique, les SBC (Session Border Controllers).
Ces deux méthodes, dans le cadre de la traversée de NAT, propose une approche relativement similaire. Elles partent toutes deux de l’idée que puisque le NAT met à mal le fonctionnement, pourquoi ne pas tenter de modifier les informations éventuellement contenues au niveau applicatif afin de les adapter en conséquence ?
Un NAT muni d’une ALG va remonter jusqu’au niveau applicatif lorsque certains protocoles ou trafics sont détectés (SIP notamment, mais pas seulement, FTP par exemple est aussi impacté). Par sa conception même en effet, un NAT n’a aucune notion du type d’application transitant, il ne se préoccupe que des informations liées au réseau (adresses IP et port notamment). L’ALG rajoute une couche supplémentaire apportant de l’intelligence à un niveau applicatif, lui permettant en théorie de modifier de manière transparente les adresses IP et ports contenus dans le corps de l’application dans l’optique de refléter les informations publiques.
En théorie donc, le fonctionnement d’une ALG semble parfaitement légitime : modifier les données applicatives au moment où les informations réseaux sont aussi altérées. En pratique toutefois, les ALG que l’on peut trouver à l’heure actuelle au sein des routeurs NAT grand public (mais pas seulement) ne disposent pas d’une implémentation correcte. En effet, il n’est pas rare que ces équipements aient des capacités relativement limitées, et ces services s’avèrent relativement lourds d’un point de vu des ressources. De ce fait, ces équipements récupèrent bien souvent des ALG génériques modifiant indistinctement toutes les adresses IP et ports contenus dans les données applicatives, sans chercher à comprendre ce qui se passe réellement.
Dans l’idéal, chacun de ces équipements se devrait de recevoir une pile SIP (dans le cas qui nous intéresse ici) complète, qui lui permettrait de comprendre les messages et d’être en mesure d’altérer les bonnes adresses IP et les bons ports, ce qui n’est malheureusement pas assez souvent le cas actuellement. A tel point que les ALG en tant que telles doivent, selon l’IETF, être totalement désactivées des NAT de manière à permettre à des méthodes plus efficaces de faire le office correctement. En effet, puisque ces ALG modifient parfois indifféremment le contenu applicatif, certains protocoles de traversée de NAT (par exemple Classic STUN qui contient l’adresse IP et port publics en « clair » dans sa réponse) se trouveront aussi modifiés…
Pourquoi ne pas mettre à jour ces ALG ? Tout simplement car les intégrateurs ne voient pas l’intérêt de maintenir ces équipements (grand public généralement), préférant se focaliser sur de nouveau équipements, et ainsi de suite. De là ressort une idée plus spécifique, sous la forme de SBC (Session Border Controllers) qui fonctionne en pratique comme une ALG (du moins pour la traversée de NAT), tout en apportant une approche plus évolutive, notamment par un support de plus longue durée des solutions proposées.
Quelle est alors la différence entre une simple ALG et un SBC ? La grosse différence entre ces deux méthodes se trouve essentiellement au niveau de la gamme de services implémentée : alors que l’ALG se focalise exclusivement sur la traversée de NAT, le SBC est capable de fournir des services supplémentaires, comme par exemple le contrôle d’appel, la facturation, etc. Toutefois au niveau de la traversée de NAT plus spécifiquement, un SBC n’est au final qu’une ALG très développée, munie d’une pile SIP (par exemple) efficace. Malheureusement, aucun standard ne formalise les fonctionnalités qu’un SBC se devrait de contenir. Par conséquent chaque intégrateur de SBC est libre d’effectuer des déploiements en fonction des demandes de leurs clients.
Et le problème se situe à ce niveau-là : les SBC sont des équipements high-end dont le développement et le déploiement est extrêmement compliqué. Cela reste par conséquent un marché de niche, très apprécié des grosses entreprises disposant de moyens conséquents :
- Compétences rares donc chères.
- Dimensionnement critique, toutes les communications étant traitées par le SBC.
- Chiffrement complexe, mettant à mal les performances de l’équipement.
- Pas standardisé, impliquant un manque de transparence.
- Empêche (à dessein ou non) l’utilisation de protocoles normalisés (STUN/TURN/ICE notamment).
Les opérateurs sont très friands de ces équipements qui leur offrent, malgré leur coût, un niveau de service leur permettant de garder la main sur les communications VoIP, leur permettant par la même occasion de respecter leurs obligations légales (écoute, urgences, …). Dans le cadre des nouveaux réseaux, et plus particulièrement dans le cadre de l’IMS (pouvant être intégré aux P-CSCF par exemple), l’utilisation de SBC peut s’avérer critique (contrôle d’appel, facturation, …), et il n’existe à l’heure actuelle pas d’équipement similaire leur permettant leur remplacement ou leur abandon.
Malgré cela, les mêmes limitations existent que pour les ALG : si une fonctionnalité d’un protocole n’est pas supportée par le SBC, ce dernier mettra a mal le fonctionnement dudit protocole, et nécessitera une mise à jour parfois complexe que les intégrateurs ne souhaitent parfois pas envisager (trop compliqué, trop long, pas assez d’avantages à implémenter une telle fonctionnalité, …).
Le marché des SBC est très mouvant, et il existe de nombreux acteurs dont peut arrivent à survivre sur le long terme (rachat, …). Il existe toutefois des grands noms qui disposent de leurs implémentations, dont par exemple Acme Packet, Cisco (CUBE), Juniper Networks, etc. L’usage des SBC est sujet à une controverse persistante, partagée bien souvent entre les opérateurs (pour qui ces équipements sont très intéressants) et les supporteurs des standards de l’IETF pour qui cette solution met à mal trop de protocoles… Les opérateurs ayant bien souvent la mainmise sur les infrastructures, et par conséquent sur les technologies et protocoles à utiliser, les SBC semblent avoir encore un bel avenir devant eux, malgré leur limitations et leur manque de normalisation.
Si les SBC offrent une solution très appréciée des grosses entreprises, ils requièrent des connaissances et compétences très spécifiques, restreignant leur marché et leurs cibles. Il existe toutefois des méthodes industrielles plus accessibles, permettant la traversée de NAT de manière efficace et à moindre coût. Ces solutions « empiriques » sont nombreuses puisque pratiquement tous les proxys SIP et les soft switch (Asterisk, FreeSWITCH) proposent leur propre approche du problème. Notre prochain article abordera non pas toutes ces solutions, mais en choisira une, performante et évolutive, sous la forme du proxy SIP OpenSIPS qui offre une approche assez intéressante du problème.