Protocole d’initiation de session (SIP) : Localisation des serveurs SIP

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

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

Résumé
Le protocole d’initiation de session (SIP, Session Initiation Protocol) utilise les procédures de DNS pour permettre à un client de résoudre un identifiant de ressource uniforme (URI, Uniform Resource Identifier) SIP en l’adresse IP, port, et protocole de transport du prochain bond à contacter. Il utilise aussi DNS pour permettre à un serveur d’envoyer une réponse à un client de secours si le client principal est défaillant. Le présent document décrit ces procédures DNS en détail.

Table des matières

1 Introduction
2 Problèmes pour lesquels DNS est nécessaire
3 Terminologie
4 Usage par le client
4.1 Sélection d’un protocole de transport
4.2 Détermination du port et de l’adresse IP
4.3 Détails du traitement de la RFC 2782
4.4 Considérations concernant les mandataires sans état
5 Usage par le serveur
6 Construction des URI SIP
7 Considérations pour la sécurité
8 Application de détermination du transport
9 Considérations relatives à l’IANA
10 Remerciements
11 Références normatives
12 Références informatives
13 Adresse des auteurs
14 Déclaration complète de droits de reproduction

1 Introduction

Le protocole d’initiation de session (SIP, Session Initiation Protocol) (RFC 3261 [1]) est un protocole client-serveur utilisé pour l’initiation et la gestion des sessions de communications entre des utilisateurs. Les systèmes terminaux de SIP sont appelés agents d’utilisateurs, et les éléments intermédiaires sont connus sous le nom de serveurs mandataires. Une configuration SIP normale, dénommée "trapézoïde" SIP, est indiquée à la Figure 1. Dans ce diagramme, un appelant dans le domaine A (UA1) souhaite appeler Joe dans le domaine B (joe@B). Pour ce faire, il communique avec le mandataire 1 dans son domaine (le domaine A). Le mandataire 1 transmet la demande au mandataire pour le domaine de la partie appelée (le domaine B), qui est le mandataire 2. Le mandataire 2 transmet l’appel au demandé , UA 2.

Au titre de ce flux d’appel, le mandataire 1 a besoin de déterminer un serveur SIP pour le domaine B. Pour ce faire, le mandataire 1 utilise les procédures DNS, utilisant à la fois les enregistrements SRV [2] et NAPTR [3]. Le présent document décrit les problèmes spécifiques que l’utilisation de DNS par SIP aide à résoudre, et donne leur solution.

2 Problèmes pour lesquels DNS est nécessaire

DNS est nécessaire pour aider à résoudre deux aspects du flux d’appel général décrit dans l’introduction. Le premier est celui de la découverte par le mandataire 1 du serveur SIP dans le domaine B, afin de transmettre l’appel pour joe@B. Le second est celui de l’identification par le mandataire 2 d’une sauvegarde pour le mandataire 1 dans l’éventualité d’une défaillance après la transmission de la demande.

Pour le premier aspect, le mandataire 1 a spécifiquement besoin de déterminer l’adresse IP, le port, et le protocole de transport pour le serveur dans le domaine B. Le choix du protocole de transport est particulièrement digne d’attention. À la différence de nombreux autres protocoles, SIP peut fonctionner sur des protocoles de transport très variés, incluant TCP, UDP, et SCTP. SIP peut aussi utiliser TLS. Actuellement, l’utilisation de TLS est seulement définie pour TCP. Et donc, les clients doivent être capables de déterminer automatiquement quels protocoles de transport sont disponibles. Le mandataire qui envoie la demande a un ensemble de protocoles de transport particulier qu’il prend en charge et une préférence pour l’utilisation de ces protocoles de transport. Le mandataire 2 a son propre ensemble de protocoles de transport qu’il prend en charge, et une préférence relative pour ces protocoles de transport. Tous les mandataires doivent mettre en oeuvre à la fois

UDP et TCP, ainsi que TLS sur TCP, de sorte qu’il y a toujours une intersection des capacités. Certaines formes des procédures DNS sont nécessaires pour que le mandataire 1 découvre les protocoles de transport disponibles pour les services SIP au domaine B, et les préférences relatives de ces protocoles de transport. Le mandataire 1 croise sa liste de protocoles de transport qu’il prend en charge avec celle du mandataire 2 et choisit alors le protocole préféré par le mandataire 2.

Figure 1 : Le trapézoïde SIP

