Sémantique des types d'adresse de réseau de remplacement (ANAT) pour le cadre de groupage du protocole de description de session (SDP)

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éfinit la sémantique des types d'adresse de réseau de remplacement (ANAT) pour le cadre de groupage du protocole de description de session (SDP). La sémantique d'ANAT permet à des types d'adresses réseau de remplacement d'établir un flux de supports particulier.

1. Introduction

Une description de session du protocole de description de session (SDP, Session Description Protocol) [RFC2327] contient les paramètres des supports à utiliser pour établir un certain nombre de flux de supports. Pour un flux de supports particulier, une description de session SDP contient, entre autres paramètres, les adresses réseau et le codec à utiliser pour transférer les supports. SDP permet un ensemble de codecs par flux de supports, mais seulement une adresse réseau.

La capacité d'offrir un ensemble d'adresses réseau pour établir un flux de supports est utile dans des environnements avec à la fois des hôtes IPv4 seul et IPv6 seul, par exemple.

Le présent document définit la sémantique des types d'adresse réseau de remplacement (ANAT, Alternative Network Address Types) pour le cadre de groupage SDP [RFC3388]. La sémantique d'ANAT permet l'expression d'adresses réseau de remplacement (par exemple, différentes versions IP) pour un flux de supports particulier.

1.1 Portée et relation avec l'établissement de connectivité interactive

La sémantique d'ANAT est destinée à traiter les scénarios qui impliquent différents types d'adresses réseau (par exemple, différentes versions IP). Elle n'est pas destinée à fournir des adresses de transport de remplacement avec le même type de réseau. Les systèmes qui ont besoin de fournir des adresses de transport différentes avec le même type de réseau devraient plutôt utiliser le format SDP défini dans l'établissement de connexité interactive (ICE, Interactive Connectivity Establishment) [RFC5245].

ICE est utilisé par des systèmes qui ne peuvent pas déterminer leur propre adresse de transport telle que vue de l'extrémité distante, mais elles peuvent fournir plusieurs solutions de remplacement possibles. ICE code l'adresse qui va très probablement être valide dans une ligne 'm', et le reste des adresses comme lignes a= après cette ligne 'm'. De cette façon, les systèmes qui ne prennent pas en charge ICE ignorent simplement la ligne a= et utilisent seulement l'adresse dans la ligne 'm'. Cela réalise une bonne rétro compatibilité.

On a choisi de grouper les lignes 'm' avec différentes versions IP au niveau 'm' (sémantique ANAT) plutôt qu'au niveau a= (format ICE) afin de garder la syntaxe IPv6 libre des paramètres ICE utilisés pour les traducteurs d'adresse réseau (NAT, Network Address Translator) (IPv4) traditionnels. Cela donne une syntaxe beaucoup plus proche du SDP traditionnel, où les adresses IPv6 sont définies dans leur propre ligne 'm', plutôt que dans des paramètres qui appartiennent à une ligne 'm' différente.

De plus, ICE permet seulement de fournir une seule adresse principale lorsque l'homologue ne prend pas en charge ICE. La sémantique ANAT évite de reléguer certains types d'adresses (par exemple, les adresses IPv6) à être seulement une solution de remplacement secondaire d'un autre type d'adresse (par exemple, des adresses IPv4).

La séparation entre ANAT et ICE aide de plus les systèmes qui prennent en charge IPv4 et IPv6 mais n'ont pas besoin de prendre en charge ICE (par exemple, un serveur de diffusion groupée).

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. Sémantique d'ANAT

On définit un nouvel attribut "semantics" au sein du cadre de groupage SDP [RFC3388] : types d'adresse réseau de remplacement (ANAT, Alternative Network Address Type).

Les lignes de supports groupées en utilisant la sémantique ANAT fournissent des adresses réseau de remplacement de différents types pour un seul flux de supports logique. L'entité qui crée une description de session avec un groupe ANAT DOIT être prête à recevoir (ou envoyer) des supports sur toute ligne 'm' groupée. La sémantique ANAT NE DOIT PAS être utilisée pour grouper des flux de supports dont les adresses réseau sont du même type.

4. Préférence

L'entité qui génère une description de session peut avoir un ordre de préférence pour les types d'adresse réseau de remplacement offerts. Les identifiants des flux de supports DOIVENT être énumérés dans l'ordre de préférence dans la ligne de groupe. Par exemple, dans la description de session de la Section 6, la ligne 'm' avec mid=1 a une plus forte préférence que la ligne 'm' avec mid=2.

5. Offre/réponse et ANAT

Un offreur qui utilise SIP [RFC3261] pour envoyer son offre DEVRAIT placer l'étiquette d'option sdp-anat [RFC4092] dans un champ d'en-tête Require.

Un répondant qui reçoit une description de session qui utilise la sémantique ANAT DEVRAIT utiliser l'adresse avec la plus forte priorité qu'il comprend et régler les accès du reste des lignes 'm' dans le groupe à zéro.

6. Exemple

La description de session ci-dessous contient une adresse IPv4 et une adresse IPv6 groupées en utilisant ANAT. Le format correspondant à la transposition de ICE dans SDP [RFC5245] peut être utilisée dans les deux lignes 'm' pour fournir des adresses supplémentaires.

v=0

o=bob 280744730 28977631 IN IP4 host.example.com

s=

t=0 0

a=group:ANAT 1 2

m=audio 25000 RTP/AVP 0

c=IN IP6 2001:DB8::1

a= <adresses (et accès) IPv6 supplémentaires codées en ICE>

a=mid:1

m=audio 22334 RTP/AVP 0

c=IN IP4 192.0.2.1

a= <adresses (et accès) IPv4 supplémentaires codées en ICE>

a=mid:2

7. Considérations sur la sécurité

Un attaquant qui ajoute des lignes "group", en utilisant la sémantique ANAT, à une description de session SDP pourrait faire qu'un point d'extrémité utilise seulement un parmi tous les flux offerts par l'extrémité distante, alors que l'intention de l'extrémité distante aurait été d'établir tous les flux.

Un attaquant qui supprime des lignes "group" en utilisant la sémantique ANAT pourrait faire qu'un point d'extrémité établisse un plus grand nombre de flux de supports. Si le point d'extrémité envoie des supports sur tous, la bande passante de session peut augmenter considérablement.

Il est donc fortement RECOMMANDÉ que la protection de l'intégrité soit appliquée aux descriptions de sessions SDP. Pour les descriptions de session portées dans SIP [RFC3261], S/MIME est le choix naturel pour fournir une telle protection d'intégrité de bout en bout, comme décrit dans la [RFC3261]. D'autres applications PEUVENT utiliser une forme différente de protection de l'intégrité.

8. Considérations relatives à l'IANA

L'IANA a enregistré le nouvel attribut "semantics" suivant pour le cadre de groupage SDP [RFC3388] :

Semantics	Jeton	Référence
Alternative Network Address Types	ANAT	[RFC4091]

ANAT a été enregistré dans le registre des paramètres SIP sous Sémantique pour l'attribut SDP "group".

9. Références

9.1 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)

[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)

[RFC4092] G. Camarillo, J. Rosenberg, "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)", juin 2005. (P.S.)

9.2 Références pour information

[RFC5245] J. Rosenberg, "Établissement de connexité interactive (ICE) : Protocole pour la traversée de traducteur d'adresse réseau (NAT) pour les prorocoles d'offre/réponse", avril 2010. (Remplace RFC4091, 4092) (P. S. ; remplacée par 8445)

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.