Résumé

  • Avec RFC 3327, certains mandataires pouvaient déposer des URI Path pendant REGISTER ; le registraire conservait ce vecteur ordonné avec le couple adresse publique–Contact, puis le mandataire d’origine le transformait en Route lors d’une requête ultérieure.
  • Ce vecteur n’était ni un journal exhaustif ni une preuve : un nœud traversé pouvait ne rien déposer, un autre pouvait être désigné sans avoir été traversé, et les politiques du registraire ou du réseau d’origine pouvaient modifier le résultat.

Le paquet était arrivé, mais son chemin utile allait disparaître

Un terminal mobile se présente à son domaine d’origine avec une adresse publique stable et un Contact qui décrit son point de rattachement du moment. Le registraire valide l’association. Pourtant, le Contact seul ne dit pas forcément qu’il faut passer par le mandataire d’accès, un relais placé près d’un pare-feu ou un réseau visité. Une tentative directe peut contourner une politique obligatoire ou ne jamais parvenir au terminal.

Le paradoxe est net : REGISTER vient précisément de franchir les intermédiaires nécessaires, mais SIP n'obligeait pas le registraire à garder cette séquence avec l’inscription. L’observation du trajet appartenait au présent de la transaction, tandis que la décision de routage appartenait à un futur appel. Sans nouvelle donnée, le succès du premier ne garantissait pas le second.

Path a comblé cet intervalle. Un mandataire qui traitait REGISTER pouvait ajouter l’URI qu’il souhaitait voir utilisée pour les requêtes futures dirigées vers ce Contact. Plusieurs mandataires formaient une liste ordonnée. Le registraire associait la liste à l’adresse de l’utilisateur et au Contact précis, puis la renvoyait dans la réponse positive. Plus tard, le mandataire du domaine d’origine chargeait ces valeurs dans l’ensemble Route avant d’envoyer la requête au Contact choisi.

L’attachement au Contact empêchait une abstraction dangereuse. Une même adresse pouvait enregistrer un téléphone, un ordinateur et une passerelle, chacun derrière une topologie différente. Le chemin du téléphone ne devait pas devenir celui de l’ordinateur. Une actualisation pouvait remplacer le vecteur, et l’expiration de l’inscription devait l’emporter avec elle. Contact et Path formaient donc une unité de durée de vie sans devenir un seul fait.

RFC 3263 situait les serveurs SIP d’un domaine au moyen de DNS. Cette découverte conduisait au service ; elle ne décrivait pas le trajet temporaire entre le domaine d’origine et un terminal particulier. RFC 3327 traitait cet étage ultérieur et plus volatil.

Une déclaration pour demain n’était pas la chronique d’hier

Le mot Path favorise une lecture trop littérale. Une liste d’URI ressemble à la trace laissée par REGISTER. Or la norme autorisait un mandataire traversé à ne pas s’inscrire dans la liste. Elle autorisait aussi un mandataire à déposer l’URI d’un autre nœud qui devait recevoir le trafic futur. Le registraire pouvait transformer le vecteur selon sa politique. Au moment de l’appel, le mandataire d’origine pouvait encore le combiner avec une Route existante ou une route par défaut.

Path exprimait ainsi une prescription. Il disait par où une prochaine requête devait être dirigée, pas nécessairement par où la précédente était passée. Une capture prouve que certaines valeurs figuraient dans un message observé ; elle ne prouve ni l’exhaustivité de la liste, ni le passage antérieur de chaque nœud, ni l’exécution future du même ordre.

Cette limite impose quatre reçus distincts : le trajet réellement observé de REGISTER, le vecteur déclaré, la version acceptée ou transformée par le registraire, puis la Route constatée lors d’une requête ultérieure. Les fusionner produit une histoire plus simple, mais fausse.

Via répond à une autre question : comment ramener la réponse le long d’une transaction. Record-Route construit le chemin d’un dialogue à partir de la requête qui l’ouvre. Path est appris pendant l’inscription pour des dialogues encore inexistants. Service-Route, défini par RFC 3608, indique au terminal le chemin de ses futures requêtes sortantes ; Path indique au côté d’origine comment revenir vers le Contact. Des noms voisins ne confèrent pas des autorités interchangeables.

Le reflet rendait l’insertion visible sans la certifier

La réponse positive à REGISTER renvoyait les valeurs Path conservées. Un terminal ordinaire pouvait les ignorer et ne les utilisait pas comme sa propre Route. Il pouvait néanmoins les examiner. La présence d’un mandataire inattendu révélait peut-être qu’un acteur venait de se placer durablement sur le trajet des futurs appels.

Le risque dépassait la transaction d’inscription. Un mandataire malveillant capable d’ajouter son URI pouvait intercepter ensuite toutes les requêtes destinées au Contact tant que la liaison restait active. Supprimer un élément pouvait contourner un contrôle ; changer l’ordre pouvait déplacer le premier point d’observation ; transformer silencieusement une URI pouvait rendre une route inopérante.

La norme recommandait donc l’intégrité et l’authentification mutuelle appropriées. Ces protections ne répondent qu’à une question bornée : les octets protégés ont-ils changé entre des pairs identifiés ? Elles ne démontrent pas qu’un mandataire est honnête, disponible ou habilité à parler pour un autre nœud. Le renvoi de la liste prouve ce que le registraire a retourné, pas ce que le monde rend vrai.

La mise en garde concernant les terminaux est révélatrice. Si un terminal insérait lui-même Path, des mandataires pouvaient interpréter l’URI comme l’instruction d’un pair et demander plus tard au terminal de se comporter en mandataire. La syntaxe correcte ne suffit pas ; l’identité de l’auteur et son rôle font partie de la sémantique.

Les extensions ultérieures ont précisé l’environnement

Publié en décembre 2002, RFC 3327 a ensuite été mis à jour par RFC 5626. SIP Outbound a donné un cadre plus riche aux flux maintenus depuis des terminaux placés derrière des frontières réseau et aux relais de bord. Cette évolution n’a pas transformé Path en relevé forensique ; elle a précisé la coopération entre inscription, flux et routage.

RFC 5627 a introduit les GRUU pour identifier une instance de terminal au-delà d’un seul flux. RFC 3680 a défini la notification des événements d’inscription. RFC 5922 a encadré les certificats de domaine SIP. Le registre IANA recense les paramètres et noms normalisés. Chacun apporte une pièce voisine ; aucun ne permet de déduire le déploiement, l’adoption ou la véracité d’un chemin.

La contribution durable de RFC 3327 consiste à séparer identité publique, localisateur courant, contrainte de livraison et histoire observée. Le réseau pouvait connaître les deux premiers sans savoir livrer. Il pouvait connaître le troisième sans posséder le quatrième. Path a rendu ce manque visible — à condition de ne pas transformer une intention de routage en preuve du passé.

Sources