SCTP

SCTP (англ. Stream Control Transmission Protocol — «протокол передачи с управлением потоком») — протокол транспортного уровня в компьютерных сетях, появившийся в 2000 году в IETF. RFC 4960 описывает этот протокол, а RFC 3286 содержит техническое вступление к нему.

Как и любой другой протокол передачи данных транспортного уровня, SCTP работает аналогично TCP или UDP. Будучи более новым протоколом, SCTP имеет несколько нововведений, таких как многопоточность, защита от DDoS-атак, синхронное соединение между двумя хостами по двум и более независимым физическим каналам (multi-homing).

Безопасное установление соединения

Создание нового подключения в протоколах TCP и SCTP происходит при помощи механизма подтверждения (квитирования) пакетов. В протоколе TCP данная процедура получила название трёхэтапное рукопожатие (three-way handshake). Клиент посылает пакет SYN (сокр. Synchronize). Сервер отвечает пакетом SYN-ACK (Synchronize-Acknowledge). Клиент подтверждает приём пакета SYN-ACK пакетом ACK. На этом процедура установления соединения завершается.

Протокол TCP имеет потенциальную уязвимость, обусловленную тем, что нарушитель, устанавливая фальшивые IP-адреса отправителя, может послать серверу множество пакетов SYN. При получении пакета SYN сервер выделяет часть своих ресурсов для установления нового соединения. Обработка множества пакетов SYN рано или поздно затребует все ресурсы сервера и сделает невозможной обработку новых запросов. Такой вид атак называется «SYN-флуд» (SYN flood).

Протокол SCTP защищён от подобных атак с помощью механизма четырёхэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения, посылая пакет INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, полученный от сервера. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправкой клиенту пакета COOKIE-ACK.

Для решения проблемы задержки пересылки данных при выполнении процедуры четырёхэтапного квитирования в протоколе SCTP допускается включение данных в пакеты COOKIE-ECHO и COOKIE-ACK.

Поэтапное завершение передачи данных

Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.

В протоколе TCP возможна ситуация частичного закрытия соединения, когда один узел закончил передачу данных (выполнив посылку пакета FIN), но продолжает принимать данные по этому соединению. Другой узел может продолжать передавать данные до тех пор, пока сам не проведёт закрытие соединения на своей стороне. Состояние частичного закрытия используется приложениями крайне редко, поэтому разработчики протокола SCTP посчитали нужным заменить его последовательностью сообщений для разрыва существующей ассоциации. Когда узел закрывает свой сокет (посылает сообщение SHUTDOWN), оба корреспондента должны прекратить передачу данных, при этом разрешается лишь обмен пакетами, подтверждающими приём ранее отправленных данных.

Многопоточность

TCP управляет последовательностью байт: данные, посланные приложением-отправителем, должны поступать приложению-получателю строго в том же порядке (в то время как протокол IP способен поменять последовательность пакетов; кроме того, пропавшие пакеты посылаются повторно и обычно прибывают к получателю с нарушением последовательности; для борьбы с этими явлениями данные накапливаются в буфере). SCTP может транспортировать данные между двумя точками (узлами) одновременно по нескольким потокам сообщений. В противоположность к TCP, SCTP обрабатывает целые сообщения (preserve message boundary), а не обычные байты информации. Этим SCTP похож на UDP. Таким образом, если отправитель отсылает серверу сообщение, состоящее из 100 байт за первый шаг, а за ним ещё 50 байт, то получатель за первый шаг получит именно первые 100 байт в первом сообщении, а только затем 50 байт на второй операции чтения из сокета.

Термин «многопоточность» (англ. multi-streaming) обозначает способность SCTP параллельно передавать по нескольким независимым потокам сообщений. Например, мы передаём несколько фотографий через HTTP-приложение (например, браузер). Можно использовать для этого связку из нескольких TCP-соединений, однако также допустима SCTP-ассоциация (англ. SCTP-association), управляющая несколькими потоками сообщений для этой цели. Потоки являются однонаправленными, то есть передают информацию только в одном направлении (картинка выше является неточной).

