Appendix B. Design Motivations (Motivations de conception)

ICE contient un certain nombre de comportements normatifs qui peuvent eux-mêmes être simples, mais qui découlent d'une réflexion complexe ou non évidente ou de cas d'utilisation qui méritent une discussion plus approfondie. Étant donné que ces motivations de conception ne sont pas nécessaires à comprendre à des fins de mise en œuvre, elles sont discutées ici dans une annexe à la spécification. Cette section est non normative.

B.1. Pacing of STUN Transactions (Cadencement des transactions STUN)

Les transactions STUN utilisées pour collecter les candidats et vérifier la connectivité sont cadencées à un taux approximatif d'une nouvelle transaction toutes les Ta millisecondes. Chaque transaction, à son tour, a un temporisateur de retransmission RTO qui est également fonction de Ta. Pourquoi ces transactions sont-elles cadencées et pourquoi ces formules sont-elles utilisées ?

L'envoi de ces requêtes STUN aura souvent pour effet de créer des liaisons sur les dispositifs NAT entre le client et les serveurs STUN. L'expérience a montré que de nombreux dispositifs NAT ont des limites supérieures sur le taux auquel ils créeront de nouvelles liaisons. Des expériences ont montré qu'une fois toutes les 20 ms est bien pris en charge, mais pas beaucoup moins que cela. C'est pourquoi Ta a une limite inférieure de 20 ms. De plus, la transmission de ces paquets sur le réseau utilise de la bande passante et doit être limitée en débit par l'agent. Les déploiements basés sur des versions préliminaires antérieures de ce document avaient tendance à surcharger les liens d'accès à débit limité et à avoir de mauvaises performances globales, en plus d'avoir un impact négatif sur le réseau. En conséquence, le cadencement garantit que le dispositif NAT n'est pas surchargé et que le trafic est maintenu à un taux raisonnable.

B.2. Candidates with Multiple Bases (Candidats avec plusieurs bases)

La section 4.1.3 parle d'éliminer les candidats qui ont la même adresse de transport et la même base. Cependant, les candidats avec les mêmes adresses de transport mais des bases différentes ne sont pas redondants. Quand un agent peut-il avoir deux candidats qui ont la même adresse IP et le même port, mais des bases différentes ?

Considérez un cas où un offrant est multihébergé. Il a une adresse IP sur un réseau privé C et une autre sur le réseau A qui est NATé vers le réseau B. L'offrant obtient un candidat hôte sur C et un candidat hôte sur A. Il effectue une requête STUN à partir de A, qui traverse le NAT et se voit attribuer une liaison qui correspond par hasard à l'IP:port sur C. Maintenant, l'offrant a obtenu un candidat réflexif serveur avec une adresse de transport qui est identique à un candidat hôte. Cependant, le candidat réflexif serveur a une base différente de celle du candidat hôte.

B.3. Purpose of the <rel-addr> and <rel-port> Attributes (Objectif des attributs <rel-addr> et <rel-port>)

L'attribut candidate contient deux valeurs qui ne sont pas du tout utilisées par ICE lui-même -- <rel-addr> et <rel-port>. Pourquoi est-il présent ?

Il y a deux motivations pour son inclusion. La première est diagnostique. Il est très utile de connaître la relation entre les différents types de candidats. En l'incluant, un agent peut savoir quel candidat relayé est associé à quel candidat réflexif, qui à son tour est associé à un candidat hôte spécifique. Lorsque les vérifications pour un candidat réussissent et pas pour d'autres, cela fournit des diagnostics utiles sur ce qui se passe dans le réseau.

La deuxième raison a à voir avec les mécanismes de qualité de service (QoS) hors chemin. Lorsque ICE est utilisé dans des environnements tels que PacketCable 2.0, les proxys inspecteront le SDP et extrairont l'adresse IP et le port pour le trafic média afin d'établir une QoS garantie. Lorsqu'un candidat relayé est sélectionné, le proxy a besoin du candidat réflexif serveur vers le serveur TURN pour demander la QoS au routeur d'accès. En portant la traduction dans le SDP, le proxy peut utiliser cette adresse de transport.

