Resumen

  • RFC 3336 aprovechó la multiplexación AAL2 para transportar con eficiencia cargas PPP pequeñas, como voz tras comprimir los encabezados RTP.
  • El límite de confianza seguía siendo más estrecho que la conexión ATM compartida: la autenticación de una sesión PPP no protegía los CID vecinos no PPP ni la red de conmutación ATM.

El CID separaba flujos, no identidades

El problema era una diferencia de escala. PPP sobre AAL5 servía bien para transportar IP, pero RFC 3336 señalaba que el relleno y el encapsulado podían desperdiciar ancho de banda cuando la carga era pequeña, sobre todo en voz cuyos encabezados RTP ya se habían comprimido. AAL2 ofrecía otra organización: su subcapa común (CPS) podía multiplexar varias cargas PPP dentro de las celdas ATM, en vez de imponer a cada paquete corto el coste de una trama completa.

Ese ahorro no convertía la conexión virtual ATM en un único enlace PPP. RFC 3336 describía el servicio PPP/AAL2 como una conexión virtual bidireccional y punto a punto, dedicada mediante provisión o conmutada bajo demanda. Dentro de ella, el identificador de canal AAL2 (CID) señalaba un subflujo. Una sesión PPP podía usar uno o varios CID; ambos extremos debían acordar cuántos, qué correspondencia tenían con las subcapas específicas del servicio y qué valores emplear. La provisión podía proporcionar esos parámetros para una conexión dedicada; la señalización, para una conexión conmutada.

La misma conexión virtual podía transportar también tráfico AAL2 convencional y distintas funciones de convergencia específicas del servicio. Por eso, un CID separaba subflujos, pero no era una identidad criptográfica. RFC 3336 trazó un límite explícito: la autenticación de la sesión PPP y sus mecanismos asociados no permitían suponer que los CID no PPP de la misma conexión también estaban protegidos. Tampoco protegían la propia red de conmutación ATM. Si esa infraestructura de transporte se comprometía, advertía el documento, aún podía producirse un ataque de intermediario.

Había otros comprobantes, pero ninguno borraba esas fronteras. El estado activo o inactivo del enlace podía derivarse de paquetes de gestión de fallos de tipo 3 dentro del flujo CID correspondiente. El encapsulado añadía además un CRC de 16 bits para detectar errores. Ni una indicación de estado ni un CRC demostraban quién controlaba un CID vecino o protegían su contenido frente a un adversario. Para ir más allá de la protección de la sesión PPP, RFC 3336 apuntaba a la autenticación o el cifrado de capas superiores y/o a servicios de seguridad ATM.

RFC 3337, publicado en la misma época, ayuda a entender por qué la separación de canales interesó a quienes diseñaban para tiempo real: una sesión PPP podía abarcar varios CID para intercalar fragmentos de distintas clases. Pero el documento complementario dejaba el método de planificación CPS sujeto a las necesidades de cada aplicación. Un identificador de clase no garantizaba por sí solo una latencia determinada. El formato habilitaba un trato diferenciado; no demostraba que una red o planificador concreto lo entregara.

La conclusión debe limitarse al registro documental. El RFC Editor cataloga RFC 3336 como Proposed Standard, y el texto especifica un mecanismo. Ninguno de esos hechos demuestra qué proveedores lo implementaron, cuán extendido estuvo ni si algún operador sufrió un fallo de seguridad relacionado. La Nota 65 de Lu Heng aporta una disciplina editorial útil: leer una norma como propuesta para sistemas en funcionamiento, no como prueba de que estos la adoptaron.

La lección es arquitectónica. Compartir una conexión de transporte puede reducir el coste por paquete y, a la vez, mantener dentro de ella varios dominios de control y confianza. Cuando una revisión encuentra “PPP autenticado”, debe preguntar qué quedó autenticado: ¿los pares PPP y el tráfico de esa sesión, o cada CID, función de servicio y conmutador que atravesaba la conexión virtual? RFC 3336 respondía que lo primero no implicaba lo segundo.

Fuentes

Ficha de estado de RFC Editor

Fuentes: RFC 3336 · RFC 3337 · PPP sobre AAL5, RFC 2364 · Multiplexación PPP, RFC 3153 · PPP, RFC 1661 · Compresión de encabezados RTP, RFC 2508 · Enlaces de baja velocidad, RFC 2689 · UIT-T I.363.2 · UIT-T I.366.1 · Lu Heng, Nota 65