22. IAB Considerations (Considérations IAB)
L'IAB a étudié le problème de la « réparation unilatérale d'auto-adresse » (Unilateral Self-Address Fixing), qui est le processus général par lequel un agent tenta de déterminer son adresse dans un autre domaine de l'autre côté d'un NAT via un mécanisme de réflexion de protocole collaboratif [RFC3424]. ICE est un exemple de protocole qui exécute ce type de fonction. Il est intéressant de noter que le processus pour ICE n'est pas unilatéral, mais bilatéral, et la différence a un impact significatif sur les questions soulevées par l'IAB. En effet, ICE peut être considéré comme un protocole B-SAF (Bilateral Self-Address Fixing), plutôt que comme un protocole UNSAF. Quoi qu'il en soit, l'IAB a exigé que tous les protocoles développés à cette fin documentent un ensemble spécifique de considérations. Cette section répond à ces exigences.
22.1. Problem Definition (Définition du problème)
Selon la RFC 3424, toute proposition UNSAF doit fournir :
Une définition précise d'un problème spécifique et de portée limitée qui doit être résolu avec la proposition UNSAF. Une solution à court terme ne doit pas être généralisée pour résoudre d'autres problèmes ; c'est pourquoi « les solutions à court terme ne le sont généralement pas ».
Les problèmes spécifiques résolus par ICE sont :
-
Fournir un moyen pour deux pairs de déterminer l'ensemble des adresses de transport qui peuvent être utilisées pour la communication.
-
Fournir un moyen pour un agent de déterminer une adresse accessible par un autre pair avec lequel il souhaite communiquer.
22.2. Exit Strategy (Stratégie de sortie)
Selon la RFC 3424, toute proposition UNSAF doit fournir :
Description d'une stratégie de sortie/plan de transition. Les meilleures solutions à court terme sont celles qui verront naturellement de moins en moins d'utilisation à mesure que la technologie appropriée est déployée.
ICE lui-même ne s'élimine pas facilement. Cependant, il est utile même dans un Internet connecté mondialement, pour servir de moyen de détecter si une défaillance de routeur a temporairement interrompu la connectivité, par exemple. ICE aide également à prévenir certaines attaques de sécurité qui n'ont rien à voir avec le NAT. Cependant, ce que fait ICE, c'est aider à éliminer progressivement d'autres mécanismes UNSAF. ICE sélectionne efficacement parmi ces mécanismes, en donnant la priorité à ceux qui sont meilleurs et en dépriorisant ceux qui sont pires. Les adresses IPv6 locales peuvent être préférées. À mesure que les NAT commencent à se dissiper avec l'introduction d'IPv6, les candidats réflexifs serveur et relayés (tous deux des formes d'adresses UNSAF) ne sont tout simplement jamais utilisés, car une connectivité de priorité plus élevée existe vers les candidats hôtes natifs. Par conséquent, les serveurs sont de moins en moins utilisés et peuvent finalement être supprimés lorsque leur utilisation atteint zéro.
En effet, ICE peut aider à la transition d'IPv4 vers IPv6. Il peut être utilisé pour déterminer s'il faut utiliser IPv6 ou IPv4 lorsque deux hôtes à double pile communiquent avec SIP (IPv6 est utilisé). Il peut également permettre à un réseau avec une connectivité 6to4 et v6 native de déterminer quelle adresse utiliser lors de la communication avec un pair.
22.3. Brittleness Introduced by ICE (Fragilité introduite par ICE)
Selon la RFC 3424, toute proposition UNSAF doit fournir :
Discussion de problèmes spécifiques qui peuvent rendre les systèmes plus « fragiles ». Par exemple, les approches qui impliquent l'utilisation de données à plusieurs couches réseau créent plus de dépendances, augmentent les défis de débogage et rendent la transition plus difficile.
ICE supprime en fait la fragilité des mécanismes UNSAF existants. En particulier, le STUN classique (tel que décrit dans la RFC 3489 [RFC3489]) présente plusieurs points de fragilité. L'un d'eux est le processus de découverte qui oblige un agent à essayer de classer le type de NAT derrière lequel il se trouve. Ce processus est sujet aux erreurs. Avec ICE, ce processus de découverte n'est tout simplement pas utilisé. Plutôt que d'évaluer unilatéralement la validité de l'adresse, sa validité est déterminée dynamiquement en mesurant la connectivité avec un pair. Le processus de détermination de la connectivité est très robuste.
Un autre point de fragilité dans le STUN classique et tout autre mécanisme unilatéral est sa dépendance absolue à un serveur supplémentaire. ICE utilise un serveur pour allouer des adresses unilatérales, mais permet aux agents de se connecter directement si possible. Par conséquent, dans certains cas, la défaillance d'un serveur STUN permettrait toujours à un appel de progresser lorsque ICE est utilisé.
Un autre point de fragilité dans le STUN classique est qu'il suppose que le serveur STUN est sur l'Internet public. Il est intéressant de noter qu'avec ICE, ce n'est pas nécessaire. Il peut y avoir une multitude de serveurs STUN dans une variété de domaines d'adresses. ICE découvrira celui qui a fourni une adresse utilisable.
Le point de fragilité le plus troublant dans le STUN classique est qu'il ne fonctionne pas dans toutes les topologies de réseau. Dans les cas où il y a un NAT partagé entre chaque agent et le serveur STUN, le STUN traditionnel peut ne pas fonctionner. Avec ICE, cette restriction est supprimée.
Le STUN classique introduit également certaines considérations de sécurité. Heureusement, ces considérations de sécurité sont également atténuées par ICE.
Par conséquent, ICE sert à réparer la fragilité introduite dans le STUN classique et n'introduit aucune fragilité supplémentaire dans le système.
La pénalité de ces améliorations est qu'ICE augmente les temps d'établissement de session.
22.4. Requirements for a Long-Term Solution (Exigences pour une solution à long terme)
Selon la RFC 3424, toute proposition UNSAF doit fournir :
... exigences pour des solutions techniques solides à plus long terme -- contribuer au processus de recherche de la bonne solution à plus long terme.
Nos conclusions de la RFC 3489 restent inchangées. Cependant, nous pensons qu'ICE aide réellement parce que nous pensons qu'il peut faire partie de la solution à long terme.
22.5. Issues with Existing NAPT Boxes (Problèmes avec les boîtiers NAPT existants)
Selon la RFC 3424, toute proposition UNSAF doit fournir :
Discussion de l'impact des problèmes pratiques notés avec les NA[P]T existants et déployés et rapports d'expérience.
Un certain nombre de boîtiers NAT sont maintenant déployés sur le marché qui tentent de fournir une fonctionnalité ALG « générique ». Ces ALG génériques recherchent des adresses IP, sous forme textuelle ou binaire dans un paquet, et les réécrivent si elles correspondent à une liaison. Cela interfère avec le STUN classique. Cependant, la mise à jour de STUN [RFC5389] utilise un codage qui cache ces adresses binaires aux ALG génériques.
Les boîtiers NAPT existants ont des temps d'expiration non déterministes et généralement courts pour les liaisons basées sur UDP. Cela nécessite que les implémentations envoient des keepalives périodiques pour maintenir ces liaisons. ICE utilise une valeur par défaut de 15 s, ce qui est une estimation très prudente. Finalement, au fil du temps, à mesure que les boîtiers NAT deviennent conformes à behave [RFC4787], ce keepalive minimum deviendra déterministe et bien connu, et les minuteries ICE pourront être ajustées. Avoir un moyen de découvrir et de contrôler l'intervalle de keepalive minimum serait encore bien mieux.