la traversée de nat en voip sip - .over internet protocol) sont particulièrement affectés,...

Download La traversée de NAT en VoIP SIP - .over Internet Protocol) sont particulièrement affectés, notamment

Post on 12-Sep-2018

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • La traverse de NAT en VoIP SIPBest Current Practice

    O. Gremaud

    20 juin 2012

    c2012 NEXCOM SystemsCe document ne peut tre copi ou reproduit sans laccord crit exprs de NEXCOM Systems

  • TABLE DES MATIRES

    Table des matires

    Introduction 1

    Caractrisation des NAT 2Le type de translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Le type de filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Le choix du port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

    Traverse de NAT : Best Current Practice 5Signalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

    Les rponses SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Les invitations SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

    Flux multimdias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Direction des flux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Contigit des ports RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . 9STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

    Mise en situation 19Lenregistrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Protocoles orients connexion (TCP) . . . . . . . . . . . . . . . . . . . . . 20

    Ltablissement de session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Initie par le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Recevoir linvitation une session . . . . . . . . . . . . . . . . . . . . . . . 22

    Interactive Connectivity Establishment . . . . . . . . . . . . . . . . . . . . . . . 23Lchange des candidats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23La cration des paires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Les tests de connectivit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Choix de la paire finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

    Conclusion 30

    Annexes 31[A] Correspondance RFC3489 et RFC4787 . . . . . . . . . . . . . . . . . . . . . 31[B] Authentification TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

    Rfrences 32

    c2005-2012 NEXCOM Systems i

  • TABLE DES FIGURES

    Table des figures

    1 Problmatique gnrale des NAT . . . . . . . . . . . . . . . . . . . . . . . 12 Type de translation/association . . . . . . . . . . . . . . . . . . . . . . . . 23 Type de filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Consistence des dfinitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Choix des ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Echec de rponse SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Rponse symtrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Echec dinvitation SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Contact et Flow Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710 Topologie OutBound complexe . . . . . . . . . . . . . . . . . . . . . . . . 811 Keepalives TCP/UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812 RTP symtrique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913 Contigit RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1014 Mcanismes de STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1115 Retransmissions STUN (algorithme de Karn) . . . . . . . . . . . . . . . . 1116 Mcanismes de TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1217 Permissions TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318 tapes dICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1419 Types de candidats ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520 change des candidats ICE . . . . . . . . . . . . . . . . . . . . . . . . . . 1621 Mcanismes des tests de connectivit . . . . . . . . . . . . . . . . . . . . . 1722 Enregistrement en UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1923 Enregistrement en TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2024 Session initie par le client . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125 Rception dune invitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2226 Echange des candidats en SDP . . . . . . . . . . . . . . . . . . . . . . . . 2327 Latence introduite par ICE . . . . . . . . . . . . . . . . . . . . . . . . . . 2428 Gnration des paires de candidats . . . . . . . . . . . . . . . . . . . . . . 2529 Tests host et relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2530 Combinaisons de NAT et rsultats . . . . . . . . . . . . . . . . . . . . . . 2631 Combinaisons 1B:3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2632 Combinaisons 2D:2F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2733 Combinaisons 4C:6C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2934 Authentification TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

    c2005-2012 NEXCOM Systems ii

  • INTRODUCTION

    Introduction

    Les NAT, en marge dapporter une solution temporaire la pnurie latente dadressesIPv4, ont apport leur lot de problmes. Les protocoles de voix sur IP (VoIP ou Voiceover Internet Protocol) sont particulirement affects, notamment SIP (Session Initia-tion Protocol [1]), SDP (Session Description Protocol [2]) et RTP (Real-time TransportProtocol [3]). Ce document fait ltat de la pratique actuelle appliquer en priorit dansle cadre du dploiement dune solution de traverse de NAT 1.

    Lobjectif de SIP est de rcuprer lensemble des informations ncessaires ltablisse-ment dune connexion entre deux terminaux. partir de ces renseignements, les quipe-ments apprennent quel chemin emprunter afin de contacter un destinataire spcifique. Ilest alors possible dutiliser SIP pour de nombreux usages, avec en tte les applicationstemps-rel (tlphonie, visiophonie . . .) grce SDP (paramtres de connexion des fluxRTP).

    Fig. 1 Problmatique gnrale des NAT

    La Figure 1 ci-dessus dcrit, dans les grandes lignes, le problme qui va se poser avec latraverse de NAT. Ceux-ci ne travaillent en effet quau niveau des premires couches dela pile rseau. De ce fait, toutes les informations transportes un niveau applicatif neseront pas altres, empchant le bon fonctionnement dans ltablissement des sessionset des communications audio/vido 2.

    Cette problmatique, plus subtile quelle nen a lair, peut tre fragmente en de mul-tiples aspects bien distincts pour lesquels des solutions ddies existent. Toutefois, avantdaborder ces lments plus en dtails, les NAT et leurs comportements doivent tredfinis de manire claire afin de pouvoir y apporter les solutions appropries.

    1. Si cette approche est ici traite dans loptique de la VoIP, elle ne se limite pas ce cas de figure,et peut tre tendue et/ou adapte dautres protocoles (FTP, . . .).

    2. Les ALG (Application Level Gateways) tentent dapporter une intelligence de niveau applicatifaux NAT. Leurs implmentations apportent toutefois plus de problmes quelles nen rsolvent, et sontdonc proscrire.

    c2005-2012 NEXCOM Systems 1

  • CARACTRISATION DES NAT

    Caractrisation des NAT

    Pendant longtemps, aucune dfinition nexistait permettant de catgoriser le comporte-ment des NAT. LIETF a tent, avec la premire version de STUN [4], dy apporter desdfinitions simples, connues actuellement sous le nom de terminologie CONE (full cone,restricted cone, port-restricted cone et symmetric NAT). Il sest toutefois avr que sices dfinitions couvraient une majorit des NAT disponibles, il tait impossible de dfinirlensemble de leurs comportements de manire aussi simple.

    Une nouvelle dfinition, plus prcise et donc privilgier, a t cre dans ce but. Ces d-finitions, connues sous le nom de terminologie BEHAVE [5][6], traitent sparment cha-cune des fonctions dun NAT (translation, filtrage . . .) 3. Trois aspects essentiels prennentune part importante en VoIP : Le type de translation, spcifiant le comportement du NAT pour le trafic sortant. Le type de filtrage, spcifiant le comportement du NAT pour le trafic entrant. La slection du port externe, spcifiant la faon dont le port est choisi pour le trafic

    sortant.

    Le type de translation

    Deux catgories principales existent lorsquil est question du type de translation effectu.Une translation peut en effet tre faite en fonction du destinataire (endpoint dependant)ou non (endpoint independant), comme dcrit dans la Figure 2 ci-dessous.

    Fig. 2 Type de translation/association

    Dans le cadre dune translation indpendante du destinataire, un client C sera traduitde la mme faon, quil tente de joindre le serveur S1 ou S2. Seul un changement auniveau de la source, que ce soit ladresse IP ou le port, modifiera lassociation faite parle NAT. Tant que le client utilise systmatiquement le mme couple adresse IP/port, ilsera toujours traduit de la mme faon par le NAT. Il est recommand pour un NAT de

    3. Pour une correspondance entre les deux nomenclatures, cf. Annexe [A] Correspondance RFC3489et RFC4787, page 31.

    c2005-2012 NEXCOM Systems 2

  • CARACTRISATION DES NAT

    disposer dun tel comportement, qui facilite le travail des solutions de traverse de NATdoffrir une efficacit accrue 4.

    loppos, une translation dpendante de la destination imposera au NAT de crer unenouvelle association ds que la destination change, que ce soi