Usage de la sémantique des types d'adresse de réseau de remplacement (ANAT) du protocole de description de session (SDP)
dans le protocole d'initialisation de session (SIP)

Statut de ce mémoire

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

Notice de copyright

Copyright (C) The Internet Society (2005).

Résumé

Le présent document décrit comment utiliser la sémantique des types d'adresse réseau de remplacement (ANAT, Alternative Network Address Types) du cadre de groupage du protocole de description de session (SDP, Session Description Protocol) dans SIP. En particulier, il définit l'étiquette d'option SIP "sdp-anat". Cette étiquette d'option SIP assure que les descriptions de session SDP qui utilisent ANAT ne sont traitées que par des entités SIP qui prennent en charge ANAT. Pour justifier le besoin d'une telle étiquette d'option SIP, il décrit ce qui pourrait se produire si une entité SIP sans capacité ANAT essayait de traiter des lignes de supports groupées avec ANAT.

1. Introduction

Les agents d'utilisateur (UA, User Agent) SIP [RFC3261] prennent souvent en charge différents types d'adresse réseau. Par exemple, un UA peut avoir une adresse IPv6 et une adresse IPv4. Un tel UA va normalement vouloir utiliser une de ses adresses pour établir une session de supports avec un UA distant. Si l'UA distant ne prend en charge que IPv6, par exemple, les deux UA vont utiliser IPv6 pour envoyer et recevoir les supports.

La sémantique des types d'adresse de réseau de remplacement (ANAT, Alternative Network Address Types) [RFC4091] du cadre de groupage [RFC3388] de SDP [RFC2327] permet aux UA d'offrir [RFC3264] des adresses de remplacement de différents types dans une description de session SDP. L'UA SIP à double pile IPv4/IPv6 de notre exemple précédent va générer une offre groupant une ligne de supports IPv6 et une ligne de supports IPv4 utilisant ANAT. À réception de cette offre, le répondant [RFC3264] va accepter une ligne de supports et rejeter l'autre.

Si le receveur d'une offre qui utilise ANAT prend en charge la sémantique d'ANAT, tout fonctionne comme décrit dans la spécification ANAT [RFC4091]. Néanmoins, le receveur d'une telle offre (c'est-à-dire, le répondant) peut ne pas prendre en charge les ANAT. Dans ce cas, des mises en œuvre différentes de répondant vont réagir de façons différentes. Le présent document discute du comportement du répondant qui a la plus forte chance d'avoir lieu et décrit ses conséquences. Pour éviter ces conséquences, on définit l'étiquette d'option SIP sdp-anat.

