VoIP & NAT (2): Les différents types de NAT

Comme nous en discutions dans notre précédent post, l’introduction des NAT dans les réseaux actuels, si elle a résolu, du moins temporairement, le problème de la pénurie d’adresses IPv4, a par la même occasion engendré de nouvelles contraintes techniques pour un certain type de trafic, et plus particulièrement, en ce qui nous intéresse ici, en téléphonie sur IP (ToIP ou Telephony over IP). La prise en compte de ces nouvelles contraintes se repose sur la détermination du type de NAT que le trafic doit traverser. En effet, par un manque de cadre et d’orientation lors de leurs conceptions, leurs implémentations s’avèrent très disparates. Ce post vous décrit les différentes méthodes existantes permettant leur classification.

Les organismes de standardisation, IETF en tête, ont régulièrement tenté d’apporter une réponse simple à cette question. Au travers de la première spécification de STUN (protocole dont il sera question plus tard dans un futur post), l’IETF a tenté de catégoriser ces équipements sous 4 appellations différentes :

• Full Cone NAT
• Restricted Cone NAT
• Port-Restricted Cone NAT
• Symmetric NAT

Nos lecteurs familiers avec les télécoms et le problème des NAT ont déjà dû voir ces termes plus d’une fois. Ces termes, s’ils sont encore souvent considéré comme faisant référence, s’avèrent néanmoins vagues et perturbent la compréhension de certains cas de figure sortant de leur cadre. Cette terminologie ne correspond en effet qu’à une partie des types de NAT qu’il est possible de rencontrer au sein des réseaux actuels, amalgamant du même fait plusieurs fonctionnalités inhérentes aux NAT (association, filtrage, port, …)

L’IETF, partant de ce constat, a établit une nouvelle spécification permettant une définition exacte d’un NAT quel que soit le cas de figure et quelle qu’en soit l’implémentation. En effet, en traitant chaque fonctionnalité indépendamment, ces nouvelles définitions permettent de considérer tous les cas, même les plus improbables. Seul inconvénient à cela, il n’existe plus de terminologie courte tel que définit précédemment. Tout cela est bien beau, mais comment peut-on désormais définir quel type de NAT nous sépare du reste du monde ? Afin de comprendre cette problématique, abordons tout d’abord les principaux points qui vont nous intéresser ici, à savoir les types d’associations et les types de filtrages différents.

Les associations

Un NAT effectue une traduction d’une adresse privée vers une adresse publique. Toutefois, si ce comportement reste le même quel que soit le NAT considéré, certains détails l’altèrent sensiblement d’un cas sur l’autre.

Lorsque le client (la source) souhaite contacter un des serveurs (les destinations) montrés en exemple dans la représentation schématique ci-dessus, le NAT dispose de trois différentes méthodes pour gérer la traduction.

• Indépendante du point de terminaison (endpoint independant)

L’association effectuée ne se fait que sur la base de l’adresse et le port d’émission (X:x), sans prendre en compte la destination. De ce fait, si la source ne change pas, l’association restera toujours identique. Si tout ou partie (soit adresse et/ou port) de la source se trouve altérée, une association différente devra être utilisée.

Synthétiquement : pour un couple (X:x) donné, (X1:x1) ? (X2:x2) ? (Yn:yn)

Un NAT se comportant de cette manière respecte les recommandations de l’IETF.

• Dépendante de l’adresse de terminaison (address dependant)

A l’opposé du cas précédent, le NAT considère la destination lorsqu’il choisit quelle association utiliser. De ce fait, la moindre modification dans l’adresse de destination (et uniquement l’adresse) imposera au NAT de créer une nouvelle association. Bien évidemment, tout changement dans la source impliquera aussi une modification de l’association.

Synthétiquement, pour un couple (X:x) donné, (X1:x1) ? (X2:x2) ? Y1 ? Y2

• Dépendante de l’adresse et du port de terminaison (address and port dependant)

Le dernier cas de figure reprend les concepts du cas précédent, mais renforce encore la règle appliquée en envisageant aussi le port de destination lors du choix de l’association. De ce fait, seule une requête à destination de l’exacte même destination (adresse et port) est susceptible de réutiliser une association créée précédemment.

Synthétiquement, pour un couple (X:x) donné, (X1:x1) ? (X2:x2) ? (Y1:y1) ? (Y2:y2)  

Le filtrage

Traité distinctement des associations, la notion de filtrage va se charger de définir le comportement du NAT lorsqu’une requête venant de l’extérieur tente de traverser l’équipement. Considérons la représentation ci-dessous :

De manière similaire à ce qui a été définit pour les associations, le filtrage est aussi régit par 3 comportements différents.

• Indépendant du point de terminaison (endpoint independant)

Le NAT ne filtre que les requêtes en provenance du réseau public n’ayant pas comme destination le client X. Toute requête à destination d’un autre client n’ayant pas créé d’association au niveau du NAT est refusée. Toutefois, n’importe quel serveur Y peut contacter X par cette association.

