Aller au contenu principal

RFC 8838 - Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol

  • Statut: Proposed Standard
  • Publié: January 2021
  • Stream: IETF
  • Errata: Pas d'errata

Résumé (Abstract)​

Ce document décrit « Trickle ICE », une extension du protocole ICE (Interactive Connectivity Establishment) qui permet aux agents ICE de commencer les vérifications de connectivité pendant qu'ils collectent encore des candidats, en échangeant les candidats de manière incrémentale au fil du temps au lieu de tous en une seule fois. Cette méthode peut considérablement accélérer le processus d'établissement d'une session de communication.

Table des matières (Table of Contents)​

Annexes (Appendices)​

1. Introduction (Introduction)​

Le protocole ICE (Interactive Connectivity Establishment) [RFC8445] décrit comment un agent ICE collecte des candidats, échange des candidats avec un agent ICE pair et crée des paires de candidats. Une fois les paires collectées, l'agent ICE effectuera des vérifications de connectivité et finira par nommer et sélectionner les paires qui seront utilisées pour envoyer et recevoir des données dans une session de communication.

Le respect des procédures dans [RFC8445] peut entraîner des temps d'établissement quelque peu longs pour les sessions de communication, car la collecte de candidats implique souvent l'interrogation de serveurs STUN (Session Traversal Utilities for NAT) [RFC5389] et l'allocation de candidats relayés sur des serveurs TURN (Traversal Using Relay NAT) [RFC5766]. Bien que de nombreuses procédures ICE puissent être effectuées en parallèle, les exigences de rythme de [RFC8445] doivent toujours être respectées.

Ce document définit « Trickle ICE », un mode d'opération supplémentaire d'ICE dans lequel les candidats peuvent être échangés de manière incrémentale dès qu'ils deviennent disponibles (et simultanément avec la collecte d'autres candidats). Les vérifications de connectivité peuvent également commencer dès que les paires de candidats ont été créées. Comme Trickle ICE permet d'effectuer la collecte de candidats et les vérifications de connectivité en parallèle, la méthode peut considérablement accélérer le processus d'établissement d'une session de communication.

Ce document définit également comment découvrir le support de Trickle ICE, comment les procédures dans [RFC8445] sont modifiées ou complétées lors de l'utilisation de Trickle ICE, et comment un agent Trickle ICE peut interopérer avec un agent ICE conforme à [RFC8445].

