Résumé

  • Le rôle contrôlant d’ICE permet de nommer une paire valide pour chaque composante ; si deux agents complets revendiquent ce rôle, un nombre aléatoire uniforme de 64 bits les départage.
  • Cette victoire procédurale n’atteste ni l’identité, ni l’autorisation humaine, ni la propriété d’une adresse, ni la sécurité du média, ni le résultat du service.

Un arbitrage sans hiérarchie

Le mot « contrôlant » invite à imaginer un rapport de force. Le mécanisme décrit par la RFC 5245 est beaucoup plus modeste. Avant l’échange, chaque agent ICE complet choisit une valeur entre zéro et 2^64 moins un. Lorsque les deux côtés s’annoncent contrôlants, ils comparent ces valeurs. Le gagnant conserve le rôle ; l’autre le corrige, éventuellement après une réponse 487 Role Conflict.

Rien dans ce tirage ne mesure la confiance. La valeur haute n’est pas celle de l’appelant, du client payeur, du propriétaire du terminal ou de l’organisation qui commande la session. L’agent qui change de rôle ne retire pas un nouveau numéro pour fabriquer une nouvelle identité. Le nombre sert à faire converger deux automates vers des tâches complémentaires.

Une exploitation qui affiche « maître », « propriétaire de session » ou « côté autorisé » change donc la nature de la preuve. Elle transforme un mécanisme anti-collision en attribution de pouvoir.

Nommer vient après vérifier

ICE rassemble des candidats hôte, réflexifs côté serveur et relayés. Les agents les transmettent par une signalisation déjà disponible, construisent et ordonnent des paires, puis exécutent des contrôles de connectivité STUN. Une transaction réussie peut faire entrer une paire dans la liste valide. Ce reçu signifie qu’à cet instant des messages ont pu parcourir le chemin testé dans les deux sens.

Le contrôlant choisit ensuite, selon sa politique locale, une paire valide pour chaque composante. Avec la nomination régulière, un nouveau contrôle transporte USE-CANDIDATE. La RFC 8445 a conservé cette procédure et supprimé la nomination agressive de la RFC 5245.

Priorité d’un candidat, succès d’un contrôle, appartenance à la liste valide, nomination et sélection finale sont ainsi cinq faits distincts. Le rôle contrôlant autorise l’un de ces passages ; il ne rend pas vrais les précédents et ne garantit pas les suivants.

La confiance arrive par la signalisation

ICE suppose qu’une connexion de signalisation existe. Il ne traverse pas les NAT pour établir cette signalisation. Les candidats, fragments de nom d’utilisateur et mots de passe courts utilisés par STUN dépendent donc de cette frontière extérieure.

L’intégrité STUN protège utilement les contrôles, mais ne transforme pas la valeur de départage en justificatif d’identité. Si la signalisation a substitué des candidats ou livré les secrets au mauvais correspondant, une machine peut exécuter parfaitement la procédure sur des prémisses trompeuses.

La RFC 8445 étudie d’ailleurs des attaques capables de provoquer des conclusions faussement invalides, faussement valides ou faussement réflexives. « Valide » reste un état calculé par ICE avec des garanties précises. Ce n’est ni un titre de propriété sur l’adresse ni un certificat universel de vérité.

Le consentement expire sur un autre calendrier

La RFC 7675 qualifie le succès initial d’ICE de consentement applicatif initial pour l’envoi vers une paire. Elle précise aussitôt qu’aucune intervention humaine n’est impliquée. Ce consentement de protocole concerne un seul quintuplet réseau. Il doit être renouvelé par requête et réponse, puis cesse d’être actuel quand sa fenêtre expire.

ICE seul ne dit pas non plus quand le consentement prend fin. Une base d’exploitation peut conserver la paire sélectionnée alors que le dernier reçu de fraîcheur est périmé. La fiche doit donc distinguer la sélection, le quintuplet, la dernière confirmation et l’autorisation humaine ou contractuelle obtenue ailleurs.

Le même soin vaut pour la confidentialité. ICE choisit un chemin ; d’autres protocoles protègent le média et authentifient ses extrémités. Une paire sélectionnée ne prouve ni qu’un paquet protégé l’a empruntée, ni que l’application l’a décodé, ni qu’un participant l’a compris.

L’adresse visible n’est pas une adresse possédée

La RFC 8828 traite la confidentialité des candidats hôte parce que leur divulgation révèle de la topologie. Découvrir ou joindre une adresse ne confère pas le droit de l’exposer. Une preuve de portée ne vaut pas preuve de propriété.

La RFC 5128 rappelle de son côté que les chemins directs échouent parfois et qu’un relais devient nécessaire. Une paire nommée peut donc être coûteuse, temporaire ou dépendante d’un tiers. Son statut ne permet pas d’inventer un chemin direct ni une durabilité.

Le dossier d’exploitation devrait conserver une échelle plutôt qu’un voyant : revendication de rôle, résolution du conflit, échange de candidats authentifié, contrôle intègre, paire valide, nomination, sélection des deux côtés, consentement actuel, trafic protégé, acceptation applicative, résultat observé.

La discipline des couches de réalité défendue par Lu Heng interdit à un reçu inférieur d’emprunter l’autorité d’un reçu supérieur. La RFC 5245 est désormais historique ; la RFC 8445 gouverne la procédure commune et la RFC 8839 le volet SDP. Ce changement de texte ne change pas la limite : le hasard peut attribuer une tâche, pas fabriquer une autorité.

Sources