seminario sul NAT traversal - the Netgroup at Politecnico di Torino

Transcript

Giugno 2008
Problematiche di NAT traversal
Livio Torrero
Netgroup
<[email protected]>
Problematiche di NAT traversal- 1
Copyright: si veda nota a pag. 2
Giugno 2008
Copyright note
These slides are protected by copyright and international treaties. The
title and the copyrights concerning the slides (inclusive, but non only,
every image, photograph, animation, video, audio, music and text) are the
author’s (see Page 1) property.
The slides can be copied and used by research institutes, schools and
universities affiliated to the Ministry of Public Instruction and the Ministry
of University and Scientific Research and Technology, for institutional
purpose, not for profit. In this case there is not requested any
authorization.
Any other complete or partial use or reproduction (inclusive, but not only,
reproduction on discs, networks and printers) is forbidden without written
authorization of the author in advance.
The information contained in these slides are believed correct at the
moment of publication. They are supplied only for didactic purpose and
not to be used for installation-projects, products, networks etc. However,
there might be changes without notice. The authors are not responsible
for the content of the slides.
In any case there can not be declared conformity with the information
contained in these slides.
In any case this note of copyright may never be removed and must be
written also in case of partial use.
Giugno 2008
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
delle caratteristiche
comportamentali dei NAT
Regole per avere NAT application
“friendly”
Come rilevo di essere dietro un NAT?
STUN
Come inoltro i pacchetti attraverso un
NAT? NAT traversal
Relay
Hole
punching
Caso di studio: SIP
Giugno 2008
Concetti base sui NAT
I Network Address Traslator effettuano la traduzione
di indirizzi e/o porte fra spazi di indirizzamento
differenti
gli indirizzi dell’uno possono essere inutilizzabili nell’altro
Es: indirizzi locali in spazio indirizzamento 1
I NAT:
Modificano gli indirizzi IP e/o le porte dei pacchetti
Mantengono informazioni di stato relativamente al mapping
fra gli spazi (binding cache)
Spazio di indirizzamento 1
(controllato dal NAT)
IP.src= X
port.src=xp
X:xp associato a
X’:xp’
(non controllato dal NAT)
IP.src=X’
port.src=xp’
Giugno 2008
Esempio
Rete privata
IP.src= 10.0.0.1
port.src=5060
10.0.0.1:5060
associato a
130.192.31.1:5080
Rete pubblica
IP.src=130.192.31.1
port.src=5080
130.192.31.2
I NAT permettono di risparmiare indirizzi
Gli
indirizzi IPv4 sono una risorsa preziosa
Grazie ai NAT solo chi accede alla rete pubblica ha
un IP pubblico
I NAT hanno avuto molto successo
Il
73,81% degli host sono posti dietro a NAT
Quanti hanno un access point? Contiene un NAT…
Giugno 2008
Problemi causati dai NAT
Alcune applicazioni si basano sull’invio di
messaggi contenti indirizzi e/o porte
Un
host dietro a NAT inserisce l’indirizzo che ha nel
suo spazio di indirizzamento: non è detto che sia
globalmente utilizzabile (es indirizzo locale)
I NAT sono disegnati per soddisfare il
paradigma client/server
Il
client sta nella rete gestita dal NAT
Le applicazioni peer-to-peer non funzionano
Ogni
nodo è sia client che server
Come raggiungo un server dietro il NAT?
Chi mi garantisce che l’indirizzo e la porta pubbliche
assegnate dal NAT non cambino nel tempo?
Giugno 2008
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
Regole per avere NAT “application
friendly”
STUN
NAT? NAT traversal
Relay
Hole
punching
Caso di studio: SIP
Giugno 2008
Classificazione dei NAT
BEHAVE è un working group di IETF
BEHAVE nell’RFC 4787 definisce le
caratteristiche di funzionamento dei NAT
Si
definiscono le caratteristiche più comuni dei NAT
Sulla base di queste caratteristiche, vengono
fornite regole per definire il comportamento
di NAT “application friendly”
Con
opportune tecniche di NAT traversal è possibile
host dietro NAT “application friendly” possono
scambiare pacchetti senza intermediari
Anche il peer-to-pee
Esame delle sole regole principali
Giugno 2008
Traduzione di porte e indirizzi: scenario
Un host dietro a NAT inizia ad inviare dati ad un host
esterno
Come si comporta il NAT rispetto al traffico uscente?
Come e in base a cosa associa un indirizzo/porta interno a un
indirizzo/porta esterno?
Dominio privato
?:?
10.0.0.1:5060
Giugno 2008
Traduzione di porte e indirizzi:
Endpoint independent mapping
Il mapping non cambia in base all’indirizzo di
destinazione
130.192.31.55:80
Dominio privato
130.192.31.15:5080
130.192.31.50:5060
130.192.31.15:5080
10.0.0.1:5060
Giugno 2008
Traduzione di porte e indirizzi:
address dependent mapping
Il NAT assegna all’host privato stesso IP pubblico e porta pubblica
l’indirizzo IP dell’host esterno contattato non cambia
130.192.31.55:5080
130.192.31.58:5080
130.192.31.55:5090
130.192.31.22:5090
10.0.0.1:5060
130.192.31.25:5080
Dominio privato
Dominio privato
130.192.31.25:5080
130.192.31.55:5080
130.192.31.25:5080
10.0.0.1:5060
Giugno 2008
Traduzione di porte e indirizzi :
address and port dependent mapping(1/2)
Il NAT assegna all’host privato stesso IP pubblico e porta pubblica
l’indirizzo IP e la porta dell’host esterno contattato non cambiano
130.192.31.55:5080
130.192.31.58:5090
130.192.31.55:5080
130.192.31.22:5090
10.0.0.1:5060
130.192.31.25:5080
Dominio privato
Dominio privato
130.192.31.25:5080
130.192.31.55:5090
130.192.31.22:5090
10.0.0.1:5060
Giugno 2008
Traduzione di porte e indirizzi: regola
Riassumendo:
independent mapping: si usa sempre lo stesso
mapping per tutte le destinazioni.
Address dependent mapping: si usa stesso mapping per
tutti i pacchetti inviati al medesimo IP esterno
Address and port dependent mapping: si riusa stesso
mapping per tutti i pacchetti inviati ai medesimi IP+porta
esterni
Endpoint
REGOLA 1: un NAT application “friendly” DEVE
avere un comportamento basato sull’endpoint
Independent Mapping.
Giugno 2008
Gestione dei binding: durata
Le traduzioni indirizzo/porta eseguite dal NAT sono dette binding
Memorizzate nella binding cache del NAT
REGOLA 2:
• NAT UDP binding DEVE durare almeno di 2 min
• Sessioni sulle porte da [1-1023] possono durare
meno
•Il timer di durata deve essere configurabile
•5 minuti = valore raccomandato
Tipicamente le sessioni sulle well-known port sono di tipo
richiesta/risposta su UDP
Tenerne i binding a lungo è solo overhead
Giugno 2008
Gestione dei binding: keepalive
Per mantenere un binding sul NAT, è sufficiente fare traffico
(keepalive)
Si deve garantire il transito di pacchetti prima dello scadere del timer
NAT outbound refresh: keep-alive mandati da host
privato verso l’esterno.
NAT inbound refresh: keep-alive mandati dall’esterno
verso l’host privato.
Alcuni NAT consentono i keep-alive in entrambe le
direzioni
REGOLA 3: un NAT “application friendly” deve
avere il NAT outbound refresh attivo. Può
eventualmente avere il NAT Inbound Refresh
attivo.
Giugno 2008
Politiche di filtering
I NAT comunemente implementano anche delle
politiche di filtraggio del traffico diretto agli host da
loro controllati
I NAT come rudimentali meccanismi di sicurezza
Con le policy di mapping il NAT “mimetizza” gli host
Se cambio il mapping per ogni destinazione nessuno localizzerà
l’host protetto
Attraverso le policy di filtering il NAT limita il
traffico verso la sua rete
Utile
per impedire attacchi da fuori
Giugno 2008
Politiche di filtering: scenario
Prima di tutto host A crea una sessione mandando un
pacchetto a Y:yp
Si crea un binding sul NAT
Come si comporta ora il NAT rispetto al traffico entrante?
!
Host A
!
IP=Y
port=yp
IP=X
port=xp
Host B
Giugno 2008
Endpoint Independent Filtering
Host B
Host B
Host C
Host A
Dominio privato
Dominio privato
IMPLICA
Appena c’è un binding, tutti possono
mandare pacchetti a host A
Host A
Giugno 2008
Address dependent filtering
Host B
Host B
Host C
Host A
Dominio privato
Dominio privato
IMPLICA
Host A manda un pacchetto a host B
Solo Host B può mandare pacchetti a host A
Host B può usare qualsiasi porta
Host A
Giugno 2008
Address and port dependent
filtering
Host B
Host B
B_a:bp
B_a:bp
B_a:bz
Dominio privato
Dominio privato
IMPLICA
Host A
Host A
Host A manda un pacchetto a host B
all’indirizzo B_a, sulla porta bp
Solo Host B può mandare pacchetti a host A
Host
B deve usare la porta bp
Giugno 2008
Politiche di filtering: riassunto
Riassumendo:
?
Host A
IP=Y
port=yp
IP=X
port=xp
Host B
Policy
il NAT scarta:
Endpoint Independent Filtering
(Dst ≠X:xp)
Addrress dependent Filtering
(Dst ≠X:xp) + (pacchetto non
inviato da Y)
Address and port dependent
Filtering
(Dst ≠X:xp) + (pacchetto non
inviato da Y:yp)
Giugno 2008
Politiche di filtering: regola
REGOLA 4: un NAT application “friendly”:
• Se la trasparenza per le applicazioni è fondamentale =>
endpoint independent filering
• Altrimenti si RACCOMANDA address dependent filtering.
• Il comportamento può essere configurato da amminsitratore
Endpoint independent filtering:
Massima
trasparenza
Poca sicurezza
Address dependent filtering:
Maggior
sicurezza
Compromesso accettabile
Giugno 2008
Considerazioni sugli host dietro a NAT
Se non esiste un mapping sul NAT l’host
dietro a NAT non è raggiungibile
Non
ha un indirizzo/porta pubblico assegnato
Se esiste un mapping dipende dalle
politiche di filtering
Endpoint
independent filtering => chiunque può
inviare pacchetti
Endpoint dependent filtering => il mittente esterno va
“abilitato”
Rete privata 1
Da 10.0.1.1:5060
a 130.192.36.30:5080
Da 130.192.31.12:5061
a 130.192.36.30:5080
Peer A
Peer B
(10.0.1.1:5060)
Ora 130.192.36:30:5080 (B)
può mandare pacchetti a
130.192.31.12:5061 (A)
(130.192.36.30:5080)
Giugno 2008
Comportamento deterministico dei
NAT
Alcuni NAT hanno policy che cambia in base a
situazioni concomitanti
Ogni NAT che cambia il suo comportamento
senza essere riconfigurato è non deterministico
I NAT non deterministici sono difficili da gestire
Difficile
troubleshooting per via del comportamento
complesso
REGOLA 5: un NAT application “friendly” deve
avere un comportamento deterministico:
• No variazioni policy di mapping
• No variazioni policy di filtraggio
Giugno 2008
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
“friendly”
STUN
NAT? NAT traversal
Relay
Hole
punching
Caso di studio: SIP
Giugno 2008
Rilevamento dei NAT: STUN
Come fa un host a scoprire di essere dietro
un NAT?
Come fa un host a scoprire il proprio
indirizzo/porta pubblici?
IETF ha definito STUN
Session
Traversal Utilities for NATs (STUN)
Originariamente basato su UDP
Poi esteso per supportare TCP e TCP/TLS
Qui viene presentata solo la versione di
base di STUN
In realtà STUN fa anche operazioni più complesse
STUN è tuttora in evoluzione
Giugno 2008
STUN: Binding Request
STUN è client/server
STUN server pubblico
Lo STUN server deve essere localizzabile (SRV)
L’host dietro NAT integra uno STUN client
L’host invia un messaggio di Binding Request allo
STUN server
Il NAT cambia indirizzo e porta sorgente dei pacchetti
Lo STUN server vede l’indirizzo IP pubblico e la porta
assegnate dal NAT
Rete privata
IP.src= 10.0.0.1
port.src=5060
Binding Request
Rete pubblica
Ricevuto un
pacchetto inviato
da 130.192.31.1,
porta 5080
IP.src=130.192.31.1
port.src=5080
Binding Request
STUN server
Giugno 2008
STUN: Binding Response
Il server risponde con una Binding Response
L’indirizzo
IP e la porta pubbliche osservate sono
nell’attributo XOR MAPPED ADDRESS della risposta
La Binding Response arriva sicuramente
Rete pubblica
Rete privata
Binding Response
Binding Response
(Mapped: 130.192.31.1: 5080)
(Mapped: 130.192.31.1: 5080)
STUN server
Giugno 2008
Problemi di STUN
Non serve in caso di:
address dependent mapping
Address and port dependent mapping
Rete privata
IP.src= 10.0.0.1
port.src=5060
Binding Request
Rete pubblica
(non controllata dal NAT)
Ricevuto un
pacchetto inviato
da 130.192.31.1,
porta 5080
IP.src=130.192.31.1
port.src=5080
Binding Request
STUN server
IP.src=130.192.31.56
port.src=5080
DATA
Giugno 2008
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
“friendly”
STUN
NAT? NAT traversal
Relay
Hole
punching
Caso di studio: SIP
Giugno 2008
Tecniche di NAT traversal
NAT traversal = garantire la connettività fra
host in presenza di NAT
Gli
host diventano consapevoli della presenza dei NAT
Gli host svolgono una serie di operazioni
miranti a:
Creare
delle entry nelle binding cache dei NAT per
garantire la comunicazione
Mantenere attivo il canale instaurato per il tempo della
sessione
Le tecniche che verranno esaminate:
Relaying
Hole
punching
Giugno 2008
Relaying
Richiede un server (relay) pubblico
Attraversa il NAT grazie al pardigma client/server
I due host sono client, il relay è il server
Entrambi gli host creano una connessione verso il relay:
Rete privata 1
Rete privata 2
Alloca
Alloca
Host A
Host B
Relay
Fatto questo gli host possono comunicare attraverso il
relay
Rete privata 1
Rete privata 2
Canale da/verso
host B
Canale da/verso
host A
Host A
Relay
Host B
Giugno 2008
Relaying: pro e contro
Il relaying funziona sempre
Non richiede scambi di troppi messaggi
Tuttavia, la comunicazione fra gli host è sempre
mediata
è un single point of failure
Se cade la comunicazione si interrompe
Non scala
Sia che il NAT sia application “friendly” o no
All’aumentare del numero di host collegati le prestaizoni
del relay decadono
Il relay è una risorsa limitata
È come se mi “prestasse” una delle sue interfacce
Da usare con parsimonia
Giugno 2008
Hole Punching
Tecnica per stabilire una comunicazione diretta tra
peer attraverso NAT
Pensato originariamente per UDP (estendibile a TCP)
Attori:
I due peer
Rendez-vouz server
Nodo pubblico
Usato solo in una fase iniziale, per aiutare i peer a creare un
percorso attraverso I NAT
Scenario di esempio:
RVS
(Rendez-vous server)
Rete privata 1
Peer A
NAT1
(10.0.1.1:5060)
Rete privata 2
NAT2
130.192.31.10
Peer B
(10.0.2.1:5060)
Giugno 2008
UDP Hole punching: passo 1
Peer A si registra presso il rendez vous server (RVS)
RVS vede il public endpoint di peer A
RVS associa il private endpoint al public endpoint
Se peer A non è dietro NAT i due enpoint sono identici
Peer B esegue la medesima procedura
B è
130.192.36.30:5080
A è
130.192.31.12:5061
Rete privata 1
Rete privata 2
NAT1
Da 130.192.31.12:5062
a RVS
NAT2
Da 130.192.36.30:5080
a RVS
Peer A
Peer B
(10.0.1.1:5060)
(10.0.2.1:5060)
RVS
(Rendez-vous server)
Giugno 2008
UDP Hole punching: passo 2
RVS comunica a peer A l’indirizzo (e porta)
pubblica di peer B
RVS comunica a peer B l’indirizzo (e porta)
pubblica di peer A
Entrambi
i peer hanno già comunicato con RVS
I messaggi passano
Rete privata 2
Rete privata 1
Voglio parlare con A
Voglio parlare con B
UDP
Peer A
UDP
B è 130.192.36.30:5080
(10.0.1.1:5060)
UDP
UDP
A è 130.192.31.12:5061
RVS (Rendez-vous server)
130.192.31.10
Peer B
(10.0.2.1:5060)
Giugno 2008
UDP Hole punching: passo 3 (1/2)
Peer A manda pacchetti UDP al public endpoint di peer B
Scarto il pacchetto
UDP di Peer A
Rete privata 1
Da 10.0.1.1:5060
a 130.192.36.30:5080
Peer A
(10.0.1.1:5060)
Rete privata 2
Da 130.192.31.12:5061
a 130.192.36.30:5080
Peer B
Ora 130.192.36:30:5080 (B)
130.192.31.12:5061 (A)
(10.0.2.1:5060)
Simultaneamente B fa la stessa cosa
Rete privata 1
Da 130.192.36.30:5080
a 10.0.1.1:5060
Rete privata 2
Da 130.192.36.30:5080
a 130.192.31.12:5061
Da 10.0.2.1:5060
a 130.192.31.12:5061
Peer A
(10.0.1.1:5060)
Peer B
Ora 130.192.31.12:5061 (A)
130.192.36.30:5080 (B)
(10.0.2.1:5060)
Giugno 2008
UDP Hole punching: passo 3 (2/2)
Continuando a scambiarsi pacchetti UDP,
prima o poi si aprono i biniding sui NAT
Anche
se i pacchetti sono filtrati, l’importante è creare
traffico attraverso i NAT
Peer A
C’è un binding: il
pacchetto passa!!!
C’è un binding: il
pacchetto passa!!!
UDP
UDP
UDP
UDP
Scambio pacchetti UDP con
130.192.36.30:5080
(public endpoint di B)!!!!
Peer B
UDP
UDP
Scambio pacchetti UDP con
130.192.31.12:5061
(public endpoint di A)!!!!
Giugno 2008
Hole Punching: pro e contro
Stabilisce un canale diretto tra due host
Molto più leggero del realying
Il relaying è da usare solo come soluzione estrema se non si
riesce a connettersi
Non funziona con tutti i NAT
Il Rendez Vous server serve solo a far conoscere i due host
Il relay, invece, veicola tutti i pacchetti
Sicuramente funziona con i NAT application “friendly”(BEHAVE)
Richiede uno scambio di messaggi per aprire la
comunicazione
Potrebbe volerci tempo prima di scoprire che non è possibile
fare hole punching
Giugno 2008
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
“friendly”
STUN
NAT? NAT traversal
Relay
Hole
punching
Caso di studio: SIP
Giugno 2008
Caso di studio: SIP
SIP è un protocollo p2p like
Gli
UA usano i proxy per localizzarsi reciprocamente
La comunicazione dovrebbe essere diretta
Sia SIP che media (RTP)
Due problemi:
Come
gestisco il/I NAT per i messaggi SIP?
Come gestisco il/I NAT per i flussi RTP?
I due problemi sono affrontati
separatamente
Giugno 2008
NAT traversal per messaggi SIP (1/2)
Considerazioni:
1.
2.
qualsiasi UA manda un messaggio REGISTER al proxy
del suo dominio
Se il proxy riceve il messaggio può mandare indietro una
risposta
3.
In caso di UA dietro un NAT creo un “hole” sul NAT
Basta rifare esattamente lo stesso percorso della richiesta
Quindi se il proxy riutilizza lo stesso percorso del
messaggio REGISTER può inoltrare qualsiasi messaggio
SIP all’UA
Idea:
Il proxy tiene traccia del percorso seguito dal messaggio
REGISTER
Informazione memorizzata insieme al “contact”
“flow” riutilizzabile
Giugno 2008
NAT traversal per messaggi SIP (2/2)
Tutte le richieste fuori dialogo vengono inoltrate attraverso il
“flow” dal proxy
“flow”
NAT
INVITE
“flow”
SIP proxy 2
INVITE
SIP proxy 1
INVITE
INVITE
UA 2
UA 1
Dominio SIP 2
Dominio SIP 1
I messaggi scambiati a dialogo instaurato sono consegnati
attraverso il proxy di dominio
Record route
“flow”
NAT
BYE
“flow”
SIP proxy 2
BYE
BYE
UA 2
UA 1
Dominio SIP 2
Dominio SIP 1
Giugno 2008
NAT traversal per flussi media (1/2)
Interactive Connectivity Establishment (ICE)
Pensato
per i soli media flow
ICE aggiunge un nuovo header SDP usato dagli UA
per annunciare tutti gli indirizzi loro associati
Indirizzi privati
Indirizzi imparati da un server STUN
Indirizzi ottenuti in prestito da un relay
I nuovi header SDP sono inclusi nel messaggio di INVITE e
nella relativa risposta 200 OK
Il/i proxy SIP agisce/agiscono da rendez-vous
Sulla base degli indirizzi scambiati gli UA eseguono
l’hole punching
Basato sullo scambio di messaggi STUN diretti tra gli UA
Per farlo entrambi gli UA includono:
Uno STUN client
Uno STUN server
Giugno 2008
NAT A
Annuncio indirizzi
NAT B
NAT traversal per flussi media (2/2)
ProxyB
ProxyA
INVITE
(payload SDP modificato)
200 OK
(payload SDP modifcato)
Individuazione delle coppie
ottimali di indirizzi (hole
punching)
Comunicazione diretta
media (SIP tramite “flows”)
Scambio di messaggi STUN di verifica
(provo 2 a 2 tutte le coppie possibili)
SIP
SIP
SIP
Canale media (uno per flusso)
Giugno 2008
Esempio: provider SIP e NAT (1/3)
SIP proxy
NAT
INVITE
10.0.0.102
INVITE
213.192.59.75
130.192.225.135
Pacchetti 8, 15 e 16: tutti messaggi del dialogo attraversano relay SIP
Record route
chi e come lo inserisce?
Pacchetti da 9 a 14: tutti i pacchetti RTP attraversano un media relay
Giugno 2008
Il proxy SIP modifica il messaggio INVITE includendo il media relay
Così il chiamato crede che il media relay sia il chiamante
INVITE prima di attraversare il proxy SIP
INVITE dopo aver attraversato il proxy SIP
Giugno 2008
Il proxy SIP modifica il messaggio OK includendo il media relay
Così il chiamante crede che il media relay sia il chiamato
OK prima di attraversare il proxy SIP
OK dopo aver attraversato il proxy SIP
Giugno 2008
Esempio: NAT traversal con ICE (1/3)
L’UA inserisce nell’SDP delle INVITE:
L’indirizzo/porta
scoperto con STUN
Tutte le coppie indirizzo/porta note
Giugno 2008
L’UA inserisce nell’SDP della “200 OK”:
L’indirizzo/porta
scoperto con STUN
Tutte le coppie indirizzo/porta note
Giugno 2008
Hole punching
Flussi media
Giugno 2008
Conclusioni
E’ possibile garantire il funzionamento delle
normali applicazioni in presenza di NAT
Occorre tuttavia:
Che
l’amministratore configuri i NAT secondo le
regole di BEHAVE
Che gli sviluppatori integrino le funzionalità di NAT
traversal nei software
E’ possibile in questo modo:
Mantenere
la trasparenza di indirizzamento tipica dei
NAT
Mantenere le policy di sicurezza elementari dei NAT
Garantire le normali funzionalità SENZA riconfigurare
l’infrastruttura

seminario sul NAT traversal - the Netgroup at Politecnico di Torino

Transcript

Documenti analoghi

Nuova pagina 1 - MC-link

Notizie Naturalistiche CASO DI PREDAZIONE DI ELAPHE

20x408”x16” - Pastorelli

1/1 Come posso scoprire un host che mette in atto un

Medieval Workshop, January 31, 2015 Dr. Catherine Harding

Problematiche di NAT traversal - the Netgroup at Politecnico di Torino

pezzi speciali.

file in PDF - Legnomagia

Sicurezza e Gestione delle Reti (di telecomunicazioni)

Problematiche di NAT traversal - the Netgroup at Politecnico di Torino

atm garibaldi Milano_ITA