Groupe de travail Réseau	A. Morton, AT&T Labs	
Request for Comments: 5618	K. Hedayat, EXFO	
RFC mise à jour : 5357		
Catégorie : Sur la voie de la normalisation	août 2009	
Traduction Claude Brière de L'Isle		

Mode de sécurité mixte pour le protocole de mesures actives bidirectionnelles (TWAMP))

Résumé
Le présent mémoire décrit une simple extension au protocole de mesures actives bidirectionnelles (TWAMP, Two-Way Active Measurement Protocol). L'extension ajoute l'option d'utiliser des modes de sécurité différents simultanément dans les protocoles TWAMP-Control et TWAMP-Test. Le mémoire décrit aussi un nouveau registre de l'IANA pour des caractéristiques supplémentaires, appelé le registre des modes TWAMP.

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 droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
1.1 Langage des exigences	2
2. Objet et portée	2
3. Extensions à TWAMP-Control	2
3.1 Établissement de connexion de contrôle étendue	2
4. Essai TWAMP étendu	3
4.1 Comportement de l'envoyeur	3
4.2 Comportement du réflecteur	4
5. Considérations sur la sécurité	4
6. Considérations relatives à l'IANA	4
6.1 Spécification de registre	4
6.2 Gestion du registre	4
6.3 Numéros expérimentaux	4
6.4 Contenu initial du registre	4
7. Remerciements	5
8. Références normatives	5
Adresse des auteurs	5

 	1.	Introduction

Le protocole de mesure active bidirectionnelle (TWAMP, Two-Way Active Measurement Protocol) [RFC5357] est une extension du protocole de mesure active unidirectionnelle (OWAMP, One-Way Active Measurement Protocol) [RFC4656].  La spécification de TWAMP a subi une large révision lorsqu'elle approchait de son achèvement, et les sous produits ont été plusieurs recommandations pour de nouvelles caractéristiques dans TWAMP. Il y a un nombre croissant de mises en œuvre  de TWAMP à présent, et un large usage est attendu. Il y a même des appareils qui sont conçus pour vérifier la conformité des mises en œuvre au protocole.

Le présent mémoire décrit une simple extension à TWAMP : l'option d'utiliser différents modes de sécurité dans les protocoles TWAMP-Control et TWAMP-Test (mode de sécurité mixte). Il décrit aussi un nouveau registre de l'IANA pour des caractéristiques supplémentaires, appelé le registre des modes TWAMP.

Quand le serveur et le client de contrôle se sont mis d'accord pour utiliser le mode de sécurité mixte durant l'établissement de la connexion de contrôle, le client de contrôle, le serveur, l'envoyeur de session, et le réflecteur de session DOIVENT alors tous se conformer aux exigences de ce mode comme décrit dans les Sections 3, 4, et 5.

Le présent mémoire met à jour la [RFC5357].

 	1.1	Langage des exigences
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].

 	2.	Objet et portée

L'objet du présent mémoire est de décrire et spécifier une extension pour TWAMP [RFC5357], et de demander l'établissement d'un registre pour les futures extensions à TWAMP.

La portée de ce mémoire est limitée à la spécification de ce qui suit :
o	l'extension des modes de fonctionnement par l'allocation d'une nouvelle valeur dans le champ Modes (voir le paragraphe 3.1 de la [RFC4656]) tout en conservant la rétro compatibilité avec les mises en œuvre de TWAMP [RFC5357]. Cette valeur ajoute la capacité FACULTATIVE d'utiliser des modes de sécurité différents dans les protocoles TWAMP-Control et TWAMP-Test. Le motif de cette extension est de permettre au protocole de contrôle TWAMP à faible débit de paquet d'utiliser un mode plus fort de protection de l'intégrité que celui utilisé dans le protocole d'essai TWAMP.

 	3.	Extensions à TWAMP-Control

Le protocole TWAMP-Control est dérivé du protocole OWAMP-Control, et coordonne une capacité de mesure bidirectionnelle. Tous les messages de TWAMP-Control sont de format similaire et suivent des lignes directrices similaires à celles définies à la Section 3 de la [RFC4656], avec les exceptions décrites dans TWAMP [RFC5357] et dans les paragraphes qui suivent.

Tous les messages de OWAMP-Control s'appliquent à TWAMP-Control, sauf pour la commande Fetch-Session.

 	3.1	Établissement de connexion de contrôle étendue
