4. Choisir un CNAME RTCP

Il est difficile, et dans certains cas impossible, pour un hôte de déterminer s'il y a un NAT entre lui-même et son pair RTP. De plus, même certaines adresses IPv4 publiques peuvent être partagées par plusieurs hôtes sur Internet. Utiliser la représentation numérique de l'adresse IPv4 comme partie "hôte" du CNAME RTCP n'est PAS RECOMMANDÉ.

4.1. CNAME RTCP persistants versus CNAME RTCP par session

Le CNAME RTCP peut être soit persistant à travers différentes sessions RTP pour un point d'extrémité RTP, soit unique par session, ce qui signifie qu'un point d'extrémité RTP choisit un CNAME RTCP différent pour chaque session RTP.

Un point d'extrémité RTP qui émet plusieurs flux RTP liés nécessitant une synchronisation à l'autre point d'extrémité (ou aux autres) DOIT utiliser le même CNAME RTCP pour tous les flux qui doivent être synchronisés. Cela nécessite un CNAME RTCP persistant à court terme qui soit commun à plusieurs flux RTP, et potentiellement à plusieurs sessions RTP liées. Un exemple courant d'une telle utilisation se produit lors de la synchronisation de flux audio et vidéo dans une session multimédia, où un seul participant doit utiliser le même CNAME RTCP pour sa session RTP audio et pour sa session RTP vidéo. Un autre exemple pourrait être la synchronisation des couches d'un codec audio en couches, où le même CNAME RTCP doit être utilisé pour chaque couche.

Si les multiples flux RTP d'une session RTP ne sont pas liés, et ne nécessitent donc pas de synchronisation, un point d'extrémité RTP peut utiliser des CNAME RTCP différents pour ces flux.

Un CNAME RTCP persistant à plus long terme est parfois utile pour faciliter la surveillance par des tiers, conformément à la [RFC3550]. Une telle utilisation pourrait par exemple permettre à des outils de gestion de réseau de corréler la qualité de service continue d'un participant à travers plusieurs sessions RTP pour le diagnostic de pannes et pour comprendre les statistiques de performance du réseau à long terme. Un développeur d'application qui souhaite décourager ce type de surveillance par des tiers peut choisir de générer un CNAME RTCP unique pour chaque session RTP, ou groupe de sessions RTP liées, que l'application rejoindra. Un tel CNAME RTCP par session ne peut pas être utilisé pour l'analyse de trafic, et fournit ainsi une certaine forme limitée de confidentialité. Notez qu'il existe des moyens non RTP qui peuvent être utilisés par un tiers pour corréler les sessions RTP, donc l'utilisation de CNAME RTCP par session n'empêchera pas un analyste de trafic déterminé de surveiller de telles sessions.

Ce mémo définit plusieurs façons différentes par lesquelles une mise en œuvre peut choisir un CNAME RTCP. Il est possible, et légitime, que des mises en œuvre indépendantes fassent des choix différents de CNAME RTCP lorsqu'elles s'exécutent sur le même hôte. Cela peut entraver la surveillance par des tiers, à moins qu'un moyen externe ne soit fourni pour configurer un choix persistant de CNAME RTCP pour ces mises en œuvre.

Notez qu'il n'y a pas de problème de compatibilité descendante (avec les mises en œuvre compatibles avec la [RFC3550]) introduit dans ce mémo, puisque les CNAME RTCP sont des chaînes de caractères opaques pour les pairs distants.

4.2. Exigences

Les points d'extrémité RTP choisiront de générer des CNAME RTCP persistants ou par session. Un point d'extrémité RTP qui souhaite générer un CNAME RTCP persistant DOIT utiliser l'une des deux méthodes suivantes :