Il est important de noter que les recherches DNS peuvent être utilisées plusieurs fois à travers le traitement d’un appel. En général, un élément (qu’on appelle un client) qui souhaite envoyer une demande peut avoir besoin d’effectuer un traitement DNS pour déterminer l’adresse IP, le port, et le protocole de transport de l’élément du prochain bond, appelé un serveur (il peut être un mandataire ou un agent d’utilisateur). Un tel traitement pourrait, en principe, survenir à chaque bond entre les éléments.

Comme SIP est utilisé pour l’établissement de services de communication interactifs, le temps nécessaire à l’achèvement d’une transaction entre appelant et appelé est important. Normalement, le temps depuis le moment où l’appelant initie un appel jusqu’au moment où l’appelé est alerté ne devrait pas dépasser quelques secondes. Comme il peut y avoir plusieurs bonds, dont chacun d’eux fait des recherches DNS en plus d’autres opérations potentiellement consommatrices de temps, la quantité de temps disponible pour les recherches DNS à chaque bond est limitée.

La mesurabilité et une forte disponibilité sont importantes dans SIP. Les services SIP s’échelonnent à travers des techniques de mise en grappe. Normalement, dans une version réaliste du réseau à la Figure 1, le mandataire 2 serait une grappe de mandataires configurés de façon homogène. DNS a besoin de fournir au domaine B la capacité de configurer un ensemble de serveurs, ainsi que des priorités et des pondérations, afin de fournir un niveau brut d’équilibrage de charge fondé sur la capacité.

SIP assure une forte disponibilité en ayant une détection des défaillances sur les éléments amont. Par exemple, supposons que le mandataire 2 soit mis en œuvre comme une grappe de deux mandataires, les mandataires 2.1 et 2.2. Si le mandataire 1 envoie une demande au mandataire 2.1 et que la demande échoue, il réessaye la demande en l’envoyant au mandataire 2.2. Dans de nombreux cas, le mandataire 1 ne connaîtra pas les domaines avec lesquels il va en fin de compte communiquer. Cette information serait connue lorsqu’un usager fait réellement un appel à un autre usager dans ce domaine. Le mandataire 1 peut ne jamais communiquer à nouveau avec ce domaine après la fin de cet appel. Le mandataire 1 peut communiquer avec des milliers de domaines différents en quelques minutes, et le mandataire 2 pourrait recevoir des demandes de milliers de domaines différents en quelques minutes. À cause de ces relations de "beaucoup à beaucoup", et de la possibilité de longs intervalles entre les communications entre une paire de domaines, il n’est généralement pas possible à un élément de maintenir un état de disponibilité dynamique avec les mandataires avec lesquels il communique. Lorsqu’un mandataire obtient son premier appel avec un domaine particulier, il va essayer les serveurs de ce domaine dans un certain ordre jusqu’à ce qu’il en trouve un qui soit disponible. L’identité du serveur disponible pourrait dans l’idéal être mise en mémoire cache pendant un certain temps afin de réduire les délais d’établissement d’appel pour les appels ultérieurs. Le client ne peut pas interroger constamment un serveur défaillant pour déterminer quand il va redevenir disponible. De plus, l’état de disponibilité doit en fin de compte être dépassé afin de redistribuer les charges aux éléments récupérés lorsqu’ils reviennent en ligne.

Il est possible que des éléments défaillent au milieu d’une transaction. Par exemple, après que le mandataire 2 ait transmis la demande à l’UA 2, le mandataire 1 a une défaillance. L’UA 2 envoie sa réponse au mandataire 2, qui essaye de la transmettre au mandataire 1, qui n’est plus disponible. Le second aspect du flux de l’introduction pour lequel DNS est nécessaire est pour que le mandataire 2 identifie une sauvegarde pour le mandataire 1, à laquelle il puisse envoyer la réponse. Ce problème est plus réaliste dans SIP que dans les autres protocoles transactionnels. La raison en est que certaines réponses SIP peuvent mettre longtemps à être générées, parce qu’un utilisateur humain a souvent besoin d’être consulté pour générer cette réponse. C’est pourquoi il n’est pas rare que des dizaines de secondes s’écoulent entre une demande d’appel et son acceptation.

3 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 la RFC 2119 [2] et indiquent les niveaux d’exigence pour les mises en œuvre SIP conformes.

4 Usage par le client

L’usage de DNS est différent pour les clients et les serveurs. La présente section discute des usages de client. On suppose que le client est à états pleins (soit un client d’agent d’utilisateur (UAC, User Agent Client) soit un mandataire à états pleins). Les mandataires sans états sont exposés au paragraphe 4.4.