TCP достигает правильного порядка байт в потоке, абстрактно назначая порядковый номер каждой отосланной единице, а упорядочивая принятые байты, используя назначенные порядковые номера, по мере их прибывания. С другой стороны, SCTP присваивает различные порядковые номера сообщениям, посылаемым в конкретном потоке. Это разрешает независимое упорядочивание сообщений по разным потокам. Так или иначе, многопоточность является опцией в SCTP. В зависимости от желаний пользовательского приложения сообщения могут быть обработаны не в порядке их отправления, а в порядке их поступления.

Достоинства

Достоинства использования SCTP включают в себя:

• Использование множественных интерфейсов (англ Multihoming)
  Допустим, у нас есть два хоста. И хотя бы один из них имеет несколько сетевых интерфейсов и, соответственно, несколько IP-адресов. В TCP понятие «соединение» означает обмен данными между двумя точками, в то время как в SCTP имеет место концепция «ассоциации» (англ. association), обозначающая всё происходящее между двумя узлами

• Многопоточность
  Данные приходят в точку по независимым потокам. Это позволяет устранить феномен en:Head-of-line blocking, которым так страдает TCP
• Поиск пути с мониторингом
  Протоколом выбирается первичный маршрут передачи данных, а также производится проверка и мониторинг связности пути.
• Механизмы проверки подлинности
  Защита адресата от flood-атак (технология 4-way handshake), и уведомление о потерянных пакетах и нарушенных цепочках.
• Улучшенная система контроля ошибок, подходящая для jumbo-пакетов в Ethernet.

Часть достоинств вытекает из того факта, что изначально разработчики SCTP проектировали протокол под нужды передачи телефонии (SS7) по протоколу IP.

Недостатки

• Бóльшая занимаемая полоса, то есть относительный объём служебного трафика больше, чем при использовании TCP/UDP.

Безопасность

SCTP был разработан с некоторыми функциями, позволяющими повысить безопасность, такими как «4-кратное рукопожатие» (по сравнению с «трёхкратным рукопожатием» в TCP), чтобы предотвратить SYN-flood атаки, и больших (Cookie) для проверки подлинности ассоциации.

Надёжность была одним из ключевых аспектов разработки безопасности протокола SCTP. Multi-homing позволяет ассоциации оставаться открытой, даже если некоторые используемые маршруты и интерфейсы стали недоступны. Это имеет особое значение для (SIGTRAN), который используя SCTP, передаёт сообщения и сервисы протоколов ОКС-7 поверх IP сети, что требует сильной устойчивости во время отключений линков для поддержания телекоммуникационных услуг, даже при серьёзных аномалиях в сети.

Шифрование не является частью оригинального дизайна SCTP.

В некоторых случаях SCTP является хорошим кандидатом для ^[англ.]. Причиной для этого является тот факт, что некоторые операционные системы распространяются с поддержкой протокола SCTP, но ввиду его слабой известности (по сравнению с TCP или UDP), администраторы иногда забывают настроить в брандмауэре обнаружения вторжений, что даёт возможности для сканирования трафика.

Сравнение возможностей протоколов транспортного уровня

Параметр	UDP	TCP	SCTP
Установка соединения	Нет	Да	Да
Надёжная передача	Нет	Да	Да
Сохранение границ сообщения	Да	Нет	Да
Упорядоченная доставка	Нет	Да	Да
Неупорядоченная доставка	Да	Нет	Да
Контрольные суммы данных	Да	Да	Да
Размер контрольной суммы (бит)	16	16	32
MTU пути	Нет	Да	Да
Управление накоплением	Нет	Да	Да
Многопоточность	Нет	Нет	Да
Поддержка множественных интерфейсов	Нет	Нет	Да
Связка потоков	Нет	Да	Да

Формирование кадров сообщения

