Appendix A. Interaction with Regular ICE (Interaction avec l'ICE régulier)

Le protocole ICE a été conçu pour être suffisamment flexible pour fonctionner et s'adapter à autant d'environnements réseau que possible. Malgré cette flexibilité, ICE tel que spécifié dans [RFC8445] ne prend pas en charge Trickle ICE par lui-même. Cette section décrit comment le trickling des candidats interagit avec ICE.

[RFC8445] décrit les conditions requises pour mettre à jour les listes de vérification et les états de minuterie pendant qu'un agent ICE est dans l'état En cours d'exécution (Running). Ces conditions sont vérifiées lors de l'achèvement de la transaction, et l'une d'elles stipule que :

s'il n'y a pas de paire valide dans la liste valide pour chaque composant du flux de données associé à la liste de vérification, l'état de la liste de vérification est défini sur Échoué (Failed).

Cela pourrait être un problème et causer l'échec prématuré du traitement ICE dans un certain nombre de scénarios. Considérez le cas suivant :

Scénario 1 : Collision de blocs d'adresses privées

1. Alice et Bob sont tous deux situés dans différents réseaux avec traduction d'adresses réseau (NAT). Alice et Bob eux-mêmes ont des adresses différentes, mais les deux réseaux utilisent le même bloc internet privé (par exemple, le « bloc de 20 bits » 172.16/12 spécifié dans [RFC1918]).
2. Alice transmet à Bob le candidat 172.16.0.1, qui correspond également à un hôte existant sur le réseau de Bob.
3. Bob crée une paire de candidats à partir de son candidat hôte et 172.16.0.1, place cette paire dans une liste de vérification et démarre les vérifications.
4. Ces vérifications atteignent l'hôte à 172.16.0.1 dans le réseau de Bob, qui répond avec une erreur ICMP « port inaccessible » ; selon [RFC8445], Bob marque la transaction comme Échouée.

À ce stade, la liste de vérification ne contient qu'une paire Échouée, et la liste valide est vide. Cela entraîne l'échec du flux de données et potentiellement de tout le traitement ICE, même si les agents Trickle ICE peuvent ultérieurement transmettre des candidats qui pourraient réussir.

Scénario 2 : Non-concordance de famille d'adresses

Une condition de course similaire se produirait si la description ICE initiale d'Alice ne contient que des candidats qui peuvent être déterminés comme inaccessibles à partir de n'importe lequel des candidats que Bob a collectés (par exemple, ce serait le cas si les candidats de Bob ne contenaient que des adresses IPv4 et le premier candidat qu'il reçoit d'Alice est une adresse IPv6).

Scénario 3 : Interaction Non-Trickle ICE

Un autre problème potentiel pourrait survenir lorsqu'une implémentation Non-Trickle ICE initie une interaction avec une implémentation Trickle ICE. Considérez le cas suivant :

1. Le client d'Alice a une implémentation Non-Trickle ICE.
2. Le client de Bob prend en charge Trickle ICE.
3. Alice et Bob sont derrière des NAT avec filtrage dépendant de l'adresse [RFC4787].
4. Bob a deux serveurs STUN, mais l'un d'eux est actuellement inaccessible.

Après que l'agent de Bob a reçu la description ICE initiale d'Alice, il commencerait immédiatement les vérifications de connectivité. Il commencerait également à collecter des candidats, ce qui prendrait beaucoup de temps en raison du serveur STUN inaccessible. Au moment où la réponse de Bob est prête et transmise à Alice, les vérifications de connectivité de Bob pourraient avoir échoué : jusqu'à ce qu'Alice obtienne la réponse de Bob, elle ne pourra pas commencer les vérifications de connectivité et percer des trous dans son NAT. Le NAT filtrerait donc les vérifications de Bob comme provenant d'un point de terminaison inconnu.

---