22. IAB Considerations (Considerazioni IAB)

L'IAB ha studiato il problema del "Fissaggio unilaterale dell'auto-indirizzo" (Unilateral Self-Address Fixing), che è il processo generale mediante il quale un agente tenta di determinare il proprio indirizzo in un altro regno dall'altra parte di un NAT attraverso un meccanismo di riflessione del protocollo collaborativo [RFC3424]. ICE è un esempio di protocollo che esegue questo tipo di funzione. È interessante notare che il processo per ICE non è unilaterale, ma bilaterale, e la differenza ha un impatto significativo sulle questioni sollevate dallo IAB. Infatti, ICE può essere considerato un protocollo B-SAF (Bilateral Self-Address Fixing), piuttosto che un protocollo UNSAF. Indipendentemente da ciò, lo IAB ha imposto che qualsiasi protocollo sviluppato a questo scopo documenti una serie specifica di considerazioni. Questa sezione soddisfa tali requisiti.

22.1. Problem Definition (Definizione del problema)

Dalla RFC 3424, qualsiasi proposta UNSAF deve fornire:

Definizione precisa di un problema specifico e a portata limitata che deve essere risolto con la proposta UNSAF. Una soluzione a breve termine non dovrebbe essere generalizzata per risolvere altri problemi; questo è il motivo per cui "le soluzioni a breve termine di solito non lo sono".

I problemi specifici risolti da ICE sono:

• Fornire un mezzo a due peer per determinare l'insieme di indirizzi di trasporto che possono essere utilizzati per la comunicazione.

• Fornire un mezzo a un agente per determinare un indirizzo raggiungibile da un altro peer con cui desidera comunicare.

22.2. Exit Strategy (Strategia di uscita)

Dalla RFC 3424, qualsiasi proposta UNSAF deve fornire:

Descrizione di una strategia di uscita/piano di transizione. Le migliori soluzioni a breve termine sono quelle che vedranno naturalmente sempre meno utilizzo man mano che viene implementata la tecnologia appropriata.

ICE stesso non viene eliminato facilmente. Tuttavia, è utile anche in un Internet connesso a livello globale, per servire come mezzo per rilevare se un guasto del router ha interrotto temporaneamente la connettività, ad esempio. ICE aiuta anche a prevenire alcuni attacchi alla sicurezza che non hanno nulla a che fare con il NAT. Tuttavia, ciò che fa ICE è aiutare a eliminare gradualmente altri meccanismi UNSAF. ICE seleziona efficacemente tra tali meccanismi, dando priorità a quelli migliori e togliendo priorità a quelli peggiori. Gli indirizzi IPv6 locali possono essere preferiti. Man mano che i NAT iniziano a dissiparsi con l'introduzione di IPv6, i candidati server reflexive e relayed (entrambe forme di indirizzi UNSAF) semplicemente non vengono mai utilizzati, perché esiste una connettività con priorità più alta verso i candidati host nativi. Pertanto, i server vengono utilizzati sempre meno e possono eventualmente essere rimossi quando il loro utilizzo va a zero.

In effetti, ICE può aiutare nella transizione da IPv4 a IPv6. Può essere utilizzato per determinare se utilizzare IPv6 o IPv4 quando due host dual-stack comunicano con SIP (viene utilizzato IPv6). Può anche consentire a una rete con connettività sia 6to4 che v6 nativa di determinare quale indirizzo utilizzare quando comunica con un peer.

22.3. Brittleness Introduced by ICE (Fragilità introdotta da ICE)

Dalla RFC 3424, qualsiasi proposta UNSAF deve fornire:

Discussione di questioni specifiche che possono rendere i sistemi più "fragili". Ad esempio, gli approcci che comportano l'utilizzo di dati a più livelli di rete creano più dipendenze, aumentano le sfide di debug e rendono più difficile la transizione.

ICE rimuove effettivamente la fragilità dai meccanismi UNSAF esistenti. In particolare, lo STUN classico (come descritto nella RFC 3489 [RFC3489]) ha diversi punti di fragilità. Uno di questi è il processo di scoperta che richiede a un agente di provare a classificare il tipo di NAT dietro cui si trova. Questo processo è soggetto a errori. Con ICE, quel processo di scoperta non viene semplicemente utilizzato. Invece di valutare unilateralmente la validità dell'indirizzo, la sua validità viene determinata dinamicamente misurando la connettività con un peer. Il processo di determinazione della connettività è molto robusto.

Un altro punto di fragilità nello STUN classico e in qualsiasi altro meccanismo unilaterale è la sua assoluta dipendenza da un server aggiuntivo. ICE fa uso di un server per allocare indirizzi unilaterali, ma consente agli agenti di connettersi direttamente se possibile. Pertanto, in alcuni casi, il guasto di un server STUN consentirebbe comunque a una chiamata di progredire quando viene utilizzato ICE.

Un altro punto di fragilità nello STUN classico è che presuppone che il server STUN sia sull'Internet pubblico. È interessante notare che con ICE non è necessario. Ci può essere una moltitudine di server STUN in una varietà di regni di indirizzi. ICE scoprirà quello che ha fornito un indirizzo utilizzabile.

Il punto di fragilità più preoccupante nello STUN classico è che non funziona in tutte le topologie di rete. Nei casi in cui è presente un NAT condiviso tra ciascun agente e il server STUN, lo STUN tradizionale potrebbe non funzionare. Con ICE, tale restrizione viene rimossa.

Lo STUN classico introduce anche alcune considerazioni sulla sicurezza. Fortunatamente, tali considerazioni sulla sicurezza sono mitigate anche da ICE.

Di conseguenza, ICE serve a riparare la fragilità introdotta nello STUN classico e non introduce alcuna fragilità aggiuntiva nel sistema.

La penalità di questi miglioramenti è che ICE aumenta i tempi di creazione della sessione.

22.4. Requirements for a Long-Term Solution (Requisiti per una soluzione a lungo termine)

Dalla RFC 3424, qualsiasi proposta UNSAF deve fornire:

... requisiti per soluzioni tecniche solide a lungo termine -- contribuire al processo di ricerca della giusta soluzione a lungo termine.

Le nostre conclusioni dalla RFC 3489 rimangono invariate. Tuttavia, riteniamo che ICE aiuti effettivamente perché crediamo che possa far parte della soluzione a lungo termine.

22.5. Issues with Existing NAPT Boxes (Problemi con le box NAPT esistenti)

Dalla RFC 3424, qualsiasi proposta UNSAF deve fornire:

Discussione dell'impatto delle questioni pratiche rilevate con i NA[P]T esistenti e implementati e rapporti sull'esperienza.

Un certo numero di box NAT viene ora distribuito sul mercato che cerca di fornire funzionalità ALG "generiche". Questi ALG generici cercano indirizzi IP, in forma testuale o binaria all'interno di un pacchetto, e li riscrivono se corrispondono a un binding. Ciò interferisce con lo STUN classico. Tuttavia, l'aggiornamento a STUN [RFC5389] utilizza una codifica che nasconde questi indirizzi binari dagli ALG generici.

Le box NAPT esistenti hanno tempi di scadenza non deterministici e tipicamente brevi per i binding basati su UDP. Ciò richiede che le implementazioni inviino keepalive periodici per mantenere tali binding. ICE utilizza un valore predefinito di 15 s, che è una stima molto conservativa. Alla fine, nel tempo, man mano che le box NAT diventano conformes a behave [RFC4787], questo keepalive minimo diventerà deterministico e ben noto e i timer ICE potranno essere regolati. Avere un modo per scoprire e controllare l'intervallo di keepalive minimo sarebbe ancora molto meglio.