Résumé

  • RFC 3327 permettait aux proxys d’ajouter un Path ordonné pendant REGISTER ; après une inscription réussie, le registrar associait ce vecteur à la liaison AOR/Contact et le renvoyait.
  • Un proxy du domaine d’origine pouvait ensuite placer le vecteur conservé dans un en-tête Route pour les requêtes destinées à ce Contact. Ce n’était pas la preuve du chemin réellement suivi par REGISTER.

« Où » ne suffisait pas à dire « par où »

Un registrar SIP peut mémoriser l’adresse à laquelle joindre un agent utilisateur, ou UA. Cette liaison répond à une question précise : quel Contact recevoir pour cette adresse-of-record ? Elle ne dit pas nécessairement quels mandataires intermédiaires la requête devra traverser.

La difficulté apparaît lorsque REGISTER passe par des proxys d’accès qu’un proxy du domaine d’origine ne peut retrouver dans le DNS ou dans ses propres tables de routage. L’UA peut s’inscrire depuis un réseau visité ; le registrar peut se trouver ailleurs ; et une requête entrante ultérieure doit repasser par des nœuds absents de l’URI de Contact. Publiée en décembre 2002, RFC 3327 a permis à ces nœuds de laisser un vecteur de routage dans l’échange d’inscription.

Le nom « Path » peut évoquer une mesure de trajet. Ce n’était pas sa fonction. Un proxy traversé par REGISTER pouvait ajouter une valeur Path. Le registrar conservait les valeurs ordonnées avec la liaison du Contact et de l’AOR, puis les renvoyait dans une réponse REGISTER réussie. Plus tard, en récupérant cette liaison, un proxy du domaine d’origine pouvait placer le vecteur dans un en-tête Route préchargé et faire transiter la nouvelle requête par ces proxys. Cette mémoire appartenait à la liaison, pas à une capture de la transaction REGISTER.

Une route qui franchit la frontière de la transaction

Path ressemble à Record-Route, mais leur durée diffère. Record-Route établit le routage des requêtes au sein du dialogue qui l’a créé. Path est transmis dans REGISTER et dans sa réponse réussie pour qu’une séquence de proxys serve à des dialogues ultérieurs. Le mécanisme de routage existant de RFC 3261 exécute Route ; RFC 3327 transporte la séquence au-delà de l’inscription.

Cette portée était délimitée. Le mécanisme concernait les requêtes qui transitent par le domaine d’origine de l’utilisateur ou qui en proviennent. Les valeurs suivent la syntaxe d’un élément Route et utilisent le paramètre de routage lâche ;lr. L’UA peut signaler la prise en charge au moyen de Supported: path ; en règle générale, les proxys ne devraient pas ajouter Path sans cette indication. Si le registrar reçoit Path sans marqueur de prise en charge, RFC recommande le rejet tout en laissant place à la politique locale.

Le changement historique n’est donc pas que SIP se serait mis à savoir où chaque paquet est passé. La transaction d’inscription est devenue un endroit où les proxys peuvent joindre un contexte de routage à la liaison qui gouvernera des requêtes entrantes futures. La réponse du registrar rend également ce Path visible à l’UA : le vecteur n’est pas automatiquement transformé en base universelle de topologie.

Un vecteur n’est pas un témoin

RFC 3327 autorise explicitement un proxy connaissant la topologie à ajouter une valeur Path qui référence un autre nœud, même si cette valeur ne correspond pas au trajet réellement emprunté par REGISTER. Cela tranche l’interprétation : Path est une prescription de routage ordonnée, assemblée selon la politique des proxys et du registrar, et non une preuve judiciaire du trajet des paquets. À lui seul, il ne prouve ni qu’un proxy a transmis un message antérieur, ni que la route proposée reste joignable, ni qu’un futur appel aboutira.

Ce choix créait aussi une frontière de sécurité. Un proxy inséré dans le vecteur conservé pouvait se trouver sur les requêtes futures et intercepter des appels. RFC 3327 évoque donc l’intégrité du transport et l’authentification mutuelle, par exemple avec TLS ou IPsec, ainsi que des copies S/MIME protégées qui permettent à l’UA de détecter une modification du Path retourné. Un URI syntaxiquement valide n’équivalait pas à un intermédiaire autorisé.

Des travaux ultérieurs ont réutilisé le mécanisme dans un but plus ciblé. RFC 5626 place un jeton de flux unique dans Path afin que le proxy d’accès associe une requête future à une connexion initiée par le client. Ce comportement par flux relève de l’extension ultérieure ; il ne faut pas l’attribuer à chaque vecteur RFC 3327. À l’inverse, le Service-Route de RFC 3608 fournit à l’UA une route pour ses propres requêtes sortantes, et non un chemin pour les requêtes qui lui sont destinées.

Sources