Protocolo de transmisión de control de flujo

El Protocolo de Transmisión de Control de Flujo ( SCTP ) es un protocolo de comunicaciones de redes informáticas en la capa de transporte del conjunto de protocolos de Internet . Originalmente diseñado para el transporte de mensajes del Sistema de Señalización 7 (SS7) en telecomunicaciones, el protocolo ofrece la funcionalidad orientada a mensajes del Protocolo de Datagramas de Usuario (UDP) al tiempo que garantiza un transporte fiable y secuencial de mensajes con control de congestión , similar al del Protocolo de Control de Transmisión (TCP). A diferencia de UDP y TCP, el protocolo admite la multiconexión y rutas redundantes para aumentar la resiliencia y la fiabilidad.

SCTP está estandarizado por el Grupo de Trabajo de Ingeniería de Internet (IETF) en el RFC 9260. La implementación de referencia de SCTP se publicó como parte de FreeBSD versión 7 y desde entonces se ha adaptado ampliamente a otras plataformas. 

El grupo de trabajo SIGTRAN (Señalización y Transporte ) de la IETF definió el protocolo (número 132 ^{[ 1 ]} ) en octubre de 2000 ^{[ 2 ]} , y el grupo de trabajo TSVWG (Área de Transporte) de la IETF lo mantiene. El RFC 9260 define el protocolo. El RFC 3286 proporciona una introducción.  

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 bloques separados (bloques de datos y bloques de control), cada uno identificado por una cabecera de bloque . El protocolo puede fragmentar un mensaje en varios bloques de datos, pero cada bloque de datos contiene información de un solo mensaje de usuario. SCTP agrupa los bloques en paquetes SCTP. El paquete SCTP, que se envía al protocolo de Internet , consta de una cabecera de paquete, bloques de control SCTP (cuando sea necesario) seguidos de bloques de datos SCTP (cuando estén disponibles).

SCTP se caracteriza por estar orientado a mensajes, lo que significa que transporta una secuencia de mensajes (cada uno un grupo de bytes), en lugar de transportar un flujo continuo de bytes como en TCP. Al igual que en UDP, en SCTP un emisor envía un mensaje en una sola operación, y ese mismo mensaje se transmite al proceso de la aplicación receptora también 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 emisora ​​ha llamado al transporte TCP pasándole grupos de bytes para su envío. En el emisor, TCP simplemente añade más bytes a una cola de bytes que esperan ser enviados 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 única asociación SCTP, operando con mensajes (o fragmentos) en lugar de bytes.

TCP conserva el orden de 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 un identificador de mensaje ^{[ nota 1 ]} a cada mensaje enviado en un flujo. Esto permite ordenar los mensajes de forma independiente 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 del orden de envío.

Las características de SCTP incluyen:

• Transmisión fiable de flujos de datos tanto ordenados como desordenados.
• Compatibilidad con multihoming, donde 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 cabecera de línea , a diferencia de la entrega de flujo de bytes TCP.
• Fiabilidad parcial explícita
• Selección y monitorización de la ruta para seleccionar una ruta de transmisión de datos principal y probar la conectividad de la ruta de transmisión.
• Los mecanismos de validación y confirmación protegen contra los ataques de inundación y notifican la presencia de fragmentos de datos duplicados o faltantes.
• Detección de errores mejorada adecuada para tramas jumbo de Ethernet

Los diseñadores de SCTP lo concibieron originalmente para el transporte de telefonía (es decir, el Sistema de Señalización 7) a través del Protocolo de Internet, con el objetivo de replicar 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 ^{[ 3 ]} y Reliable Server Pooling (RSerPool) ^{[ 4 ] .}

TCP ha proporcionado el principal medio para transferir datos de forma fiable a través de Internet. Sin embargo, TCP ha impuesto limitaciones a varias aplicaciones. Del RFC 4960 : 