Ce document ne définit aucune utilisation spécifique au protocole de Trickle ICE. Au lieu de cela, les détails spécifiques au protocole pour Trickle ICE sont définis dans des documents d'utilisation séparés. Des exemples de tels documents sont [RFC8840] (qui définit l'utilisation avec le protocole SIP (Session Initiation Protocol) [RFC3261] et le protocole SDP (Session Description Protocol) [RFC4566]) et [XEP-0176] (qui définit l'utilisation avec le protocole XMPP (Extensible Messaging and Presence Protocol) [RFC6120]). Cependant, certains des exemples dans le document utilisent SDP et le modèle Offre/Réponse (Offer/Answer) [RFC3264] pour expliquer les concepts sous-jacents.

Le diagramme suivant illustre un échange Trickle ICE réussi avec un protocole d'utilisation qui suit le modèle Offre/Réponse :

     Alice                                            Bob
       |                     Offre                     |
       |---------------------------------------------->|
       |          Candidats supplémentaires            |
       |---------------------------------------------->|
       |                     Réponse                   |
       |<----------------------------------------------|
       |          Candidats supplémentaires            |
       |<----------------------------------------------|
       |  Candidats supplémentaires et vérifications   |
       |<--------------------------------------------->|
       |<========== CONNEXION ÉTABLIE ================>|

Figure 1 : Flux (Flow)

Le corps principal de ce document est structuré pour décrire le comportement des agents Trickle ICE dans l'ordre approximatif des opérations et des interactions lors d'une session ICE :

  1. Détermination du support de Trickle ICE
  2. Génération de la description ICE initiale
  3. Traitement de la description ICE initiale et génération de la réponse ICE initiale
  4. Traitement de la réponse ICE initiale
  5. Formation de listes de vérification, élagage des candidats, exécution des vérifications de connectivité, etc.
  6. Collecte et transmission des candidats après la description ICE initiale et la réponse
  7. Traitement des candidats trickle entrants
  8. Génération et traitement de l'indication de fin de candidats
  9. Traitement des redémarrages ICE

Il existe une expérience opérationnelle considérable avec la technique derrière Trickle ICE, remontant à 2005 (lorsque l'extension XMPP Jingle a défini un « dribble mode » tel que spécifié dans [XEP-0176]) ; ce document intègre les retours de ceux qui ont implémenté et déployé la technique au fil des ans.

2. Terminology (Terminologie)​

Les mots-clés « doit (MUST) », « ne doit pas (MUST NOT) », « requis (REQUIRED) », « doit (SHALL) », « ne doit pas (SHALL NOT) », « devrait (SHOULD) », « ne devrait pas (SHOULD NOT) », « recommandé (RECOMMENDED) », « non recommandé (NOT RECOMMENDED) », « peut (MAY) » et « optionnel (OPTIONAL) » dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Cette spécification utilise toute la terminologie définie pour l'établissement de connectivité interactive (Interactive Connectivity Establishment) dans [RFC8445]. De plus, elle définit les termes suivants :

Liste de vérification vide (Empty Checklist) : Une liste de vérification qui ne contient initialement aucune paire de candidats car elles seront ajoutées de manière incrémentale au fur et à mesure qu'elles sont trickle. (Ce scénario ne se produit pas avec un agent ICE régulier, car toutes les paires de candidats sont connues lorsque l'agent crée l'ensemble de listes de vérification.)

Trickle complet (Full Trickle) : Le mode de fonctionnement typique pour les agents Trickle ICE, dans lequel la description ICE initiale peut inclure n'importe quel nombre de candidats (même zéro candidat) et n'a pas besoin d'inclure une génération complète de candidats comme dans le half trickle.

Génération (Generation) : Tous les candidats transmis au sein d'une session ICE (corrélés avec une combinaison particulière de fragment de nom d'utilisateur (Username Fragment) et de mot de passe (Password)).

Half Trickle : Un mode de fonctionnement Trickle ICE dans lequel l'initiateur collecte une génération complète de candidats strictement avant de créer et de transmettre la description ICE initiale. Une fois transmises, ces informations de candidat peuvent être traitées par des agents ICE réguliers, qui ne nécessitent pas de support pour Trickle ICE. Cela permet également aux répondeurs compatibles Trickle ICE de toujours collecter des candidats et d'effectuer des vérifications de connectivité de manière non bloquante, offrant ainsi environ « la moitié » des avantages de Trickle ICE. Le mécanisme half-trickle est principalement destiné à être utilisé lorsque le support de Trickle ICE du répondeur ne peut pas être confirmé avant de transmettre la description ICE initiale.

Description ICE (ICE Description) : Tous les attributs liés à la session ICE (autres que les candidats) requis pour configurer un agent ICE. Ceux-ci incluent, mais ne sont pas limités à, le fragment de nom d'utilisateur (Username Fragment), le mot de passe (Password) et d'autres attributs.

Candidats Trickle (Trickled Candidates) : Candidats qu'un agent Trickle ICE transmet après avoir transmis ou répondu à la description ICE initiale, mais au sein de la même session ICE. Les candidats trickle peuvent être transmis en parallèle avec la collecte de candidats et les vérifications de connectivité.

Trickling : L'acte de transmettre de manière incrémentale des candidats trickle.

3. Determining Support for Trickle ICE (Détermination du support de Trickle ICE)​

Pour prendre pleinement en charge Trickle ICE, les protocoles d'utilisation devraient (SHOULD) incorporer l'un des mécanismes suivants afin que les implémentations puissent déterminer si Trickle ICE est pris en charge :

  1. Fournir une méthode de découverte de capacités afin que les agents puissent vérifier le support de Trickle ICE avant d'initier une session (la découverte de service (Service Discovery) de XMPP [XEP-0030] est l'un de ces mécanismes).

  2. Rendre le support de Trickle ICE obligatoire afin que les agents utilisateurs puissent supposer le support.

Si un protocole d'utilisation ne fournit pas de méthode pour déterminer à l'avance si Trickle ICE est pris en charge, les agents peuvent utiliser la procédure half-trickle décrite dans la section 16.

Avant de transmettre la description ICE initiale, les agents qui implémentent des protocoles d'utilisation prenant en charge la découverte de capacités peuvent tenter de vérifier si la partie distante prend en charge Trickle ICE ou non. Si un agent détermine que la partie distante ne prend pas en charge Trickle ICE, il doit (MUST) revenir à l'utilisation d'ICE régulier ou abandonner la session entière.

