Équipe d'ingénierie de l'Internet (IETF)

Accès du protocole de contrôle RTP (RTCP)
pour les sessions de diffusion groupée spécifique de la source (SSM)

Le protocole de description de session (SDP, Session Description Protocol) a un attribut qui permet aux applications RTP de spécifier une adresse et un accès associés au trafic du protocole de contrôle de RTP (RTCP). Dans les sessions en diffusion groupée spécifique de source (SSM, source-specific multicast) fondées sur RTP, le même attribut est utilisé pour désigner l'adresse et l'accès RTCP de la cible de retour dans la description SDP. Cependant, l'accès RTCP associé à la session SSM elle-même ne peut pas être spécifié par le même attribut pour éviter les ambiguïtés, et donc, il faut le déduire de la ligne "m=" de la description du support. Déduire l'accès RTCP de la ligne "m=" impose une restriction inutile. Le présent document supprime cette restriction en introduisant un nouvel attribut SDP.

Le présent document a été produit par l'équipe d'ingénierie de l'Internet (IETF). Il représente le consensus de la communauté de l'IETF. Il a été accepté après relecture publique et sa publication a été approuvée par le groupe de pilotage de l'ingénierie de l'Internet (IESG, Internet Engineering Steering Group). D'autres informations sur les normes de l'Internet sont disponibles à la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, sur tout errata, et sur la façon d'y faire des commentaires peuvent être obtenues à ;http://www.rfc-editor.org/info/rfc6128.

Le présent document est soumis aux dispositions légales du BCP 78 et de l'IETF Trust qui se rapportent aux documents de l'IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication du présent document. Prière de relire ces documents avec soin, car ils décrivent vos droits et obligations à l'égard du présent document. Les composants de code extraits de ce document doivent comporter le texte de la licence simplifiée de BSD telle que décrite au paragraphe 4.e des dispositions légales du Trust et ils sont fournis sans garantie comme décrit dans la license BSD simplifiée.

Table des matières

1. Introduction 1

2. Attribut 'multicast-rtcp' 2

3. Exemple de SDP 2

4. Considérations sur la sécurité 3

5. Considérations relatives à l'IANA 3

5.1 Enregistrement des attributs SDP 3

6. Remerciements 4

7. Références 4

7.1 Références normatives 4

7.2 Références pour information 4

Le protocole de description de session (SDP) [RFC4566] a un attribut qui permet aux applications RTP [RFC3550] de spécifier une adresse et un accès associés au trafic du protocole de contrôle de RTP (RTCP) [RFC3605]. Cet attribut est appelé 'rtcp'.

Considérons maintenant un réseau où un ou plusieurs envoyeurs de supports envoient des paquets RTP à une source de distribution, qui envoie alors ces paquets en diffusion groupée aux receveurs de la diffusion groupée en utilisant un arrangement de diffusion groupée spécifique de la source (SSM, source-specific multicast) de la [RFC5760]. La source de la distribution envoie aussi en diffusion groupée le trafic RTCP à transmettre (c'est-à-dire, les rapports d'envoyeur RTCP et les rapports de receveu ou leurs résumés) aux receveus dans la même session SSM.

Dans les sessions SSM fondées sur RTP, l'attribut 'rtcp' est utilisé pour désigner l'adresse et l'accès RTCP de la cible de retours dans la description SDP [RFC5760]. Cependant, l'accès RTCP associé à la session SSM elle-même ne peut pas être spécifié par le même attribut car cela pourrait éventuellement causer une ambiguïté. Donc, l'accès RTCP de diffusion groupée doit être déduit de la ligne "m=" de la description du support (voir au paragraphe 10.2 de la [RFC5760]) en suivant la règle +1 (voir la Section 11 de la [RFC3550]). Cependant, la [RFC3550] a levé l'exigence de la règle +1 car elle imposait une restriction inutile au choix de l'accès RTCP.

Dans la présente spécification, on introduit un nouvel attribut SDP pour supprimer cette restriction. Le nouvel attribut permet à l'envoyeur de diffusion groupée d'utiliser l'accès désiré dans la session RTCP. Le présent document met à jour la [RFC5760].

Dans les sessions SSS fondées sur RTP, la source de distribution peut utiliser différents accès RTP et RTCP de diffusion groupée pour envoyer respectivement les paquets RTP et RTCP. Autrement, la source de distribution peut utiliser le mélange d'accès RTP/ RTCP de la [RFC5761], auquel cas, les paquets RTP et RTCP sont envoyée au même accès de destination dans la session SSM.

