Corso di Applicazioni Telematiche

Tecniche e protocolli per l attraversamento di NAT (Network Address Translator) Corso di Applicazioni Telematiche A.A. 2009-10 Prof. Simon Pietro Romano Università degli Studi di Napoli Federico II Facoltà di Ingegneria

Outline NAT: Network Address Translation Problemi legati all utilizzo dei NAT in reti VoIP Protocolli standard per NAT-traversal STUN TURN ICE 2

NAT: Network Address Translation Network Address Translation (RFC 3022) consente ad un dispositivo di agire come intermediario tra Internet (rete pubblica) e una rete privata In questo modo, un unico indirizzo IP può rappresentare un intero gruppo di computer Aiuta a preservare gli indirizzi IPv4 3

NAT L uso più comune del NAT è quello di mappare un insieme di indirizzi privati su di un unico indirizzo pubblico, utilizzando differenti porti per mantenere traccia delle diverse connessioni Per-flow stateful 4

NAT Quando il router riceve un pacchetto inviato da un computer della rete privata ad un computer esterno, salva in una tabella l indirizzo e il porto del mittente, oltre ai nuovi valori che esso assegna Tale tabella viene consultata anche quando il router riceve un pacchetto dal computer destinazione Le connessioni devono essere iniziate dall interno! 5

NAT: un esempio 2: NAT router changes datagram source addr from 10.0.0.1, 3345 to 138.76.29.7, 5001, updates table NAT translation table WAN side addr LAN side addr 138.76.29.7, 5001 10.0.0.1, 3345 S: 10.0.0.1, 3345 D: 128.119.40.186, 80 1: host 10.0.0.1 sends datagram to 128.119.40.186, 80 updates table 10.0.0.1 1 S: 138.76.29.7, 5001 2 D: 128.119.40.186, 80 10.0.0.4 S: 128.119.40.186, 80 D: 138.76.29.7, 5001 3 3: Reply arrives dest. address: 138.76.29.7, 5001 138.76.29.7 S: 128.119.40.186, 80 D: 10.0.0.1, 3345 4 10.0.0.2 10.0.0.3 4: NAT router changes datagram dest addr from 138.76.29.7, 5001 to 10.0.0.1, 3345 6

NAT Un NAT non è un proxy Approccio trasparente Le applicazioni sono in genere all oscuro della presenza di NAT Il NAT è in genere all oscuro del tipo di applicazione che genera i pacchetti Problema: che succede quando informazioni su indirizzi IP e/o numero di porto sono trasportate nel payload dei pacchetti? Internet my address is 10.1.1.1 Internet sees 161.44.1.1 7

Tipi di NAT (RFC 4787) Restrictive Permissive Mapping Endpoint-Independent Address-Dependent Address and Port- Dependent Filtering Endpoint-Independent Address-Dependent Address and Port- Dependent 8

Tipi di NAT (RFC 3489, obsoleta) Restrictive Permissive Full Cone Restricted Cone Port Restricted Cone Symmetric 9

Indirizzo server-reflexive L indirizzo IP ed il numero di porta pubblici costituiscono il cosiddetto server-reflexive transport address Private Public 192.168.1.123:1234 <---> 143.225.229.212:5678 Il binding è creato quando un pacchetto TCP SYN oppure il primo pacchetto UDP è inviato dalla rete interna Il binding è mantenuto fino a quando la connessione TCP o il flusso UDP sono vivi Il timeout di un flusso dipende dalle implementazioni 10

Full Cone NAT Qualunque pacchetto proveniente dall esterno e indirizzato all indirizzo server-reflexive di A viene inoltrato FC NAT P1 P2 B A P1 P2 P3 P1 P2 C 11

Restricted Cone NAT Solo i pacchetti provenienti dall indirizzo IP dell host contattato in precedenza (B) e indirizzati all indirizzo serverreflexive di A vengono inoltrati Se B invia pacchetti con porto sorgente diverso da quello su cui li riceve da A, questi vengono inoltrati ugualmente Se A invia pacchetti, dal medesimo porto sorgente, verso più destinazioni, questi vengono tutti mappati sullo stesso indirizzo server-reflexive RC NAT P1 P2 B A P1 P2 P3 P1 P2 C 12

Port Restricted Cone NAT Solo i pacchetti provenienti dall indirizzo IP dell host contattato in precedenza (B) e indirizzati all indirizzo serverreflexive di A vengono inoltrati Se B invia pacchetti con porto sorgente diverso da quello su cui li riceve da A, questi vengono scartati dal NAT Se A invia pacchetti, dal medesimo porto sorgente, verso più destinazioni, questi vengono tutti mappati sullo stesso indirizzo server-reflexive PRC NAT P1 P2 B A P1 P2 P3 P1 P2 C 13