Même si un protocole d'utilisation n'inclut pas de méthode de découverte de capacités, un agent utilisateur peut fournir une indication dans la description ICE qu'il prend en charge Trickle ICE en communiquant une option ICE de 'trickle'. Ce jeton doit (MUST) être fourni soit au niveau de la session, soit, s'il est au niveau du flux de données, pour chaque flux de données (un agent ne doit pas (MUST NOT) spécifier le support de Trickle ICE pour certains flux de données mais pas pour d'autres). Remarque : L'encodage de l'option ICE 'trickle' et le(s) message(s) utilisé(s) pour le transmettre au pair sont spécifiques au protocole ; par exemple, l'encodage pour SDP [RFC4566] est défini dans [RFC8840].

Les sémantiques de découverte dédiées et le half trickle ne sont nécessaires qu'avant l'initiation d'une session ICE. Après qu'une session ICE est établie et que le support de Trickle ICE est confirmé pour les deux parties, l'un ou l'autre agent peut utiliser le trickle complet pour les échanges ultérieurs (voir également la section 15).

4. Generating the Initial ICE Description (Génération de la description ICE initiale)​

Un agent ICE peut commencer à collecter des candidats dès qu'il a une indication que la communication est imminente (par exemple, un signal d'interface utilisateur ou une demande explicite d'initier une session de communication). Contrairement à l'ICE régulier, dans les implémentations Trickle ICE, il n'est pas nécessaire de collecter les candidats de manière bloquante. Par conséquent, à moins que le half trickle ne soit utilisé, l'expérience utilisateur est améliorée si l'agent initiateur génère et transmet sa description ICE initiale le plus tôt possible (permettant ainsi à la partie distante de commencer à collecter et à trickle les candidats).

Un initiateur peut (MAY) inclure n'importe quelle combinaison de candidats lors de la transmission de la description ICE initiale. Cela inclut la possibilité de transmettre tous les candidats que l'initiateur prévoit d'utiliser (comme dans le half trickle), de transmettre uniquement une adresse IP publiquement accessible (par exemple, un candidat sur un relais de données dont on sait qu'il n'est pas derrière un pare-feu), ou de ne transmettre aucun candidat (auquel cas l'initiateur peut obtenir la liste de candidats initiale du répondeur plus tôt, et le répondeur peut commencer la collecte de candidats plus rapidement).

Pour les candidats inclus dans la description ICE initiale, les méthodes de calcul des priorités et des fondations (Foundations), de détermination de la redondance des candidats, et similaires fonctionnent exactement comme dans l'ICE régulier [RFC8445].

5. Handling the Initial ICE Description and Generating the Initial ICE Response (Traitement de la description ICE initiale et génération de la réponse ICE initiale)​

Lorsqu'un répondeur reçoit la description ICE initiale, il vérifie d'abord si la description ICE ou l'initiateur indique le support de Trickle ICE comme expliqué dans la section 3. Si ce n'est pas le cas, le répondeur doit (MUST) traiter la description ICE initiale selon les procédures ICE régulières [RFC8445] (ou, si aucun support ICE n'est détecté du tout, selon les règles de traitement pertinentes pour le protocole d'utilisation, telles que les règles de traitement Offre/Réponse [RFC3264]). Cependant, si le support de Trickle ICE est confirmé, un répondeur supposera automatiquement le support de l'ICE régulier également.

Si la description ICE initiale indique le support de Trickle ICE, le répondeur déterminera son rôle et commencera à collecter et à hiérarchiser les candidats ; ce faisant, il répondra également en transmettant une réponse ICE initiale, afin que l'initiateur et le répondeur puissent former des listes de vérification et commencer les vérifications de connectivité.

Un répondeur peut répondre à la description ICE initiale à tout moment pendant la collecte des candidats. La réponse ICE initiale peut (MAY) contenir n'importe quel ensemble de candidats, y compris tous les candidats ou aucun candidat. (L'avantage de n'inclure aucun candidat est de transmettre la réponse ICE initiale aussi rapidement que possible, afin que les deux parties puissent considérer la session ICE comme étant en négociation active le plus tôt possible.)

Comme noté dans la section 3, dans les protocoles d'utilisation qui utilisent SDP, la réponse ICE initiale peut indiquer le support de Trickle ICE en incluant un jeton 'trickle' dans l'attribut ice-options.

8. Performing Connectivity Checks (Exécution des vérifications de connectivité)​

Comme spécifié dans [RFC8445], chaque fois que le temporisateur Ta se déclenche, seules les listes de vérification dans l'état En cours (Running) seront sélectionnées lors de la planification des vérifications de connectivité pour les paires de candidats. Par conséquent, un agent Trickle ICE doit (MUST) maintenir chaque liste de vérification dans l'état En cours tant qu'il s'attend à ce que des paires de candidats soient ajoutées de manière incrémentale à la liste. Après cela, l'état de la liste de vérification est défini selon les procédures dans [RFC8445].

Chaque fois que le temporisateur Ta se déclenche et qu'une liste de vérification vide est sélectionnée, aucune action n'est effectuée pour la liste. Sans attendre que le temporisateur Ta expire à nouveau, l'agent sélectionne la liste de vérification suivante dans l'état En cours, conformément à la section 6.1.4.2 de [RFC8445].

La section 7.2.5.4 de [RFC8445] exige que les agents mettent à jour les listes de vérification et les états de temporisateur lors de la finalisation d'une transaction de vérification de connectivité. Lors d'une telle mise à jour, les agents ICE réguliers définiraient l'état d'une liste de vérification sur Échec (Failed) si les deux conditions suivantes sont satisfaites :

  • toutes les paires dans la liste de vérification sont soit dans l'état Échec (Failed) soit dans l'état Réussi (Succeeded) ; et

  • il n'y a pas de paire dans la liste valide pour chaque composant du flux de données.