Pour les cas où la source de distribution ne veut pas utiliser l'accès supérieur pour le trafic RTCP, le présent document définit un nouvel attribut SDP, appelé 'multicast-rtcp'. En utilisant cet attribut, la source de distribution se sert d'un accès désiré pour la session SSM RTCP. En l'absence de l'attribut 'multicast-rtcp', la règle +1 s'applique suivant la [RFC5760].

La syntaxe ABNF suivante [RFC5234] décrit formellement l'attribut 'multicast-rtcp' :

Ici, le jeton 'port' est défini comme spécifié à la Section 9 de la [RFC4566].

L'attribut 'multicast-rtcp' est défini comme un attribut à la fois de niveau support et un attribut de niveau session. Sauf mention contraire dans ce document, les règles de la [RFC3550] s'appliquent.

Dans la description de ssession que montre la Figure 2, un flux de source est envoyé en diffusion groupée d'une source de distribution (avec une adresse IP de source de 198.51.100.1) à l'adresse de destination de diffusion groupée 233.252.0.2 et l'accès 41000. Le trafic RTCP transmis est envoyé en diffusion groupée dans le même groupe de diffusion groupée mais à l'accès 42000 comme spécifié par la ligne "a=multicast-rtcp:42000". Une cible de retour avec une adresse de 192.0.2.1 et un accès de 43000 est spécifiée par l'attribut 'rtcp'.

Figure 2 : Exemple de SDP montrant l'utilisation de l'attribut 'multicast-rtcp'

On ne pense pas que l'attribut 'multicast-rtcp' introduise aucun risque significatif pour la sécurité des applications multimédia. Un tiers malveillant pourrait utiliser cet attribut pour rediriger le trafic RTCP, mais cela exige d'intercepter et de réécrire les paquets qui portent la description SDP ; et si un intercepteur peut faire cela, il peut faire bien d'autres attaques, y compris un changement complet des adresses et des numéros d'accès auxquels le support sera envoyé.

Pour éviter des attaques de cette sorte, l'intégrité de la description SDP doit être protégée et munie d'une authentification de source. Cela peut, par exemple, être réalisé de bout en bout avec S/MIME [RFC5652] [RFC5751] lorsque SDP est utilisé dans un paquet de signalisation qui utilise les types MIME (application/sdp). Autrement, HTTPS [RFC2818] ou la méthode d'authentification du protocole d'annonce de session (SAP) [RFC2974] pourraient aussi être utilisés.

Les informations de contact suivantes devront être utilisées pour tout enregistrement dans ce document :

Merci à Colin Perkins et Magnus Westerlund pour leur suggestion du nom de l'attribut 'multicast-rtcp' et pour la fourniture de portions du texte de cette spécification. Certaines parties de cette spécification s'appuient sur la [RFC3605] et la [RFC5760]. Alors, merci aussi à ceux qui ont contribué à ces spécifications.

[RFC4566] M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.)

[RFC5760] J. Ott, J. Chesterfield, E. Schooler, "Extensions au protocole de contrôle RTP (RTCP) pour les sessions de diffusion groupée à une seule source avec retour en envoi individuel", février 2010. (P. S.)

[RFC3605] C. Huitema, "Attribut du protocole de contrôle en temps réel (RTCP) dans le protocole de description de session (SDP)", octobre 2003. (P.S.)

[RFC5761] C. Perkins, M. Westerlund, "Multiplexage de paquets de données et de contrôle RTP sur un seul accès", avril 2010. (MàJ RFC3550, RFC3551). (P. S.)

[RFC5652] R. Housley, "Syntaxe de message cryptographique (CMS)", septembre 2009. (Remplace RFC3852) (D. S.)

[RFC2974] M. Handley, C. Perkins, E. Whelan, "Protocole d'annonce de session (SAP)", octobre 2000. (Expérimentale)

[RFC5751] B. Ramsdell, S. Turner, "Spécification du message des extensions de messagerie Internet multi objets sécurisée (S/MIME) version 3.2", janvier 2010. (Remplace RFC3851). (P. S.)

Équipe d'ingénierie de l'Internet (IETF)	A. Begen, Cisco
Request for Comments : 6128	février 2011
RFC mise à jour : 5760
Catégorie : En cours de normalisation
ISSN: 2070-1721	Traduction Claude Brière de L'Isle