Protocolo de transmisión de control de flujo

El Protocolo de transmisión de control de flujo o SCTP (Stream Control Transmission Protocol) es un protocolo de comunicaciones de redes informáticas en la capa de transporte del conjunto de protocolos de Internet. Diseñado originalmente para el transporte de mensajes del Sistema de señalización 7 (SS7) en telecomunicaciones, el protocolo proporciona la función orientada a mensajes del Protocolo de datagramas de usuario (UDP), al tiempo que garantiza el transporte confiable y en secuencia de mensajes con control de congestión como el Protocolo de control de transmisión (TCP). A diferencia de UDP y TCP, el protocolo admite múltiples hosts y rutas redundantes para aumentar la resiliencia y la confiabilidad.

SCTP está estandarizado por el Grupo de trabajo de ingeniería de Internet (IETF) en RFC 4960. La implementación de referencia de SCTP se lanzó como parte de la versión 7 de FreeBSD y, desde entonces, se ha portado ampliamente a otras plataformas.

Supervisión formal

El grupo de trabajo de transporte de señalización de IETF (SIGTRAN) definió el protocolo (número 132) en octubre de 2000, y el grupo de trabajo de área de transporte de IETF (TSVWG) lo mantiene. RFC 4960 define el protocolo. RFC 3286 proporciona una introducción.

Transmisión múltiple basada en mensajes

Las aplicaciones SCTP envían datos para su transmisión en mensajes (grupos de bytes) a la capa de transporte SCTP. SCTP coloca los mensajes y la información de control en fragmentos separados (fragmentos de datos y fragmentos de control), cada uno identificado por un encabezado de fragmento. El protocolo puede fragmentar un mensaje en varios fragmentos de datos, pero cada fragmento de datos contiene datos de un solo mensaje de usuario. SCTP agrupa los fragmentos en paquetes SCTP. El paquete SCTP, que se envía al Protocolo de Internet, consta de un encabezado de paquete, fragmentos de control SCTP (cuando sea necesario), seguidos de fragmentos de datos SCTP (cuando estén disponibles).

SCTP puede caracterizarse como orientado a mensajes, lo que significa que transporta una secuencia de mensajes (cada uno de los cuales es un grupo de bytes), en lugar de transportar un flujo ininterrumpido de bytes como en TCP. Al igual que en UDP, en SCTP un remitente envía un mensaje en una sola operación y ese mensaje exacto se pasa al proceso de la aplicación receptora en una sola operación. Por el contrario, TCP es un protocolo orientado a flujos, que transporta flujos de bytes de forma fiable y en orden. Sin embargo, TCP no permite que el receptor sepa cuántas veces la aplicación del remitente llamó al transporte TCP y le pasó grupos de bytes para enviar. En el remitente, TCP simplemente agrega más bytes a una cola de bytes que esperan salir a través de la red, en lugar de tener que mantener una cola de mensajes salientes individuales separados que deben conservarse como tales.

El término transmisión múltiple se refiere a la capacidad de SCTP para transmitir varias secuencias independientes de fragmentos en paralelo, por ejemplo, transmitir imágenes de páginas web simultáneamente con el texto de la página web. En esencia, implica agrupar varias conexiones en una sola asociación SCTP, que opera con mensajes (o fragmentos) en lugar de bytes.

TCP conserva el orden de los bytes en el flujo al incluir un número de secuencia de bytes con cada segmento. SCTP, por otro lado, asigna un número de secuencia o una identificación de mensaje a cada mensaje enviado en una secuencia. Esto permite la ordenación independiente de mensajes en diferentes flujos. Sin embargo, el orden de los mensajes es opcional en SCTP; una aplicación receptora puede optar por procesar los mensajes en el orden de recepción en lugar de en el orden de envío.

Características

Las características de SCTP incluyen:

• Transmisión confiable de flujos de datos ordenados y no ordenados
• Compatibilidad con alojamiento múltiple en el que uno o ambos extremos de una conexión pueden constar de más de una dirección IP, lo que permite una conmutación por error transparente entre rutas de red redundantes
• La entrega de fragmentos dentro de flujos independientes elimina el bloqueo innecesario de cabeza de línea, a diferencia de la entrega de flujo de bytes TCP.
• Fiabilidad parcial explícita
• Selección y monitoreo de ruta para seleccionar una ruta de transmisión de datos primaria y probar la conectividad de la ruta de transmisión
• Los mecanismos de validación y reconocimiento protegen contra ataques de desbordamiento y notifican fragmentos de datos duplicados o faltantes.
• Detección de errores mejorada adecuada para tramas jumbo de Ethernet

