RTP : protocole de transport - RFC

RFC 3550 page - 38 - Schulzrinne & autresIl est RECOMMANDÉ que des algorithmes de chiffrement plus forts tels que Triple-DES soient utilisés à la place del'algorithme par défaut. De plus, le mode CBC sécurisé exige que le premier bloc de chaque paquet soit traité parl'opérateur OUX avec un vecteur d'initialisation aléatoire indépendant de la même taille que celle du bloc de chiffrement.Pour RTCP, ceci est (partiellement) réalisé par l'ajout en tête de chaque paquet d'un nombre aléatoire de 32 bits, choisiindépendamment pour chaque paquet. Pour RTP, l'horodatage et le type de charge utile commencent à partir de valeursaléatoires, mais les paquets suivants ne seront pas rendus aléatoires de façon indépendante. Il devrait être noté que l'aléadans les deux cas (RTP et RTCP) est limité. Des applications de haute sécurité DEVRAIENT considérer d'autres moyensde protection, plus conventionnels. D'autres algorithmes de chiffrement PEUVENT être spécifiés de façon dynamique pourune session par des moyens non RTP. En particulier, le profil SRTP [28] fondé sur AES est en cours de développementpour prendre en compte les soucis connus de manipulations de libellé et de libellé CBC, et sera le choix correct à l'avenir.Comme solution de remplacement au chiffrement au niveau IP ou au niveau RTP comme décrit ci-dessus, les profilsPEUVENT définir des types de charge utile supplémentaires pour les codages chiffrés. Ces codages DOIVENT spécifiercomment le bourrage et les autres aspects du chiffrement sont à traiter. Cette méthode permet de ne chiffrer que les donnéestout en laissant les en-têtes en clair pour les applications où cela est souhaité. Il peut être particulièrement utile pour lesappareils matériels qui vont traiter à la fois le déchiffrement et le décodage. Il est aussi précieux pour les applications où lacompression de niveau liaison des en-têtes RTP et de couche inférieure est désirée et où la confidentialité de la charge utile(mais pas des adresses) est suffisante car le chiffrement des en-têtes empêche la compression.9.2 Authentification et intégrité du messageLes services d'authentification et d'intégrité du message ne sont pas définis au niveau de RTP car ces services ne seraientpas directement réalisables sans une infrastructure de gestion de clés. Il est prévu que des services d'authentification etd'intégrité seront fournis par les protocoles de couche inférieure.10. Contrôle de l'encombrementTous les protocoles de transport utilisés sur l'Internet ont besoin de s'occuper d'une façon ou d'une autre du contrôle del'encombrement [31]. RTP n'y fait pas exception, mais comme les données transportées sur RTP sont souvent inélastiques(générées à un débit fixe ou contrôlé), les moyens de contrôler l'encombrement dans RTP peuvent être assez différents deceux d'autres protocoles de transport tels que TCP. Dans un sens, l'inélasticité réduit le risque d'encombrement parce que leflux RTP ne va pas s'étendre pour consommer toute la bande passante disponible comme le peut un flux TCP. Cependant,l'inélasticité signifie aussi que le flux RTP ne peut pas réduire arbitrairement sa charge sur le réseau pour éliminerl'encombrement lorsque il survient.Comme RTP peut être utilisé pour une grande variété d'applications dans de nombreux contextes différents, il n'y a pas ununique mécanisme de contrôle de l'encombrement qui puisse tout faire. Donc, le contrôle de l'encombrement DEVRAITêtre défini dans chaque profil RTP comme approprié. Pour certains profils, il peut être suffisant d'inclure une déclarationd'applicabilité restreignant l'utilisation de ce profil aux environnements dans lesquels l'encombrement est évité parl'ingénierie. Pour les autres profils, des méthodes spécifiques, telles que l'adaptation du débit des données fondée sur lesretours RTCP peuvent être requises.11. RTP sur les protocoles de réseau et de transportLa présente section décrit les questions spécifique du transport des paquets RTP au sein de protocoles de réseau et detransport particuliers. Les règles suivantes s'appliquent sauf si elles sont supplantées par des définitions spécifiques deprotocole en dehors de la présente spécification.RTP s'appuie sur le ou les protocoles sous-jacents pour fournir le démultiplexage des données RTP et des flux de contrôleRTCP. Pour UDP et les protocoles similaires, RTP DEVRAIT utiliser un numéro pair d'accès de destination et le fluxRTCP correspondant DEVRAIT utiliser le numéro d'accès de destination immédiatement supérieur (impair). Pour lesapplications qui prennent un seul numéro d'accès comme paramètre et déduisent la paire d'accès RTP et RTCP de cenuméro, si un numéro impair est fourni, alors l'application DEVRAIT remplacer ce numéro par le prochain nombreinférieur (pair) à utiliser comme base de la paire d'accès. Pour les applications dans lesquelles les numéros d'accès dedestination RTP et RTCP sont spécifiés via des paramètres séparés explicites (utilisant un protocole de signalisation oud'autres moyens) l'application PEUT négliger les restrictions sur les numéros d'accès pair/impair consécutifs bien quel'utilisation d'une paire pair/impair soit toujours conseillée. Les numéros d'accès RTP et RTCP NE DOIVENT PAS être lesmêmes car RTP s'appuie sur les numéros d'accès pour démultiplexer les données RTP et les flux de contrôle RTCP.