Problematiche di NAT traversal - the Netgroup at Politecnico di Torino

Transcript

Problematiche di NAT traversal - the Netgroup at Politecnico di Torino
Problematiche di NAT
traversal
Livio Torrero
Dipartimento di Automatica e Informatica
Politecnico di Torino
1
Sommario
Concetti generali sui NAT
Specifiche BEHAVE: come dovrebbe essere un
NAT
Tecniche di Attraversamento
Relaying
Metodi UNSAF:
Hole punching
STUN (turn)
ICE
2
Concetti generali sui NAT
I Network Address Traslator effettuano la
traduzione di indirizzi fra realm differenti
I NAT garantiscono la trasparenza del routing fra i
realm
I NAT:
Modificano gli inidirizzi IP e/o le porte dei
pacchetti
Mantengono informazioni di stato relativamente al
mapping fra i realm
3
I NAT e le applicazioni
Indirizzi IP nei payload dei pacchetti:
Il NAT da solo non garantisce trasparenza routing
E’ necessaria la presenza degli Application Level
Gateway (ALGs)
Gli ALG utilizzano le informazioni di stato del NAT
per aggiornare i payload
Se l’applicazione presenta sessioni contigue
correlate ci possono essere problemi
Il NAT non sa nulla della correlazione
Il mapping può cambiare
4
I NAT e le applicazioni p2p
La maggior parte dei NAT è sviluppata
intorno al paradigma client/server
Garantiscono l’anonimità degli host
I NAT spesso scartano le sessioni originate
dall’esterno
I peer esterni devono conscere gli indirizzi
pubblici dei peer dietro i NAT per instaurare
sessioni
Esitono differenti tipologie di NAT
Per superare alcuni NAT occorre per forza
appoggiarsi a nodi esterni
5
Sommario
Concetti generali sui NAT
Specifiche BEHAVE: come dovrebbe essere un
NAT
Tecniche di Attraversamento
Relaying
Metodi UNSAF:
Hole punching
STUN (turn)
ICE
6
Specifiche BEHAVE
BEHAVE è un working group di IETF
Definisce una serie di specifiche per
avere NAT “application friendly”
Questi NAT non richeidono l’uso di nodi
intermedi di supporto
Esame delle sole regole principali
7
Specifiche BEHAVE: NAT UDP
Regole relative a:
Traduzione di porte
Traduzione di indirizzi
Port preservation e port overloading
Gestione dei binding
Filtraggio dei pacchetti
Gestione del hairpinning
Gestione degli ALG
Comportamento deterministico del NAT
8
Traduzione di porte
Endpoint independent mapping: si riusa
stesso port mapping per tutte le destinazioni.
Address dependent mapping: si riusa stesso
port mapping per tutti i pacchetti inviati al
medesimo IP esterno
Address and port dependent mapping: si
riusa stesso port mapping per tutti i pacchetti
inviati ai medesimi IP+porta esterni
REGOLA: il NAT DEVE avere un comportamento
basato sull’endpoint Independent Mapping.
9
Esempio: Endpoint
independent mapping
HostY1
Y1
Host
HostY2
Y2
Host
X’:x1’
X’:x1’
Realm interno
NAT
NAT
X:x
HostXX
Host
Il mapping non cambia in base all’indirizzo di destinazione
10
Esempio: address dependent
mapping
HostY1
Y1
Host
HostY2
Y2
Host
Y1:y1
Y2:y2
X’:x1’
X’:x2’
Realm interno
NAT
NAT
X:x
HostXX
Host
X’:x1’ eqiuvale a X’:x2’ Y1 equivale a Y2
11
Esempio: address and port
dependent mapping
HostY1
Y1
Host
HostY2
Y2
Host
Y1:y1
Y2:y2
X’:x1’
X’:x2’
Realm interno
NAT
NAT
X:x
HostXX
Host
X’:x1’ eqiuvale a X’:x2’ Y1:y1 equivale a Y2:y2
12
Traduzione di indirizzi
Il NAT ha più indirizzi: IP address
pooling
Arbitrary: stesso IP interno, differenti IP
esterni su diverse sessioni
Paired: stesso IP interno, stesso IP esterno
su diverse sessioni
REGOLA: SI RACCOMANDA che l’IP address pooling
di un NAT sia settato a paired .
13
Port preservation
Non si garantisce che la porta interna
sia uguale a quella esterna in ogni caso
ma si fa il possibile
Si comincia come basic NAT
Quando si esauriscono gli indirizzi si passa
a un comportamento “Network address
and port translator” (NAPT)
14
Basic NAT
Si riusa sempre la stessa porta: cambio l’indirizzo IP
HostY1
Y1
Host
HostY2
Y2
Host
Y1:y1
Y2:y2
X1’:x
X2’:x
Realm interno
NAT
NAT
X1:x
HostX1
X1
Host
X2:x
HostX2
X2
Host
15
NAPT
Si riusa sempre lo stesso indirizzo IP: cambia la porta
HostY1
Y1
Host
HostY2
Y2
Host
Y1:y1
Y2:y2
X’:x1’
X’:x2’
Realm interno
NAT
NAT
X1:x
HostX1
X1
Host
X2:x
HostX2
X2
Host
16
Port overloading (1/2)
Come port preservation, ma quando
esaurisco gli indirizzi continuo a non
cambiare la porta
Posso avere due sessioni da due host
dietro il NAT con il medesimo IP e porta
pubblici
I pacchetti in ingresso sono riconosciuti
solo dall’indirizzo sorgente
17
Port overloading (2/2)
HostY1
Y1(Y1:y1)
(Y1:y1)
Host
Realm interno
X’:x
X’:x
NAT(singolo
(singoloIP
IPpubblico
pubblicoX’)
X’)
NAT
HostX1
X1(x1:x)
(x1:x)
Host
HostX2
X2(x2:x)
(x2:x)
Host
Se X1 e X2 mandano pacchetti entrambi a Y1, le sessioni sono
indistinguibili
REGOLA:
• NO “port assignment” = “port overloading”
• porta privata [1-1023] => porta pubblica [1-1023]
• porta privata [1023-65535] => porta pubblica [1023-65535]
18
Gestione dei binding (1/2)
REGOLA:
• 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
19
Gestione dei binding (2/2)
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 entrabi
i modi
REGOLA: Il NAT deve avere il NAT outbound refresh
attivo. Può eventualmente avere il NAT Inbound
Refresh attivo.
20
Compatibilità fra realm (1/2)
NAT1
NAT1
NAT2
NAT2
Clientnetwork
network
Client
(reteprivata)
privata)
(rete
ISP (Rete privata)
Lo spazio di indirizzamento privato del cliente
e quello dell’ISP possono sovrapporsi
21
Compatibilità fra realm (2/2)
Il NAT potrebbe autoconfigurare la sua
subnet interna ad hoc
Problemi di renumbering
Poco pratico
Il NAT deve gestire la sovrapposizione
REGOLA 7: un NAT con l’interfaccia esterna
riconfigurabile dinamicamnente:
• o assicura che non ci siano conflitti tra i realm
• o consente la comuinicazione solo fra nodi che
non presentano sovrapposizioni
22
Filtraggio dei pacchetti (1/2)
HostY1
Y1
Host
Realm interno
Y1:y1
NAT
NAT
X:x
HostXX
Host
Policy
Pacchetti scartati
Endpoint Independent Filtering
(Dst ≠ X:x)
Addrress dependent Filtering
(Dst ≠ X:x) + (pacchetto non
inviato a Y1)
(Dst ≠ X:x) + (pacchetto non
inviato a Y1:y1)
Address and port dependent
Filtering
23
Filtraggio dei pacchetti (2/2)
REGOLA:
• 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
24
Hairpinning (1/3)
Realm interno
X1’:x1’
X2’:x2’
NAT
NAT
HostAA(X1:x1)
(X1:x1)
Host
HostBB(X2:x2)
(X2:x2)
Host
Permette ad A di comunicare con B anche se
sono noti solamente gli indirizzi “pubblici”
Il NAT inoltra dati da A a B
B ha un mapping attivo (X2’:x2’)
25
Hairpinning (2/3)
X2”:x2”
NAT
NAT ISP
ISP
NAT
NAT AA
Host
Host AA (X1:x1)
(X1:x1)
Da S non riescono a scoprire gli indirizzi (S vede solo (X1”,x1”), (X2”,x2”))
Anche se potessero apprenderli forse sarebbero inutilizzabili
Host
Host BB (X2:x2)
(X2:x2)
A e B volgliono comunicare: converrebbe usare (X1’,x1’), (X2’,x2’)
NAT
NAT BB
Realm privato B
X2’:x2’
Realm privato A
X1’:x1’
Realm privato ISP
X1”:x1”
Internet
SS (indirizzo
(indirizzo pubblico)
pubblico)
Magari (X2’, x2’) è riusato nel realm di A: host A non ha modo di capire che si tratta
di B
L’hairpinning permette ad A e B di interagire comunque: ((X1”:x1”),(X2”,x2”))
26
Hairpinning (3/3)
Realm interno
X1’:x1’
NAT
NAT
HostAA(X1:x1)
(X1:x1)
Host
HostBB(X2:x2)
(X2:x2)
Host
Due policy:
X2’:x2’
External Source IP and port: src=(X1’:x1’), dst=(X2:x2)
Internal Source IP and port: src=(X1:x1), dst=(X2:x2)
Alcuni host vogliono indirizzi sorgente pubblici
C’è il rischio che sacrtino ciò che non si aspettano
REGOLA: l’hairpinning deve essere supportato dal NAT.
•“l’External source IP and port” deve essere attivo
27
Application Level Gateways
I NAT possono incorporare un ALG
In alcuni casi sono permanentemente
abilitati
Possono interferire con i protocolli
“NAT-aware”
REGOLA: se un NAT include un ALG che può
influenzare UDP si raccomanda la sua
disattivazione
28
Comportamento deterministico
dei NAT
Alcuni NAT hanno policy che cambia in
base a situazini esterne
Esempio: port preserving NAT
(Basic NAT che diventa NAPT)
Difficili da gestire
REGOLA: il NAT deve avere un comportamento
deterministico:
• No variazioni policy di mapping
• No variazioni policy di filtraggio
29
Sommario
Concetti generali sui NAT
Specifiche BEHAVE: come dovrebbe essere un
NAT
Tecniche di Attraversamento
Relaying
Metodi UNSAF:
Hole punching
STUN (turn)
ICE
30
Relaying
HostAA
Host
NAT
NAT
AA
ENABLE
DATA
NATBB
NAT
DATA
ENABLE
HostBB
Host
Prevede un server di supporto
Implementa il paradigma client/server
Relay
Relay
Entrambi gli endpoint aprono una connessione verso il
server
Il metodo più efficace
Il metodo più oneroso
Latenza nella consegna dei pacchetti
Consuma risorse server
31
Sommario
Concetti generali sui NAT
Specifiche BEHAVE: come dovrebbe essere un
NAT
Tecniche di Attraversamento
Relaying
Metodi UNSAF:
Hole punching
STUN (turn)
ICE
32
Processi UNSAF (1/2)
RFC 3424 da Internet Architecture Board
(IAB)
UNilateral Self Address Fixing (UNSAF)
Processi attraverso cui un host cerca di
scoprire il suo indirizzo pubblico
Creano i NAT binding necessari alla comunicazione
Necessitano di keep-alive periodico
Non funzionano con qualsiasi NAT
33
Processi UNSAF (2/2)
L’host fai il fix del suo IP/porta pubblico
contatta un host pubblico per farlo
L’host privato è detto UNSAF client
L’host pubblico è detto UNSAF server
Problemi con gli ALG
ALG context sensitive (in base alle porte
src e/o dst): difficili da prevedere
Alcuni non manipolano correttamente TCP
34
Sommario
Concetti generali sui NAT
Specifiche BEHAVE: come dovrebbe essere un
NAT
Tecniche di Attraversamento
Relaying
Metodi UNSAF:
Hole punching
STUN (turn)
ICE
35
Hole Punching (1/4)
Sviluppata su UDP
Si basa sull’aprire “buchi” sul NAT
Si basa sulla presenza di un server di
appoggio
Deve avere indirizzo pubblico
Deve propagare le informazioni necessarie
36
Hole Punching (2/4)
HostAA
Host
10.0.0.1
Host B:130.192.225.19:5060
NATAA
NAT
Dst = Server S
ServerSS
Server
Host A:130.192.225.18:5060
NATBB
NAT
Dst = Server S
HostBB
Host
10.0.0.2
Host A: 130.192.225.18:5060
Host B: 130.192.225.19:5060
enable Host A Host B:
130.192.225.19:5060
HostAA
Host
10.0.0.1
NAT
B:NAT
startAA
enable Host A Host B:
130.192.225.19:5060
Dst = 130.192.225.18:5060
Server
NAT
DATA SS
B:
start
Server
NAT
BB
Dst = 130.192.225.19:5060
HostBB
Host
10.0.0.2
37
Hole Punching (3/4)
Vantaggi:
Se A vuole parlare con un host C, B può prendere
il posto di S
Scala, carico ridotto (non grava tutto su S)
Funziona con NAT multipli
Se A e B dietro a stesso NAT
Con hole punching fanno hairpinning
Includono nei pacchetti scambiati i loro indirizzi
privati
Provano a parlare direttamente
38
Hole Punching (4/4)
Funziona solo con NAT “friendly”
Specifiche BEHAVE
Non funziona con address dependent mapping e address
and port dependent mapping
Si può pensare di usare “port number prediction”
(sconsigliata)
Simultaneous TCP open
Variante TCP
Sessione iniziata simultaneamente dai due peer (SYN
packets)
Se i due NAT credono che le sessioni sono aperte i pacchetti
passano
Le due richieste devono essere sincronizzate
39
Sommario
Concetti generali sui NAT
Specifiche BEHAVE: come dovrebbe essere un
NAT
Tecniche di Attraversamento
Relaying
Metodi UNSAF:
Hole punching
STUN (turn)
ICE
40
STUN
RFC 3489 (aggiornato con un draft)
Simple Traversal of UDP through NAT
Algoritmo UNSAF
Funziona su UDP
Non bisogna modificare il NAT
STUN client UNSAF client
STUN server UNSAF server
STUN è un protocollo client/server
41
Funzioni base di STUN
Realm B
Internet
Realm A
Host
Host AA
(STUN
(STUN client)
client)
Il server esamina IP + porta della richiesta
Binding response -> indirizzo visto dal server
integrità messaggi + autenticazione
Binding request -> quale indirizzo pubblico?
STUN
STUN server
server
Shared secret request -> richiesta user+pass (temp.)
Shared secret response -> user+pass (temp.)
SHARED
SECRET
RESPONSE
SHARED
REQUEST
NAT
AA
NAT
BB
BINDING
RESPONSE
BINDING
REQUEST
NAT SECRET
NAT
L’indirizzo scoperto è detto “reflexive transport address”
STUN funziona anche con NAT multipli
Se mapped address ≠ proprio indirizzo -> c’è NAT
42
Messaggi STUN
Due tipi di messaggi:
Richieste
Sono mandate dal client al server
Le risposte generate dallo STUN server
contengono un codice numerico
Indication
Generate indifferentemente dal client e dal
server
Non viene generata alcuna risposta
43
Transazioni STUN
Porta default 3478
L’affidabilità si ottiene con le ritrasmissioni
Si parte dopo 100 ms raddoppiando ogni volta fino
a 1.6 s
Nel caso di TCP questi assicura la consegna
Prima di tutto: STUN server discovery
Entry DNS SRV “stun”
Se non c’è entry SRV si fa una query A o AAAA per
il dominio: si porverà a contattare questi indirizzi
sulla porta di default
44
Funzioni di STUN
STUN prevede diverse modalità di
funzionamento:
Binding discovery
Connectivity check
Verrà illustrata in ICE
NAT keepalive
Modalità relay
45
STUN: Binding discovery
Descritta nell’RFC 3489
E’ la tecnica per apprendere l’indirizzo
pubblico
Oltre a questo è possibile determinare se
l’host è:
Sulla open Internet
Dietro un firewall che blocca UDP
Dietro a un full-cone NAT
Dietro a un NAT simmetrico
Dietro a un address restricted cone NAT
Dietro a un port address restricted cone NAT
46
Full cone NAT
Una volta stabilito un mapping il NAT
accetterà tutte le connessioni
Anche detto NAT promiscuo
130.192.225.15
IP.src = 130.192.225.17
IP.src = 10.0.0.1
IP.dst = 10.0.0.1
IP.dst = 130.192.225.15
HostAA
Host
IP.src = 130.192.225.17
HostBB
Host
IP.dst = 130.192.225.16
Fullcone
coneNAT
NAT
Full
IP.src = 130.192.225.16
IP.dst = 130.192.225.15
10.0.0.1
Binding:
10.0.0.1 130.192.225.16
HostCC
Host
47
130.192.225.17
Restricted cone NAT
Address Restricted
Port and Address Restricted
HostAA
Host
10.0.0.1
Una volta stabilito un binding, il NAT inoltrerà
pacchetti provenienti da tutti quegli host al cui
indirizzo IP è stato inviato un pacchetto
Come il precedente ma conta anche la porta
Pacchetto
IP.src = 10.0.0.1
scartato
IP.dst = 130.192.225.15
Address
Address
restricted
restricted
coneNAT
NAT
cone
130.192.225.15
IP.src = 130.192.225.17
IP.dst = 130.192.225.16
HostBB
Host
IP.src = 130.192.225.16
IP.dst = 130.192.225.15
Binding:
10.0.0.1 130.192.225.16
HostCC
Host
130.192.225.17
48
NAT simmetrici
Il NAT assegna un mapping differente per
ogni destinazione (IP+porta)
Solo chi ha ricevuto un pacchetto può
comunicare con l’host
130.192.225.15
HostAA
Host
10.0.0.1
IP.src = 10.0.0.1
IP.src = 130.192.225.18
IP.dst = 130.192.225.17
130.192.225.15
IP.dst = 130.192.225.16
NAT
NAT
simmetrico
simmetrico
Da 10.0.0.1 a 130.192.225.15:
10.0.0.1 130.192.225.16
Da 10.0.0.1 a 130.192.225.17:
10.0.0.1 130.192.225.18
HostBB
Host
IP.src = 130.192.225.16
IP.dst = 130.192.225.15
HostCC
Host
130.192.225.17
49
STUN: Discovery del tipo di
NAT (1/2)
Si usa l’attributo CHANGE-REQUEST
della Binding request
Le richieste STUN hanno una serie di
attributi opzionali dopo l’header
Contiene due flag:
“Changed IP”: lo STUN server risponde da
un IP diverso
“Changed port”: lo STUN server risponde
da una porta
50
STUN: Discovery del tipo di
NAT (2/2)
Tre test effettuati:
Test 1
Test 2
Test 3
Changed IP
False
True
True
Changed port
False
True
false
Interpretandone i risultati si indiidua la
tipologia di NAT
51
STUN: NAT keepalive
Serve a due scopi:
Si multiplexano le richieste STUN sulla stessa
porta di un altro protocollo
Mantenere attivo un binding su un NAT
Verificare che il server sia attivo
Ad esempio può servire per tenere attiva una
connessione SIP: le richieste STUN sono inviate
sulla 5060
Se si rileva (dalla risposta) un cambiamento
dell’indirizzo pubblico si informa la
applicazione
52
STUN: modalità relay (1/5)
La binding discovery funziona solo se il NAT
rispetta le specifiche BEHAVE
Se il mapping è address dependendent o address
and port dependent, il reflexive transport address
è inutile
È il caso dei NAT simmetrici
L’unico modo per attraversare NAT non
BEHAVE consiste in un relay pubblico
Modalità descritta in un draft a parte
53
STUN: modalità relay (2/5)
Precedentemente funzionalità standalone nota come “traversal
using relay NAT” (TURN)
Lo STUN server mette a disposizione un suo indirizzo IP
L’indirizzo “prestato” è detto “relayed transport address”
Tutto il traffico passa dallo STUN server (ora detto STUN relay)
Due messaggi di richiesta:
Richiesta “allocate”
Richiesta “set active destiantion”
Due messaggi indication
Fornisce al client un’indirizzo di trasporto dello STUN server
Data
Send
Molto oneroso per lo STUN server
Questa modalità deve essere usata solo se è inevitabile
54
STUN: modalità relay (3/5)
Realm B
Internet
Realm A
Host
Host AA
(STUN
(STUN client)
client)
NAT
NAT
ALLOCATE
ALLOCATE
RESPONSE
NAT AA REQUEST
NAT BB
STUN
STUN relay
relay
Allocate request -> richiesta di un indirizzo pubblico del
server
Il client può richiedere una porta pubblica specifica
Allocate response -> contiene IP+porta allocati dal
server
L’indirizzo è detto “allocated transport address”
È l’indirizzo di una interfaccia del server
Viene mantenuto attivo con successive Allocate Request
La risposta contiene anche il mapped address
55
STUN: modalità relay (4/5)
Realm B
130.192.225.16:5060
STUN
STUN
relay
relay
Dst=130.192.225.16:5060
pacchetto
dati
130.192.225.20
ALLOCATE
DATA
RESPONSE
SEND(130.192.225.20:5060)
ALLOCATE
REQUEST
NAT
AA indication
NAT
NAT
NAT BB
130.192.225.16
Host
Host AA
(STUN
(STUN client)
client)
Host A
130.192.225.16:5060
Host BB
Host
Realm A
Internet
updated
drop
B non può mandare nulla ad A per primo
A manda una “Send indication”
Contiene dati per B
Aggiorna lo STUN relay
I dati mandati da B sono incapsulati nelle
“Data indication”
56
STUN: modalità relay (5/5)
I pacchetti dati sono tutti incapsulati
A => B: Send indication
B => A: Data indication
Ottimizzazione per ridurre l’overhead
Realm B
Internet
Realm A
Host
Host AA
(STUN
(STUN client)
client)
NAT
NAT AA
NAT
NAT BB
SET
SETACTIVE
ACTIVEDESTINATION
DESTINATIONREQUEST
RESPONSE
STUN
STUN relay
relay
I pacchetti non sono più incapsulati
57
Sommario
Concetti generali sui NAT
Specifiche BEHAVE: come dovrebbe essere un
NAT
Tecniche di Attraversamento
Relaying
Metodi UNSAF:
Hole punching
STUN (turn)
ICE
58
ICE: introduzione (1/2)
Interactive Connectivity Establishment
(ICE)
Documentazione su draft
Permette di fare NAT traversal per i
media stream
Funziona con i protocolli basati su
richiesta/offerta
Utilizza le funzionalità di STUN
59
ICE: introduzione (2/2)
A priori un host non conosce il realm
del destinatario
Deve provare con tutti gli indirizzi che ha
Un host ICE:
Ottiene tutti gli indirizzi che può
Li mette in una offerta
Negozia l’indirizzo migliore col destinatario
60
ICE: funzionamento
Host
Host AA
(STUN
(STUN client)
client)
ST
H IE
Z
RIZ
I
D
A IN
I
STUN
STUN
servers
servers
RIC
H
IES
TA I
NDI
RIZ
MEDIA
ZI
RIC TESTTEST
DELLA
DELLA
CONNETTIVITA’
CONNETTIVITA’
OFFERTA
RISPOSTA
(VALIDAZIONE)
(VALIDAZIONE)
MEDIA
Host A
Host
Host BB
(STUN
(STUN client)
client)
Host B
Azioni
descrizione
Azioni
descrizione
Richiesta
indirizzi
Cerca tutti gli ind. possibili
(STUN)
Richiesta
indirizzi
Cerca tutti gli ind. possibili
(STUN)
Invio offerta
contiene gli indirizzi ottenuti
precedentemente
Invio risposta
contiene gli indirizzi ottenuti
precedentemente
Testa la
connetività
Ricevuta la risposta con gli
indirizzi di B si verificano la
connettività delle coppie di
indirizzi
Testa la
connetività
Ricevuta la risposta con gli
indirizzi di B si verificano la
connettività delle coppie di
indirizzi
Avvia flusso
media
Lo stream è instradato su una
delle coppie vierificate
Avvia flusso
media
Lo stream è instradato su una
delle coppie vierificate
61
ICE ottenimento indirizzi (1/2)
Candidato = insieme di indirizzi di trasporto
(componenti) che formano una unità atomica
per un media stream
Es: Indirizzo RTP + indirizzo RTCP
Tipo di candidato
Tipo indirizzi di trasporto
Locale
Server reflexive
Indirizzo locale
Imparato da una richiesta a un server esterno
(STUN)
Peer reflexive
Imparato da una richiesta a un peer
(validazione)
Relayed
Fornito da un relay (STUN relay)
62
ICE ottenimento indirizzi (1/2)
L’host utilizza anche gli STUN relay
si manda una Allocate request per ogni indirizzo del
candidato locale con cui si ottengono:
Il client cerca i relayed address per un solo candidato
Se ne ha altri utilizza la STUN binding discovery
I reflexive address (dall’attributo MAPPED-ADDRESS della
risposta)
I relayed address (dall’attributo RELAYED-ADDRESS della
risposta)
Cerca solamente i reflexive address (manda delle Binding
Request)
L’invio delle STUN request è intervallato per ridurre
overhead
63
Generazione offerta/risposta
Si assegna una priorità a ogni candidato
Valore tra 0 e 1 (1=preferito)
Priorità più bassa ai candidati relayed
IPv6 prevale su IPv4
Si sceglie un candidato come default
Una volta validato si userà per il flusso
Si usa anche con UA ALEX unaware
Tipicamente è relayed
Le liste di candidati sono aggiunte alla
offerta/risposta
Payload SDP
64
SDP (cenni)
Session Description Protocol, RFC 2327
RFC 3266 aggiunge il supporto IPv6
Porta informazioni sui media stream delle
sessioni
Sessione multimediale = insieme flussi media
v=0
Originatore sessione
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
c= IN IP4 224.2.17.12/127
t=2873397496 2873404696
attributi
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 31
Indirizzo host che
origina i dati
Indirizzo host da cui è
originata la sessione
Descrizione media
65
Codifica dei candidati in SDP
La linea “a=“ serve a estendere SDP
Ogni candidato ha un set di linee “a=“ tanti quanti
sono i suoi componenti
a=candidate <ID candidato> <ID componente> <q-value> <indirizzo IP> <porta>
“a=ice_pwd” => password temporanea per i
connectivity check
“a=rtcp” => indirizzo + porta RTCP
Il candidato di default è messo nella linea “m”
66
Formazione delle coppie di
candidati
Si accoppiano due candidati solo sei i
protocolli di trasporto sono uguali
All’interno di una coppia di candidati si accoppiano
i componenti
Devono avere stesso component ID (numero
progressivo)
Per accelerare la convergenza le coppie di
candidati sono ordinate
Q-value degli “a=“
Se il q-value è uguale => candidate-ID
I candidati di default saranno comunque in cima
alla lista
67
Test di connettività
Si verifica la connettività fra i candidati
Ulitizza la modailità “connectivity check” di
STUN
Si basa su Binding Request e Binding
Response
Binding request intervallate (limitare
overhead)
Macchina a stati specifica per il trasporto
Rileva la bidirezionalità delle connessioni
Ogni candidato ha un stato derivato da quello dei
suoi componenti
68
Test di connettività: scoperta
di nuovi indirizzi
STUN
STUN server
server
(vero)
(vero)
t nse
s
e
u 2p)o
eq e
5.s
R
2
r
g
2
in 9in
2.g
d
n
1
Bi 20in. d
c 1B
r
s
NAT
Host
( Binding Request
Binding Request
NAT AA
Host BB
Binding
response
INVITE
INVITE
Binding
response
(src 10.0.0.1)
(simmetrico)
(simmetrico) (src 130.192.225.1) (STUN
(STUN server)
server)
Server reflexive address: 130.192.225.1
Peer reflexive address: 130.192.225.2
Host
Host AA
(STUN
(STUN client)
client)
NAT => address dependent mapping o
address and port dependent mapping
69
ICE e SIP
In SIP l’offerta è inviata tramite INVITE
Forking: un proxy può inoltrare una
INVITE a più UA
ICE interagisce bene con il forking
Lo scambio delle liste di indirizzi con gli ID
dei candidat aiuta a capire quali indirizzi
appartengono a un stesso UA
70
ANAT: introduzione
Alternative Network Address Types
(ANAT) RFC 4091
Estende SDP
Definisce due gruppi: IPv4 e IPv6
Si definisce “a=group:ANAT”
Si definisce “a=mid”: ID di gruppo
71
ANAT: esempio
v=0
o=bob 280744730 28977631 IN IP4 host.example.com s=
t=0 0
a=group:ANAT 1 2
m=audio 25000 RTP/AVP 0
Indirizzo di default
c=IN IP6 2001:DB8::1
a= <ICE-encoded additional IPv6 addresses (and ports)>
a=mid:1
m=audio 22334 RTP/AVP 0
ID di gruppo
c=IN IP4 192.0.2.1
a= <ICE-encoded additional IPv4 addresses (and ports)>
a=mid:2
Gruppo IPv6
72
ICE e ANAT
ICE esprime le alternative di un singolo tipo di
indirizzi
ANAT esprime alternative sul tipo degli
indirizzi
ANAT permette ad ICE di:
Separare bene IPv6 da IPv4
Avere due candidati di default
Ripartire meglio le priorità
Il gruppo IPv6 è ignorato da UA IPv4
73
Grazie per l’attenzione
Ci sono domande?
74

Documenti analoghi

Sicurezza e Gestione delle Reti (di telecomunicazioni)

Sicurezza e Gestione delle Reti (di telecomunicazioni) Il NAT tenta di adattarsi all’applicazione, ma le applicazioni tentano di adattarsi al tipo di NAT ! Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, “STUN - Simple Traversal of User Datagr...

Dettagli

seminario sul NAT traversal - the Netgroup at Politecnico di Torino

seminario sul NAT traversal - the Netgroup at Politecnico di Torino 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

Dettagli