Symmetric NAT Solo i pacchetti provenienti dall indirizzo IP dell host contattato in precedenza (B) e indirizzati all indirizzo serverreflexive di A vengono inoltrati Se B invia pacchetti con porto sorgente diverso da quello su cui li riceve da A, questi vengono scartati dal NAT Se A invia pacchetti, dal medesimo porto sorgente, verso più destinazioni, questi vengono tutti mappati su indirizzi server-reflexive diversi S NAT P1 P2 B A P1 P2 P3 P8 P1 P2 C 14

NAT & SIP I messaggi SIP trasportano informazioni su indirizzo IP e numeri di porto impiegati dallo User Agent che li genera Tali informazioni sono contenute in alcuni header SIP e nell eventuale payload SDP Tali informazioni sono necessarie sia per completare correttamente la fase di segnalazione, sia per instaurare correttamente i canali RTP Un NAT analizza (e modifica) esclusivamente l header di livello IP 15

Esempio di messaggio SIP/SDP 1. INVITE sip:206@192.168.0.30:10455 SIP/2.0 2. Via: sip/2.0/udp 192.168.0.154:5060;branch=z9hG4bKz9hG4bKf8e2c7ca 3. Via: SIP/2.0/UDP 192.168.0.24:5060 4. From: <sip:215@192.168.0.154>;tag=414d5646-ad-407469a8 5. To: <sip:206@192.168.0.154> 6. Contact:<sip:215@192.168.0.24> 7. Call-ID: 56460000-24692b04@192.168.0.24 8. Subject: sip phone call 9. CSeq: 2 INVITE 10. User-Agent: Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F3F 11. Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY 12. Max-Forwards: 70 13. Content-Type: application/sdp 14. Content-Length: 242 15. Record-Route: <sip:192.168.0.154:5060;maddr=192.168.0.154> 16. 17. v=0 18. o=215 1095587577 1095587576 IN IP4 192.168.0.24 19. s=sip Call 20. c=in IP4 192.168.0.24 21. t=0 0 22. m=audio 8004 RTP/AVP 0 8 18 96 23. a=rtpmap:0 PCMU/8000 24. a=rtpmap:8 PCMA/8000 25. a=rtpmap:18 G729/8000 26. a=rtpmap:96 telephone-event/8000 16

NAT & SIP: problemi Un peer che invia un messaggio SIP nei cui header Contact, From o To è riportato un indirizzo privato, potrebbe non essere in grado di ricevere messaggi di risposta o, in generale, di essere contattato Problema parzialmente risolto con l RFC 3581: An Extension to the Session Initiation Protocol for Symmetric Response Routing Se il body SDP contiene indirizzi privati, potrebbe risultare impossibile instaurare canali RTP bidirezionali per la trasmissione dei flussi multimediali È necessario un metodo per scoprire il proprio indirizzo server-reflexive e comunicarlo ai nodi remoti con cui si vuole comunicare 17

Application Layer Gateway (ALG) Introduce intelligenza all interno di un NAT, rendendolo consapevole dell applicazione che genera i pacchetti Modifica indirizzi IP e numeri di porto all interno del payload dei pacchetti Ogni applicazione richiede un apposito ALG FTP, SIP, RTSP, RealAudio, Internet 10.1.1.1:1234 NAT + ALG 161.44.1.1:5678 18

Problemi con gli ALG È necessario un ALG diverso per ogni applicazione L ALG va aggiornato ad ogni modifica o estensione dello standard Richiede che il protocollo non sia crittografato Un ALG opera come un man in the middle, pertanto è difficile distinguere il suo operato da un attacco MITM Errori nell implementazione dell ALG possono causare problemi piuttosto che risolverli! 19

STUN RFC 5389 Session Traversal Utilities for NAT (STUN) è un protocollo con cui un host può scoprire il proprio indirizzo server-reflexive Protocollo di tipo richiesta/risposta Può utilizzare sia UDP (più frequente) che TCP, porto 3478 Utilizzato da: STUN stesso, per apprendere indirizzi IP TURN, per configurare il server TURN ICE, per test di connettività Un server STUN è collocato nella Internet pubblica o nella rete di un ISP, qualora questi offra il servizio Una transazione STUN si articola nei seguenti passi: 1. L host nattato inizia una connessione con il server STUN, creando un binding nella tabella del NAT 2. Il server STUN riceve il messaggio e legge l indirizzo IP ed il porto sorgenti, che costituiscono l indirizzo server-reflexive 3. Il server STUN invia una risposta contenente, nel payload, tale indirizzo 20

STUN flow diagram 21

STUN Uno User Agent che conosce il proprio indirizzo serverreflexive, può inserirlo negli header SIP al posto del proprio indirizzo privato Lo stesso processo deve essere eseguito per i numeri di porto dei flussi RTP, contenuti nell SDP In generale, all atto di una chiamata un client SIP STUN- enabled eseguirà una transazione STUN per la segnalazione e altrettante transazioni quanti sono i media negoziati nell SDP Sebbene sia ampiamente diffuso ed effettivamente utile in molti scenari, il protocollo STUN risulta inefficace: In presenza di NAT simmetrici Quando entrambe le parti della comunicazione sono dietro allo stesso NAT 22

