Groupe de travail Réseau	R. Stastny, Oefeg	
Request for Comments : 4759	R. Shockey, Neustar Inc.	
Catégorie : Sur la voie de la normalisation	L. Conroy, Roke Manor Research	
Traduction Claude Brière de L'Isle	01/11/06	

Paramètre d'indicateur ENUM Dip pour l'URI "tel"

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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 "Protocoles officiels de l’Internet" (STD 1) pour voir 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 (2006). Tous droits réservés.

Résumé
Le présent document définit un nouveau paramètre "enumdi" pour que l'identifiant de ressource universel (URI, Uniform Resource Identifier) "tel" prenne en charge le traitement des interrogations ENUM dans les éléments de réseau de voix sur le protocole Internet (VoIP, Voice over Internet Protocol). Un élément de réseau VoIP peut recevoir un URI contenant un numéro E.164, où cet URI contient un paramètre "enumdi". La présence du paramètre "enumdi" indique qu'une interrogation ENUM a déjà été effectuée sur le numéro E.164 par un précédent élément de réseau VoIP. Également, si un élément de réseau VoIP envoie un tel URI, cela affirme qu'une interrogation ENUM a été effectuée sur ce numéro.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Syntaxe formelle	2
4. Règles normatives	2
4.1 Options pour les fournisseurs de domaine ENUM	2
4.2 Comportement du client pour les éléments de reseau VoIP	2
5. Exemples	3
6. Considérations sur la sécurité	3
7. Considérations relatives à l'IANA	3
8. Remerciements	4
9. Références	4
9.1 Références normatives	4
9.2 Références pour information	4
Adresse des auteurs	4
Déclaration complète de droits de reproduction	4

 	1.	Introduction

Les éléments de réseau VoIP (incluant les serveurs d'agent d'utilisateur et les clients d'agent d'utilisateur) peuvent être établis de différentes façons pour traiter les numéros [E.164] durant l'établissement d'appel, selon les capacités fournies. Une approche courante est d'interroger ENUM comme défini dans la [RFC3761], et d'utiliser l'ensemble des enregistrements de ressource NAPTR qui est retourné.

Si l'interrogation ENUM conduit à un résultat, l'appel est établi en conséquence. Si l'interrogation ENUM ne donne finalement pas de résultat, une autre base de données peut être interrogée et/ou l'appel peut finalement être acheminé au réséau téléphonique public commuté (RTPC). En faisant ainsi, l'appel peut être acheminé à un autre élément de réseau VoIP. Pour indiquer dans la signalisation à ce prochain élément VoIP qu'une interrogation ENUM a déjà été faite pour l'URI "tel" (spécifié dans la [RFC3966]) le paramètre "enumdi" est utilisé, pour empêcher le prochain élément de réseau VoIP de répéter des interrogations redondantes.

 	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 le BCP 14, [RFC2119].

 	3.	Syntaxe formelle

La spécification de syntaxe suivante utilise la forme Backus-Naur augmenté (ABNF) décrite dans la [RFC4234] pour étendre la syntaxe de la production "par" définie dans l'ABNF de la [RFC3966].

par =/ enum-dip-indicator

enum-dip-indicator = ";enumdi"

enum-dip-indicator est un paramètre facultatif pour l'URI "tel". Noter aussi que enum-dip-indicator peut apparaître au plus une fois dans un URI "tel".

 	4.	Règles normatives
 	4.1	Options pour les fournisseurs de domaine ENUM
Un fourniseur de domaine peut, à son choix, remplir un enregistrement NAPTR avec un URI "tel" qui contient l'indicateur enum dip. Cela informerait, par suite des règles déclarées ci-dessous, le client qu'il ne devrait pas se soucier d'effectuer une interrogation et passer la demande.

 	4.2	Comportement du client pour les éléments de reseau VoIP
Cette section discute comment un élément de réseau VoIP traite un URI "tel" reçu qui contient le paramètre "enumdi" ou a interrogé ENUM dans e164.arpa. sur un certain numéro E.164.

 	4.2.1	Traitement d'un URI avec le paramètre "enumdi"
Si un élément de réseau VoIP reçoit un URI "tel" contenant le paramètre "enumdi", l'élément de réseau VoIP NE DEVRAIT PAS restituer les informations qui s'y rapportent pour ce numéro de ENUM dans e164.arpa. même si il le ferait normalement.

Noter que le receveur d'un élément de réseau peut raisonnablement choisir d'interroger ENUM si il n'a pas une relation de confiance avec l'envoyeur immédiat de l'URI.

Si l'URI "tel" (reçu d'une entité de confiance) est à passer au prochain élément de réseau, l'élément de réseau VoIP DOIT passer inchangé l'URI reçu contenant le paramètre "enumdi".

Si, cependant, l'URI a été reçu d'une entité qui n'est pas de confiance, l'entité receveuse peut alors soit le supprimer avant de l'envoyer plus loin, soit plutôt effectuer sa propre interrogation ENUM et ajouter le paramètre en conséquence à l'URI (voir le paragraphe qui suit).

 	4.2.2	Ajout du paramètre "enumdi" aux URI
Quand un élément de réseau VoIP interroge ENUM dans e164.arpa. sur un certain numéro E.164 et que le résultat de l'interrogation est le code d'erreur DNS 3 (généralement appelé "NXDOMAIN") alors si cet élément de réseau choisit de passer l'appel à un autre élément de réseau en utilisant un URI "tel", le paramètre "enumdi" DOIT être établi.

 	4.2.3	Traitement d'un URI Restitué de ENUM
