Appendix A. Interaction with Regular ICE (Interazione con ICE regolare)

Il protocollo ICE è stato progettato per essere sufficientemente flessibile da funzionare e adattarsi a quanti più ambienti di rete possibile. Nonostante questa flessibilità, ICE come specificato in [RFC8445] non supporta Trickle ICE da solo. Questa sezione descrive come il trickling dei candidati interagisce con ICE.

[RFC8445] descrive le condizioni richieste per aggiornare le checklist e gli stati dei timer mentre un agente ICE è nello stato In esecuzione (Running). Queste condizioni vengono verificate al completamento della transazione, e una di esse stabilisce che:

se non c'è una coppia valida nella lista valida per ogni componente del flusso di dati associato alla checklist, lo stato della checklist viene impostato su Fallito (Failed).

Questo potrebbe essere un problema e causare il fallimento prematuro del trattamento ICE in un certo numero di scenari. Considerare il seguente caso:

Scenario 1: Collisione di blocchi di indirizzi privati

1. Alice e Bob sono entrambi situati in reti diverse con Network Address Translation (NAT). Alice e Bob stessi hanno indirizzi diversi, ma entrambe le reti utilizzano lo stesso blocco internet privato (ad esempio, il "blocco da 20 bit" 172.16/12 specificato in [RFC1918]).
2. Alice trasmette a Bob il candidato 172.16.0.1, che corrisponde anche a un host esistente sulla rete di Bob.
3. Bob crea una coppia di candidati dal suo candidato host e 172.16.0.1, posiziona questa coppia in una checklist e avvia i controlli.
4. Questi controlli raggiungono l'host a 172.16.0.1 sulla rete di Bob, che risponde con un errore ICMP "porta irraggiungibile"; secondo [RFC8445], Bob segna la transazione come Fallita.

A questo punto, la checklist contiene solo una coppia Fallita, e la lista valida è vuota. Questo porta al fallimento del flusso di dati e potenzialmente all'intero trattamento ICE, anche se gli agenti Trickle ICE possono successivamente trasmettere candidati che potrebbero avere successo.

Scenario 2: Non corrispondenza della famiglia di indirizzi

Una condizione di gara simile si verificherebbe se la descrizione ICE iniziale di Alice contiene solo candidati che possono essere determinati come irraggiungibili da qualsiasi candidato che Bob ha raccolto (ad esempio, questo sarebbe il caso se i candidati di Bob contenessero solo indirizzi IPv4 e il primo candidato che riceve da Alice è un indirizzo IPv6).

Scenario 3: Interazione Non-Trickle ICE

Un altro potenziale problema potrebbe sorgere quando un'implementazione Non-Trickle ICE avvia un'interazione con un'implementazione Trickle ICE. Considerare il seguente caso:

1. Il client di Alice ha un'implementazione Non-Trickle ICE.
2. Il client di Bob supporta Trickle ICE.
3. Alice e Bob sono dietro NAT con filtraggio dipendente dall'indirizzo [RFC4787].
4. Bob ha due server STUN, ma uno di essi è attualmente irraggiungibile.

Dopo che l'agente di Bob ha ricevuto la descrizione ICE iniziale di Alice, inizierebbe immediatamente i controlli di connettività. Inizierebbe anche a raccogliere candidati, il che richiederebbe molto tempo a causa del server STUN irraggiungibile. Nel momento in cui la risposta di Bob è pronta e trasmessa ad Alice, i controlli di connettività di Bob potrebbero essere falliti: fino a quando Alice non ottiene la risposta di Bob, non potrà iniziare i controlli di connettività e forare buchi nel suo NAT. Il NAT filtrerebbe quindi i controlli di Bob come provenienti da un endpoint sconosciuto.

---