Résumé

  • RFC 3336 utilisait le multiplexage AAL2 pour transporter plus efficacement de petits contenus PPP, dont des flux vocaux après compression des en-têtes RTP.
  • Le périmètre de confiance restait plus étroit que la connexion ATM partagée : l’authentification PPP ne protégeait ni les CID voisins non-PPP ni le réseau de commutation ATM.

Le multiplexage a élargi le support, pas la confiance

Le problème était une question d’échelle. PPP sur AAL5 convenait bien au transport IP, mais RFC 3336 jugeait son remplissage et son encapsulation coûteux lorsque les contenus étaient courts, en particulier pour la voix après compression des en-têtes RTP. AAL2 proposait une autre organisation : son sous-système commun (CPS) pouvait multiplexer plusieurs contenus PPP dans les cellules ATM au lieu de faire porter à chaque petit paquet les mêmes coûts de trame.

Ce gain ne transformait pas la connexion virtuelle ATM en un unique lien PPP. RFC 3336 modélisait le service PPP/AAL2 comme une connexion virtuelle bidirectionnelle et point à point, provisionnée à l’avance ou commutée à la demande. À l’intérieur, l’identifiant de canal AAL2 (CID) désignait un sous-flux. Une session PPP pouvait utiliser un CID ou plusieurs; ses extrémités devaient s’accorder sur leur nombre, leur correspondance avec les sous-couches spécifiques au service et leurs valeurs. Le provisionnement pouvait fournir ces paramètres pour une connexion dédiée; la signalisation, pour une connexion commutée.

Or une même connexion virtuelle pouvait également transporter du trafic AAL2 conventionnel et différentes fonctions de convergence spécifiques au service. Un CID séparait des sous-flux, mais ne constituait pas une identité cryptographique. Le texte posait donc une limite nette : l’authentification d’une session PPP et ses mécanismes associés ne permettaient pas de conclure que les CID non-PPP présents sur la même connexion étaient protégés. L’authentification PPP ne sécurisait pas davantage le réseau de commutation ATM.

Si cette infrastructure de transport était compromise, avertissait RFC 3336, une attaque de l’homme du milieu restait possible.

D’autres signaux existaient, sans effacer ces frontières. Les paquets de gestion de défaut de type 3 pouvaient servir à déduire l’état actif ou inactif du lien dans le flux CID concerné. L’encapsulation ajoutait aussi un CRC de 16 bits pour détecter les erreurs. Ni cet état de lien ni ce CRC ne prouvaient qui contrôlait un CID voisin ou ne protégeaient son contenu contre un adversaire. Lorsque la protection devait dépasser la session PPP, le document renvoyait à l’authentification ou au chiffrement de couche supérieure et/ou aux services de sécurité ATM.

RFC 3337, publié à la même période, montre l’intérêt d’une telle séparation pour les applications temps réel : une session PPP pouvait s’étendre sur plusieurs CID afin d’entrelacer des fragments de classes différentes. Mais le document compagnon laissait le choix de l’ordonnanceur CPS aux besoins de l’application. Un identifiant de classe ne garantissait donc pas, à lui seul, un délai donné. Le format rendait un traitement différencié possible; il ne prouvait pas qu’un ordonnanceur ou un réseau particulier le fournissait.

La conclusion doit rester limitée aux textes. L’éditeur des RFC classe RFC 3336 comme Proposed Standard; le document spécifie un mécanisme. Aucun de ces éléments ne prouve quels fournisseurs l’ont implémenté, son ampleur de déploiement ou l’existence d’un incident de sécurité lié à ce choix. La Note 65 de Lu Heng offre une discipline éditoriale utile : lire une norme comme une proposition pour des systèmes en fonctionnement, et non comme la preuve qu’ils l’ont adoptée.

La leçon est architecturale. Partager une connexion de transport peut réduire le coût par paquet tout en conservant plusieurs domaines de contrôle et de confiance à l’intérieur. Quand un examen constate « PPP authentifié », il faut demander ce qui l’a été exactement : les pairs PPP et le trafic de cette session, ou chaque CID, fonction de service et commutateur de la connexion virtuelle? RFC 3336 répondait que le premier n’impliquait pas le second.

Sources

Fiche de statut RFC Editor

Sources : RFC 3336 · RFC 3337 · PPP sur AAL5, RFC 2364 · Multiplexage PPP, RFC 3153 · PPP, RFC 1661 · Compression des en-têtes RTP, RFC 2508 · Liaisons à faible débit, RFC 2689 · UIT-T I.363.2 · UIT-T I.366.1 · Lu Heng, Note 65