• Pour produire un CNAME RTCP persistant à long terme, un point d'extrémité RTP DOIT générer et stocker un identifiant unique universel (UUID) [RFC4122] pour l'utiliser comme partie "hôte" de son CNAME RTCP. L'UUID DOIT être de version 1, 2 ou 4, comme décrit dans la [RFC4122], avec le "urn:uuid:" retiré, résultant en une représentation sous forme de chaîne de caractères imprimable de 36 octets.

• Pour produire un CNAME RTCP persistant à court terme, un point d'extrémité RTP DOIT générer et utiliser un identifiant en suivant la procédure décrite à la section 5. Cette procédure est effectuée au moins une fois par initialisation du logiciel. Après avoir obtenu un identifiant, les 96 bits les moins significatifs au minimum DEVRAIENT être convertis en ASCII en utilisant l'encodage Base64 [RFC4648] (pour faire un compromis entre la taille du paquet et l'unicité -- voir la section 6.1). Si 96 bits sont utilisés, la chaîne résultante sera de 16 octets. Notez que la valeur encodée en Base64 ne peut pas dépasser la longueur maximale du CNAME RTCP de 255 octets [RFC3550].

Dans les deux cas ci-dessus, la partie "user@" du CNAME RTCP PEUT être omise sur les systèmes mono-utilisateur et PEUT être remplacée par un jeton opaque sur les systèmes multi-utilisateurs, pour préserver la confidentialité.

Un point d'extrémité RTP qui souhaite générer un CNAME RTCP par session DOIT utiliser la méthode suivante :

• Pour chaque nouvelle session RTP, un nouveau CNAME RTCP est généré en suivant la procédure décrite à la section 5. Après avoir effectué cette procédure, les 96 bits les moins significatifs au minimum DEVRAIENT être convertis en ASCII en utilisant l'encodage Base64 [RFC4648]. Le CNAME RTCP ne peut pas changer au cours de la vie d'une session RTP [RFC3550]. La partie "user@" du CNAME RTCP est omise lors de la génération de CNAME RTCP par session.

On pense que l'obtention de l'unicité (avec une probabilité élevée) est une propriété importante qui nécessite une évaluation minutieuse de la méthode. Ce document fournit un certain nombre de méthodes, dont au moins une serait adaptée à tout scénario de déploiement donné. Ce document ne permet donc pas au responsable de la mise en œuvre de définir et de sélectionner une méthode alternative.

Une spécification future pourrait définir une méthode alternative pour générer des CNAME RTCP, tant que la méthode proposée présente une unicité appropriée et qu'il y a une cohérence entre les méthodes utilisées pour les multiples sessions RTP qui doivent être corrélées. Cependant, une telle spécification doit être revue et approuvée avant le déploiement.

Les mécanismes décrits dans ce document doivent être utilisés pour générer des CNAME RTCP, et ils ne doivent pas être utilisés pour générer des identifiants uniques à usage général.

5. Procédure pour générer un identifiant unique

Pour produire localement un identifiant unique, on génère simplement une valeur pseudo-aléatoire de manière cryptographique comme décrit dans la [RFC4086]. Cette valeur DOIT être d'au moins 96 bits.

Le plus gros goulot d'étranglement pour la mise en œuvre de cet algorithme est la disponibilité d'un générateur de nombres pseudo-aléatoires cryptographiquement sûr (CSPRNG) approprié. Dans tout environnement qui dispose déjà d'un PRNG sûr, cet algorithme décrit est beaucoup plus simple que l'algorithme décrit à la section 5 de la [RFC6222]. Les piles SIP [RFC3261] sont tenues d'utiliser des nombres aléatoires de manière cryptographique pour générer les balises To et From (section 19.3). Les mises en œuvre de communications en temps réel sur le Web (RTCWEB) [ARCH] devront disposer de PRNG sûrs pour mettre en œuvre ICE [RFC5245] et DTLS-SRTP [RFC5764]. Et, bien sûr, pratiquement chaque navigateur Web prend déjà en charge TLS, ce qui nécessite un PRNG sûr.