TURN RFC 5766 Per essere raggiungibile, un device dietro un NAT simmetrico può utilizzare un relay Traversal Using Relays around NAT (TURN) è un protocollo per comunicare con il relay (server TURN) Sfrutta il protocollo STUN Il server TURN è collocato al di là del NAT, o nella Internet pubblica o nella rete di un ISP, qualora questi offra il servizio Una transazione TURN si articola nei seguenti passi: 1. Un host nattato chiede al relay di allocare un indirizzo di trasporto pubblico e di inoltrare i pacchetti da/verso tale indirizzo 2. Il server TURN comunica l indirizzo allocato al client L indirizzo allocato dal server TURN è detto relayed address 23

TURN flow diagram 24

TURN È necessario richiedere un relayed address per la segnalazione e uno per ogni flusso RTP TURN garantisce la comunicazione in presenza di qualsiasi tipo di NAT Il binding nella tabella del NAT deve essere rinfrescato periodicamente Il server TURN è nel media path Richiede molta banda Aumenta la latenza (end-to-end delay/jitter) Solitamente è usato come ultima soluzione, quando tutte le altre falliscono o non sono disponibili 25

ICE RFC 5245 In generale, possono essere disponibili più indirizzi Host address Server-reflexive address Relayed address Tutti nella loro versione UDP e TCP! Ciascun indirizzo potrebbe essere inadeguato sotto particolari condizioni dell ambiente di rete È necessario un meccanismo per selezionare dinamicamente, tra quelli disponibili, un indirizzo che possa garantire la comunicazione: ICE! Interactive Connectivity Establishment (ICE) fornisce capacità di NAT-traversal per qualsiasi protocollo orientato alla sessione È efficace in presenza di qualsiasi tipo di NAT Una transazione ICE si articola in 6 passi: gathering, prioritising, encoding, offering&answering, checking, completing 26

Step 1: Gathering Prima di effettuare una chiamata, il chiamante colleziona tutti gli indirizzi IP e numeri di porto che potrebbero garantirgli la comunicazione, facendo anche uso di STUN e TURN. Ciascun indirizzo è definito candidate Host candidate Server-reflexive candidate Relayed candidate 27

Step 2 e 3: Prioritizing e Encoding Prioritising: a ciascun indirizzo collezionato si assegna un valore di priorità compreso tra 0 e 2 31-1 Encoding: lo UA costruisce un messaggio di INVITE; per ogni m-line presente nel body SDP, inserisce un attributo candidate per ogni indirizzo collezionato 28

Step 4: Offering & Answering L INVITE costruito è inviato al destinatario della chiamata Se il destinatario supporta ICE, esegue a sua volta i passi 1 e 2 e genera una risposta provvisoria La risposta provvisoria avrà un body SDP contenente i candidate del destinatario 29

Step 5: Checking Lo UA combina ogni suo candidate con tutti quelli dell altro, producendo una lista di candidate pairs A ciascun candidate pair viene assegnata una priorità pari alla somma delle priorità dei singoli candidate Per verificare se una coppia di candidate possa essere sfruttata per la comunicazione, ogni UA esegue una transazione STUN verso l altro, utilizzando gli indirizzi del candidate pair Gli stessi indirizzi IP e numeri di porto saranno eventualmente usati per la trasmissione dei flussi RTP 30

Step 6: Completing Al termine della fase precedente, lo UA avrà eletto una coppia di indirizzi Una delle parti, tipicamente il chiamante, genera un ultima transazione STUN verso l altro UA, confermando il candidate pair selezionato A questo punto, lo UA del destinatario può iniziare a far squillare il telefono Quando la chiamata è stabilita e il three-way-handshake di SIP è completato, il chiamante genera un re-invite al fine di aggiornare gli indirizzi IP ed i numeri di porto di default contenuti nell SDP Quest ultimo scambio di messaggi ha lo scopo di informare eventuali elementi ICE-unaware che si trovino nel path di segnalazione del percorso effettivo che seguiranno i flussi RTP 31

ICE ICE incrementa i ritardi dovuti alla fase di call setup Lo UA del destinatario inizia a squillare solo durante lo step 6! L aumento del ritardo, comunque, tende ad essere proporzionale alla complessità dello scenario Per una semplice chiamata tra due endpoint aventi indirizzo pubblico, ICE aggiunge un singolo RTT alla fase di callsetup L utilizzo di ICE riesce a garantire che, quando il destinatario risponderà alla chiamata, i flussi multimediali fluiranno correttamente in entrambe le direzioni Elimina di cosiddetti ghost ring 32

Domande? 33