Champ d’en-tête d’extension du protocole d’initialisation de session (SIP) pour l’enregistrement des contacts non adjacents

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

(La présente traduction incorpore l’errata 2778 du 16 avril 2011)

Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés

Résumé

La fonction REGISTER est utilisée dans un système du protocole d’initialisation de session (SIP, Session Initiation Protocol) principalement pour associer une adresse de contact temporaire à une adresse d’enregistrement (address-of-record). Ce contact est généralement sous la forme d’un identifiant universel de ressource (URI, Uniform Resource Identifier) comme Contact: <sip:alice@pc33.atlanta.com> et est généralement dynamique et associé à l’adresse IP ou au nom d’hôte de l’agent d’utilisateur (UA, User Agent) SIP. Le problème est que la topologie du réseau peut avoir un ou plusieurs mandataires SIP entre l’UA et le registraire, de sorte que toute demande qui voyage du réseau de rattachement de l’usager à l’UA enregistré doit traverser ces mandataires. La méthode REGISTER ne nous donne pas de mécanisme pour découvrir et enregistrer cette séquence de mandataires dans le registre pour une future utilisation. Le présent document définit un champ d’en-tête d’extension, "Path" (chemin) qui assure un tel mécanisme.

1. Fondements

Le 3GPP (projet en partenariat pour la troisième génération de téléphonie cellulaire) a établi une exigence pour la découverte des mandataires intermédiaires durant l’enregistrement SIP et a publié cette exigence dans la [RFC4083].

Scénario : UA1----P1-----P2-----P3------REGISTRAIRE

UA1 souhaite s’enregistrer auprès de REGISTRAIRE. Cependant, à cause de la topologie du réseau, UA1 doit utiliser P1 comme "mandataire extérieur", et toutes les demandes entre UA1 et REGISTRAIRE doivent aussi traverser P1, P2, et P3 avant d’atteindre REGISTRAIRE. De même, toutes les demandes entre REGISTRAIRE et UA1 doivent aussi traverser P3, P2, et P1 avant d’atteindre UA1.

UA1 a une relation établie avec REGISTRAIRE. Comment UA1 établit cette relation sort du domaine d’application du présent document. UA1 découvre P1 par sa configuration, par une allocation DHCP ou autre opération similaire, qui sort aussi du domaine d’application du présent document. REGISTRAIRE a une relation similaire de "mandataire extérieur par défaut" avec P3.

Finalement, REGISTRAIRE ou un "mandataire de rattachement" (un mandataire qui sert de point terminal pour l’acheminement d’une adresse d’enregistrement) en rapport étroit avec lui, va recevoir une demande destinée à UA1. Il a besoin de savoir quels mandataires doivent être traversés par cette demande afin de retourner à UA1. Dans certains cas, ces informations peuvent être déduites des tableaux de configuration d’acheminement SIP ou des entrées du DNS. Dans d’autres cas, comme ceux soulevés par le 3GPP, les informations ne sont pas directement disponibles en dehors de la transaction REGISTER de SIP.

Le champ d’en-tête d’extension Path permet d’accumuler et de transmettre la liste des mandataires entre UA1 et REGISTRAIRE. Des nœuds intermédiaires comme P1 peuvent conserver la totalité des informations de Path si nécessaire pour la politique de fonctionnement. Ce mécanisme est par de nombreux côtés similaire au fonctionnement de Record-Route dans les demandes d’initiation de dialogue. L’acheminement établi par le mécanisme du champ d’en-tête Path ne s’applique qu’aux demandes qui transitent par, ou sont générées dans, le domaine de rattachement.

2. Terminologie

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes à SIP.

3. Déclaration d’applicabilité

Le mécanisme Path est applicable chaque fois qu’il y a des mandataires intermédiaires entre un UA SIP et un registraire SIP utilisé par cet UA lorsque les conditions suivantes sont vérifiées :

1. Un ou plusieurs des mandataires intermédiaires sont visités par des demandes d’enregistrement au registraire provenant de l’UA.