Les procédures présentes sont invoquées lorsqu’un client a besoin d’envoyer une demande à une ressource identifiée par un URI SIP ou SIPS (SIP sécurisé). Cet URI peut identifier la ressource désirée que vise la demande (auquel cas, l’URI se trouve dans le Request-URI), ou il peut identifier un bond intermédiaire vers cette ressource (auquel cas, l’URI se trouve dans l’en-tête Route). La procédure définie ici n’affecte en aucune façon cet URI (c’est-à-dire que l’URI n’est pas réécrit par suite de la recherche DNS), elle a pour seul résultat une adresse IP, un port et le protocole de transport où la demande peut être envoyée. La RFC 3261 [1] donne des lignes directrices sur la détermination des URI qui ont besoin d’être résolus dans DNS pour déterminer l’hôte auquel la demande doit être envoyée. Dans certains cas, également mentionnés dans [1], la demande peut être envoyée à un mandataire intermédiaire spécifique non identifié par un URI SIP, mais plutôt par un nom d’hôte ou une adresse IP numérique. Dans ce cas, il est construit un URI temporaire, utilisé pour les besoins de la présente spécification. Cet URI est de la forme sip:<proxy>, où <proxy> est le FQDN ou l’adresse IP numérique du mandataire du prochain bond. Il en résulte, dans tous les cas, que le problème se réduit à la résolution d’un URI SIP ou SIPS dans DNS pour déterminer l’adresse IP, le port, et le transport de l’hôte auquel la demande est à envoyer.

Ces procédures DOIVENT être suivies exactement une fois par transaction, transaction étant définie en [1]. C’est-à-dire que une fois qu’un serveur SIP a été contacté avec succès (succès est défini ci-dessous), toutes les retransmissions de la demande SIP et le ACK pour les réponses SIP non 2xx à INVITE DOIVENT être envoyées au même hôte. De plus, un CANCEL pour une demande SIP particulière DOIT être envoyé au même serveur SIP que celui auquel la demande SIP a été livrée.

Parce que la demande ACK pour les réponses 2xx à INVITE constitue une transaction différente, il n’est pas exigé qu’elle soit livrée au même serveur que celui qui a reçu la demande d’origine (bien sûr, si un serveur n’a pas enregistré l’acheminement, il n’obtiendra pas l’accusé de réception ACK).

On définit TARGET comme la valeur du paramètre maddr de l’URI, s’il est présent, autrement, la valeur d’hôte du composant hostport de l’URI. Elle identifie le domaine à contacter. Une description des URI SIP et SIPS et une définition de ces paramètres se trouve dans [1].

On détermine le protocole de transport, le port et l’adresse IP d’une instance convenable de TARGET aux paragraphes 4.1 et 4.2.

4.1 Sélection d’un protocole de transport

Tout d’abord, le client choisit un protocole de transport.

Si l’URI spécifie un protocole de transport dans le paramètre transport, ce protocole de transport DEVRAIT être utilisé.

Autrement, si aucun protocole de transport n’est spécifié, mais si TARGET est une adresse IP numérique, le client DEVRAIT utiliser UDP pour un URI SIP, et TCP pour un URI SIPS. De même, si aucun protocole de transport n’est spécifié, et si TARGET n’est pas numérique, mais qu’un accès explicite est fourni, le client DEVRAIT utiliser UDP pour un URI SIP, et TCP pour un URI SIPS. Cela parce que UDP est le seul transport obligatoire dans la RFC 2543 [6], et donc le seul dont l’interopérabilité soit garantie pour un URI SIP. Il était aussi spécifié comme transport par défaut dans la RFC 2543 lorsque aucun transport n’était présent dans l’URI SIP. Cependant, un autre transport, tel que TCP, PEUT être utilisé si les lignes directrices de SIP le rendent obligatoire pour cette demande particulière. C’est le cas, par exemple, pour les demandes qui dépassent la MTU du chemin.

Autrement, si aucun protocole de transport ou port n’est spécifié, et si la cible n’est pas une adresse IP numérique, le client DEVRAIT effectuer une interrogation NAPTR pour le domaine dans l’URI. Les services pertinents pour le choix du protocole de transport sont ceux dans les champs de service NAPTR ont les valeurs "SIP+D2X" et "SIPS+D2X", où X est une lettre qui correspond à un protocole de transport pris en charge par le domaine. Cette spécification définit D2U pour UDP, D2T pour TCP, et D2S pour SCTP. On établit aussi un registre IANA pour le nom de service NAPTR pour les transpositions de protocole de transport.

