Resumen

  • RFC 3436 emparejó flujos SCTP opuestos con el mismo identificador y puso una conexión TLS independiente sobre cada pareja; reanudar una sesión ahorraba trabajo, pero no sustituía el handshake de cada conexión.
  • El flujo protegido tenía que ser ordenado y totalmente fiable, mientras que TLS cubría datos de usuario y no todo el control SCTP. RFC 6083 trasladó después la seguridad a una conexión DTLS por asociación.

Un solo estado verde no bastaba

En una asociación SCTP, el flujo 0 podía estar listo tras un handshake completo, el 1 reanudando una sesión, el 2 sin negociar hasta su primer uso y otro enviando SCTP nativo. Los flujos unidireccionales ni siquiera podían usar este TLS. Marcar toda la asociación como «segura» borraba diferencias operativas decisivas.

RFC 3436, publicado en diciembre de 2002, explicó cómo ejecutar TLS 1.0 sobre SCTP. Su texto, registro editorial y expediente IETF prueban la especificación, no una implementación, interoperabilidad, despliegue ni rendimiento concretos.

TLS 1.0 esperaba bytes fiables y en orden. SCTP entregaba mensajes delimitados, varios flujos y varias direcciones de red. RFC 3436 no cambió ninguno: convirtió cada registro TLS en un mensaje de usuario SCTP. SCTP debía fragmentarlo y recomponerlo para ocultar el MTU a TLS y evitar fragmentación IP. El mínimo exigido era 18.437 bytes, 2^14 + 2048 + 5.

Los flujos con igual número en sentidos opuestos formaban una pareja. El menor de los dos recuentos negociados fijaba cuántas parejas existían; el resto seguía siendo unidireccional. Cada pareja protegida ejecutaba su propio handshake.

Podía ser completo, abreviado mediante una sesión de otra conexión o aplazado hasta el uso real. La reanudación reducía cómputo; varios handshakes completos en paralelo podían rendir mejor con mucha latencia. Compartir sesión no significaba compartir conexión: ningún flujo heredaba automáticamente el estado listo de otro.

La protección quitaba capacidades

Los registros TLS exigían secuencia estricta. Por eso RFC 3436 prohibió la entrega desordenada y la vida limitada en flujos protegidos. Tampoco admitió TLS en flujos unidireccionales. RFC 3758 añadió después fiabilidad parcial a SCTP, pero un registro TLS serial no podía abandonarse sin romper su secuencia.

La frontera de seguridad era aún más estrecha. RFC 4895 señaló que TLS según RFC 3436 sólo protegía datos de usuario SCTP; no autenticaba los chunks de la asociación. SCTP-AUTH tuvo que aportar esa prueba. Contenido cifrado, identidad TLS, chunk DATA auténtico y control auténtico no eran sinónimos.

El multihoming tampoco equivalía a identidad. Los registros podían llegar desde una IP distinta a la observada al autenticar. La decisión debía apoyarse en el par autenticado, no en la dirección de transporte.

El rediseño posterior

RFC 6083 enumeró cuatro limitaciones serias: sin entrega desordenada, sin fiabilidad parcial, sólo igual número de flujos en ambos sentidos y una conexión TLS por pareja, costosa al escalar. Su DTLS usó una conexión dentro de la asociación. El flujo 0 transportaba control de seguridad ordenado y plenamente fiable; los demás podían conservar límites de mensaje, desorden y fiabilidad parcial. DATA y, cuando procedía, FORWARD-TSN necesitaban SCTP-AUTH.

RFC 8996 terminó de deprecar TLS 1.0 y 1.1. La criptografía de RFC 3436 debe leerse como historia, no como recomendación presente.

Las capas de realidad de Heng Lu ayudan a separar norma, handshake, autenticación de transporte y resultado de aplicación. La primacía del código en ejecución exige observación real; la especificación inicial mínima permite entender retrospectivamente por qué se reutilizaron piezas existentes con un perfil limitado.

La lección no fue «SCTP quedó seguro». Fue más exacta: este flujo completó esta conexión para esta identidad, bajo estas reglas, mientras el control de la asociación requería otra prueba.

Fuentes

Otros registros congelados