• TCP proporciona tanto una transferencia de datos fiable como una entrega de datos con estricto orden de transmisión. Algunas aplicaciones requieren una transferencia fiable sin mantenimiento de la secuencia, mientras que otras se conformarían con un orden parcial de los datos. En ambos casos, la propiedad de bloqueo de cabecera de TCP provoca retrasos innecesarios.
• 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 cuando un único paquete más grande habría sido suficiente, la implementación de TCP puede retrasar la transmisión de datos mientras espera que la aplicación pueda tener más datos en cola ( algoritmo de Nagle ). Aunque muchas implementaciones de TCP permiten deshabilitar el algoritmo de Nagle, esto no es un requisito de la especificación. SCTP, por otro lado, permite configurar la transmisión sin retardo como predeterminada para una asociación, eliminando cualquier retraso no deseado, pero a costa de una mayor sobrecarga de transferencia. ^{[ 5 ]}
• El alcance limitado de los sockets TCP complica la tarea de proporcionar una capacidad de transferencia de datos de alta disponibilidad utilizando hosts con múltiples interfaces de red.
• TCP es relativamente vulnerable a ataques de denegación de servicio, como los ataques SYN .

La adopción de SCTP se ha visto ralentizada por la falta de conocimiento, la falta de implementaciones (en particular en Microsoft Windows), la falta de soporte de aplicaciones y la falta de soporte de red. ^{[ 6 ]}

SCTP ha sido adoptado en el ámbito de la telefonía móvil como protocolo de transporte para varias interfaces de red centrales . ^{[ 7 ]}

Multiconexión SCTP

Multihoming asimétrico: multihoming local a conexión única remota

Multihoming asimétrico: de conexión única local a multihoming remoto.

SCTP proporciona rutas redundantes para aumentar la fiabilidad.

Cada punto final SCTP debe comprobar la accesibilidad de las direcciones principal y redundante del punto final remoto mediante una señal de latido . Cada punto final SCTP debe confirmar la recepción de las señales de latido del punto final remoto.

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

En la multiconexión asimétrica, uno de los dos puntos finales no admite la multiconexión.

En el caso de multihoming local y homing único remoto, si la dirección primaria remota no es accesible, la asociación SCTP falla incluso si es posible una ruta alternativa.

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 porción restante del paquete. El primer fragmento está resaltado en verde, y el último de los N fragmentos (Fragmento N) está resaltado en rojo.

Cada fragmento comienza con un identificador de tipo de un byte, con 15 tipos de fragmentos definidos por RFC 9260 y al menos 5 más definidos por RFC adicionales. ^{[ nota 2 ]} 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 se incluyen 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).  

Aunque el cifrado no formaba parte del diseño original de SCTP, este protocolo se diseñó con características 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 de TCP ) para proteger contra los ataques de inundación SYN , y grandes "cookies" para la verificación de la asociación y la autenticidad.

La fiabilidad también fue un aspecto clave del diseño de seguridad de SCTP. La multiconexión permite que una asociación permanezca abierta incluso cuando algunas rutas e interfaces no están disponibles. Esto es de particular importancia para SIGTRAN , ya que transmite SS7 a través de una red IP mediante SCTP y requiere una gran resiliencia durante las interrupciones del enlace para mantener el servicio de telecomunicaciones incluso ante anomalías en la red.

La implementación de referencia de SCTP se ejecuta en FreeBSD, Mac OS X, Microsoft Windows y Linux. ^{[ 8 ]}

Los siguientes sistemas operativos implementan SCTP:

• AIX versión 5 y posteriores
• NetBSD ^{[ 9 ]} desde 8.0 ^{[ 10 ]}
• Cisco IOS 12 y versiones posteriores
• DragonFly BSD desde la versión 1.4, sin embargo, el soporte se está descontinuando en la versión 4.2 ^{[ 11 ]}
• FreeBSD , versión 7 y superior, contiene la implementación de referencia de SCTP ^{[ 12 ].}
• HP-UX , 11i v2 y superior ^{[ 13 ]}
• illumos
• Núcleo de Linux 2.4 y versiones posteriores
• QNX Neutrino Realtime OS, ^{[ 14 ]} 6.3.0 a 6.3.2, obsoleto desde 6.4.0 ^{[ 15 ]}
• Tru64 con el paquete de complementos Compaq SCTP
• Sol Solaris 10 y superior ^{[ 16 ]}
• Versiones de VxWorks de 6.2.x a 6.4.x, y 6.7 y posteriores.

Controladores de terceros:

• Microsoft Windows :
  • El controlador del kernel SctpDrv es una adaptación de la pila SCTP de BSD a Windows (abandonada después de 2012) ^{[ 17 ].}
• macOS :
  • Extensión del núcleo de red SCTP para Mac OS X ^{[ 18 ]}

Biblioteca de espacio de usuario :

• Pila de espacio de usuario SCTP portátil ^{[ 19 ]}
• La biblioteca SCTP ^{[ 20 ]}
  • Puerto de Windows XP ^{[ 21 ]}
• Oracle Java SE 7
• Erlang/OTP

Las siguientes aplicaciones implementan SCTP:

• WebRTC
• NetFlow

• Protocolo de transmisión de control de flujo RFC 9260 
• RFC 8540 Protocolo de transmisión de control de flujo: Erratas y problemas en RFC 4960 (obsoleto por RFC 9260) 
• RFC 7829 SCTP-PF: Un algoritmo de conmutación por error rápida para el protocolo de transmisión de control de flujo 
• Reinicio del RTO del protocolo TCP y del protocolo de transmisión de control de flujo (SCTP) según RFC 7765 
• RFC 7496 Políticas adicionales para la extensión del protocolo de transmisión de control de flujo parcialmente confiable 
• Extensión SACK-IMMEDIATELY del RFC 7053 para el protocolo de transmisión de control de flujo (obsoleta por el RFC 9260) 
• RFC 6951 Encapsulación UDP de paquetes del Protocolo de Transmisión de Control de Flujo (SCTP) para comunicación de host final a host final 
• RFC 6525 Protocolo de transmisión de control de flujo (SCTP) Reconfiguración de flujo 
• Extensiones de la 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 fragmento (obsoleto por RFC 9260) 
• RFC 5062: Se han detectado ataques de seguridad contra el Protocolo de Transmisión de Control de Flujo (SCTP) y existen contramedidas actuales. 
• RFC 5061 Protocolo de transmisión de control de flujo (SCTP) Reconfiguración dinámica de direcciones 
• Adaptación del protocolo de transmisión de control de flujo (SCTP) de RFC 5043 para la colocación directa de datos (DDP). 
• RFC 4960 Protocolo de transmisión de control de flujo (obsoleto por RFC 9260) 
• RFC 4895 Fragmentos autenticados para el protocolo de transmisión de control de flujo (SCTP) 
• RFC 4820: Relleno de fragmentos y parámetros 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 (obsoleto por RFC 9260) 
• RFC 3873 Base de información de gestión (MIB ) del protocolo de transmisión de control de flujo (SCTP ) 
• RFC 3758 Extensión de confiabilidad parcial del protocolo de transmisión de control de flujo (SCTP) 
• 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 Cambio de suma de comprobación del protocolo de transmisión de control de flujo (SCTP) (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) 

• Capa de transporte §  Comparación de protocolos de la capa de transporte
• Protocolo de inicio de sesión (SIP): puede iniciar múltiples flujos a través de SCTP, TCP o UDP.
• TCP multipath : permite que una conexión TCP utilice múltiples rutas para maximizar el uso de recursos y aumentar la redundancia.
• Happy Eyeballs , diseñado originalmente para la selección eficiente de IPv4 o IPv6 para una conexión; ^{[ 24 ]} también podría adaptarse para seleccionar entre diferentes protocolos de transporte como TCP y SCTP ^{[ 25 ].}

• sigtran (archivado)
• "Grupo de Trabajo sobre Señalización del Transporte (sigtran)" .
• "Grupo de Trabajo del Área de Transporte (tsvwg)" .
• "Proyecto OpenSS7" .
• Grupo de trabajo SCTP para Linux
• "Página de Michael Tüxen en SCTP" .
• "Página de SCTP de Lode Coene" .
• "Página del proyecto SCTP de Thomas Dreibholz" .