Los diseñadores de SCTP originalmente lo concibieron para el transporte de telefonía (es decir, el Sistema de señalización 7) sobre el Protocolo de Internet, con el objetivo de duplicar algunos de los atributos de confiabilidad de la red de señalización SS7 en IP. Este esfuerzo del IETF se conoce como SIGTRAN. Mientras tanto, se han propuesto otros usos, por ejemplo, el protocolo Diameter y Reliable Server Pooling (RSerPool).

Motivación y adopción

TCP ha proporcionado el medio principal para transferir datos de manera confiable a través de Internet. Sin embargo, TCP ha impuesto limitaciones en varias aplicaciones. De RFC 4960:

• TCP proporciona una transferencia de datos confiable y una entrega de datos en orden estricto de transmisión. Algunas aplicaciones necesitan transferencias confiables sin mantenimiento de secuencia, mientras que otras estarían satisfechas con una ordenación parcial de los datos. En ambos casos, la propiedad de bloqueo de cabecera de línea de TCP provoca un retraso innecesario.
• Para las aplicaciones que intercambian registros o mensajes distintos, la naturaleza orientada al flujo de TCP requiere la adición de marcadores explícitos u otra codificación para delimitar los registros individuales.
• Para evitar el envío de muchos paquetes IP pequeños donde un solo paquete más grande hubiera sido suficiente, la implementación de TCP puede retrasar la transmisión de datos mientras espera que la aplicación ponga en cola posiblemente más datos (algoritmo de Nagle). Si y cuando no se desea un retraso tan pequeño, la aplicación debe solicitar explícitamente una transmisión sin retraso caso por caso utilizando la función de inserción (es decir, configurando el indicador PSH en el encabezado del paquete TCP). SCTP, por otro lado, permite que la transmisión sin demora se configure como predeterminada para una asociación, eliminando cualquier demora no deseada, pero a costa de una mayor sobrecarga de transferencia.
• El alcance limitado de los sockets TCP complica la tarea de proporcionar una capacidad de transferencia de datos de alta disponibilidad mediante hosts multitarjeta.
• TCP es relativamente vulnerable a los ataques de denegación de servicio, como los ataques SYN.

La adopción se ha visto retrasada por la falta de conocimiento, la falta de implementaciones (particularmente en Microsoft Windows), la falta de soporte de aplicaciones y la falta de soporte de red.

Multiubicación

SCTP proporciona rutas redundantes para aumentar la confiabilidad.

Cada punto final SCTP debe verificar la accesibilidad de las direcciones principal y redundante del punto final remoto mediante un latido. Cada punto final SCTP debe reconocer los latidos que recibe del punto final remoto.

Cuando SCTP envía un mensaje a una dirección remota, la interfaz de origen solo la decidirá la tabla de enrutamiento del host (y no SCTP).

En el alojamiento múltiple asimétrico, uno de los dos extremos no admite el alojamiento múltiple.

En multihoming local y single homing remoto, si no se puede acceder a la dirección principal remota, la asociación SCTP falla incluso si es posible una ruta alternativa.

Estructura del paquete

Un paquete SCTP consta de dos secciones básicas:

1. El encabezado común, que ocupa los primeros 12 bytes y está resaltado en azul.
2. Los fragmentos de datos, que ocupan la parte restante del paquete. El primer fragmento se resalta en verde y el último de N fragmentos (Chunk N) se resalta en rojo.

bits	0–7	8–15	16–23	24–31
+0	Puerto de origen	Puerto de destino
32	Etiqueta de verificación
64	Suma de verificación
96	Tipo de trozo 1	Trozo 1 banderas	Longitud del trozo 1
128	Datos del fragmento 1
…	…
…	Tipo de trozo N	Chunk N banderas	Longitud del trozo N
…	Datos de fragmento N

Cada fragmento comienza con un identificador de tipo de un byte, con 15 tipos de fragmentos definidos por RFC 4960 y al menos 5 más definidos por RFC adicionales. Ocho bits de bandera, un campo de longitud de dos bytes y los datos componen el resto del fragmento. Si el fragmento no forma un múltiplo de 4 bytes (es decir, la longitud no es un múltiplo de 4), se rellena con ceros, que no están incluidos en la longitud del fragmento. El campo de longitud de dos bytes limita cada fragmento a una longitud de 65.535 bytes (incluidos los campos de tipo, banderas y longitud).

Seguridad

Aunque el cifrado no formaba parte del diseño SCTP original, SCTP se diseñó con funciones para mejorar la seguridad, como el protocolo de enlace de 4 vías (en comparación con el protocolo de enlace de 3 vías TCP) para proteger contra los ataques de inundación SYN y "cookies" grandes para la verificación de asociación. y autenticidad.

La confiabilidad también fue una parte clave del diseño de seguridad de SCTP. Multihoming permite que una asociación permanezca abierta incluso cuando algunas rutas e interfaces están inactivas. Esto es de particular importancia para SIGTRAN, ya que transporta SS7 a través de una red IP que utiliza SCTP y requiere una gran capacidad de recuperación durante las interrupciones del enlace para mantener el servicio de telecomunicaciones, incluso cuando se presentan anomalías en la red.