Ces enregistrements NAPTR donnent une transposition d’un domaine dans l’enregistrement SRV pour contacter un serveur avec le protocole de transport spécifique dans le champ des services NAPTR. L’enregistrement de ressource sera contenu dans une expression régulière vide et une valeur de remplacement, qui est l’enregistrement SRV pour ce protocole de transport particulier. Si le serveur accepte plusieurs protocoles de transport, il y aura plusieurs enregistrements NAPTR, chacun avec une valeur de service différente. Conformément à la RFC 2915 [3], le client élimine tout enregistrement dont les champs de service ne sont pas applicables. Pour les besoins de la présente spécification, plusieurs règles sont définies.

D’abord, un client qui résout un URI SIPS DOIT éliminer tous les services qui ne contiennent pas "SIPS" comme protocole dans le champ de service. L’inverse n’est cependant pas vrai. Un client qui résout un URI SIP DEVRAIT conserver les enregistrements portant "SIPS" comme protocole, si le client prend en charge TLS. Ensuite, un client DOIT éliminer tous les champs de service qui identifient un service de résolution dont la valeur n’est pas "D2X", pour les valeurs de X qui indiquent les protocoles de transport acceptés par le client. Le traitement NAPTR tel que décrit dans la RFC 2915 permettra la découverte du protocole de transport ayant la plus forte préférence pour le serveur et qui est pris en charge par le client, ainsi qu’un enregistrement SRV pour le serveur. Il permettra aussi au client de découvrir si TLS est disponible et sa préférence d’utilisation.

Par exemple, considérons un client qui souhaite résoudre sip:user@example.com. Le client effectue une interrogation NAPTR pour ce domaine, et les enregistrements NAPTR suivants sont retournés.

Ceci indique que le serveur prend en charge TLS sur TCP, TCP, et UDP, dans cet ordre de préférence. Comme le client accepte TCP et UDP, TCP sera utilisé, ciblé sur un hôte déterminé par une recherche SRV de _sip._tcp.example.com. Cette recherche retournerait :

Si un mandataire SIP, serveur de redirection ou registraire doit être contacté à travers la recherche d’enregistrements NAPTR, il DOIT y avoir au moins trois enregistrements – un avec un champ de service "SIP+D2T", un avec un champ de service "SIP+D2U", et un avec un champ de service "SIPS+D2T". Les enregistrements avec SIPS comme protocole dans le champ de service DEVRAIENT être préférés (c’est-à-dire, avoir une valeur inférieure du champ d’ordre) aux enregistrements ayant SIP comme protocole dans le champ de service. Un enregistrement avec un champ de service "SIPS+D2U" NE DEVRAIT PAS être placé dans le DNS, car il n’est pas possible d’utiliser TLS sur UDP.

Il n’est pas nécessaire que les suffixes de domaine dans le champ de remplacement NAPTR correspondent au domaine de la demande originale (c’est-à-dire, example.com ci-dessus). Cependant, pour les besoins de la rétrocompatibilité avec la RFC 2543, un domaine DOIT conserver les enregistrements SRV pour le domaine de la demande d’origine, même si l’enregistrement NAPTR est dans un domaine différent. Par exemple, bien que l’enregistrement SRV pour TCP soit _sip._tcp.school.edu, il DOIT aussi y avoir un enregistrement SRV à _sip._tcp.example.com.

La RFC 2543 recherche directement les enregistrements SRV pour le domaine. S’ils n’existent pas parce que le remplacement NAPTR pointe sur un domaine différent, le client va échouer.

Pour les enregistrements NAPTR avec des champs de protocole SIPS, (si le serveur utilise un certificat de site), le nom de domaine dans l’interrogation et le nom de domaine dans le champ de remplacement DOIVENT être tous deux valides sur la base du certificat de site détenu par le serveur dans l’échange TLS. De même, le nom de domaine dans l’interrogation SRV et le nom de domaine dans la cible dans l’enregistrement SRV DOIVENT tous deux être valides sur la base du même certificat de site. Autrement, un attaquant pourrait modifier les enregistrements DNS pour qu’ils contiennent des valeurs de remplacement dans un domaine différent, et le client ne pourrait pas valider s’il s’agit du comportement désiré ou le résultat d’une attaque.

Si aucun enregistrement NAPTR n’est trouvé, le client construit des interrogations SRV pour les protocoles de transport qu’il prend en charge, et fait une interrogation pour chacun. Les interrogations sont effectuées en utilisant l’identifiant de service "_sip" pour les URI SIP et "_sips" pour les URI SIPS. Un transport particulier est pris en charge si l’interrogation est un succès. Le client PEUT utiliser tout protocole de transport qu’il désire et qui est pris en charge par le serveur.