Quand un élément de réseau VoIP interroge ENUM dans e164.arpa. sur un certain numéro E.164 et que soit :
o	le résultat de l'interrogation inclut un enregistrement de ressource NAPTR contenant un URI "tel" qui a le même numéro E.164, soit
o	le résultat de l'interrogation inclut un enregistrement de ressource NAPTR contenant un URI "tel" qui a le paramètre "enumdi" établi,
alors si cet URI "tel" restitué est choisi pour être passé à un autre élément de réseau, l'élément de réseau VoIP envoyeur DOIT passer l'URI restitué avec le paramètre "enumdi" établi.

Quand un élément de réseau VoIP interroge ENUM dans e164.arpa. sur un certain numéro E.164 et que le résultat est un URI "tel" avec un numéro E.164 différent qui n'a pas l'indicateur enum dip, le client peut soit effectuer une autre interrogation sur ce numéro soit passer la demande, selon la politique locale.

 	5.	Exemples

a.	Un élément de réseau VoIP appelé serveur.exemple.com reçoit un URI "tel" tel:+441632960038. L'élément de réseau VoIP interroge le DNS pour des enregistrements de ressource NAPTR dans 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., et obtient une réponse d'erreur avec le code = 3 (couramment appelé "NXDOMAIN"). L'élément de réseau VoIP décide d'acheminer l'appel au RTPC via un autre élément de réseau VoIP appelé gw.exemple.com.

Il le signale donc au prochain élément de réseau VoIP avec : tel:+441632960038;enumdi
ou (en utilisant les procédures du paragraphe 19.1.6 de la [RFC3261]) :
sip:+441632960038;enumdi@gw.exemple.com;user=phone

b.	Un élément de réseau VoIP appelé serveur.exemple.com reçoit un URI "tel" tel:+441632960038. L'élément de réseau VoIP interroge le DNS pour des enregistrements de ressource NAPTR dans 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., et reçoit le même URI "tel" en réponse (c'est-à-dire, tel:+441632960038).

L'élément de réseau VoIP décide d'acheminer l'appel au RTPC via un autre élément de réseau VoIP appelé gw.exemple.com. Il le signale au prochain élément de réseau VoIP avec : tel:+441632960038;enumdi
ou (en utilisant les procédures du paragraphe 19.1.6 de la [RFC3261]) :
sip:+441632960038;enumdi@gw.exemple.com;user=phone

 	6.	Considérations sur la sécurité

En plus des implications pour la sécurité discutées dans la spécification de l'URI "tel" [RFC3966], il y a de nouvelles implications de sécurité associées au paramètre défini.

Si le "enumdi" est illégalement inséré dans l'URI "tel" quand le message de signalisation portant l'URI "tel" est en route pour l'entité de destination, l'appel peut être acheminé au RTPC, subissant des charges inattendues ou causant le rejet par un élément de réseau VoIP de l'établissement d'appel. De nombreux éléments de réseau qui vont traiter les URI contenant ce paramètre vont conserver des relations de confiance les uns avec les autres. Si un tel URI est reçu d'une entité en dehors des frontières de confiance du receveur, alors cette entité receveuse peut raisonnablement l'ignorer et faire une interrogation ENUM elle-même. Ce faisant, elle peut éviter cette attaque potentielle.

Cela pose moins de problèmes si le "enumdi" est illégalement supprimé. Une interrogation ENUM supplémentaire peut être effectuée pour restituer les informations de numéro d'acheminement et avoir le "enumdi" inclus à nouveau.

Il est RECOMMANDÉ que les protocoles qui portent l'URI "tel" s'assurent de l'intégrité du message durant le transfert du message entre les deux éléments de réseau communicants afin de détecter tout changement non autorisé du contenu de l'URI "tel" et autres informations.

 	7.	Considérations relatives à l'IANA

Le présent document n'exige par lui-même aucune action de l'IANA.
Il définit un paramètre pour l'URI "tel". Plus d'informations sur un registre pour de tels paramètres sont données dans la [RFC5341] "Registre des paramètres d'identifiant de ressource uniforme (URI) de l'IANA".

 	8.	Remerciements

Un grand merci à Alex Mayrhofer pour sa relecture attentive.

 	9.	Références
 	9.1	Références normatives

[E.164]	Recommandation UIT-T E.164, "Plan de numérotation des télécommunication internationales publiques", UIT-T, Genève, février 2005.

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

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3761]	P. Faltstrom, M. Mealling, "Application de E.164 au système de découverte dynamique de délégation (DDDS) d'identifiants de ressource uniformes (URI) (ENUM)", avril 2004. (P.S.) (Obsolète, voir la RFC6116)

[RFC3966]	H. Schulzrinne, "L'URI tel pour les numéros de téléphone", décembre 2004. (MàJ par RFC5341) (P.S.)

[RFC4234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", octobre 2005. (Remplace RFC2234, remplacée par RFC5234)

 	9.2	Références pour information

[RFC5341]	C. Jennings, V. Gurbani, "Registre des paramètres d'identifiant de ressource uniforme (URI) de l'IANA", septembre  2008. (MàJ RFC3966) (P.S.)

 	Adresse des auteurs

Richard Stastny	Richard Shockey	Lawrence Conroy	
Oefeg	Neustar Inc.	Roke Manor Research	
Postbox 147	46000 Center Oak Plaza	Romsey	
1103 Vienna	Sterling, VA  20166	United Kingdom	
Austria	USA	téléphone : +44-1794-833666	
téléphone : +43-664-420-4100	téléphone : +1-571-434-5651	mél : lconroy@insensate.co.uk 	
mél : Richard.stastny@oefeg.at 	mél : richard.shockey@neustar.biz 		

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2006)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, 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, le IETF TRUST 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 encloses ne viole 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 le 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.