Avec Trickle ICE, la situation ci-dessus se produirait souvent lorsque la collecte de candidats et le trickling sont encore en cours, même s'il est tout à fait possible que les futures vérifications réussissent. Pour cette raison, les agents Trickle ICE ajoutent les conditions suivantes à la liste ci-dessus :

  • toute la collecte de candidats est terminée, et l'agent ne s'attend pas à découvrir de nouveaux candidats locaux ; et

  • l'agent distant a transmis une indication de fin des candidats pour cette liste de vérification comme décrit dans la Section 13.

9. Gathering and Conveying Newly Gathered Local Candidates (Collecte et transmission des candidats locaux nouvellement collectés)​

Après que les agents Trickle ICE ont transmis les descriptions ICE initiales et les réponses ICE initiales, ils continueront très probablement à collecter de nouveaux candidats locaux à mesure que les mécanismes de collecte de candidats STUN, TURN et autres candidats non-hôtes commencent à produire des résultats. Chaque fois qu'un agent découvre un tel nouveau candidat, il calculera sa priorité, son type, sa fondation (Foundation) et son ID de composant selon les procédures ICE régulières.

Le nouveau candidat est ensuite vérifié pour la redondance par rapport à la liste existante de candidats locaux. Si son adresse de transport et sa base correspondent à celles d'un candidat existant, il sera considéré comme redondant et sera ignoré. Cela se produirait souvent pour les candidats réflexifs de serveur qui correspondent aux adresses d'hôte à partir desquelles ils ont été obtenus (par exemple, lorsque ces dernières sont des adresses IPv4 publiques). Contrairement à l'ICE régulier, les agents Trickle ICE considéreront le nouveau candidat comme redondant quelle que soit sa priorité.

Ensuite, l'agent « trickle » le(s) candidat(s) nouvellement découvert(s) vers l'agent distant. La livraison réelle des nouveaux candidats est gérée par un protocole d'utilisation tel que SIP ou XMPP. Trickle ICE n'impose aucune restriction sur la façon dont cela est fait (par exemple, certains protocoles d'utilisation peuvent choisir de ne pas trickle les mises à jour pour les candidats réflexifs de serveur et s'appuyer plutôt sur la découverte de candidats réflexifs de pair).

Lorsque les candidats sont trickle, le protocole d'utilisation doit (MUST) livrer chaque candidat (et toute indication de fin de candidats comme décrit dans la section 13) à l'implémentation Trickle ICE réceptrice exactement une fois et dans le même ordre qu'il a été transmis. Si le protocole d'utilisation fournit des retransmissions de candidats, elles doivent être cachées de l'implémentation ICE.

De plus, le trickling de candidats doit être corrélé à une session ICE spécifique, de sorte que s'il y a un redémarrage ICE, toutes les mises à jour retardées pour une session précédente peuvent être reconnues comme telles et ignorées par la partie réceptrice. Par exemple, les protocoles d'utilisation qui signalent les candidats via SDP peuvent inclure une valeur de fragment de nom d'utilisateur (Username Fragment) dans la ligne a=candidate correspondante, telle que :

a=candidate:1 1 UDP 2130706431 2001:db8::1 5000 typ host ufrag 8hhY

Ou, comme autre exemple, les implémentations WebRTC peuvent inclure un fragment de nom d'utilisateur dans les objets JavaScript qui représentent les candidats.

Remarque : Le protocole d'utilisation doit fournir un mécanisme permettant aux deux parties d'indiquer et de s'accorder sur la session ICE en vigueur (identifiée par la combinaison fragment de nom d'utilisateur et mot de passe), afin qu'elles aient une vue cohérente des candidats à apparier. Ceci est particulièrement important dans le cas des redémarrages ICE (voir section 15).

Remarque : Un protocole d'utilisation pourrait préférer ne pas trickle les candidats réflexifs de serveur vers des entités dont on sait qu'elles sont publiquement accessibles et où l'envoi d'une demande de liaison STUN directe est susceptible d'atteindre la destination plus rapidement que la mise à jour trickle qui voyage par le chemin de signalisation.

10. Pairing Newly Gathered Local Candidates (Appariement des candidats locaux nouvellement collectés)​

