Appendix B. Design Motivations (Motivazioni di progettazione)

ICE contiene una serie di comportamenti normativi che possono essere essi stessi semplici, ma derivano da pensieri complicati o non ovvi o casi d'uso che meritano ulteriori discussioni. Poiché queste motivazioni di progettazione non sono necessarie da comprendere ai fini dell'implementazione, vengono discusse qui in un'appendice alla specifica. Questa sezione non è normativa.

B.1. Pacing of STUN Transactions (Pacing delle transazioni STUN)

Le transazioni STUN utilizzate per raccogliere candidati e verificare la connettività vengono regolate a una velocità approssimativa di una nuova transazione ogni Ta millisecondi. Ogni transazione, a sua volta, ha un timer di ritrasmissione RTO che è anch'esso una funzione di Ta. Perché queste transazioni sono regolate e perché vengono utilizzate queste formule?

L'invio di queste richieste STUN avrà spesso l'effetto di creare binding sui dispositivi NAT tra il client e i server STUN. L'esperienza ha dimostrato che molti dispositivi NAT hanno limiti superiori alla velocità con cui creeranno nuovi binding. Gli esperimenti hanno dimostrato che una volta ogni 20 ms è ben supportato, ma non molto inferiore a quello. Questo è il motivo per cui Ta ha un limite inferiore di 20 ms. Inoltre, la trasmissione di questi pacchetti sulla rete fa uso della larghezza di banda e deve essere limitata in velocità dall'agente. Le implementazioni basate su versioni precedenti di bozza di questo documento tendevano a sovraccaricare i collegamenti di accesso con vincoli di velocità e a funzionare male nel complesso, oltre a influire negativamente sulla rete. Di conseguenza, il pacing assicura che il dispositivo NAT non venga sovraccaricato e che il traffico sia mantenuto a una velocità ragionevole.

B.2. Candidates with Multiple Bases (Candidati con più basi)

La sezione 4.1.3 parla dell'eliminazione dei candidati che hanno lo stesso indirizzo di trasporto e la stessa base. Tuttavia, i candidati con gli stessi indirizzi di trasporto ma basi diverse non sono ridondanti. Quando un agente può avere due candidati che hanno lo stesso indirizzo IP e porta, ma basi diverse?

Considera un caso in cui un offerente è multihomed. Ha un indirizzo IP su una rete privata C e un altro sulla rete A che è NATtata sulla rete B. L'offerente ottiene un candidato host su C e un candidato host su A. Esegue una query STUN da A, che passa attraverso il NAT e viene assegnato un binding che capita di corrispondere all'IP:porta su C. Ora, l'offerente ha ottenuto un candidato server reflexive con un indirizzo di trasporto identico a un candidato host. Tuttavia, il candidato server reflexive ha una base diversa rispetto al candidato host.

B.3. Purpose of the <rel-addr> and <rel-port> Attributes (Scopo degli attributi <rel-addr> e <rel-port>)

L'attributo candidate contiene due valori che non vengono utilizzati affatto da ICE stesso -- <rel-addr> e <rel-port>. Perché è presente?

Ci sono due motivazioni per la sua inclusione. La prima è diagnostica. È molto utile conoscere la relazione tra i diversi tipi di candidati. Includendolo, un agente può sapere quale candidato relay è associato a quale candidato reflexive, che a sua volta è associato a uno specifico candidato host. Quando i controlli per un candidato hanno successo e non per altri, ciò fornisce una diagnostica utile su cosa sta succedendo nella rete.

Il secondo motivo ha a che fare con i meccanismi di Quality of Service (QoS) off-path. Quando ICE viene utilizzato in ambienti come PacketCable 2.0, i proxy ispezioneranno l'SDP ed estrarranno l'indirizzo IP e la porta per il traffico multimediale per stabilire una QoS garantita. Quando viene selezionato un candidato relay, il proxy ha bisogno del candidato server reflexive verso il server TURN per richiedere la QoS al router di accesso. Trasportando la traduzione nell'SDP, il proxy può utilizzare quell'indirizzo di trasporto.

B.4. Importance of the STUN Username (Importanza del nome utente STUN)

ICE richiede l'utilizzo dell'integrità del messaggio con STUN utilizzando la sua funzionalità di credenziali a breve termine. Le credenziali a breve termine effettive sono formate scambiando frammenti di nome utente nello scambio offerta/risposta SDP. La necessità di questo meccanismo va oltre la semplice sicurezza; è effettivamente richiesto per il corretto funzionamento di ICE in primo luogo.

Considera gli agenti L, R e Z in reti private sovrapposte. L invia un'offerta a Z. Z fornisce candidati host. R sta usando per caso lo stesso IP:porta di Z. L invia una richiesta STUN che va a R invece che a Z. Se R rispondesse semplicemente, L crederebbe di avere connettività con Z. Per risolvere questo problema, vengono utilizzati i meccanismi di credenziali a breve termine STUN. I frammenti di nome utente sono sufficientemente casuali che è altamente improbabile che R stia utilizzando gli stessi valori di Z. Di conseguenza, R rifiuterebbe la richiesta STUN poiché le credenziali non erano valide.