2. Les mêmes mandataires intermédiaires ou un ensemble de mandataires connus des mandataires intermédiaires doivent être traversés, en sens inverse, par les demandes envoyées à travers un mandataire de rattachement de l’UA. Dans la forme la plus simple, le chemin entre le mandataire de rattachement et l’UA est l’exact inverse du chemin entre l’UA et le registraire.

3. La topologie du réseau est telle que les mandataires intermédiaires qui doivent être visités ne sont PAS impliqués par les tableaux d’acheminement de SIP, du DNS, ou de mécanismes similaires.

4. Définition et syntaxe du champ d’en-tête Path

Le champ d’en-tête Path est un champ d’en-tête d’extension SIP avec une syntaxe très similaire à celle du champ d’en-tête Record-Route. Il est utilisé conjointement avec les demandes SIP REGISTER et les messages de classe 200 en réponse aux REGISTER (réponses REGISTER).

Un champ d’en-tête Path PEUT être inséré dans un REGISTER par tout nœud SIP traversé par cette demande. Comme le champ d’en-tête Route, les champs d’en-tête Path en séquences sont évalués dans la séquence dans laquelle ils sont présents dans la demande, et les champs d’en-tête Path PEUVENT être combinés en un en-tête Path composé dans un seul champ d’en-tête Path. Le registraire reflète les Path accumulés dans la réponse REGISTER, et les nœuds intermédiaires les propagent en retour vers l’UA d’origine. L’UA d’origine est donc informé de l’inclusion de nœuds sur son chemin enregistré, et PEUT utiliser ces informations dans d’autres capacités qui sortent du domaine d’application du présent document.

La différence entre Path et Record-Route est que Path s’applique à REGISTER et que les réponses de classe 200 s’appliquent à REGISTER. Ce n’est pas le cas de Record-Route, qui ne peut pas être défini dans REGISTER pour des raisons de rétro compatibilité. De plus, le vecteur établi par Record-Route ne s’applique qu’aux demandes au sein du dialogue qui établit ce Record-Route, tandis que le vecteur établi par Path s’applique aux dialogues futurs.

La syntaxe de Path est définie comme suit :

Path = "Path" HCOLON valeur-de-chemin *( COMMA valeur-de-chemin )

valeur-de-chemin = nom-adresse *( SEMI rr-param )

Noter que les valeurs de champ d’en-tête Path se conforment à la syntaxe d’un élément Route tel que défini dans la [RFC3261]. Comme il y est suggéré, de telles valeurs DOIVENT inclure le paramètre indicateur d’acheminement lâche ";lr" pour être pleinement conforme à la [RFC3261].

Les utilisations admissibles de champs d’en-tête sont décrites dans le tableau 2/3 de SIP [RFC3261]. Les ajouts suivants à ce tableau sont nécessaires pour Path.

La prise en charge du champ d’en-tête Path PEUT être indiquée par un UA en incluant l’étiquette d’option "path" dans un champ d’en-tête Supported.

Ajout de Path au Tableau 2/3 de SIP :

5. Utilisation du champ d’en-tête Path

5.1 Procédures chez l’UA

L’UA exécute l’opération d’enregistrement comme d’habitude. La réponse PEUT contenir un champ d’en-tête Path. Le comportement général de l’UA est d’ignorer le champ d’en-tête Path dans la réponse. Il PEUT choisir d’afficher le contenu du champ d’en-tête Path à l’usager ou d’accomplir d’autres actions qui sortent du domaine d’application du présent document. Les informations de chemin dans la réponse REGISTER font savoir à l’UA quels mandataires intermédiaires ont été ajoutés durant l’enregistrement. L’examen de ces informations peut être important du point de vue de la sécurité, car une telle inspection pourrait permettre à l’UA de détecter des mandataires intermédiaires qui se sont eux-mêmes ajoutés de façon inappropriée.

L’UA DEVRAIT inclure l’étiquette d’option "path" comme valeur de champ d’en-tête dans tous les champs d’en-tête Supported, et DEVRAIT inclure un champ d’en-tête Supported dans toutes les demandes.

