Problematiche di NAT traversal - the Netgroup at Politecnico di Torino

Transcript

Giugno 2007
Problematiche di NAT traversal
Livio Torrero
Netgroup
<[email protected]>
Problematiche di NAT traversal- 1
Copyright: si veda nota a pag. 2
Giugno 2007
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 2007
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
Giugno 2007
Concetti base sui NAT
I Network Address Traslator effettuano la traduzione
di indirizzi e/o porte fra spazi di indirizzamento
differenti
I due spazi sono scorrelati: gli indirizzi dell’uno sono
inutilizzabili nell’altro
I NAT:
Modificano gli inidirizzi 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 2007
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 scarseggiavano
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 2007
Problemi causati dai NAT (1/2)
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
Se
il messaggio attraversa il NAT l’indirizzo non è
utilizzabile
Esempio: SIP durante la fase di registrazione
Campo Contact
Potrei risolvere tutto con un Application
Level Gateway
Ma
sei il messaggio contente l’indirizzo è
criptato?
Giugno 2007
Probelmi causati dai NAT (2/2)
L’host controllato dal NAT potrebbe volere che il suo
inidirizzo interno sia associato con il medesimo
indirizzo nello spazio di indirizzamento esterno per
più sessioni contigue
Il NAT non sa riconoscere una correlazione fra
sessioni e potrebbe cambiare l’assegnazione
I NAT sono disegnati per soddisfare il paradigma
client/server
Il client è pensato nello spazio controllato dal NAT
Però le applicazioni peer-to-peer possono non
funzionare
Come fanno gli host fuori dallo spazio di
indirizzamento del NAT a localizzare i peer gestiti dal
NAT?
Gli indirizzi nello spazio di NAT non sono utilizzabili da host nello
spazio esterno
Giugno 2007
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
“friendly”
STUN
NAT? NAT traversal
Relay
Hole
punching
Giugno 2007
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
Vengono fornite regole per definire il comportamento
di NAT “application friendly”:
permettono alle comuni applicazioni di funzionare
attuando tecniche note come “tecniche di NAT
traversal” ottimizzate per la comunicazione diretta
non richiedono l’uso di nodi intermedi di supporto
Esame delle sole regole principali
Regole (principali) relative a:
Traduzione di porte e indirizzi
Gestione dei binding
Filtraggio dei pacchetti in ingresso
Politiche di filtering
Comportamento deterministico
Giugno 2007
Traduzione di porte e indirizzi
Endpoint independent mapping: si riusa stesso
mapping per tutte le destinazioni.
Address dependent mapping: si riusa 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
REGOLA 1: un NAT application “friendly” DEVE
avere un comportamento basato sull’endpoint
Independent Mapping.
Giugno 2007
Esempio:
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 2007
Esempio:
address dependent mapping
Il NAT assegna all’host privato stesso IP pubblico e porta pulbblica
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
Esempio:
address and port dependent
mapping(1/2)
Il NAT assegna all’host privato stesso IP pubblico e porta pulbblica
l’indirizzo IP e la porta dell’host esterno contattato non cambia
130.192.31.55:5090
Dominio privato
130.192.31.25:5080
130.192.31.58:5090
130.192.31.22:5090
10.0.0.1:5060
130.192.31.55:5080
130.192.31.25:5080
Dominio privato
Giugno 2007
130.192.31.55:5090
130.192.31.22:5090
10.0.0.1:5060
Giugno 2007
Esempio:
address and port dependent
mapping(2/2)
Affinchè il mapping non cambi inidirizzo e porta di
destinazione non devono cambiare
130.192.31.55:5090
130.192.31.55:5090
Passa un tempo T
(inferiore a durata binding)
10.0.0.1:5060
130.192.31.25:5080
Dominio privato
Dominio privato
130.192.31.25:5080
10.0.0.1:5060
Giugno 2007
Gestione dei binding (1/2)
REGOLA 2:
• NAT UDP binding DEVE durare almeno 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
Per mantenere l’indirizzo assegnato dal NAT, è sufficiente
fare traffico utilizzandolo (keepalive)
Si deve garantire il transito di pacchetti prima dello
scadere del timer
Giugno 2007
Gestione dei binding (2/2)
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
entrabi i modi
NAT
REGOLA 3: un NAT “application friendly” deve
avere il NAT outbound refresh attivo. Può
eventualmente avere il NAT Inbound Refresh
attivo.
Giugno 2007
Politiche di filtering (1/2)
Sino ad ora i NAT sono stati visti come semplici
traduttori di indirizzi e/o porte
I NAT comunemente implementano delle politiche di
filtraggio del traffico diretto agli host da loro
controllati
I NAT sono spesso considerati dei rudimentali
meccanismi di sicurezza
Attraverso le policy di mapping posso impedire agli
host esterni di capire con quale host interno parlano
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 2007
Politiche di filtering (2/2)
Prima di tutto host A crea una sessione mandando
un pacchetto a Y:yp
Si crea un binding sul NAT
Host A
IP=Y
port=yp
IP=X
port=xp
Policy
Host B
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 2007
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 2007
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 2007
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 può deve usare bp
Giugno 2007
Politiche di filtering: regola
REGOLA 4: un NAT e’ 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 2007
Comportamento deterministico dei
NAT
Alcuni NAT hanno policy che cambia in base a
situazini concomitanti
Ogni NAT che cambia il suo comportamento
senza essere riconfigurato è non deterministico
I NAT non deterministici sono difficili da gestire
Difficile
fare troubleshooting per via del loro
comportamento complesso
REGOLA 5: un NAT application “friendly” deve
avere un comportamento deterministico:
• No variazioni policy di mapping
• No variazioni policy di filtraggio
Giugno 2007
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
“friendly”
STUN
NAT? NAT traversal
Relay
Hole
punching
Giugno 2007
Rilevamento dei NAT: STUN
Come fa un host a scoprire di essere dietro
un NAT?
IETF ha definito STUN
Originariamente basato su UDP
Poi
esteso per supportare TCP e TCP/TLS
Si basa su uno STUN server pubblico
Lo
STUN server deve essere localizzabile
Entry SRV
Qui viene presentata solo la versione di base di
STUN
In realtà STUN fa anche operazioni più
complesse
Giugno 2007
STUN Binding Request
L’host 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 2007
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 2007
Problemi di STUN
In questo approccio le informazioni ritornate
nel mapped address sono inutili se il NAT
assegna un indirizzo diverso per ogni
destinazione
Ricevuto un
Rete privata
IP.src= 10.0.0.1
port.src=5060
Binding Request
Rete pubblica
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
Giugno 2007
STUN: work in progress
STUN cambia spesso nome…
2/2006
=> STUN = simple traversal of UDP
through NATs
7/2006 => STUN = simple traversal underneath
network address translators
10/2006 => STUN = session underneath network
address translators
3/2007 => STUN = session traversal utilities for
NAT
… eppure e` gia` largamente diffuso, anche
se e` ancora un work in progress
Giugno 2007
Sommario
Che cosa sono i NAT
BEHAVE:
Definizione
“friendly”
STUN
NAT? NAT traversal
Relay
Hole
punching
Giugno 2007
Tecniche di NAT traversal
Le tecniche di NAT traversal mirano a
garantire la connettività fra gli host in
presenza di NAT
Gli
host sono 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 2007
Relaying
Richiede un server (relay) pubblico
Attraversa il NAT grazie al pradigma 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
Manda a host A
Manda a host B
Host A
Relay
Host B
Giugno 2007
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
Giugno 2007
STUN relay
I server STUN recenti integrano anche la
funzionalita` di relay
Due
modi operativi
STUN normale
Servizio di relay
Il server entra in una modalita` piuttosto che
nell`altra a seconda delle richieste che gli manda
il client
Binding request: funzionamento normale
Allocate request: funzionalita` relay
Allocate request = riservami un indirizzo e/o porta relay
Giugno 2007
Hole Punching
Tecnica per stabilire una comunicazione diretta tra peer
attraverso NAT
Obiettivo:
creare dei binding sui NAT per permettere la comunicazione
Pensato originariamente per UDP
Si può pensare di usarlo anche per TCP
Attori:
I due peer
Rendez-vouz server
Nodo pubblico
Usato solo in una fase iniziale
“aiuta” i peer a scorpire i loro indirizzi
Entrambi i peer hanno una sessione UDP con lui
Conosce IP e porta pubblica dei peer
Private endpoint
Public endpoint
Giugno 2007
UDP Hole punching: passo 1
Peer A si registra presso RVS
Private endpoint associato a public endpoint visto da
RVS
Se peer A non è dietro NAT i due enpoint sono identici
Peer B esegue la medesima procedura
Peer B è
130.192.36.30:5080
Peer A è
130.192.31.12:5061
10.0.1.1:5060
10.0.2.1:5060
UDP
Peer A
10.0.1.1:5060 è
130.192.31.12:5061
verso RVS
UDP
UDP
UDP
Peer B
RVS
(Rendez-vous server)
130.192.31.10
10.0.2.1:5060 è
130.192.36.30:5080
verso RVS
Giugno 2007
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
Peer A è
130.192.31.12:5061
Peer B è
130.192.36.30:5080
UDP
Peer A
10.0.1.1:5060
UDP
UDP
RVS (Rendez-vous server)
130.192.31.10
UDP
Peer B
10.0.2.1:5060
Giugno 2007
UDP Hole punching: passo 3 (1/2)
Peer A manda pacchetti UDP al public endpoint di peer B
Mando pacchetti UDP a
130.192.36.30:5080!!!!
Scarto il pacchetto
UDP di Peer A!!!
Peer A
Peer B
UDP
10.0.1.1:5060
UDP
Binding tra 10.0.1.1:5060 e
130.192.36:30:5080
(public endpoint di B)
10.0.2.1:5060
Simultaneamente B fa la stessa cosa
Mando pacchetti UDP a
130.192.31.12:5061!!!!
C’è un binding: il
pacchetto passa!!!
Peer A
Peer B
UDP
UDP
10.0.1.1:5060
UDP
Binding tra 10.0.2.1:5060
e
130.192.31:12:5061
(public endpoint di A)
10.0.2.1:5060
Giugno 2007
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
pacchetto passa!!!
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 2007
TCP hole punching
Concettualmente simile alla versione UDP
L’instaurazione della sessione diretta
segue le seguenti fasi:
1.
2.
3.
4.
5.
Entrambi i peer A e B creano una sessione TCP
verso RVS
RVS manda ad A il public endpoint di B e
viceversa
A cerca di creare una connessione TCP diretta
verso il public endpoint di B
B cerca di creare una connessione TCP diretta
verso il public endpoint di A allo stesso tempo
Se le operazioni riescono i due peer possono
comunicare senza intermediari
Giugno 2007
Problemi del TCP hole punching
(1/2)
L’API TCP originale di Berkeley era pensata secondo
un paradigma client/server
Posso usare un socket TCP per aprire una
connessione uscente (connect())
Posso usare un socket TCP per restare in attesa di
connessione da parte di altri (listen() + accept())
Ma non posso fare entrambe le cose con lo stesso
socket
Problema: una volta che una porta è associata a un
socket TCP, è impossibile associare la medesima
porta a un altro socket
Tuttavia l’hole punching richiede di essere in ascolto
sulla medesima porta da cui si mandano pacchetti
Soluzione: socket option “SO_REUSEADDR”
permette di fare il bind del medesimo socket su più
endpoint
Giugno 2007
Problemi del TCP hole punching
(2/2)
In UDP bastava un socket solo per ogni
peer, con TCP ne servono di più
Un
socket per ciascun peer per comunicare con
RVS
Un socket in ascolto su cui ricevere le chiamate
degli altri peer
Almeno un socket per aprire una connessione in
uscita verso l’altro peer
Giugno 2007
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”di BEHAVE
Richiede uno scambio di messaggi per aprire la
comunicazione
Potrebbe volerci tempo prima di scoprire che non è
possibile fare hole punching
Giugno 2007
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

Problematiche di NAT traversal - the Netgroup at Politecnico di Torino

Transcript

Documenti analoghi

Nuova pagina 1 - MC-link

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

Notizie Naturalistiche CASO DI PREDAZIONE DI ELAPHE

20x408”x16” - Pastorelli

Medieval Workshop, January 31, 2015 Dr. Catherine Harding

pezzi speciali.

Sicurezza e Gestione delle Reti (di telecomunicazioni)

Massimiliano Sbaraglia networking engineer UDP flood è un tipo di

file in PDF - Legnomagia

seminario sul NAT traversal - the Netgroup at Politecnico di Torino