B.5. The Candidate Pair Priority Formula (La formula di priorità della coppia di candidati)

La priorità per una coppia di candidati ha una forma strana. È:

pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

Perché questo? Quando le coppie di candidati vengono ordinate in base a questo valore, l'ordinamento risultante ha la proprietà MAX/MIN. Ciò significa che le coppie vengono prima ordinate in base al valore decrescente del minimo delle due priorità. Per le coppie che hanno lo stesso valore della priorità minima, la priorità massima viene utilizzata per ordinare tra di loro. Se le priorità massima e minima sono le stesse, la priorità dell'agente di controllo viene utilizzata come spareggio. Questo crea l'ordinamento MAX/MIN. MAX/MIN assicura che, per un particolare agente, un candidato a priorità inferiore non venga mai utilizzato fino a quando non sono stati provati tutti i candidati a priorità superiore.

B.6. The remote-candidates Attribute (L'attributo remote-candidates)

L'attributo a=remote-candidates esiste per eliminare una race condition tra l'offerta aggiornata e la risposta alla richiesta di Binding STUN che ha spostato un candidato nell'elenco Valid. Per eliminare questa condizione, i candidati effettivi su R che sono stati selezionati dall'offerente (i candidati remoti) sono inclusi nell'offerta stessa e il risponditore ritarda la sua risposta fino alla convalida di tali coppie.

B.7. Why Are Keepalives Needed? (Perché sono necessari i keepalive?)

Una volta che i media iniziano a fluire su una coppia di candidati, è ancora necessario mantenere vivi i binding ai NAT intermedi per la durata della sessione. Normalmente, i pacchetti del flusso multimediale stessi soddisfano questo obiettivo. Tuttavia, se i media vengono messi in attesa o se viene utilizzata la soppressione del silenzio, la trasmissione dei media potrebbe cessare sufficientemente a lungo da far scadere i binding NAT. Per questi motivi, non si può fare affidamento sui pacchetti multimediali stessi. ICE definisce un semplice keepalive periodico che utilizza le indicazioni di Binding STUN.

B.8. Why Prefer Peer Reflexive Candidates? (Perché preferire i candidati peer reflexive?)

La sezione 4.1.2 richiede che la preferenza di tipo per i candidati peer reflexive sia sempre superiore a quella server reflexive. Perché questo? Il motivo ha a che fare con le considerazioni sulla sicurezza. È molto più facile per un attaccante indurre un agente a utilizzare un falso candidato server reflexive di quanto non lo sia per un attaccante indurre un agente a utilizzare un falso candidato peer reflexive. Di conseguenza, gli attacchi contro la raccolta degli indirizzi con le richieste di Binding vengono sventati da ICE preferendo i candidati peer reflexive.

B.9. Why Send an Updated Offer? (Perché inviare un'offerta aggiornata?)

Entrambi gli agenti possono inviare media una volta completati i controlli ICE, senza attendere un'offerta aggiornata. In effetti, l'unico scopo dell'offerta aggiornata è "correggere" l'SDP in modo che la destinazione predefinita per i media corrisponda a dove vengono inviati i media in base alle procedure ICE (che sarà la coppia di candidati nominata con la priorità più alta).

Perché è necessario lo scambio offerta/risposta aggiornato? In pratica, numerosi componenti lungo il percorso di segnalazione esaminano le informazioni SDP (ad esempio, per QoS, attraversamento NAT, diagnostica). Affinché questi strumenti continuino a funzionare senza modifiche, la proprietà principale dell'SDP -- che le definizioni esistenti pre-ICE degli indirizzi utilizzati per i media devono essere mantenute. Per questo motivo, deve essere inviata un'offerta aggiornata.

B.10. Why Are Binding Indications Used for Keepalives? (Perché le indicazioni di Binding vengono utilizzate per i keepalive?)

Il motivo principale ha a che fare con i meccanismi QoS di rete. Se un agente sta inviando pacchetti multimediali e quindi riceve una richiesta di Binding, dovrebbe generare un pacchetto di risposta insieme ai suoi pacchetti multimediali. Ciò aumenterà i requisiti effettivi di larghezza di banda e introdurrà jitter. L'utilizzo di un'indicazione di Binding consente di disabilitare l'integrità, consentendo prestazioni migliori.

B.11. Why Is the Conflict Resolution Mechanism Needed? (Perché è necessario il meccanismo di risoluzione dei conflitti?)

La condizione in cui entrambi gli agenti credono di essere controllati si presenta nei casi di controllo delle chiamate di terze parti. Ad esempio, un controller invia un INVITE senza offerta all'agente A, che risponde con un'offerta. Il controller invia quindi un INVITE senza offerta all'agente B, che risponde con un'offerta. Il controller utilizza le offerte per generare risposte. Quando viene utilizzato questo flusso, ICE verrà eseguito tra gli agenti A e B, ma entrambi crederanno di essere nel ruolo di controllo. Con le procedure di risoluzione dei conflitti di ruolo, questo flusso funzionerà correttamente.