Ceci est un changement par rapport à la RFC 2543. Celle-ci spécifiait qu’un client chercherait dans les enregistrements SRV tous les transports pris en charge et amalgamerait les valeurs de priorité de ces enregistrements. Puis, il choisirait l’enregistrement de plus haute préférence.

Si aucun enregistrement SRV n’est trouvé, le client DEVRAIT utiliser TCP pour un URI SIPS, et UDP pour un URI SIP. Cependant, un autre protocole de transport, comme TCP, PEUT être utilisé si les lignes directrices de SIP le rendent obligatoire pour cette demande particulière. C’est le cas, par exemple, pour les demandes qui dépassent la MTU du chemin.

4.2 Détermination du port et de l’adresse IP

Une fois que le protocole de transport a été déterminé, l’étape suivante est de déterminer l’adresse IP et le port.

Si TARGET est une adresse IP numérique, le client utilise cette adresse. Si l’URI contient aussi un port, il utilise ce port. Si aucun port n’est spécifié, il utilise le port par défaut pour le protocole de transport particulier.

Si TARGET n’était pas une adresse IP numérique mais si un port est présent dans l’URI, le client effectue une recherche d’enregistrement A ou AAAA du nom de domaine. Le résultat sera une liste d’adresses IP, dont chacune peut être contactée au port spécifique provenant de l’URI et avec le protocole de transport déterminé précédemment. Le client DEVRAIT essayer le premier enregistrement. Si une tentative devait échouer, sur la base de la définition de l’échec au paragraphe 4.3, la suivante DEVRAIT être tentée, et si elle échoue, la suivante DEVRAIT être tentée, et ainsi de suite.

Ceci est un changement par rapport à la RFC 2543. Précédemment, si le port était explicite, mais avait une valeur de 5060, les enregistrements SRV étaient utilisés. Maintenant, les enregistrements A ou AAAA seront utilisés.

Si TARGET n’était pas une adresse IP numérique, et si aucun port n’était présent dans l’URI, le client effectue une interrogation SRV sur l’enregistrement retourné du traitement NAPTR du paragraphe 4.1, si un tel traitement a été effectué. Si ce n’est pas le cas, parce qu’un transport était explicitement spécifié, le client effectue une interrogation SRV pour ce transport spécifique, en utilisant l’identifiant de service "_sips" pour les URI SIP. Pour un URI SIP, si le client souhaite utiliser TLS, il utilise aussi l’identifiant de service "_sips" pour ce transport spécifique, autrement, il utilise "_sip". Si le traitement NAPTR n’a pas été effectué parce qu’aucun enregistrement NAPTR n’a été trouvé, mais si une interrogation SRV pour un protocole de transport pris en charge a réussit, ces enregistrements SRV sont choisis. Indépendamment de la façon dont les enregistrements SRV ont été déterminés, les procédures de la RFC 2782, comme décrites au paragraphe intitulé "Règles d’usage" sont suivies, augmentées des procédures supplémentaires du paragraphe 4.3 du présent document.

Si aucun enregistrement SRV n’a été trouvé, le client effectue une recherche d’enregistrement A ou AAAA dans le nom de domaine. Le résultat sera une liste d’adresses IP, chacune d’elles pouvant être contactée en utilisant le protocole de transport déterminé précédemment, au port par défaut pour ce transport. Le traitement se déroule alors comme décrit ci-dessus pour un port explicite une fois que les enregistrements A ou AAAA ont été trouvés.

4.3 Détails du traitement de la RFC 2782

La RFC 2782 précise les détails de la façon dont un ensemble d’enregistrements SRV est trié puis essayé. Cependant, elle établit seulement que le client devrait "essayer de se connecter au (protocole, adresse, service)" sans donner aucun détail sur ce qui arrive en cas d’échec. Ces détails sont précisés ici pour SIP.

Pour les demandes SIP, l’échec survient si la couche de transaction rapporte une réponse d’erreur 503 ou un échec de transport de quelque sorte (généralement, dû à des erreurs ICMP fatales dans UDP ou des défaillances de connexion dans TCP). L’échec survient aussi si la couche de transaction dépasse le temps imparti sans avoir jamais reçu de réponse, provisoire ou finale (c’est à dire que le temporisateur B ou F de la RFC 3261 [1] arrive à expiration). Si une défaillance survient, le client DEVRAIT créer une nouvelle demande, identique à la précédente, mais avec une valeur différente de l’identifiant de branche Via de celle de la précédente (et donc qui constitue une nouvelle transaction SIP). Cette demande est envoyée à l’élément suivant de la liste comme spécifié par la RFC 2782.

4.4 Considérations concernant les mandataires sans état

