Actions visant les problèmes identifiés de la transaction Non-INVITE du protocole d’initialisation de session (SIP)

Statut du présent mémoire

Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restrictions.

Déclaration de copyright

Copyright (C) The Internet Society (2006).

Résumé

Le présent document décrit les modifications apportées au protocole d’initialisation de session (SIP, Session Initiation Protocol) pour régler les problèmes qui ont été identifiés avec la transaction SIP Non-INVITE. Ces modifications réduisent la probabilité que des messages perdent la condition de compétition inhérente à la transaction Non-INVITE et réduisent le trafic réseau inutile. Elles améliorent aussi la robustesse des réseaux SIP lorsque des éléments cessent de répondre. Ces changements mettent à jour le comportement défini dans la RFC 3261.

1 Introduction

Un certain nombre d’effets aux contours déplaisants sont créés par la durée fixe du modèle de transaction Non-INVITE (NIT) de SIP. Leurs aspects négatifs sont exacerbés par l’effet qu’ont les réponses provisoires sur les automates à état de transaction Non-INVITE. Ces problèmes sont exposés dans [3]. En résumé :

Une transaction Non-INVITE doit s’achever immédiatement ou risquer de perdre la course ;

La perte de la course causera l’arrêt de l’envoi de trafic du demandeur à celui qui répond (celui qui répond sera temporairement mis en liste noire) ;

Les réponses provisoires peuvent retarder la récupération de la perte de réponses finales ;

La réponse 408 est inutile pour la transaction Non-INVITE ;

Lorsque des transactions Non-INVITE arrivent à expiration de temporisation à travers N mandataires, il peut y avoir une avalanche de O(N^2) réponses 408 inutiles.

Le présent document spécifie les mises à jour à la RFC 3261 [1] qui améliorent le comportement des éléments SIP lorsque surviennent ces conditions.

2 Amélioration de la situation lorsque des réponses sont seulement retardées

Deux objectifs sont à atteindre lorsqu’on restreint le problème aux cas où tous les éléments répondent en fin de compte et où les réseaux finissent par livrer les messages :

o Réduire la probabilité de perdre la course, de préférence jusqu’au point où elle est négligeable ;

o Réduire ou éliminer les échanges de messages inutiles.

2.1 Action 1 : Faire le meilleur usage des réponses provisoires

o Interdire les réponses provisoires non-100 aux demandes Non-INVITE ;

o Interdire la réponse 100 En-essai aux demandes Non-INVITE avant que le temporisateur E n’atteigne T2 (pour les bonds UDP) ;

o Permettre la réponse 100 En-essai après que le temporisateur E ait atteint T2 (pour les bonds UDP) ;

o Permettre 100 En-essai pour les bonds sur les transports fiables.

Comme les transactions Non-INVITE doivent se terminer rapidement ([3]), toute information au-delà de "Je suis là" (qui peut être fournie par un 100 En-essai) peut aussi bien être retardée jusqu’à la réponse finale. L’envoi de réponses provisoires non-100 gaspille de la bande passante.

Comme indiqué dans [3], l’envoi de toute réponse provisoire à l’intérieur d’une NIT avant que le temporisateur E n’atteigne T2 entrave la récupération sur échec d’un transport non fiable.

Sans réponse provisoire, une réponse finale tardive est la même chose que pas de réponse du tout et va vraisemblablement déboucher sur la mise en liste noire de l’élément qui tarde à répondre ([3]). Si un élément doit retarder sa réponse finale, l’envoi d’un 100 En-essai après que le temporisateur E atteigne T2 empêche sa mise en liste noire sans entraver la récupération de l’échec d’un transport non fiable.

La mise en liste noire pour réponse tardive survient également sur les transports fiables. Et donc, si un élément qui traite une demande reçue sur un transport fiable retarde sa réponse finale, et envoie un 100 En-essai bien avant l’expiration du temporisateur, il empêchera sa mise en liste noire. L’envoi immédiat d’un 100 En-essai n’entravera pas la transaction comme ce serait le cas sur UDP, mais une politique d’envoi systématique d’un tel message résulte en du trafic inutile. Une politique d’envoi d’un 100 En-essai après la période dans laquelle le temporisateur E aurait atteint T2 si cela avait été un bond UDP est un compromis raisonnable.

2.2 Action 2 : Supprimer l’avalanche de réponses tardives inutiles

o Interdire la réponse 408 aux demandes Non-INVITE ;

o Absorber les réponses Non-INVITE errantes au niveau des mandataires.

Une réponse 408 à une transaction Non-INVITE arrivera toujours trop tard pour être utile ([3]). Le client a déjà une parfaite connaissance de la fin de temporisation. La seule information que va apporter ce message est de savoir si le serveur croit ou non que la transaction est arivée en fin de temporisation. Cependant, avec la conception actuelle de la NIT, un client ne peut rien faire de cette information. Et donc, la réponse 408 est simplement un gaspillage des ressources du réseau et contribue au bombardement de réponses illustré dans [3].