L'établissement de connexion TWAMP-Control suit la même procédure que définie au paragraphe 3.1 de la [RFC4656]. Le mode étendu alloue une nouvelle position (et valeur) de bit pour permettre au mode de sécurité du protocole d'essais de fonctionner dans le mode non authentifié, tandis que le protocole de contrôle opère en mode chiffré. Avec cette extension, l'ensemble complet de valeurs de mode TWAMP est comme suit :

Valeur	Description	Référence/explication
0	réservé
1	non authentifié	RFC 4656, paragraphe 3.1
2	authentifié	RFC 4656, paragraphe 3.1
4	chiffré	RFC 4656, paragraphe 3.1
8	non authentifié	protocole d'essai, nouvelle position de bit (3) CONTROLE chiffré

Dans le champ original Modes OWAMP et TWAMP, le réglage de position de bit 0, 1, ou 2 indiquait le mode de sécurité du protocole de contrôle, et le protocole d'essai héritait du même mode (voir la Section 4 de la [RFC4656]).

Dans cette extension à TWAMP, quand le client de contrôle règle la position de bit du champ Modes à 3, il DEVRA arrêter l'héritage du mode de sécurité dans le protocole d'essai, et le mode de chaque protocole DEVRA être comme spécifié ci-dessous. Quand le mode de protocole d'essai TWAMP désiré est identique au mode de session de contrôle, le bit du champ Modes correspondant (position 0, 1, ou 2) DEVRA être établi par le client de contrôle. Le tableau ci-dessous donne les diverses combinaisons de protection de l'intégrité qui sont permises dans TWAMP (avec cette extension). Les protocoles TWAMP-Control et TWAMP-Test DEVRONT utiliser le mode dans chaque colonne correspondant à la position de bit établi dans le champ Modes.

Protocole	Combinaisons de mode permises (bit Modes établi)
Contrôle	Non authentifié(0)	Authentifié == Chiffré (1, 2, 3)
	Non authentifié(0)	Non authentifié (3)
Essai		Authentifié (1)
		Chiffré (2)

Noter que les mesures de sécurité du protocole de contrôle TWAMP sont identiques dans les modes authentifié et chiffré. Donc, seulement une nouvelle position de bit (3) est nécessaire pour porter le seul mode de sécurité mixte.

La valeur du champ Modes envoyée par le serveur dans le message Accueil de serveur est le OU au bit près des modes (positions de bit) qu'il veut accepter durant cette session. Donc, les quatre derniers bits du champ Modes de 32 bits sont utilisés. Quand aucune autre caractéristique n'est activée, les 28 premiers bits DOIVENT être à zéro. Un client conforme à la présente extension à la [RFC5357] PEUT ignorer les valeurs des 28 premiers bits du champ Modes, ou il PEUT prendre en charge d'autres caractéristiques qui sont communiquées dans ces positions de bits.

D'autres façons dont TWAMP étend OWAMP sont décrites dans la [RFC5357].

 	4.	Essai TWAMP étendu

Le protocole d'essai TWAMP est similaire au protocole d'essai OWAMP [RFC4656] avec l'exception que le réflecteur de session transmet des paquets d'essai à l'envoyeur de session en réponse à chaque paquet d'essai qu'il reçoit. TWAMP [RFC5357] définit deux formats différents de paquet d'essai : un pour les paquets transmis par l'envoyeur de session et un pour les paquets transmis par le réflecteur de session. Comme avec le protocole d'essai OWAMP, il y a trois modes de sécurité qui déterminent aussi le format de paquet d'essai : non authentifié, authentifié, et chiffré. La présente extension à TWAMP rend possible d'utiliser le mode d'essai TWAMP non authentifié sans considération du mode utilisé dans le protocole de contrôle TWAMP.

Quand le serveur a identifié la capacité de prendre en charge le mode de sécurité mixte, que le client de contrôle a choisi le mode de sécurité mixte dans sa réponse d'établissement, et que le serveur a répondu avec un champ Accept de zéro dans le message Server-Start, ces extensions sont EXIGÉES.

 	4.1	Comportement de l'envoyeur
Ce paragraphe décrit des extensions au comportement de l'envoyeur de session TWAMP.

 	4.1.1	Rythme des paquets
La programmation d'envoi n'est pas utilisée dans TWAMP, et il n'y a pas d'extension définie dans ce mémoire.

 	4.1.2	Format et contenu des paquets