L'étiquette d'option sdp-anat peut être utilisée pour assurer qu'une offre utilisant ANAT n'est pas traitée par les répondants qui ne prennent pas en charge les ANAT. Cette étiquette d'option peut aussi être utilisée pour découvrir explicitement les capacités d'un UA (c'est-à-dire si il prend en charge les ANAT).

2. Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

3. Étiquette d'option sdp-anat

On définit les étiquettes d'option sdp-anat à utiliser dans les champs d'en-tête SIP Require et Supported [RFC3261]. Les agents d'utilisateur SIP qui placent cette étiquette d'option dans un champ d'en-tête Supported comprennent la sémantique des ANAT telle que définie dans la [RFC4091].

4. Rétro compatibilité

Les répondants qui ne prennent pas en charge les ANAT vont réagir de différentes façons à réception d'une offre qui utilise des ANAT. On s'attend à ce que, même dans des circonstances identiques, des mises en œuvre différentes se comportent de façons différentes. Dans cette section, on analyse ces comportements (c'est-à-dire que les paragraphes qui suivent supposent que le répondant ne prend pas en charge les ANAT).

4.1 Prise en charge de tous les types de réseau offerts par le répondant

Si le répondant prend en charge tous les types de réseau de l'offre, il peut accepter l'offre et établir tous les flux de supports qui sont dedans. Ce comportement n'est pas ce que l'offreur attend parce qu'il résulte en l'établissement de trop de flux de supports. Si le répondant commence à envoyer des supports sur tous ces flux, le résultat peut être une forte utilisation de la bande passante.

Le répondant peut aussi rejeter l'offre, parce que bien qu'il prenne en charge tous les types de réseau qu'elle contient, le répondant peut ne pas les prendre en charge simultanément. La réponse d'erreur envoyée par le répondant va très certainement n'être pas assez explicite sur la situation. Donc, l'offreur ne va pas comprendre ce qui ne va pas.

Dans les scénarios précédents, l'étiquette d'option sdp-anat va éviter l'établissement de trop de flux de supports et va permettre au répondant d'informer explicitement l'offreur que le répondant ne prend pas en charge les ANAT.

4.2 Non prise en charge de tous les types de réseau offerts par le répondant

Si le répondant ne prend pas en charge tous les types de réseau de l'offre, il peut seulement établir les flux de supports dont il comprend les types d'adresses et rejeter le reste. Cela serait un comportement acceptable du point de vue de l'offreur.

D'un autre côté, le répondant peut aussi rejeter l'offre parce que elle contient des types d'adresses inconnus. La réponse d'erreur envoyée par le répondant va très probablement n'être pas assez explicite sur la situation. Donc, l'offreur ne va pas comprendre ce qui ne va pas.

Dans le scénario précédent, l'étiquette d'option sdp-anat va permettre au répondant d'informer explicitement l'offreur qu'il ne prend pas en charge les ANAT.

4.3 Demandes OPTIONS

Bien que la [RFC3388] fournisse aux serveurs un moyen d'indiquer la prise en charge des ANAT dans une description SDP, de nombreux serveurs n'incluent pas de description SDP dans leurs réponses aux demandes OPTIONS. L'étiquette d'option sdp-anat rend possible de découvrir si un serveur prend en charge les ANAT, car ils vont inclure cette étiquette d'option dans un champ d'en-tête Supported dans leurs réponses.

5. Usage de l'étiquette d'option

Comme exposé à la section précédente, l'utilisation de l'étiquette d'option sdp-anat rend les messages SIP plus explicites quant à la prise en charge des ANAT. Donc, les entités SIP qui génèrent une offre qui utilise la sémantique de ANAT DEVRAIT placer l'étiquette d'option sdp-anat dans un champ d'en-tête Require. Les entités SIP qui prennent en charge la sémantique des ANAT DOIVENT comprendre l'étiquette d'option sdp-anat.

6. Considérations sur la sécurité

Un attaquant peut tenter d'ajouter l'étiquette d'option sdp-anat au champ d'en-tête Require d'un message pour effectuer une attaque de déni de service. Si l'UAS ne prend pas en charge les ANAT, il va retourner une réponse d'erreur au lieu de traiter le message.

Un attaquant peut tenter de retirer l'étiquette d'option sdp-anat du champ d'en-tête Require d'un message. Il peut en résulter l'établissement de trop de flux de supports.

Pour éviter ces attaques, la protection de l'intégrité du champ d'en-tête Require est RECOMMANDÉE. Le choix naturel pour protéger l'intégrité des champs d'en-tête dans SIP est S/MIME [RFC3853].

7. Considérations relatives à l'IANA

Le présent document définit une étiquette d'option SIP (sdp-anat) à la Section 3. Elle a été enregistrée par l'IANA dans le registre des paramètres SIP.

Les agents d'utilisateur SIP qui placent l'étiquette d'option sdp-anat dans un champ d'en-tête Supported comprennent la sémantique des ANAT.

8. Références normatives

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

[RFC2327] M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998. (Obsolète; voir RFC4566)

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

[RFC3264] J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002.

[RFC3388] G. Camarillo, G. Eriksson, J. Holler et H. Schulzrinne, "Groupage des lignes de support dans le protocole de description de session (SDP)", décembre 2002. (Remplacée par RFC5888)

[RFC3853] J. Peterson, "Exigences S/MIME de la norme de chiffrement évolué (AES) pour le protocole d'initialisation de session (SIP)", juillet 2004. (P.S.)

[RFC4091] G. Camarillo, J. Rosenberg, "Sémantique des types d'adresse de réseau de remplacement (ANAT) pour le cadre de groupage du protocole de description de session (SDP)", juin 2005. (P.S.)

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations 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.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Remerciement

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