L’UA PEUT inclure un champ d’en-tête Path dans une demande. Ceci n’est pas largement applicable et il faut faire attention de s’assurer de la fonction appropriée, car le champ d’en-tête Path inséré par l’UA peut avoir des valeurs de champ d’en-tête Path supplémentaires ajoutées par des mandataires intermédiaires. De tels mandataires ne savent pas que la valeur du champ d’en-tête Path a été insérée par un UA, et ils vont le traiter comme si il avait été inséré par un mandataire traversé précédemment, et il pourrait en résulter un comportement d’acheminement inattendu dans lequel il est demandé à l’UA d’agir comme un mandataire.

5.2 Procédures chez les mandataires intermédiaires

Lorsque un mandataire qui traite une demande REGISTER souhaite être sur le chemin de futures demandes dirigées vers l’UA qui a généré cette demande REGISTER, le mandataire insère un URI pour ce mandataire comme valeur de sommet du champ d’en-tête Path (ou il insère un nouvel en-tête Path de sommet) avant de faire suivre cette demande. Il est aussi possible à un mandataire qui a une connaissance spécifique de la topologie du réseau d’ajouter une valeur de champ d’en-tête Path qui fait référence à un autre nœud, permettant par là la construction d’un Path qui n’est pas congruent avec le chemin suivi par la demande REGISTER. Une telle construction est spécifique de la mise en œuvre et sort du domaine d’application du présent document.

Les mandataires intermédiaires NE DEVRAIENT PAS ajouter de champ d’en-tête Path à une demande sauf si l’UA a indiqué qu’il prend en charge cette extension par une valeur de champ d’en-tête Supported. Si l’UA a indiqué qu’il la prend en charge et si le mandataire exige que le registraire accepte l’extension Path, le mandataire DEVRAIT alors insérer une valeur de champ d’en-tête Requires pour cette extension. Si l’UA n’a pas indiqué prendre en charge l’extension et si le mandataire exige sa prise en charge par le registraire, le mandataire DEVRAIT rejeter la demande avec une réponse 421 indiquant une exigence pour cette extension.

Les mandataires qui traitent une réponse REGISTER NE DEVRAIENT PAS altérer les valeurs de champ d’en-tête Path qui pourraient être présentes dans la réponse. Le registraire PEUT protéger le champ d’en-tête Path dans la réponse en l’incluant dans un corps S/MIME protégé, et les altérations du Path par un mandataire intermédiaire peuvent donc être détectées par l’UA comme des attaques par interposition. Les mandataires ne DEVRAIENT envisager d’altérer la valeur d’un champ d’en-tête Path dans la réponse REGISTER que si ils ont les accréditifs pour altérer correctement le corps S/MIME afin de prendre en compte le changement.

5.3 Procédures chez le registraire

Si il existe un champ d’en-tête Path dans une demande REGISTER réussie, le registraire construit une liste ordonnée des éléments de chemin (un vecteur de chemin) à partir des nœuds énumérés dans les valeurs de champ d’en-tête Path, en préservant l’ordre tel qu’indiqué dans les valeurs de champ d’en-tête Path. Le registraire mémorise alors ce vecteur de chemin en association avec ce contact et l’adresse d’enregistrement indiquée dans la demande REGISTER (le "lien" comme défini dans la [RFC3261]). Le registraire copie les valeurs de champ d’en-tête Path dans un champ d’en-tête Path dans la réponse (classe 200) au REGISTER réussi. Dans le cas où le mandataire de rattachement et le registraire ne seraient pas colocalisés, le registraire PEUT appliquer une transformation déterminée en local au vecteur de chemin mémorisé.

Si un registraire reçoit une demande REGISTER qui contient un champ d’en-tête Path et qu’il n’y a pas d’indication de prise en charge de l’extension par l’UA (via un champ d’en-tête Supported) le registraire doit s’appuyer sur la politique locale pour déterminer comment traiter cette demande. La politique recommandée est que le registraire rejette la demande avec une réponse 420 "Mauvaise extension" qui indique l’extension Path. Cette approche permet à l’UA de détecter qu’un mandataire intermédiaire a incorrectement ajouté un champ d’en-tête Path. Cependant, le mécanisme Path devrait fonctionner techniquement en l’absence de prise en charge par l’UA (au prix de quelques risques pour la sécurité) de sorte que certains registraires PEUVENT choisir de prendre en charge l’extension en l’absence d’une valeur de champ d’en-tête Supported dans la demande.