Les réponses Non-INVITE tardives arrivent par définition après l’expiration du temporisateur F de la transaction du client et après que la transaction du client soit entrée dans l’état Terminé. Et donc, ces réponses ne peuvent pas être distinguées des errantes. Changer le comportement du protocole pour interdire la transmission des réponses Non-INVITE errantes arrête l’avalanche de réponses tardives. Cela améliore aussi les défenses du mandataire contre les usagers malveillants qui comptent sur les exigences de la RFC 3261 pour transmettre de telles réponses errantes.

3 Améliorer la situation lorsqu’un élément ne va pas répondre

Lorsqu’on étend le domaine d’application du problème pour couvrit aussi l’échec d’un élément ou du réseau, on a aussi plus d’objectifs à réaliser :

o Identifier le moment où un élément ne répond plus ;

o Minimiser ou éliminer les éléments qui envoient des réponses faussement identifiantes comme non répondants ;

o Éviter les éléments non répondants des futures demandes.

L’action 1 aide pour les deux premiers objectifs, améliorant considérablement la capacité d’un élément à distinguer entre un échec et une réponse en retard de la part du prochain élément aval. Une réponse, provisoire ou finale sera presque certainement reçue avant l’expiration du temps imparti à la transaction. Ainsi, un élément peut plus surement supposer que pas de réponse du tout indique que l’homologue n’est pas disponible et suivre les exigences existantes dans [1] et [2] pour ce cas.

Réaliser le troisième objectif exige des changements plus marqués du protocole. Comme noté dans [3], les transactions Non-INVITE futures vont vraisemblablement échouer à nouveau si la mise en œuvre ne prend pas des mesures allant au-delà de ce qui est indiqué dans [1] et [2] pour se souvenir entre les transactions des destinations qui ne répondent pas. La normalisation de ces autres étapes fera l’objet de travaux ultérieurs.

4 Mises à jour normatives à la RFC 3261

4.1 Action 1

Un élément SIP NE DOIT PAS envoyer de réponse provisoire avec un code d’état autre que 100 à une demande non INVITE.

Un élément SIP NE DOIT PAS répondre à une demande non INVITE par un code d’état de 100 sur un transport non fiable, tel que UDP, avant la durée que met le temporisateur E d’une transaction de client pour se remettre à T2.

Un élément SIP PEUT répondre à une demande Non-INVITE par un code d’état de 100 sur un transport fiable à tout moment.

Sans considération pour le transport, un élément SIP DOIT répondre à une demande Non-INVITE par un code d’état de 100 si il n’a pas répondu autrement après le temps que met le temporisateur E de la transaction d’un client pour se remettre à T2.

4.2 Action 2

Un élément SIP à états de transaction pleins NE DOIT PAS envoyer de réponse avec un code d’état de 408 à une demande Non-INVITE. Par conséquent, un élément qui ne peut pas répondre avant que la transaction n’arrive à expiration n’enverra pas de réponse finale du tout.

Un mandataire SIP à états de transaction pleins NE DOIT PAS envoyer de réponse à une demande Non-INVITE à ùoins qu’il n’ait une transaction d’un serveur correspondant qui ne soit pas dans l’état Terminé. Par conséquent, ce mandataire ne transmettra aucune réponse Non-INVITE "tardive".

5 Considérations pour la sécurité

Le présent document fait un certain nombre de petits changements à la spécification principale de SIP [1] pour améliorer la robustesse des transactions Non-INVITE de SIP. Beaucoup de ces actions empêchent aussi les attaques par débordement et de déni de service.

Un changement interdit aux madataites et agents d’utilisateur d’envoyer des réponses 408 à des transactions Non-INVITE. Sans ce changement, les mandataires génèrent automatiquement une avalanche de réponses inutiles comme décrit dans [3]. Un attaquant pourrait s’appuyer sur cela en amenant des agents d’utilisateur à envoyer des demandes Non-INVITE à un trou noir (par de l’ingénierie sociale ou l’empoisonnement du DNS) ou en éliminant des réponses choisies.

Un autre changement interdit aux mandataires de transmettre des réponses tardives. Sans ce changement, un attaquant pourrait facilement falsifier des messages pour qu’ils apparaissent comme des réponses tardives. Tous les mandataires conformes à la RFC 3261 sont obligés de transmettre ces réponses, qui gaspillent de la bande passante et des CPU et submergeant potentiellement les agents d’utilisateur cibles (en particulier ceux qui ont des connexions à basse vitesse).

Le reste de ces changements n’affecte pas la sécurité du protocole SIP.

6 Contributeurs

Rohan Mahy a fourni la section des Considérations sur la sécurité.

7 Références normatives

[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley et E. Schooler, "SIP: Protocole d’initialisation de session", RFC 3261, juin 2002.

[2] J. Rosenberg et H. Schulzrinne, "Protocole d’initialisation de session (SIP) : Localisation des serveurs SIP", RFC 3263, juin 2002.

[3] Sparks, R., "Problèmes identifiés en association avec la transaction Non-Invite du protocole d’initialisation de session (SIP)", RFC 4321, janvier 2006.

Adresse de l’auteur

Robert J. Sparks

Estacado Systems

17210 Campbell Road

Suite 250

Dallas, TX 75252-4203

USA

mél : rjsparks@estacado.net

Déclaration de copyright

Copyright (C) The Internet Society (2006).

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 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.

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 pourraient ê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 l’activité de soutien administratif (IASA) de l’IETF.