Le processus des sections précédentes est à états pleins. Lorsque un serveur est contacté avec succès, toutes les retransmissions de la demande pour la transaction, ainsi que le ACK pour une réponse finale non 2xx, et les demandes CANCEL pour cette transaction, DOIVENT aller au même serveur.

L’identité du serveur contacté avec succès est une forme d’état de transaction. Cela représente un défi pour les mandataires sans état, qui doivent encore satisfaire à l’exigence d’envoi de toutes les demandes de la transaction au même serveur.

Le problème est similaire, mais différent, du problème des transactions HTTP au sein d’une session de marqueurs routés sur différents serveurs sur la base d’un processus DNS aléatoire. Là, une telle distribution n’est pas un problème. Des groupes de serveurs ont généralement des magasins de données d’extrémité arrière communs, où les données de session sont mémorisées. Chaque fois qu’un serveur du groupe reçoit une demande HTTP, il prend l’identifiant de session, s’il est présent, et extrait l’état nécessaire au traitement de la demande. Une demande sans identifiant de session en crée un nouveau. Le problème avec les mandataires sans état est à un niveau inférieur ; ils retransmettent des demandes au sein d’une transaction qui peuvent être éparpillées entre les serveurs. Comme aucune de ces retransmissions ne porte un "identifiant de session" (un identifiant de dialogue complet en termes SIP), un nouveau dialogue sera identiquement créé à chaque serveur. Il pourrait, par exemple, en résulter que plusieurs appels téléphoniques soient faits sur le même téléphone. Donc, il est essentiel d’empêcher une telle situation d'intervenir au premier chef.

L’exigence n’est pas difficile à satisfaire pour le cas simple où il n’y a pas d’échec lors de la tentative de contact d’un serveur. Chaque fois que le mandataire sans état reçoit la demande, il effectue les interrogations de DNS appropriées comme décrit ci-dessus. Cependant, les procédures de la RFC 2782 ne sont pas d’un déterminisme garanti. Cela, parce que dans ce cas les enregistrements qui contiennent la même priorité n’ont pas un ordre spécifique. Le mandataire sans état DOIT définir un ordre déterministe des enregistrements dans ce cas, en utilisant tout algorithme à sa disposition. Une suggestion est de les alphabétiser, ou, plus généralement, de les trier par codage compatible ASCII. Pour faciliter le traitement pour les mandataires sans état, il est RECOMMANDÉ que les administrateurs de domaine rendent différentes les pondérations de priorité égales d’enregistrements SRV (par exemple, en utilisant des poids de 1000 et 1001 si deux serveurs sont équivalents, plutôt que de leur allouer à tous deux un poids de 1000), et de faire de même pour les enregistrements NAPTR. Si le premier serveur est contacté avec succès, le mandataire peut rester sans état. Cependant, si le premier serveur n’est pas contacté avec succès, et si un serveur suivant l’est, le mandataire ne peut pas rester sans état pour cette transaction. Si il était sans état, une retransmission pourrait très bien aller sur un serveur différent si celui qui a échoué récupère entre les retransmissions. Ainsi, chaque fois qu’un mandataire échoue dans le contact avec le premier serveur, il DEVRAIT agir comme un mandataire à états pleins.

Malheureusement, il est toujours possible qu’un mandataire sans état délivre les retransmissions à différents serveurs, même si il suit la recommandation ci-dessus. Cela peut arriver si la durée de vie restante DNS arrive à expiration au milieu d’une transaction, et si les entrées ont changé. Cela est inévitable. Les développeurs de réseau devraient être conscients de cette limitation, et ne pas utiliser de mandataires sans état qui accèdent au DNS si cette erreur est jugée critique.

5 Usage par le serveur

La RFC 3261 [1] définit des procédures pour le renvoi des réponses d’un serveur au client. Normalement, pour des demandes UDP en envoi individuel, la réponse est renvoyée à l’adresse IP de source d’où est venue la demande, en utilisant le port contenu dans l’en-tête Via. Pour les protocoles de transport fiables, la réponse est envoyée sur la connexion sur laquelle la demande est arrivée. Cependant, il est important de fournir la prise en charge d’une récupération lorsque l’élément client est défaillant entre l’envoi de la demande et la réception de la réponse.

Un serveur, conformément à la RFC 3261 [1], va envoyer une réponse sur la connexion sur laquelle elle est arrivée (dans le cas de protocoles de transport fiables), et pour les protocoles de transport non fiables, à l’adresse de source de la demande, et au port du champ d’en-tête Via. Les procédures présentes sont invoquées lorsqu’un serveur tente un envoi à cette localisation et que cette réponse échoue (les conditions spécifiques sont précisées dans la RFC 3261). "échec" est défini comme toute clôture de la connexion de transport sur laquelle est venue la demande avant que la réponse puisse être envoyée, ou la communication d’une erreur fatale de la part de la couche transport.

