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)
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...
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