SCTP es a veces un buen candidato para la toma de huellas dactilares. Algunos sistemas operativos se envían con la compatibilidad con SCTP habilitada y, como no es tan conocido como TCP o UDP, a veces se pasa por alto en las configuraciones de detección de intrusos y cortafuegos, lo que a menudo permite el tráfico de sondeo.

Implementaciones

La implementación de referencia SCTP se ejecuta en FreeBSD, Mac OS X, Microsoft Windows y Linux.

Los siguientes sistemas operativos implementan SCTP:

• AIX Versión 5 y posteriores
• NetBSD desde 8.0
• Cisco IOS 12 y superior
• DragonFly BSD desde la versión 1.4, sin embargo, el soporte está obsoleto en la versión 4.2
• FreeBSD, versión 7 y superior, contiene la implementación SCTP de referencia
• HP-UX, 11i v2 y superior
• ilumos
• Núcleo de Linux 2.4 y superior
• QNX Neutrino Realtime OS, 6.3.0 a 6.3.2, en desuso desde 6.4.0
• Tru64 con el paquete complementario SCTP de Compaq
• Sol Solaris 10 y superior
• Versiones de VxWorks 6.2.x a 6.4.x y 6.7 y posteriores

Controladores de terceros:

• Microsoft Windows:
  • El controlador del kernel SctpDrv es un puerto de la pila BSD SCTP para Windows (abandonado después de 2012)
• Mac OS:
  • Extensión de kernel de red SCTP para Mac OS X

Biblioteca de espacio de usuario:

• Pila de espacio de usuario SCTP portátil
• La biblioteca SCTP
  • Puerto de Windows XP
• Oracle Java SE 7
• Erlang/OTP

Las siguientes aplicaciones implementan SCTP:

• WebRTC
• Flujo de red

Tunelización sobre UDP

En ausencia de soporte SCTP nativo en los sistemas operativos, es posible tunelizar SCTP sobre UDP, así como también asignar llamadas de API TCP a llamadas SCTP para que las aplicaciones existentes puedan usar SCTP sin modificaciones.

RFC

• RFC 7829 SCTP-PF: un algoritmo de conmutación por error rápido para el protocolo de transmisión de control de flujo
• RFC 7765 TCP y Protocolo de transmisión de control de flujo (SCTP) RTO Reiniciar
• RFC 7496 Políticas adicionales para la extensión del protocolo de transmisión de control de flujo parcialmente confiable
• RFC 7053 SACK-IMMEDIATELY Extensión para el protocolo de transmisión de control de flujo (actualiza RFC 4960)
• RFC 6951 UDP Encapsulación de paquetes SCTP (Stream Control Transmission Protocol) para comunicaciones de host final a host final
• RFC 6525 Protocolo de transmisión de control de flujo (SCTP) Reconfiguración de flujo
• Extensiones API de sockets RFC 6458 para el protocolo de transmisión de control de flujo (SCTP)
• RFC 6096 Protocolo de transmisión de control de flujo (SCTP) Registro de indicadores de fragmentos (actualiza RFC 4960)
• Ataques de seguridad RFC 5062 encontrados contra el protocolo de transmisión de control de flujo (SCTP) y contramedidas actuales
• RFC 5061 Protocolo de transmisión de control de flujo (SCTP) Reconfiguración dinámica de direcciones
• RFC 5043 Protocolo de transmisión de control de flujo (SCTP) Adaptación de ubicación directa de datos (DDP)
• Protocolo de transmisión de control de flujo RFC 4960
• RFC 4895 fragmentos autenticados para el protocolo de transmisión de control de flujo (SCTP)
• RFC 4820 Fragmento de relleno y parámetro para el protocolo de transmisión de control de flujo (SCTP)
• Erratas y problemas de la especificación del protocolo de transmisión de control de flujo (SCTP) RFC 4460
• RFC 3873 Protocolo de transmisión de control de flujo (SCTP) Base de información de gestión (MIB)
• RFC 3758 Protocolo de transmisión de control de flujo (SCTP) Extensión de confiabilidad parcial
• RFC 3554 sobre el uso del protocolo de transmisión de control de flujo (SCTP) con IPsec
• RFC 3436 Seguridad de la capa de transporte sobre el protocolo de transmisión de control de flujo
• RFC 3309 Protocolo de transmisión de control de flujo (SCTP) Cambio de suma de comprobación (obsoleto por RFC 4960)
• RFC 3286 Introducción al protocolo de transmisión de control de flujo
• Declaración de aplicabilidad del protocolo de transmisión de control de flujo RFC 3257
• Protocolo de transmisión de control de flujo RFC 2960 (actualizado por RFC 3309 y obsoleto por RFC 4960)