Lorsqu'un agent Trickle ICE collecte des candidats locaux, il doit former des paires de candidats ; cela fonctionne comme décrit dans la spécification ICE [RFC8445], avec les conditions suivantes :

  1. Un agent Trickle ICE ne doit pas (MUST NOT) apparier un candidat local tant qu'il n'a pas été trickle vers la partie distante.

  2. Une fois que l'agent a transmis le candidat local à la partie distante, l'agent vérifie si des candidats distants sont actuellement connus pour ce même flux et composant. Si ce n'est pas le cas, l'agent ajoute simplement le nouveau candidat à la liste des candidats locaux (sans l'apparier).

  3. Sinon, si l'agent a déjà appris un ou plusieurs candidats distants pour ce flux et ce composant, il tente d'apparier le nouveau candidat local comme décrit dans la spécification ICE [RFC8445].

  4. Si une paire nouvellement formée a un candidat local dont le type est réflexif de serveur (server-reflexive), l'agent doit (MUST) remplacer le candidat local par sa base avant de terminer les tests de redondance pertinents.

  5. L'agent élague les paires redondantes en suivant les règles de la section 6.1.2.4 de [RFC8445] mais vérifie les paires existantes uniquement si elles ont un état En attente (Waiting) ou Gelé (Frozen) ; cela évite la suppression de paires pour lesquelles des vérifications de connectivité sont en cours (un état En cours (In-Progress)) ou pour lesquelles les vérifications de connectivité ont déjà donné un résultat définitif (un état Réussi (Succeeded) ou Échec (Failed)).

  6. Si, après avoir terminé les tests de redondance pertinents, la liste de vérification où la paire doit être ajoutée contient déjà le nombre maximum de paires de candidats (100 par défaut selon [RFC8445]), l'agent devrait (SHOULD) rejeter toutes les paires dans l'état Échec pour faire de la place à la nouvelle paire. S'il n'y a pas de telles paires, l'agent devrait (SHOULD) rejeter une paire avec une priorité inférieure à la nouvelle paire afin de faire de la place pour la nouvelle paire, jusqu'à ce que le nombre de paires soit égal au nombre maximum de paires. Ce traitement est cohérent avec la section 6.1.2.5 de [RFC8445].

11. Receiving Trickled Candidates (Réception des candidats trickle)​

À tout moment pendant une session ICE, un agent Trickle ICE peut recevoir de nouveaux candidats de l'agent distant, à partir desquels il tentera de former une paire de candidats ; cela fonctionne comme décrit dans la spécification ICE [RFC8445], avec les conditions suivantes :

  1. L'agent vérifie si des candidats locaux sont actuellement connus pour ce même flux et composant. Si ce n'est pas le cas, l'agent ajoute simplement le nouveau candidat à la liste des candidats distants (sans l'apparier).

  2. Sinon, si l'agent a déjà collecté un ou plusieurs candidats locaux pour ce flux et ce composant, il tente d'apparier le nouveau candidat distant comme décrit dans la spécification ICE [RFC8445].

  3. Si une paire nouvellement formée a un candidat local dont le type est réflexif de serveur (server-reflexive), l'agent doit (MUST) remplacer le candidat local par sa base avant de terminer la vérification de redondance à l'étape suivante.

  4. L'agent élague les paires redondantes comme décrit ci-dessous mais vérifie les paires existantes uniquement si elles ont un état En attente (Waiting) ou Gelé (Frozen) ; cela évite la suppression de paires pour lesquelles des vérifications de connectivité sont en cours (un état En cours (In-Progress)) ou pour lesquelles les vérifications de connectivité ont déjà donné un résultat définitif (un état Réussi (Succeeded) ou Échec (Failed)).

    A. Si l'agent trouve une redondance entre deux paires et que l'une de ces paires contient un candidat distant nouvellement reçu dont le type est réflexif de pair (peer-reflexive), l'agent devrait (SHOULD) rejeter la paire contenant ce candidat, définir la priorité de la paire existante à la priorité de la paire rejetée, et ré-trier la liste de vérification. (Cette politique aide à éliminer les problèmes avec les candidats réflexifs de pair distants pour lesquels une demande de liaison STUN est reçue avant que la signalisation du candidat ne soit trickle vers l'agent récepteur, tels qu'une vue différente des priorités de paire entre l'agent local et l'agent distant, car le même candidat pourrait être perçu comme réflexif de pair par un agent et comme réflexif de serveur par l'autre agent.)

    B. L'agent applique ensuite les règles définies dans la Section 6.1.2.4 de [RFC8445].

  5. Si, après avoir terminé les tests de redondance pertinents, la liste de vérification où la paire doit être ajoutée contient déjà le nombre maximum de paires de candidats (100 par défaut selon [RFC8445]), l'agent devrait (SHOULD) rejeter toutes les paires dans l'état Échec pour faire de la place à la nouvelle paire. S'il n'y a pas de telles paires, l'agent devrait (SHOULD) rejeter une paire avec une priorité inférieure à la nouvelle paire afin de faire de la place pour la nouvelle paire, jusqu'à ce que le nombre de paires soit égal au nombre maximum de paires. Ce traitement est cohérent avec la Section 6.1.2.5 de [RFC8445].