5.4 Procédures chez le mandataire de rattachement

Dans le modèle SIP commun, il y a un mandataire de rattachement associé au registraire pour un usager. Chaque demande entrante ciblée sur l’adresse d’enregistrement publique pour l’usager est acheminée à ce mandataire, qui consulte la base de données du registraire afin de déterminer le contact auquel la demande devrait être redirigée. Le mandataire de rattachement, dans son mode de fonctionnement de base, réécrit l’URI de demande à partir de la demande entrante avec la valeur du contact enregistré et retransmet la demande.

Avec l’ajout de Path, le mandataire de rattachement copie aussi le vecteur de chemin mémorisé associé au contact spécifique dans la base de données du registraire dans le champ d’en-tête Route de la demande sortante comme un chemin préchargé. Cela fait que la demande sortante transite par les mandataires qui ont été inclus dans le champ d’en-tête Path de la demande REGISTER.

Dans le traitement normal, le mandataire de rattachement est le "point terminal" pour l’adresse d’enregistrement (AOR, address-of-record) de l’usager. Par conséquent, le champ d’en-tête Route sur la demande entrante va avoir été épuisé en atteignant le mandataire de rattachement. Si il ne l’est pas, les choses deviennent alors intéressantes. Dans le cas le plus courant, le mandataire de rattachement génère le champ d’en-tête Route sortant en insérant le vecteur de chemin mémorisé devant les valeurs de champ d’en-tête Route contenues dans la demande entrante. Cette procédure peut être altérée par une politique locale chez le mandataire de rattachement.

Des chemins lâches peuvent interagir de façons intéressantes avec des politiques d’acheminement. Les spécificités de comment le vecteur de chemin mémorisé s’intègre avec des chemins par défaut exigés en local et par la politique locale dépendent de la mise en œuvre. Par exemple, certains appareils vont utiliser un acheminement explicite configuré en local pour atteindre un mandataire de prochain bond, et d’autres vont utiliser une règle d’acheminement de mandataire sortant par défaut. Cependant, pour que le résultat fonctionne, la combinaison doit fournir un acheminement valide dans l’environnement local. En général, le vecteur de chemin mémorisé est ajouté à tout chemin configuré en local nécessaire pour sortir de la grappe de service. Le mandataire de service (ou registraire, comme noté antérieurement) PEUT aussi transformer le vecteur de chemin mémorisé en tant que de besoin pour fournir une fonctionnalité correcte. Les concepteurs de systèmes doivent faire correspondre la politique d’enregistrement de Path de leurs nœuds avec la politique d’acheminement afin d’avoir un système gérable.

5.5 Exemples d’utilisation

Noter que certains champs d’en-tête (par exemple, Longueur-de-contenu) et les descriptions de session sont omis pour faire une présentation plus courte et, on l’espère, plus lisible. Le nœud marqué REGISTRAIRE est un registraire et un mandataire et sert de mandataire de rattachement. Donc, dans le DNS, le domaine EXAMPLEHOME.COM pointe sur le même hôte que REGISTRAIRE.EXAMPLEHOME.COM.

5.5.1 Exemple de mécanisme dans la transaction REGISTER

Pour l’exemple, on utilise le scénario de la section 1 Fondements :

UA1----P1-----P2----P3-----REGISTRAIRE

Dans cet exemple, UA1 envoie une demande REGISTER à REGISTRAIRE. Cette demande transite par son mandataire de sortie par défaut P1, un mandataire intermédiaire P2, et le mandataire pare-feu pour le domaine de rattachement, P3, avant d’atteindre REGISTRAIRE. Du fait de la topologie du réseau et de la politique de fonctionnement, P1 et P3 ont besoin de faire transiter les demandes par REGISTRAIRE ou d’autres nœuds dans le réseau de rattachement ciblés sur UA1. P2 ne le fait pas. P1 et P3 ont été configurés à s’inclure eux-mêmes dans les champ d’en-tête Path sur les demandes REGISTER qu’ils traitent. UA1 a l’adresse IP actuelle de "192.0.2.4".