Dans ces cas, le serveur examine la valeur de la construction sent-by dans l’en-tête Via le plus élevé. Si il contient une adresse IP numérique, le serveur tente d’envoyer la réponse à cette adresse, en utilisant le protocole de transport venant de l’en-tête Via, et le port venant de sent-by, s’il est présent, autrement, le protocole de transport par défaut. Le protocole de transport dans l’en-tête Via peut indiquer "TLS", ce qui se réfère à TLS sur TCP. Lorsque cette valeur est présente, le serveur DOIT utiliser TLS sur TCP pour envoyer la réponse.

Si, cependant, le champ sent-by contenait un nom de domaine et un numéro de port, le serveur interrogera les enregistrements A ou AAAA avec ce nom. Il essaye d’envoyer la réponse à chaque élément de la liste résultante d’adresses IP, en utilisant le port venant de Via, et le protocole de transport de Via (encore une fois, une valeur de TLS se réfère à TLS sur TCP). Comme dans le traitement client, l’entrée suivante sur la liste est essayée si celle d’avant échoue.

Si cependant, le champ sent-by contenait un nom de domaine et pas de port, le serveur interrogera les enregistrements SRV sur ce nom de domaine en utilisant l’identifiant de service "_sips" si le transport de Via est "TLS", "_sip" autrement, et le transport de l’en-tête Via le plus élevé ("TLS" implique que le protocole de transport dans l’interrogation SRV soit TCP). La liste résultante est triée comme décrit dans [2], et la réponse est envoyée à l’élément le plus élevé sur la nouvelle liste établie. S’il en résulte un échec, l’entrée suivante de la liste est essayée.

6 Construction des URI SIP

Dans de nombreux cas, un élément a besoin de construire un URI SIP pour l’inclure dans un en-tête Contact dans un REGISTER, ou dans un en-tête Record-Route dans une INVITE. Conformément à la RFC 3261 [1], ces URI doivent avoir la propriété de se résoudre en l’élément spécifique qui les a insérés. Cependant, si ils sont construits avec juste une adresse IP, par exemple : sip:1.2.3.4, il n’y a alors aucun moyen d’acheminer la demande ou la réponse à travers une sauvegarde en cas de défaillance de l’élément.

SRV donne un moyen de corriger cela. Au lieu d’utiliser une adresse IP, on peut utiliser un nom de domaine qui se résout en un enregistrement SRV : sip:server23.provider.com

Les enregistrements SRV pour une cible particulière peuvent être établis de telle sorte qu’il y ait un seul enregistrement avec une faible valeur pour le champ de priorité (indiquant le choix de la préférence), et cet enregistrement pointe sur l’élément spécifique qui a construit l’URI. Cependant, il y a des enregistrements supplémentaires avec des valeurs supérieures du champ de priorité qui pointent sur les éléments de sauvegarde qui seraient utilisés dans l’éventualité d’une défaillance. Cela satisfait à la contrainte de la RFC 3261 [1] tout en permettant un fonctionnement robuste.

7 Considérations pour la sécurité

Les enregistrements NAPTR de DNS sont utilisés pour permettre à un client de découvrir si le serveur prend en charge TLS. Un attaquant pourrait éventuellement modifier ces enregistrements, d’où il résulterait qu’un client utilisera un transport non sûr alors que TLS est en fait disponible et préféré.

Ceci est partiellement atténué par la présence du schéma d’URI sips, qui n’est jamais envoyé que sur TLS. Un attaquant ne peut pas forcer le choix d’une suppression ou modification d’enregistrements DNS. Dans le pire des cas, il peut empêcher la communication en supprimant tous les enregistrements. Un URI sips lui-même est généralement échangé dans un contexte sûr, souvent sur une carte professionnelle ou une page sécurisé de la Toile, ou au sein d’un message SIP qui a déjà été sécurisé avec TLS. Voir des précisions dans la RFC 3261 [1]. L’URI sips est donc préféré lorsque la sécurité est vraiment nécessaire, mais on permet l’utilisation de TLS pour les demandes résolues par un URI SIP afin d’avoir une sécurité meilleure que pas de TLS du tout.