12. Inserting Trickled Candidate Pairs into a Checklist (Insertion de paires de candidats trickle dans une liste de vérification)​

Après que l'agent local a trickle un candidat et formé une paire de candidats à partir de ce candidat local (Section 9), ou après que l'agent distant a reçu un candidat trickle et formé une paire de candidats à partir de ce candidat distant (Section 11), l'agent Trickle ICE ajoute la nouvelle paire de candidats à la liste de vérification comme défini dans cette section.

Pour faciliter la compréhension des procédures définies dans cette section, considérez la représentation tabulaire suivante de toutes les listes de vérification dans un agent (notez qu'initialement pour l'une des fondations, à savoir f5, il n'y a pas de paires de candidats) :

+=================+====+====+====+====+====+
|                 | f1 | f2 | f3 | f4 | f5 |
+=================+====+====+====+====+====+
|| s1 (Audio.RTP)  | F  | F  | F  |    |    |
+-----------------+----+----+----+----+----+
|| s2 (Audio.RTCP) | F  | F  | F  | F  |    |
+-----------------+----+----+----+----+----+
|| s3 (Video.RTP)  | F  |    |    |    |    |
+-----------------+----+----+----+----+----+
|| s4 (Video.RTCP) | F  |    |    |    |    |
+-----------------+----+----+----+----+----+

Tableau 1 : Exemple d'état de liste de vérification

Trickle ICE conserve toutes ces règles telles qu'elles s'appliquent à l'ensemble de listes de vérification « statique ». Cela signifie que si un agent Trickle ICE commence les vérifications de connectivité alors que toutes les paires de candidats sont déjà présentes, la façon dont les états des paires de candidats changent est indiscernable d'un agent ICE régulier.

Bien sûr, la principale différence avec Trickle ICE est que l'ensemble de listes de vérification peut être mis à jour dynamiquement, car les candidats peuvent arriver après le début des vérifications de connectivité. Lorsque cela se produit, l'agent définit l'état de la paire de candidats nouvellement formée comme décrit ci-dessous.

Règle 1 : Définir l'état sur En attente (Waiting) si la paire de candidats nouvellement formée a l'ID de composant le plus bas de toutes les paires de candidats pour cette fondation, ou si les ID de composant sont égaux, la priorité la plus élevée (c'est-à-dire si c'est la paire de candidats la plus haute dans la colonne).

Règle 2 : Définir l'état sur En attente (Waiting) s'il y a au moins une paire de candidats dans l'état Réussi pour cette fondation.

Règle 3 : Définir l'état sur Gelé (Frozen) si aucune des règles précédentes ne s'applique.

Notez que même si une paire de candidats est placée dans l'état En attente, les règles de [RFC8445] s'appliquent toujours, de sorte que les vérifications de connectivité ne sont effectuées qu'à partir de listes de vérification dans l'état En cours d'exécution (Running). Par conséquent, il est possible qu'une paire de candidats change d'état plusieurs fois entre En attente et Gelé jusqu'à ce qu'une vérification de connectivité soit réellement effectuée pour cette paire.

13. Generating an End-of-Candidates Indication (Génération d'une indication de fin des candidats)​

Une fois que toute la collecte de candidats est terminée ou expire pour une session ICE associée à un flux de données spécifique, l'agent générera une indication « fin des candidats » (end-of-candidates) pour cette session et la transmettra à l'agent distant via le canal de signalisation. Bien que la forme exacte de l'indication dépende du protocole d'utilisation, l'indication doit (MUST) spécifier la génération (combinaison de fragment de nom d'utilisateur et de mot de passe), afin qu'un agent puisse corréler l'indication de fin des candidats avec une session ICE particulière. L'indication peut être transmise de les manières suivantes :

  • Dans le cadre d'une demande d'initiation (ce qui serait typiquement le cas avec la description ICE initiale pour half trickle)
  • Avec le dernier candidat qu'un agent peut envoyer pour un flux
  • Comme une notification autonome (par exemple, après l'expiration des demandes de liaison STUN ou des demandes d'allocation TURN à un serveur et que l'agent ne collecte plus activement de candidats)

La transmission d'une indication de fin des candidats en temps opportun est importante pour éviter les ambiguïtés et accélérer la conclusion du traitement ICE. En particulier :

  • Un agent Trickle ICE contrôlé devrait (SHOULD) transmettre une indication de fin des candidats après avoir terminé la collecte pour un flux de données, à moins que le traitement ICE ne se termine avant que l'agent n'ait eu la possibilité de terminer la collecte.
  • Un agent contrôlant peut (MAY) conclure le traitement ICE avant de transmettre des indications de fin des candidats pour tous les flux. Cependant, il est recommandé (RECOMMENDED) qu'un agent contrôlant transmette des indications de fin des candidats dans la mesure du possible par souci de cohérence et pour tenir les middleboxes et les agents contrôlés au courant de l'état du traitement ICE.

Lors de la transmission d'une indication de fin des candidats pendant le trickling (plutôt que dans le cadre de la description ICE initiale ou d'une réponse à celle-ci), il incombe au protocole d'utilisation de définir des méthodes pour associer l'indication à un ou plusieurs flux de données spécifiques.

Un agent peut (MAY) également choisir de générer une indication de fin des candidats avant que la collecte de candidats ne soit réellement terminée, si l'agent détermine que la collecte s'est poursuivie pendant plus d'une période de temps acceptable. Cependant, un agent ne doit pas (MUST NOT) transmettre d'autres candidats après avoir transmis une indication de fin des candidats.

Lors de l'exécution de half trickle, un agent devrait (SHOULD) transmettre une indication de fin des candidats avec sa description ICE initiale, sauf s'il prévoit potentiellement de trickle des candidats supplémentaires (par exemple, au cas où la partie distante s'avérerait prendre en charge Trickle ICE).

Après qu'un agent a transmis l'indication de fin des candidats, il mettra à jour l'état de la liste de vérification correspondante comme expliqué dans la Section 8. Au-delà de ce point, un agent ne doit pas (MUST NOT) trickle de nouveaux candidats au sein de cette session ICE. Par conséquent, l'ajout de nouveaux candidats à la négociation n'est possible que par un redémarrage ICE (voir Section 15).

Cette spécification ne remplace pas la sémantique ICE régulière pour conclure le traitement ICE. Par conséquent, même si des indications de fin des candidats sont transmises, un agent devra toujours passer par la nomination de paires. De plus, si des paires ont été nominées pour des composants et des flux de données, le traitement ICE peut (MAY) encore conclure même si des indications de fin des candidats n'ont pas été reçues pour tous les flux. Dans tous les cas, un agent ne doit pas (MUST NOT) trickle de nouveaux candidats au sein d'une session ICE après la nomination d'une paire de candidats comme décrit dans la Section 8.1.1 de [RFC8445].

14. Receiving an End-of-Candidates Indication (Réception d'une indication de fin des candidats)​

La réception d'une indication de fin des candidats permet à un agent de mettre à jour les états de liste de vérification et, dans le cas où des paires valides n'existent pas pour chaque composant dans chaque flux de données, de déterminer que le traitement ICE a échoué. Elle permet également à un agent d'accélérer la conclusion du traitement ICE lorsqu'une paire de candidats a été validée mais utilise un transport de préférence inférieure tel que TURN. Dans de telles situations, une implémentation peut (MAY) choisir d'attendre et de voir si des candidats de priorité plus élevée sont reçus ; dans ce cas, l'indication de fin des candidats fournit une notification que de tels candidats ne sont pas à venir.

Lorsqu'un agent reçoit une indication de fin des candidats pour un flux de données spécifique, il mettra à jour l'état de la liste de vérification pertinente selon la Section 8 (ce qui pourrait conduire à ce que certaines listes de vérification soient marquées comme Échouées). Si la liste de vérification est toujours dans l'état En cours d'exécution (Running) après la mise à jour, l'agent notera qu'une indication de fin des candidats a été reçue et en tiendra compte dans les futures mises à jour de la liste de vérification.

Après qu'un agent a reçu une indication de fin des candidats, il doit (MUST) ignorer tous les candidats nouvellement reçus pour ce flux de données ou cette session de données.

15. Subsequent Exchanges and ICE Restarts (Échanges ultérieurs et redémarrages ICE)​

Avant de transmettre une indication de fin des candidats, l'un ou l'autre agent peut (MAY) transmettre des informations de candidat ultérieures à tout moment autorisé par le protocole utilisateur. Lorsque cela se produit, les agents utiliseront la sémantique de [RFC8445] (par exemple, la vérification de la combinaison de fragment de nom d'utilisateur et de mot de passe) pour déterminer si les nouvelles informations de candidat nécessitent ou non un redémarrage ICE.

Si un redémarrage ICE se produit, les agents peuvent supposer que Trickle ICE est toujours pris en charge si le support a été déterminé précédemment ; ainsi, ils peuvent s'engager dans un comportement Trickle ICE comme ils le feraient dans un échange initial de descriptions ICE où le support a été déterminé par une méthode de découverte de capacités.

16. Half Trickle (Half Trickle)​

Dans le half trickle, l'initiateur transmet la description ICE initiale avec une génération de candidats utilisable mais pas nécessairement complète. Cela garantit que la description ICE peut être traitée par un répondeur ICE régulier et est principalement destinée à être utilisée dans les cas où le support de Trickle ICE ne peut pas être confirmé avant de transmettre la description ICE initiale. La description ICE initiale indique le support de Trickle ICE, de sorte que le répondeur peut répondre avec quelque chose de moins qu'une génération complète de candidats, puis trickler le reste. La description ICE initiale pour half trickle peut contenir une indication de fin des candidats, bien que cela ne soit pas obligatoire car si le support de trickle est confirmé, l'initiateur peut choisir de trickler des candidats supplémentaires avant de transmettre une indication de fin des candidats.

Le mécanisme de half trickle peut être utilisé dans les cas où il n'y a aucun moyen pour un agent de vérifier à l'avance si une partie distante prend en charge Trickle ICE. Parce que la description ICE initiale contient une génération complète de candidats, elle peut donc être gérée par un agent ICE régulier, tout en permettant à un agent Trickle ICE d'utiliser l'optimisation définie dans cette spécification. Cela évite l'échec de la négociation dans le premier cas tout en donnant environ la moitié des avantages de Trickle ICE dans le second.

L'utilisation de half trickle n'est nécessaire que lors d'un échange initial de descriptions ICE. Après que les deux parties ont reçu une description ICE de leur pair, chacune peut déterminer de manière fiable le support de Trickle ICE et l'utiliser pour tous les échanges ultérieurs (voir Section 15).

Dans certains cas, l'utilisation de half trickle pourrait apporter plus que la moitié de l'amélioration en termes d'expérience utilisateur. Cela peut se produire lorsqu'un agent commence à collecter des candidats sur des indices d'interface utilisateur indiquant que l'utilisateur va bientôt initier une interaction, comme une activité sur un clavier ou le téléphone décrochant. Cela signifierait qu'une partie ou la totalité de la collecte de candidats pourrait être terminée avant que l'agent n'ait réellement besoin de transmettre les informations de candidat. Parce que le répondeur pourra trickler des candidats, les deux agents pourront commencer les vérifications de connectivité et terminer le traitement ICE plus tôt qu'avec l'ICE régulier et potentiellement même aussi tôt qu'avec le trickle complet.

Cependant, une telle anticipation n'est pas toujours possible. Par exemple, un agent utilisateur multifonction ou une page web WebRTC où la communication est une fonctionnalité non centrale (par exemple, appeler une ligne de support en cas de problème avec les fonctionnalités principales) n'aurait pas nécessairement un moyen de distinguer entre les intentions d'appel et d'autres activités utilisateur. Dans de tels cas, l'utilisation du trickle complet est la plus susceptible de donner une expérience utilisateur idéale. Même ainsi, l'utilisation de half trickle serait une amélioration par rapport à l'ICE régulier car elle donnerait une meilleure expérience pour les répondeurs.

18. Requirements for Using Protocols (Exigences pour les protocoles utilisateurs)​

Afin de permettre pleinement l'utilisation de Trickle ICE, cette spécification définit les exigences suivantes pour les protocoles d'utilisation.

  • Un protocole d'utilisation devrait (SHOULD) fournir un moyen pour les parties de faire la publicité et de découvrir le support de Trickle ICE avant qu'une session ICE ne commence (voir Section 3).

  • Un protocole d'utilisation doit (MUST) fournir des méthodes pour transmettre de manière incrémentielle (c'est-à-dire, « trickler ») des candidats supplémentaires après avoir transmis la description ICE initiale (voir Section 9).

  • Un protocole d'utilisation doit (MUST) livrer chaque candidat trickle ou indication de fin des candidats exactement une fois et dans le même ordre qu'il a été transmis (voir Section 9).

  • Un protocole d'utilisation doit (MUST) fournir un mécanisme pour que les deux parties indiquent et se mettent d'accord sur la session ICE en vigueur (voir Section 9).

  • Un protocole d'utilisation doit (MUST) fournir un moyen pour les parties de communiquer l'indication de fin des candidats, qui doit (MUST) spécifier la session ICE particulière à laquelle l'indication s'applique (voir Section 13).

19. IANA Considerations (Considérations IANA)​

L'IANA a enregistré l'option ICE suivante dans le sous-registre "ICE Options" du "registre Interactive Connectivity Establishment (ICE)", conformément aux procédures définies dans [RFC6336].

Option ICE : trickle

Contact : IESG <[email protected]>

Contrôleur de changement : IESG

Description : Une option ICE de 'trickle' indique le support pour la communication incrémentielle des candidats ICE.

Référence : RFC 8838

20. Security Considerations (Considérations de sécurité)​

Cette spécification hérite de la plupart de sa sémantique de [RFC8445], et en conséquence, toutes les considérations de sécurité décrites là-bas s'appliquent à Trickle ICE.

Si les implications de confidentialité liées à la révélation d'adresses hôte sur un dispositif terminal sont une préoccupation (voir, par exemple, la discussion dans [RFC8828] et dans la Section 19 de [RFC8445]), les agents peuvent générer des descriptions ICE qui ne contiennent aucun candidat, puis trickler uniquement des candidats qui ne révèlent pas d'adresses hôte (par exemple, des candidats relayés).

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.