При формировании кадров сообщения обеспечивается сохранение границ сообщения в том виде, в котором оно передаётся сокету; это означает, что если клиент посылает серверу 100 байт, за которыми следуют 50 байт, то сервер воспринимает 100 байт и 50 байт за две операции чтения. Точно так же функционирует протокол UDP, это является особенностью протоколов, ориентированных на работу с сообщениями.

В противоположность им протокол TCP обрабатывает неструктурированный поток байт. Если не использовать процедуру формирования кадров сообщения, то узел сети может получать данные по размеру больше или меньше отправленных. Такой режим функционирования требует, чтобы для протоколов, ориентированных на работу с сообщениями и функционирующих поверх протокола TCP, на прикладном уровне был предоставлен специальный буфер данных и выполнялась процедура формирования кадров сообщений (что потенциально является сложной задачей).

Протокол SCTP обеспечивает формирование кадров при передаче данных. Когда узел выполняет запись в сокет, его корреспондент с гарантией получает блок данных того же размера.

Структура пакета

Биты Биты 0-7 8-15 16-23 24-31 +0 Порт источника Порт назначения 32 Тег проверки 64 Контрольная сумма 96 Тип 1 блока Флаги 1 блока Длина 1 блока 128 Данные 1 блока … … … Тип N блока Флаги N блока Длина N блока … Данные N блока

SCTP пакеты имеют более простую структуру, чем пакеты TCP. Каждый пакет состоит из двух основных разделов:

1. Общий заголовок, который занимает первые 12 байт (выделены синим цветом)
2. Блоки данных, которые занимают оставшуюся часть пакета.

Первый блок отмечен зелёным цветом, и последний из блоков N (N блок) выделен красным.

Каждый блок имеет идентификатор типа, занимающий один байт. Таким образом, возможно определение не более 255 различных типов блоков. RFC 4960 определяет список типов блоков, всего на данный момент определено 15 типов. Остальная часть блока состоит из поля длины размером в 2 байта (максимальная длина, которая может содержаться в данном поле, равна 65535 байтам) и, собственно, данных. Если размер блока не кратен 4 байтам, то он заполняется нулями до размера, кратного 4 байтам.

Обработка ошибок

Повтор передачи

Повторная передача блоков DATA может быть обусловлена (a) тайм-аутом, определяемым таймером повтора (retransmission timer) или (b) получением SACK, показывающих что блок DATA не был получен адресатом. Для снижения вероятности насыщения повтор передачи блоков DATA ограничивается. Значение тайм-аута для повтора (RTO) устанавливается на основе оценки времени кругового обхода и уменьшается экспоненциально с ростом частоты потери сообщений. Для активных ассоциаций с почти постоянным уровнем трафика DATA причиной повтора скорей всего будут сообщения SACK, а не тайм-аут. Для снижения вероятности ненужных повторов используется правило 4 SACK, в соответствии с которым повтор передачи происходит только по четвёртому SACK, указывающему на пропуск блока данных. Это позволяет предотвратить повторы передачи, вызванные нарушением порядка доставки.

Сбой в пути

Поддерживается счётчик для числа повторов передачи по конкретному адресу получателя без подтверждения успешной доставки. Когда значение этого счётчика достигает заданного порога (конфигурационный параметр), адрес объявляется неактивным и протокол SCTP начинает использовать другой адрес для передачи блоков DATA. Кроме того, по всем неиспользуемым (дополнительным) адресам периодически передаются специальные блоки Heartbeat и поддерживается счётчик числа блоков Heartbeat, переданных без возврата соответствующего Heartbeat Ack. Когда значение счётчика достигает заданного порога (параметр конфигурации), соответствующий адрес объявляется неактивным. Блоки Heartbeat передаются по неактивным адресам до тех пор, пока не будет получено сообщение Ack, говорящее о восстановлении активности адреса. Частота передачи блоков Heartbeat определяется значением RTO и дополнительной задержкой, которая позволяет передавать блоки Heartbeat без помех для пользовательского трафика.

Отказ в конечной точке