Le format et le contenu de paquet d'envoyeur de session DOIVENT suivre la même procédure et les mêmes lignes directrices que défini au paragraphe 4.1.2 de la [RFC4656] et au paragraphe 4.1.2 de la [RFC5357], avec les exceptions suivantes :
o	La programmation d'envoi n'est pas utilisée, et
o	l'envoyeur de session DOIT prendre en charge le mode de sécurité mixte (essai non authentifié, contrôle chiffré, valeur 8, position de bit 3) défini au paragraphe 3.1 du présent mémoire.

 	4.2	Comportement du réflecteur
Il est EXIGÉ du réflecteur de session TWAMP qu'il suive les procédures et lignes directrices du paragraphe 4.2 de la [RFC5357], avec l'extension suivante :
o	le réflecteur de session DOIT prendre en charge le mode de sécurité mixte (essai non authentifié, contrôle chiffré, valeur 8, position de bit 3) défini au paragraphe 3.1 du présent mémoire.

 	5.	Considérations sur la sécurité

Le mode de fonctionnement mixte étendu permet une plus forte protection de la sécurité/intégrité sur le protocole de contrôle TWAMP tout en renforçant simultanément la précision ou efficacité du protocole d'essai TWAMP, rend ainsi possible d'augmenter la sécurité globale comparée aux options précédentes (quand des contraintes de ressources auraient forcé à moins de sécurité pour le contrôle TWAMP et que les conditions sont telles que l'utilisation d'essai TWAMP non authentifié n'est pas un problème significatif).

Les considérations de sécurité qui s'appliquent à toute mesure active de réseaux vivants sont aussi pertinentes ici. Voir les [RFC4656] et [RFC5357].

 	6.	Considérations relatives à l'IANA

Le présent mémoire ajoute une position/valeur de bit de mode de sécurité au delà de celles de la spécification de contrôle OWAMP [RFC4656], et décrit le comportement quand le nouveau mode est utilisé. Conformément à ce document, l'IANA a créé un registre pour le champ Modes TWAMP. Ce champ est un mécanisme d'extension reconnu pour TWAMP.

 	6.1	Spécification de registre
L'IANA a créé un registre des modes TWAMP. Les modes TWAMP sont spécifiés dans les messages d'accueil de serveur TWAMP et dans les messages de réponse d'établissement cohérents avec le paragraphe 3.1 de la [RFC4656] et le paragraphe 3.1 de la [RFC5357], et étendus par le présent mémoire. Les modes sont actuellement indiqués en établissant des bits seuls dans le champ Modes de 32 bits. Cependant, un codage plus complexe pourrait être utilisé à l'avenir. Donc, ce registre peut contenir un total de 2^32 allocations possibles.

 	6.2	Gestion du registre
Parce que le registre Modes TWAMP peut contenir un maximum de 2^32 valeurs, et parce que TWAMP est un protocole de l'IETF, ce registre ne doit être mis à jour que par "revue de l'IETF" comme spécifié dans la [RFC5226] (une RFC documentant l'utilisation du registre qui est approuvée par l'IESG). Pour le registre des modes TWAMP, il est prévu que de nouvelles caractéristiques seront allouées en utilisant des positions d'un seul bit de croissance monotone et dans la gamme [0-31], sauf si il y a de bonnes raisons de faire autrement (un codage plus complexe qu'une seule position de bit peut être utilisé à l'avenir, pour accéder à l'espace de 2^32 valeurs).

 	6.3	Numéros expérimentaux
Aucune valeur expérimentale n'est actuellement allouée pour le registre des modes.

 	6.4	Contenu initial du registre
Registre des Modes TWAMP

Valeur	Description	Référence
0	réservé	RFC 5618
1	non authentifié	RFC 4656, paragraphe 3.1
2	authentifié	RFC 4656, paragraphe 3.1
4	chiffré	RFC 4656, paragraphe 3.1
8	non authentifié, protocole d'essai,	RFC 5618, paragraphe 3.1
	chiffré, contrôle

 	7.	Remerciements

Les auteurs tiennent à remercier Len Ciavattone et Joel Jaeggli de leur utile relecture et commentaires.

 	8.	Références normatives

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

[RFC4656]	S. Shalunov et autres, "Protocole de mesures actives unidirectionnelles (OWAMP)", septembre 2006. (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5357]	K. Hedayat et autres, "Protocole de mesures bilatérales (TWAMP)", octobre 2008. (MàJ par RFC5618, 7750) (P.S.)

 	Adresse des auteurs

Al Morton	Kaynam Hedayat	
AT&T Labs	EXFO	
200 Laurel Avenue South	285 Mill Road	
Middletown, NJ  07748	Chelmsford, MA  01824	
USA	USA	
mél : acmorton@att.com	mél : kaynam.hedayat@exfo.com