Séquence de messages pour REGISTER avec Path :

F1 : Register UA1 -> P1

REGISTER sip:REGISTRAIRE.EXAMPLEHOME.COM SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

. . .

F2 : Register P1 -> P2

REGISTER sip:REGISTRAIRE.EXAMPLEHOME.COM SIP/2.0

Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P1.EXAMPLEVISITED.COM;lr>

. . .

Note : P1 s’est ajouté lui-même au chemin.

F3 : Register P2 -> P3

REGISTER sip:REGISTRAIRE.EXAMPLEHOME.COM SIP/2.0

Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908

Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P1.EXAMPLEVISITED.COM;lr>

. . .

Note : P2 NE s’est PAS ajouté au chemin.

F4 : Register P3 -> REGISTRAIRE

REGISTER sip:REGISTRAIRE.EXAMPLEHOME.COM SIP/2.0

Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363

Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908

Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

. . .

Note P3 s’est ajouté au chemin.

F5 : REGISTRAIRE exécute Register

REGISTRAIRE Stores:

For UA1@EXAMPLEHOME.COM

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

F6 : Réponse Register REGISTRAIRE -> P3

SIP/2.0 200 OK

Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363

Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908

Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

. . .

Note : Le champ d’en-tête Path dans la réponse est identique à celui reçu dans la demande REGISTER.

F7 : Réponse Register. P3 -> P2

SIP/2.0 200 OK

Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908

Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

. . .

F8 : Réponse Register. P2 -> P1

SIP/2.0 200 OK

Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

. . .

F9 : Réponse Register. P1 -> UA1

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7

To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077

From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact: <sip:UA1@192.0.2.4>

Supported: path

Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

. . .

5.5.2 Exemple du mécanisme dans la transaction INVITE

Cet exemple montre la séquence de messages pour une transaction INVITE générée par UA2 qui arrive finalement à UA1. REGISTRAIRE insère un chemin préchargé vers UA1 et recible la demande en remplaçant l’URI de demande par le contact enregistré. Il envoie ensuite l’INVITE reciblé sur le chemin vers UA1. Noter que cet exemple introduit l’agent d’utilisateur étranger UA2 (adresse "71.91.180.10") et le domaine étranger FOREIGN.ELSEWHERE.ORG. On a étendu le diagramme de l’exemple précédant en ajoutant UA2, et en montrant P2 hors ligne qui indique qu’il ne s’est pas inclus dans le chemin durant l’enregistrement.

Scénario

UA1----P1---------P3-----REGISTRAIRE

| |

P2 |

|

UA2--------------------------

Séquence de message pour INVITE utilisant Path :

F1 : Invite UA2 -> REGISTRAIRE

INVITE sip:UA1@EXAMPLEHOME.COM SIP/2.0

Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497

Call-ID: 48273181116@71.91.180.10

CSeq: 29 INVITE

Contact: <sip:UA2@71.91.180.10>

. . .

F2 : Traitement de REGISTRAIRE

REGISTRAIRE cherche le nom "UA1@EXAMPLEHOME.COM" et retourne :

- Contact = <sip:UA1@192.0.2.4>

- Vecteur de chemin = <sip:P3.EXAMPLEHOME.COM;lr>, <sip:P1.EXAMPLEVISITED.COM;lr>

Note : Le contact remplace l’URI de demande. Le vecteur de chemin est poussé sur la pile de chemins (chemin préchargé) de la demande INVITE sortante. Le chemin du dessus est utilisé pour prendre la décision d’acheminement (en conjonction avec la politique locale).

F3 : Invite REGISTRAIRE -> P3

INVITE sip:UA1@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176

Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497

Call-ID: 48273181116@71.91.180.10

CSeq: 29 INVITE

Contact: <sip:UA2@71.91.180.10>