Для всех адресов получателя поддерживается общий счётчик числа повторов или блоков Heartbeat, передачи данных удалённой точке без получения от неё соответствующего подтверждения (Ack). Когда значение счётчика достигает заданного порога (параметр конфигурации) конечная точка декларируется как недостижимая и ассоциация SCTP закрывается.

Причины появления

Протокол TCP предоставляет основные средства для передачи данных по сети Internet по надёжному пути. Однако TCP накладывает некоторые ограничения на транспорт данных:

• TCP предоставляет надёжную передачу данных в строгой последовательности. Тем не менее одни приложения требуют передачу без управления и контроля последовательности, а другие будут вполне удовлетворены частичной упорядоченностью данных. Оба этих случая страдают из-за ненужных задержек, связанных с восстановлением и упорядочиванием нарушенных последовательностей TCP.
• Природа TCP ориентирована на поток байт, что вызывает неудобства. Приложения вынуждены самостоятельно добавлять собственные маркеры в пакеты, чтобы распараллелить передачу собственных сообщений, а также использовать дополнительные ухищрения, чтобы убедиться в том, что целое сообщение было доставлено за определённое время.
• Ограниченные рамки возможностей TCP-сокетов ещё более усложняют задачу предоставления возможности параллельной передачи информации к хостам по нескольким каналам связи (см. multi-homing выше).
• TCP относительно уязвим для атак класса «Отказ в обслуживании» (DoS), таким как SYN-flood.

Все эти ограничения наносят ущерб производительности работы телефонных сетей через IP.

Протокол был разработан в рамках работы специально-созданной группы SIGTRAN в составе IETF для реализации протоколов и адаптаций стека ОКС-7 для применения в IP-сетях, в связи с необходимостью надёжной и быстрой доставки данных. Это прямо отражено в главе 1.1 Motivation («Побуждение») RFC 4960:

...
Transport of PSTN signaling across the IP network is an application for which all of these limitations of TCP are relevant. While this application directly motivated the development of SCTP, other applications may find SCTP a good match to their requirements...

...Передача сигнализации ТфОП по IP-сети - это применение, для которого все ограничения TCP имеют непосредственное отношение. Хотя это напрямую мотивировало разработку SCTP, другие приложения могут также определить SCTP как хорошо соответствующий их требованиям...

RFC 4960

Схема протоколов и адаптаций SIGTRAN

Протоколы ОКС-7													(TCAP)
										(ISUP)			SCCP			(DSS1)			(TCAP)
SIGTRAN										(M3UA)
Компьютерная сеть	SCTP
	IP

Реализации

Существует референсная реализация под FreeBSD, Mac OS X, Microsoft Windows и Linux.

Протокол SCTP реализован в следующих операционных системах:

• AIX Version 5 и новее
• BSD UNIX (с внешним патчем от ^[англ.])
• Cisco IOS 12 и новее
• DragonFly BSD начиная с версии 1.4, поддержка прекращена в версии 4.2
• FreeBSD начиная с версии 7, референсная реализация
• HP-UX с версии 11i v2 и новее
• Linux версия 2.4 и новее
• QNX Neutrino Realtime OS, в версиях с 6.3.0 по 6.3.2, но с 6.4.0 поддержка прекращена
• Sun Solaris 10 и новее
• VxWorks версии с 6.2.x по 6.4.x, затем с 6.7 и новее

Реализация через сторонние драйверы:

• Windows — драйвер SctpDrv является портированным стеком SCTP из BSD.
• Mac OS X — расширение SCTP Network Kernel Extension.

Отдельные пользовательские библиотеки:

• Portable SCTP userland stack
• The SCTP library
  • Портированная версия библиотеки под Windows XP
• Erlang/OTP

Приложения:

• SSH — Secure Shell.
• (WebRTC)

Примечания