L’attaque de forcement de choix peut aussi être atténuée par la mise en mémoire cache. Un client qui contacte fréquemment le même domaine DEVRAIT mettre ses enregistrements NAPTR en mémoire cache qu’ils contiennent ou non SIPS dans le champ de services. Si de tels enregistrements étaient présents, mais cessent d’apparaître lors des interrogations ultérieures, cela sera le signe d’une attaque éventuelle. Dans ce cas, le client DEVRAIT générer une sorte d’alerte ou alarme, et PEUT rejeter la demande.

Un problème supplémentaire est que les mandataires, qui sont des intermédiaires entre les utilisateurs d’un système, sont fréquemment les clients qui effectuent les interrogations NAPTR. Il est donc possible à un mandataire d’ignorer les entrées SIPS même si elles sont présentes, d’où il résulte une sécurité dégradée. Il y a peu de choses à faire pour empêcher de telles attaques. Les clients sont tout simplement dépendants des serveurs mandataires pour mener l’appel à bien, et doivent faire confiance à leur bonne mise en œuvre du protocole afin de garantir leur sécurité. La falsification des enregistrements DNS peut être effectuée par le tripotage du trafic sur le réseau (en l’absence de DNSSEC), alors que la compromission et la prise de contrôle d’un serveur mandataire exige une effraction, ce qui est perçu comme une menace de dégradation considérablement moins vraisemblable.

8 Application de détermination du transport

La présente section définit plus formellement l’utilisation NAPTR de la présente spécification, en utilisant le cadre du système de découverte de délégation dynamique (DDDS, Dynamic Delegation Discovery System) comme guide [7]. DDDS représente l’évolution de l’enregistrement de ressource NAPTR. DDDS définit les applications, qui peuvent faire usage de l’enregistrement NAPTR pour des services de résolution spécifiques. Cette application est appelée Application de détermination de transport, et son objet est de transposer un URI SIP ou SIPS entrant en un ensemble d’enregistrements SRV pour les divers serveurs qui peuvent traiter l’URI.

Voici les informations que DDDS demande à une application de fournir :

Chaîne unique d’application (AUS, Application Unique String) : c’est l’entrée du service de résolution. Pour cette application, c’est l’URI à résoudre.

Première règle bien connue : La première règle bien connue extrait une clé de l’AUS. Pour cette application, la première règle bien connue extrait la portion hôte de l’URI SIP ou SIPS.

Bases de données valides : La clé résultant de la première règle bien connue est cherchée dans une seule base de données, le DNS [8].

Sortie attendue : Le résultat de l’application est un enregistrement SRV à contacter par le serveur.

9 Considérations relatives à l’IANA

L’usage des enregistrements NAPTR décrit ici exige des valeurs bien connues pour les champs service pour chaque transport pris en charge par SIP. Le tableau des transpositions des valeurs de champ service en protocoles de transport doit être entretenu par l’IANA. De nouvelles entrées dans le tableau PEUVENT être ajoutées par la publication de RFC en cours de normalisation (standards track), comme décrit dans la RFC 2434 [5].

L’enregistrement dans la RFC DOIT inclure les informations suivantes :

Champ de service : Le champ de service enregistré. Un exemple de nouveau protocole de transport fictif appelé NCTP pourrait être "SIP+D2N".

Protocole : Le protocole de transport spécifique associé à ce champ de service. Il DOIT inclure le nom et l’acronyme du protocole, ainsi que la référence à un document décrivant le protocole de transport. Par exemple - "Nouveau protocole de transport sans connexion (NCTP), RFC 5766".

Informations et nom du contact : Le nom, l’adresse postale et de messagerie, et le numéro de téléphone de la personne qui effectue l’enregistrement.

Les valeurs suivantes ont été placées dans le registre :

10 Remerciements

Les auteurs tiennent à remercier Randy Bush, Leslie Daigle, Patrik Faltstrom, Jo Hornsby, Rohan Mahy, Allison Mankin, Michael Mealling, Thomas Narten et Jon Peterson de leurs commentaires utiles.

11 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’initiation de session", RFC 3261, juin 2002.

[2] A. Gulbrandsen, P. Vixie et L. Esibov, "RR DNS pour spécifier la localisation des services (DNS SRV)", RFC 2782, février 2000.

[3] M. Mealling et R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.

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

[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

12 Références informatives

[6] M. Handley, H. Schulzrinne, E. Schooler et J. Rosenberg, "SIP : Protocole d’initiation de session", RFC 2543, mars 1999.

[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard", Work in Progress.

[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database", Work in Progress.

13 Adresse des auteurs

14 Déclaration complète de droits de reproduction

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

e 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 copyright ci-dessus et le présent et 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 copyright 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 copyright 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 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.