SCTP ( English Stream Control Transmission Protocol - “protocolo de transmisión con control de flujo”) es un protocolo de capa de transporte en redes informáticas que apareció en el año 2000 en IETF . RFC 4960 describe este protocolo y RFC 3286 proporciona una introducción técnica.
Como cualquier otro protocolo de la capa de transporte, SCTP funciona de manera similar a TCP o UDP [1] . Al ser un protocolo más nuevo, SCTP tiene varias innovaciones, como subprocesos múltiples, protección contra ataques DDoS, conexión síncrona entre dos hosts en dos o más canales físicos independientes (multi-homing).
La creación de una nueva conexión en los protocolos TCP y SCTP se produce mediante el mecanismo de reconocimiento de paquetes (handshaking). En el protocolo TCP, este procedimiento se denomina protocolo de enlace de tres vías. El cliente envía un paquete SYN (abreviado Synchronize). El servidor responde con un paquete SYN-ACK (Synchronize-Acknowledge). El cliente acusa recibo del paquete SYN-ACK con un paquete ACK. Esto completa el procedimiento de establecimiento de la conexión.
TCP tiene una vulnerabilidad potencial en la que un atacante podría enviar múltiples paquetes SYN a un servidor configurando direcciones IP de origen falsificadas. Al recibir un paquete SYN, el servidor asigna algunos de sus recursos para establecer una nueva conexión. El procesamiento de muchos paquetes SYN tarde o temprano requerirá todos los recursos del servidor y hará que sea imposible procesar nuevas solicitudes. Este tipo de ataque se denomina " SYN flood " (inundación SYN).
El protocolo SCTP está protegido contra este tipo de ataques mediante el mecanismo de reconocimiento de cuatro vías y la introducción de un token (cookie). En SCTP, el cliente inicia el procedimiento de establecimiento de la conexión enviando un paquete INIT. En respuesta, el servidor envía un paquete INIT-ACK que contiene un token (una clave única que identifica la nueva conexión). Luego, el cliente responde enviando un paquete COOKIE-ECHO que contiene el token recibido del servidor. Solo después de eso, el servidor asigna sus recursos a la nueva conexión y lo confirma enviando un paquete COOKIE-ACK al cliente.
Para resolver el problema del retraso en la transferencia de datos cuando se realiza el procedimiento de reconocimiento de cuatro vías en el protocolo SCTP, se permite incluir datos en los paquetes COOKIE-ECHO y COOKIE-ACK.
Veamos las diferencias entre el procedimiento de cierre del socket SCTP y el procedimiento de cierre medio de TCP.
En el protocolo TCP, es posible una situación de cierre parcial de la conexión cuando un nodo ha terminado de transmitir datos (enviando un paquete FIN), pero continúa recibiendo datos en esta conexión. El otro nodo puede continuar transmitiendo datos hasta que cierre la conexión en su propio lado. Las aplicaciones rara vez utilizan el estado de cierre parcial, por lo que los desarrolladores del protocolo SCTP consideraron necesario reemplazarlo con una secuencia de mensajes para romper la asociación existente. Cuando un nodo cierra su socket (envía un mensaje de APAGADO), ambos pares deben dejar de transmitir datos, permitiendo solo el intercambio de paquetes que acusan recibo de los datos enviados previamente.
TCP gestiona la secuencia de bytes : los datos enviados por la aplicación emisora deben llegar a la aplicación receptora exactamente en el mismo orden (mientras que el protocolo IP es capaz de invertir la secuencia de paquetes; además, los paquetes perdidos se reenvían y suelen llegar al destinatario fuera de secuencia; los datos se almacenan en búfer para combatir estos fenómenos). SCTP puede transportar datos entre dos puntos ( nodos ) simultáneamente a través de múltiples flujos de mensajes . A diferencia de TCP , SCTP procesa mensajes completos (preserva el límite del mensaje) y no bytes ordinarios de información . De esta forma, SCTP es similar a UDP. Por lo tanto, si el remitente envía al servidor un mensaje que consiste en 100 bytes en el primer paso, seguido de otros 50 bytes, entonces el destinatario en el primer paso recibirá exactamente los primeros 100 bytes en el primer mensaje, y solo luego 50 bytes en la segunda operación de lectura desde el socket .
El término "multihilo" (ing. multi-streaming ) se refiere a la capacidad de SCTP para transmitir en paralelo a través de varios flujos de mensajes independientes . Por ejemplo, estamos transfiriendo varias fotos a través de una aplicación HTTP ( por ejemplo, un navegador ). Puede usar varias conexiones TCP para esto, pero también es aceptable una asociación SCTP (eng. SCTP Association ), que administra múltiples flujos de mensajes para este propósito. Los flujos son unidireccionales, lo que significa que solo transfieren información en una dirección ( la imagen de arriba no es precisa ).
TCP logra el orden de bytes correcto en un flujo asignando de manera abstracta un número de secuencia a cada unidad enviada y ordenando los bytes recibidos utilizando los números de secuencia asignados a medida que llegan. Por otro lado, SCTP asigna diferentes números de secuencia a los mensajes enviados en un flujo particular . Esto permite la ordenación independiente de mensajes a través de diferentes hilos. De todos modos, multihilo es una opción en SCTP. Dependiendo de los deseos de la aplicación del usuario, los mensajes pueden procesarse no en el orden en que fueron enviados, sino en el orden en que fueron recibidos.
Los beneficios de usar SCTP incluyen:
Parte de la ventaja proviene del hecho de que los desarrolladores originales de SCTP diseñaron el protocolo para transportar telefonía ( SS7 ) sobre IP .
SCTP se diseñó con algunas funciones para mejorar la seguridad, como un "apretón de manos 4x" (frente al "apretón de manos 3x" de TCP) para evitar ataques de inundación SYN y cookies grandes para la autenticación de asociaciones.
La confiabilidad ha sido uno de los aspectos clave del diseño de seguridad del protocolo SCTP. Multi-homing permite que una asociación permanezca abierta incluso si algunas de las rutas e interfaces en uso no están disponibles. Esto es de particular importancia para SIGTRAN , que utiliza SCTP para transportar mensajes y servicios de protocolo SS7 a través de una red IP, lo que requiere una gran resistencia durante las interrupciones del enlace para mantener los servicios de telecomunicaciones, incluso ante anomalías graves en la red.
El cifrado no forma parte del diseño original de SCTP.
En algunos casos, SCTP es un buen candidato para probar la solidez la TCP/IP La razón de esto es el hecho de que algunos sistemas operativos se distribuyen con soporte para el protocolo SCTP, pero debido a su poco conocido (en comparación con TCP o UDP), los administradores a veces se olvidan de configurar la detección de intrusos en el firewall , lo que permite escanear el tráfico.
| Parámetro | UDP | TCP | SCTP |
|---|---|---|---|
| Estableciendo una conexión | No | Sí | Sí |
| Transmisión confiable | No | Sí | Sí |
| Preservar los límites del mensaje | Sí | No | Sí |
| entrega ordenada | No | Sí | Sí |
| Entrega no ordenada | Sí | No | Sí |
| Sumas de comprobación de datos | Sí | Sí | Sí |
| Tamaño de la suma de comprobación (bits) | dieciséis | dieciséis | 32 |
| Ruta MTU | No | Sí | Sí |
| Gestión de acumulación | No | Sí | Sí |
| subprocesos múltiples | No | No | Sí |
| Soporte para múltiples interfaces | No | No | Sí |
| un montón de hilos | No | Sí | Sí |
Al formar marcos de mensajes, los límites del mensaje se conservan en la forma en que se transmite al socket; esto significa que si el cliente envía 100 bytes seguidos de 50 bytes al servidor, entonces el servidor toma 100 bytes y 50 bytes como dos lecturas. El protocolo UDP funciona exactamente de la misma manera; esta es una característica de los protocolos orientados a mensajes.
Por el contrario, el protocolo TCP maneja un flujo de bytes no estructurado. Si no se utiliza el procedimiento de formación de tramas de mensajes, entonces el nodo de red puede recibir datos que son más grandes o más pequeños que los datos enviados. Este modo de operación requiere que, para los protocolos orientados a mensajes que se ejecutan sobre TCP, se proporcione un búfer de datos dedicado en la capa de aplicación y se realice la estructuración del mensaje (una tarea potencialmente compleja).
El protocolo SCTP proporciona tramas para la transmisión de datos. Cuando un nodo escribe en un socket, se garantiza que su par recibirá un bloque de datos del mismo tamaño.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Los paquetes SCTP tienen una estructura más simple que los paquetes TCP. Cada paquete consta de dos secciones principales:
El primer bloque está marcado en verde y el último de los N bloques (N bloque) está resaltado en rojo.
Cada bloque tiene un identificador de tipo, que ocupa un byte. Por lo tanto, se pueden definir un máximo de 255 tipos de bloques diferentes. RFC 4960 define una lista de tipos de bloques, con un total de 15 tipos definidos actualmente. El resto del bloque consta de un campo de longitud de 2 bytes (la longitud máxima que puede contener este campo es de 65535 bytes) y, de hecho, los datos. Si el tamaño del bloque no es un múltiplo de 4 bytes, entonces se rellena con ceros hasta un tamaño que es un múltiplo de 4 bytes.
La retransmisión de bloques de DATOS puede deberse a (a) un tiempo de espera definido por el temporizador de retransmisión o (b) la recepción de un SACK que indica que el destino no recibió el bloque de DATOS. Para reducir la posibilidad de congestión, la retransmisión de bloques de DATOS está limitada. El valor del tiempo de espera de reintento (RTO) se establece en función de un tiempo de ida y vuelta estimado y disminuye exponencialmente a medida que aumenta la tasa de pérdida de mensajes. Para asociaciones activas con tráfico de DATOS casi constante, es probable que el motivo del reintento sean mensajes SACK en lugar de un tiempo de espera. Para reducir la probabilidad de reintentos innecesarios, se usa la regla 4 SACK, según la cual la retransmisión ocurre solo en el cuarto SACK, lo que indica que se omitió un bloque de datos. Esto evita retransmisiones causadas por entrega fuera de servicio.
Se mantiene un contador para el número de reintentos a una dirección de destino en particular sin confirmación de entrega exitosa. Cuando el valor de este contador alcanza el umbral especificado (parámetro de configuración), la dirección se declara inactiva y el protocolo SCTP comienza a utilizar otra dirección para transmitir bloques de DATOS. Además, periódicamente se envían bloques Heartbeat especiales a todas las direcciones no utilizadas (opcionales), y se mantiene un contador sobre la cantidad de bloques Heartbeat enviados sin devolver un Heartbeat Ack correspondiente. Cuando el valor del contador alcanza un determinado umbral (parámetro de configuración), la dirección correspondiente se declara inactiva. Los bloques de latidos se transmiten a direcciones inactivas hasta que se recibe un mensaje de reconocimiento que indica que la dirección ha vuelto a la actividad. La frecuencia de los bloques Heartbeat está determinada por el valor RTO y el retraso adicional, lo que permite enviar bloques Heartbeat sin interferir con el tráfico del usuario.
Para todas las direcciones de los destinatarios, se mantiene un contador común del número de repeticiones o bloques Heartbeat, los datos se transmiten a un punto remoto sin recibir una confirmación (Ack) correspondiente de este. Cuando el valor del contador alcanza el umbral especificado (parámetro de configuración), el punto final se declara inalcanzable y la asociación SCTP se cierra.
El protocolo TCP proporciona los medios básicos para transmitir datos a través de Internet a través de una ruta confiable. Sin embargo, TCP impone algunas restricciones en el transporte de datos:
Todas estas limitaciones van en detrimento del rendimiento de las redes telefónicas sobre IP .
El protocolo se desarrolló como parte del trabajo de un grupo SIGTRAN especialmente creado dentro del IETF [2] para implementar protocolos y adaptaciones de la pila SS-7 para su uso en redes IP, debido a la necesidad de una entrega de datos rápida y confiable. Esto se establece explícitamente en RFC 4960 capítulo 1.1 Motivación :
...
El transporte de señalización PSTN a través de la red IP es una aplicación para la cual todas estas limitaciones de TCP son relevantes. Si bien esta aplicación está directamente motivada por el desarrollo de SCTP, otras aplicaciones pueden encontrar que SCTP se adapta bien a sus requisitos... ... La
señalización PSTN a través de una red IP es una aplicación para la cual todas las limitaciones de TCP son directamente relevantes. Si bien esto motivó directamente el desarrollo de SCTP, otras aplicaciones también pueden encontrar que SCTP es una buena opción para sus requisitos...
RFC 4960
| Protocolos | TCAP | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| V5.2 | MTP3 | MTP3 | DEPENDE | SCCP | DSS1 | TCAP | ||||||||||||||
| SIGTRAN | V5UA | M2UA | M2PA | M3UA | AIU | SUA | ||||||||||||||
| red informática | SCTP | |||||||||||||||||||
| IP | ||||||||||||||||||||
Existe una implementación de referencia para FreeBSD, Mac OS X, Microsoft Windows y Linux [3] .
El protocolo SCTP se implementa en los siguientes sistemas operativos:
Implementación a través de controladores de terceros:
Bibliotecas de usuario separadas:
Aplicaciones:
| Protocolos TCP /IP básicos por capas del modelo OSI | |
|---|---|
| Físico | |
| canalizado | |
| la red | |
| Transporte | |
| sesión | |
| Representación | |
| Aplicado | |
| Otro aplicado | |
| Lista de puertos TCP y UDP | |