1. TCP и UDP работают столь различно, что проводить аналогию к ним обоим некорректно. Вся аналогия — в том, что SCTP, TCP и UDP относятся к одному и тому же уровню стека TCP/IP.
2.   (неопр.). www.ietf.org. Дата обращения: 16 октября 2018. Архивировано из оригинала 29 октября 2018 года.
3. Reference Implementation for SCTP - RFC4960  (неопр.). — «This is the reference implementation for SCTP. It is portable and runs on FreeBSD/MAC-OS/Windows and in User Space (including linux).» Дата обращения: 14 октября 2013. 1 марта 2017 года.
4. DragonFly Removes SCTP  (неопр.). Lists.dragonflybsd.org. Дата обращения: 28 апреля 2016. 7 августа 2017 года.
5. About FreeBSD's Technological Advances  (неопр.). The FreeBSD Project (9 марта 2008). — «SCTP: FreeBSD 7.0 is the reference implementation for the new IETF Stream Control Transmission Protocol (SCTP) protocol, intended to support VoIP, telecommunications, and other applications with strong reliability and variable quality transmission through features such as multi-path delivery, fail-over, and multi-streaming.» Дата обращения: 13 сентября 2008. 5 августа 2011 года.
6. Stream Control Transmission Protocol (SCTP)  (неопр.). Hewlett-Packard Development Company. Дата обращения: 10 марта 2017. Архивировано из оригинала 3 января 2013 года.
7. TCP/IP Networking  (неопр.). QNX Developer Support. QNX Software Systems. Дата обращения: 13 сентября 2008. 23 октября 2008 года.What's New in this Reference  (неопр.). QNX Library Reference. QNX Software Systems. Дата обращения: 18 декабря 2012. 18 октября 2012 года.
8. Solaris 10 Operating System Networking — Extreme Network Performance  (неопр.). Sun Microsystems. Дата обращения: 13 сентября 2008. 20 апреля 2009 года.
9.   (неопр.). Дата обращения: 4 февраля 2011. Архивировано из оригинала 8 января 2011 года.
10. SCTP Network Kernel Extension for Mac OS X  (неопр.). Дата обращения: 10 марта 2017. 11 июня 2018 года.
11. A portable SCTP userland stack  (неопр.). Дата обращения: 10 марта 2017. 20 декабря 2018 года.
12. SCTP Download Page  (неопр.) (29 мая 2006). Дата обращения: 4 февраля 2011. 22 апреля 2019 года.
13. Windows SCTP library installer  (неопр.). Дата обращения: 4 февраля 2011. 11 сентября 2016 года.
14. Seggelmann, R.; Tuxen, M.; Rathgeb, E.P. SSH over SCTP — Optimizing a multi-channel protocol by adapting it to SCTP (англ.) // Communication Systems, Networks & Digital Signal Processing (CSNDSP), 2012 8th International Symposium on : journal. — 2012. — 18 July. — P. 1—6. — . — doi:10.1109/CSNDSP.2012.6292659.

Ссылки

• RFC 3286
• http://rfc2.ru/3286.rfc от 24 сентября 2010 на Wayback Machine — перевод RFC 3286 на русский язык
• http://www.sctp.de от 24 февраля 2021 на Wayback Machine
• RFC 2960 — Stream Control Transmission Protocol,
• RFC 3257 — Stream Control Transmission Protocol Applicability Statement,
• RFC 3286 — An Introduction to the Stream Control Transmission Protocol (SCTP),
• RFC 3309 — Stream Control Transmission Protocol (SCTP) Checksum Change,
• RFC 3436 — Transport Layer Security over Stream Control Transmission Protocol,
• RFC 3554 — On the Use of Stream Control Transmission Protocol (SCTP) with IPsec,
• RFC 3758 — Stream Control Transmission Protocol (SCTP) Partial Reliability Extension,
• RFC 3873 — Stream Control Transmission Protocol (SCTP) Management Information Base (MIB),
• RFC 4460 — Stream Control Transmission Protocol (SCTP) Specification Errata and Issues,
• RFC 4820 — Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP),
• RFC 4895 — Authenticated Chunks for the Stream Control Transmission Protocol (SCTP),
• RFC 4960 — Stream Control Transmission Protocol,
• RFC 5061 — Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration,
• RFC 5062 — Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures.