Tecniche e protocolli per l’attraversamento di

NAT (Network Address Translator)

Corso di Applicazioni TelematicheA.A. 2010-11

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

10.0.0.1

10.0.0.2

10.0.0.3

S: 10.0.0.1, 3345D: 128.119.40.186, 80

110.0.0.4

138.76.29.7

1: host 10.0.0.1 sends datagram to 128.119.40.186, 80

NAT translation tableWAN side addr LAN side addr

138.76.29.7, 5001 10.0.0.1, 3345…… ……

S: 128.119.40.186, 80 D: 10.0.0.1, 3345 4

S: 138.76.29.7, 5001D: 128.119.40.186, 802

2: NAT routerchanges datagramsource addr from10.0.0.1, 3345 to138.76.29.7, 5001,

updates table

S: 128.119.40.186, 80 D: 138.76.29.7, 5001 3

3: Reply arrivesdest. address:

138.76.29.7, 5001

4: NAT routerchanges datagram

dest addr from138.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?

“my address is 10.1.1.1” Internet sees 161.44.1.1

Internet

7

Tipi di NAT (RFC 4787)

Mapping

• Endpoint-Independent

• Address-Dependent

• Address and Port-

Dependent

Filtering

• Endpoint-Independent

• Address-Dependent

• Address and Port-

Dependent

Rest

rict

ive

P

erm

issi

ve

8

Tipi di NAT (RFC 3489, obsoleta)

• Full Cone

• Restricted Cone

• Port Restricted Cone

• Symmetric

Rest

rict

ive Perm

issi

ve

9

Indirizzo server-reflexive

• L’indirizzo IP ed il numero di porta “pubblici” costituiscono il cosiddetto server-reflexivetransport address

• 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

Private Public 192.168.1.123:1234 <---> 143.225.229.212:5678

10

Full Cone NAT

• Qualunque pacchetto proveniente dall’esterno e

indirizzato all’indirizzo server-reflexive di A

viene inoltrato

A

B

C

P1

P2

P1

P2

P1

P2

P3

FC NAT

11

Restricted Cone NAT

• Solo i pacchetti provenienti dall’indirizzo IP dell’hostcontattato in precedenza (B) e indirizzati all’indirizzo server-reflexive 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

A

B

C

P1

P2

P1

P2

P1

P2

P3

RC NAT

12

Port Restricted Cone NAT

• Solo i pacchetti provenienti dall’indirizzo IP dell’hostcontattato in precedenza (B) e indirizzati all’indirizzo server-reflexive 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

A

B

C

P1

P2

P1

P2

P1

P2

P3

PRC NAT

13

Symmetric NAT

• Solo i pacchetti provenienti dall’indirizzo IP dell’hostcontattato in precedenza (B) e indirizzati all’indirizzo server-reflexive 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

A

B

C

P1

P2

P1

P2

P1

P2

P3

P8

S NAT

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 headerContact, 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, …

10.1.1.1:1234

Internet

161.44.1.1:5678NAT + ALG

18

Problemi con gli ALG

• È necessario un ALG diverso per ogniapplicazione

• 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 daun attacco MITM

• Errori nell’implementazione dell’ALG possonocausare 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 portosorgenti, 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 server-reflexive, 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

231-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-handshakedi 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 step6!

• 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 call-setup

• 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