Route: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>

. . .

Note : Dans cet exemple, REGISTRAIRE ne veut pas rester sur le chemin et n’insère donc pas de Record-Route.

F4 : Invite P3 -> P1

INVITE sip:UA1@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e

Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176

Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497

Call-ID: 48273181116@71.91.180.10

CSeq: 29 INVITE

Contact: <sip:UA2@71.91.180.10>

Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>

Route: <sip:P1.EXAMPLEVISITED.COM;lr>

. . .

Note : P3 a ajouté une entrée Record-Route, qui indique qu’il veut être traversé par les futurs messages de ce dialogue.

F5 : Invite P1 -> UA1

INVITE sip:UA1@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p

Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e

Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176

Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R

To: UA1 <sip:UA1@EXAMPLEHOME.COM>

From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497

Call-ID: 48273181116@71.91.180.10

CSeq: 29 INVITE

Contact: <sip:UA2@71.91.180.10>

Record-Route: <sip:P1.EXAMPLEVISITED.COM;lr>

Record-Route: <sip:P3.EXAMPLEHOME.COM;lr>

. . .

Note : P1 a ajouté une entrée Record-Route qui indique qu’il veut être traversé par les futurs messages de ce dialogue.

6. Considérations pour la sécurité

Il y a peu de considérations de sécurité pour le présent document au delà de celles de SIP [RFC3261]. Dans la perspective de la sécurité, l’extension Path et son usage sont identiques à celles du champ d’en-tête Record-Route du SIP de base. Noter que la transparence des attentes de l’usager est préservée par le retour du Path final à l’UA d’origine – c’est-à-dire que l’UA est informé des mandataires supplémentaires qui ont été insérés dans le chemin pour l’enregistrement associé à cette réponse.

Le champ d’en-tête Path accumule des informations bond par bond durant le traitement de REGISTER. Les informations de retour sont essentiellement de bout en bout, c’est-à-dire qu’elles ne sont par altérées par les mandataires intermédiaires. Cela conduit à deux approches de sécurité légèrement différentes.

6.1 Considérations sur le traitement de la demande REGISTER

Les informations accumulées dans le traitement de REGISTER sont cause que des mandataires supplémentaires sont inclus dans les demandes futures entre la localisation du registraire et l’UA. Une attaque qui permet à un mandataires intrus de s’ajouter lui-même à cette chaîne permettrait à l’attaquant d’intercepter les appels futurs destinés à l’UA.

On peut concevoir qu’un attaquant altère le chemin soit en altérant les données "au vol", soit par d’autres manipulations (comme une usurpation d’identité) qui causerait son inclusion dans la chaîne d’acheminement SIP (une "attaque d’insertion de nœud"). Altérer les données "au vol" peut être contré de façon adéquate en utilisant des mécanismes de protection d’intégrité de couche transport tels que TLS ou IPSEC. L’insertion de mandataire peut être contrée par l’authentification mutuelle au niveau des mandataires, ce qui peut aussi être assuré par TLS ou IPSEC. La classe d’URI "sips:" définie dans la [RFC3261] fournit un mécanisme par lequel un UA peut demander que les mandataires intermédiaires fournissent la protection de l’intégrité et l’authentification mutuelle.

Les systèmes qui utilisent le mécanisme Path DEVRAIENT utiliser des mécanismes appropriés (TLS, IPSEC, etc.) pour assurer l’intégrité du message et l’authentification mutuelle. Les UA DEVRAIENT utiliser "sips:" pour demander une protection transitive.

L’UA enregistreur DEVRAIT utiliser les mécanismes S/MIME pour fournir une copie protégée de la demande d’origine au registraire. Dans ce cas, l’UA DEVRAIT inclure un champ d’en-tête Supported avec une valeur indiquant la prise en charge de l’extension Path dans la copie protégée. Les registraires qui reçoivent une telle demande ne DOIVENT honorer l’extension Path que si la prise en charge est indiquée dans le champ d’en-tête protégé. De plus, ils DEVRAIENT comparer le champ d’en-tête Supported non protégé avec le champ d’en-tête Supported protégé et prendre les mesures appropriées au cas où un intermédiaire a altéré le message pour indiquer la prise en charge de Path lorsque elle n’était pas indiquée par l’UA demandeur.