Ce type de filtrage est recommandé par l’IETF dans une optique de transparence.

• Dépendant de l’adresse (address dependant)

Le NAT applique ici un mécanisme de filtrage simple, n’autorisant le trafic entrant que pour des adresses ayant au préalable été contactées par le client. De ce fait, si X contact Y1, seul Y1 sera en mesure de contacter X en retour. Si Y2 souhaite contacter X, ce dernier doit auparavant contacter le serveur pour créer une règle auprès du NAT quel que soit le type d’association, les deux fonctionnalités étant parfaitement indépendantes !

Si la sécurité est essentielle au réseau considéré, l’IETF recommande ce type de filtrage.

• Dépendant de l’adresse et du port (address and port dependant)

Similaire au cas précédent, il est aisé de savoir la différence fondamentale qui intervient ici : le port par lequel le serveur émet sa requête est aussi vérifié par le NAT. De ce fait, si le client contact le serveur Y1 sur un port y1, et que ce dernier essaie de lui répondre à partir d’un autre port (y2 par exemple), le NAT refusera le trafic. Dans le même ordre d’idée, le serveur Y2 ne pourra pas contacter X sauf si ce dernier a créé une permission au niveau du NAT pour lui.

Leur détermination

En pratique, la plupart des NAT ne respecte pas les recommandations décrites précédemment. Pire encore, certains équipements, selon la situation à laquelle ils se trouvent confrontés, vont modifier leur comportement dynamiquement. Les deux aspects du NAT dont il est fait question ici vont permettre de prendre en considération une grande majorité des cas de figure, des moins restrictifs aux plus « sécurisés ».

Dans un souci de clarifier les connaissances relatives à la nomenclature cone, le tableau ci-après la définit en fonction de ces deux aspects :

La détermination de ces types de NAT dans la pratique s’effectue grâce au dialogue entre un client et un serveur STUN. Pas d’inquiétudes toutefois : il n’est pas nécessaire de connaître le protocole STUN pour être en mesure d’appréhender ce qui suit : en se reposant sur les concepts énoncés précédemment, il est parfaitement possible de comprendre les procédures décrites ci-après.

Le protocole STUN se prète particulièrement bien à cet exercice, puisque lors du déploiement d’un serveur STUN, celui-ci est configuré de manière à « écouter » sur deux adresses et deux ports différents, c’est-à-dire qu’il peut recevoir des requêtes sur toutes les combinaisons de ces composants. Les différents tests possibles à partir de ces informations sont les suivants :

• TEST 1 : Le client émet une requête à destination de an:pn et le serveur répond à partir de ce couple. Ce test peut donc être effectué plusieurs fois, en utilisant chaque fois un couple différent (a1:p1 ; a2:p2 ; a1:p2 ; a2:p1).
• TEST 2 : Le client émet une requête à destination de an:pn et le serveur répond à partir de son couple a3-n:p3-n.
• TEST 3 : Le client émet une requête à destination de an:pn et le serveur répond à partir de son couple an:p3-n.

Puisque deux terminologies ont été décrites ci-dessus, il paraît logique qu’il existe au moins deux procédures différentes permettant de classifier les types de NAT. Il en existe en fait 3 qui nous intéressent vraiment dans le cadre des télécoms : la classification Classic STUN (RFC 3489), la classification BEHAVE (RFC 4787) et une classification particulière, spécifique à la voix sur IP. Chacune de ces procédures se repose sur les tests ci-dessus.

• Classic STUN (RFC 3489)

Cette méthode amalgame la notion d’association et de filtrage, ce qui se retrouve au sein de la procédure : chaque fois qu’un type de NAT est découvert à la suite d’un test, celui-ci définit les deux aspects en un passage. Les résultats sont par conséquents lacunaires, plusieurs combinaisons n’apparaissant pas (et ne pouvant pas apparaître sur la base de ces tests).

• BEHAVE (RFC 4787)

Cette procédure s’avère moins rapide, puisqu’elle requière un minimum de deux passages, mais offre de bien meilleurs résultats, couvrant l’intégralité des combinaisons association/filtrage. Les tests demeurent les mêmes, à la seule différence que seuls le premier test est utilisé dans le cadre de la détection de l’association.

• Spécifique à la VoIP

Ce dernier cas simplifie grandement les procédures ci-dessus. En effet, la VoIP ne nécessite pas une connaissance poussée du filtrage auquel le NAT procède. Sa principale considération concerne le type d’association. En effet, un client VoIP souhaite en être en mesure d’apprendre son adresse publique de manière à la transmettre à son destinataire. Le filtrage n’a qu’un rôle secondaire ici. De ce fait, un client souhaite savoir si son association est de type indépendante ou dépendante (quelle que soit la dépendance).

Une association indépendante signifie que le client pourra se reposer sur l’usage d’un simple serveur STUN pour apprendre son adresse publique alors qu’une association dépendante l’obligera à se servir d’un serveur relai.

Maintenant que le problème est posé, rendez-vous prochainement pour aborder les premières descriptions de solutions de traversée de NAT !