B.4. Importance of the STUN Username (Importance du nom d'utilisateur STUN)

ICE exige l'utilisation de l'intégrité des messages avec STUN en utilisant sa fonctionnalité d'identifiants à court terme. Les identifiants à court terme réels sont formés en échangeant des fragments de nom d'utilisateur dans l'échange offre/réponse SDP. La nécessité de ce mécanisme va au-delà de la simple sécurité ; il est en fait requis pour le fonctionnement correct d'ICE en premier lieu.

Considérez les agents L, R et Z dans des réseaux privés qui se chevauchent. L envoie une offre à Z. Z fournit des candidats hôtes. R utilise par hasard la même IP:port que Z. L envoie une requête STUN qui va à R au lieu de Z. Si R répondait simplement, L croirait qu'il a une connectivité avec Z. Pour résoudre ce problème, les mécanismes d'identifiants à court terme STUN sont utilisés. Les fragments de nom d'utilisateur sont suffisamment aléatoires pour qu'il soit hautement improbable que R utilise les mêmes valeurs que Z. Par conséquent, R rejetterait la requête STUN car les identifiants étaient invalides.

B.5. The Candidate Pair Priority Formula (La formule de priorité de paire de candidats)

La priorité pour une paire de candidats a une forme étrange. C'est :

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

Pourquoi est-ce ? Lorsque les paires de candidats sont triées sur la base de cette valeur, le tri résultant a la propriété MAX/MIN. Cela signifie que les paires sont d'abord triées sur la base de la valeur décroissante du minimum des deux priorités. Pour les paires qui ont la même valeur de priorité minimale, la priorité maximale est utilisée pour trier parmi elles. Si les priorités maximale et minimale sont les mêmes, la priorité de l'agent de contrôle est utilisée comme départage. Cela crée le tri MAX/MIN. MAX/MIN garantit que, pour un agent particulier, un candidat de priorité inférieure n'est jamais utilisé tant que tous les candidats de priorité supérieure n'ont pas été essayés.

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

L'attribut a=remote-candidates existe pour éliminer une condition de concurrence entre l'offre mise à jour et la réponse à la requête Binding STUN qui a déplacé un candidat dans la liste Valide. Pour éliminer cette condition, les candidats réels à R qui ont été sélectionnés par l'offrant (les candidats distants) sont inclus dans l'offre elle-même, et le répondeur retarde sa réponse jusqu'à ce que ces paires soient validées.

B.7. Why Are Keepalives Needed? (Pourquoi les keepalives sont-ils nécessaires ?)

Une fois que les médias commencent à circuler sur une paire de candidats, il est toujours nécessaire de maintenir les liaisons en vie aux NAT intermédiaires pendant la durée de la session. Normalement, les paquets de flux média eux-mêmes répondent à cet objectif. Cependant, si le média est mis en attente ou si la suppression de silence est utilisée, la transmission multimédia peut cesser suffisamment longtemps pour que les liaisons NAT expirent. Pour ces raisons, on ne peut pas compter sur les paquets média eux-mêmes. ICE définit un keepalive périodique simple utilisant des indications de liaison STUN.

B.8. Why Prefer Peer Reflexive Candidates? (Pourquoi préférer les candidats réflexifs pairs ?)

La section 4.1.2 exige que la préférence de type pour les candidats réflexifs pairs soit toujours supérieure à celle des réflexifs serveurs. Pourquoi est-ce ? La raison a à voir avec les considérations de sécurité. Il est beaucoup plus facile pour un attaquant d'amener un agent à utiliser un faux candidat réflexif serveur que pour un attaquant d'amener un agent à utiliser un faux candidat réflexif pair. Par conséquent, les attaques contre la collecte d'adresses avec des requêtes Binding sont contrecarrées par ICE en préférant les candidats réflexifs pairs.

B.9. Why Send an Updated Offer? (Pourquoi envoyer une offre mise à jour ?)

Les deux agents peuvent envoyer des médias une fois les vérifications ICE terminées, sans attendre une offre mise à jour. En effet, le seul but de l'offre mise à jour est de « corriger » le SDP afin que la destination par défaut pour les médias corresponde à l'endroit où les médias sont envoyés sur la base des procédures ICE (qui sera la paire de candidats nominée de priorité la plus élevée).

Pourquoi l'échange offre/réponse mis à jour est-il nécessaire ? En pratique, de nombreux composants le long du chemin de signalisation examinent les informations SDP (par exemple, pour la QoS, la traversée NAT, les diagnostics). Pour que ces outils continuent de fonctionner sans changement, la propriété principale du SDP -- que les définitions existantes pré-ICE des adresses utilisées pour les médias doivent être conservées. Pour cette raison, une offre mise à jour doit être envoyée.

B.10. Why Are Binding Indications Used for Keepalives? (Pourquoi les indications de liaison sont-elles utilisées pour les keepalives ?)

La raison principale a à voir avec les mécanismes de QoS du réseau. Si un agent envoie des paquets média, puis reçoit une requête Binding, il devra générer un paquet de réponse avec ses paquets média. Cela augmentera les besoins réels en bande passante et introduira de la gigue. L'utilisation d'une indication de liaison permet de désactiver l'intégrité, ce qui permet de meilleures performances.

B.11. Why Is the Conflict Resolution Mechanism Needed? (Pourquoi le mécanisme de résolution de conflits est-il nécessaire ?)

La condition où les deux agents croient qu'ils sont contrôlés apparaît dans les cas de contrôle d'appel tiers. Par exemple, un contrôleur envoie une INVITE sans offre à l'agent A, qui répond par une offre. Le contrôleur envoie ensuite une INVITE sans offre à l'agent B, qui répond par une offre. Le contrôleur utilise les offres pour générer des réponses. Lorsque ce flux est utilisé, ICE s'exécutera entre les agents A et B, mais les deux croiront qu'ils sont dans le rôle de contrôle. Avec les procédures de résolution de conflits de rôle, ce flux fonctionnera correctement.