6.2 Considérations sur le traitement de la réponse REGISTER

Les données retournées à l’UA par le champ d’en-tête Path dans la réponse à la demande REGISTER sont là pour donner des ouvertures à l’UA. Le registraire dit à l’UA "ce sont les mandataires intermédiaires qui seront inclus dans les futures demandes que vous allez traiter à travers moi". En inspectant ce champ d’en-tête, l’UA peut être capable de détecter des attaques par insertion de nœud qui impliquent d’insérer un mandataire dans la chaîne d’acheminement de SIP. Les techniques S/MIME peuvent être utilisées pour empêcher l’altération de ce champ d’en-tête par des mandataires intermédiaires durant le traitement de la réponse.

Comme spécifié, il n’y a pas d’exigence que des mandataires arbitraires entre l’UA et le registraire modifient le champ d’en-tête Path dans la réponse REGISTER. Par conséquent, on peut utiliser une technique de protection de bout en bout. La technique S/MIME définie dans la [RFC3261] fournit un mécanisme efficace. En utilisant cette technique, le registraire fait une copie de la réponse complète, la signe, et l’attache comme corps de la réponse. L’UA peut alors vérifier cette réponse, s’assurant qu’un champ d’en-tête Path non modifié est reçu.

En plus des mesures de protection d’intégrité bond par bond et d’authentification mutuelle suggérées pour le traitement des demandes REGISTER dans la section précédente, les systèmes qui utilisent les champs d’en-tête Path DEVRAIENT mettre en œuvre la protection de bout en bout en utilisant S/MIME. Plus précisément, les registraires qui retournent un champ d’en-tête Path DEVRAIENT joindre un S/MIME signé de la réponse, et les UA qui reçoivent une réponse REGISTER contenant un champ d’en-tête Path DEVRAIENT valider le message en utilisant la technique S/MIME. De plus, les UA qui reçoivent un champ d’en-tête Path dans une réponse REGISTER DEVRAIENT le rendre à l’usager, ou (lorsque c’est faisable) le vérifier programmatiquement.

7. Considérations relatives à l’IANA

Le présent document définit le champ d’en-tête d’extension SIP "Path", que l’IANA a ajouté au registre des champs d’en-tête SIP défini dans SIP [RFC3261].

Le présent document définit aussi l’étiquette d’option SIP "path" que l’IANA a ajoutée au registre des étiquettes d’option SIP défini dans SIP [RFC3261].

Voici l’enregistrement pour le champ d’en-tête Path :

Numéro de RFC : RFC3327

Nom du champ d’en-tête : Path

Forme compacte : aucune

Voici l’enregistrement pour l’étiquette d’option path :

Numéro de RFC : RFC3327

Étiquette d’option : path

8. Remerciements

À Min Huang et Stinson Mathai, qui ont assemblé la proposition originalr du 3GPP pour ce mécanisme, et on élaboré la plus grande partie des procédures du 3GPP en 24.229.

À Keith Drage, Bill Marshall, et Miguel Angel Garcia-Martin qui ont beaucoup discuté avec tout le monde de ces idées et ont aussi aidé à préciser les exigences.

À Juha Heinanen, qui s’est battue avec fermeté contre la normalisation de la fonction de découverte du mandataire de rattachement avec cette technique dans le présent document.

Références normatives

[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2223] J. Postel, J. Reynolds, "Instructions pour les auteurs de RFC", octobre 1997. (Information)

[RFC3261] J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC6665)

Références non normatives

[RFC4083] M. Garcia-Martin, "Exigences du projet en partenariat de troisième génération (3GPP) pour la version 5 des entrées du protocole d'initialisation de session (SIP)", mai 2005. (Information)

[RFC3427] A. Mankin et autres, "Processus des changements au protocole d'initialisation de session (SIP)", BCP 67, décembre 2002. (Remplacée par RFC5727)

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.