Lors de notre dernière incursion dans les méandres des NAT en VoIP, nous avions discuté de la méthode envisagée pour permettre aux réponses SIP (200 OK par exemple) d’atteindre leur cible. Il avait toutefois été noté qu’il était, en théorie, impossible de réutiliser ces informations dans le but d’acheminer des requêtes SIP (INVITE par exemple). L’IETF a de ce fait imaginé une méthode spécifique permettant aux requêtes distantes de contacter un client situé derrière un NAT : SIP-OUTBOUND. Alors que les attributs received et rport modifient les entêtes Via, cette méthode s’occupe d’altérer les informations contenues dans le Contact afin de pouvoir acheminer la requête correctement. Mais si elle se limitait à ceci, elle n’aurait que peu d’intérêts.
Le constat est simple : dans une transaction SIP, si les Via permettent d’acheminer les réponses à une requête, le Contact indique quelle entité doit être contactée dans le cadre d’une requête. Lorsqu’un client s’enregistre auprès de son proxy SIP, il doit par conséquent fournir des indications pertinentes, ce qui lui est impossible, étant derrière un NAT.
SIP-OUTBOUND offre une approche inédite, proposant une gestion du contact assez particulière, tout en y ajoutant une gamme de services intéressante. Ces fonctionnalités annexes étant intimement liées avec le contact, nous les aborderons au fur et à mesure.
Dans son principe, ce standard définit que les premiers proxy à recevoir une requête SIP (ils peuvent donc ne pas être le serveur de destination final) doivent stocker des flow tokens représentant la connexion avec le client, sous la forme d’un hash composé de l’adresse et port source et de destination (soit le couple adresse/port du NAT et leur propre couple adresse/port) ainsi que du protocole utilisé (TCP, UDP, TLS …). Exposé de cette manière, la différence avec les attributs received et rport ne semble pas flagrante…
En effet, cette spécification, en l’état, n’est pas réellement surprenante. Toutefois, il est intéressant de noter que l’IETF ne s’est pas contenté de définir ce mécanisme, mais propose par la même occasion une extension au protocole SIP en offrant notamment la possibilité d’effectuer de multiples enregistrement auprès du même serveur, chacun disposant d’un chemin différent entre le client et le serveur final (ou authoritative proxy). Chaque proxy frontalier (ou edge proxy) étant en mesure de stocker toutes les connexions d’un client, ce n’est au final qu’une question de pouvoir stocker et distinguer chacune d’entre elles, offrant par extension une redondance bienvenue.
Ceci n’est possible qu’au travers des éléments suivants :
- Les entêtes Path stockant un route pour une destination donnée.
- Le nouveau paramètre instance-id dans l’entête Contact permettant d’identifier un client de manière unique. Cet attribut est persistent à travers le temps et l’espace.
- Le nouveau paramètre reg-id de l’entête Contact permettant d’identifier, conjointement avec instance-id, une connexion, un enregistrement d’un client. Cet attribut, s’il est modifié à chaque nouvel enregistrement, doit remplacer ou mettre à jour les enregistrements précédents.
Grâce à ces informations, un client maintien un contact avec son authoritative proxy et ce, même si un proxy frontalier venait à tomber. Cette redondance est par la même occasion utile aussi dans le sens contraire, lorsqu’un hôte distant souhaite contacter notre client.
Il reste un dernier point que cette spécification prend en considération : elle maintient les associations et les permissions de filtrage des NAT ouverts ! En effet, ces derniers, dans un souci de sécurité, clôturent automatiquement les connexions ouvertes lorsque plus aucun trafic n’est détecté pendant un certain laps de temps. Deux méthodes sont introduites ici permettant d’empêcher ce comportement :
- Ping Pong
Utilisable dans le cadre de connexions TCP uniquement, le client émets un paquet dont le seul contenu est un double retour à la ligne (2x CR LF, ou Carriage Return, Line Feed) à destination du premier proxy SIP sur le chemin. Lorsque ce paquet traverse le NAT, ce dernier renouvelle à la fois la permission et l’association. Le serveur, sur réception d’un tel message, répond instantanément avec un simple CR LF, signifiant une bonne réception au client.
- Ping STUN
Au contraire du cas précédent, celui-ci n’est utilisable que dans le cadre de sessions UDP. Il se repose sur une utilisation particulière du protocole STUN, protocole dont nous discuterons plus en détails dans notre prochain billet portant sur la VoIP et les NAT. Dans le cas présent cependant, et à condition que l’infrastructure le permette : proxy SIP muni d’un serveur STUN compatible et écoutant sur le même port que SIP (5060 par défaut). Si le client reçoit une réponse STUN valide après avoir envoyé sa requête, il peut raisonnablement considérer que son NAT a été renouvelé en conséquence.
SIP-OUTBOUND est un protocole complexe qui reste à l’heure actuelle ignoré des acteurs de l’industrie. Malgré les avantages certains qu’il apporte, sa complexité et sa disparité avec ce qui existe à l’heure actuelle le rendent obscur.
Lors du prochain article relatif aux NAT, il sera question d’un protocole majeur dans le monde de la VoIP, dont il a déjà été un peu question ici : STUN. Son implication et son importance au sein des réseaux téléphoniques numériques modernes a toutes les chances pour prendre de l’ampleur à l’avenir. So, stay tuned !