RFC 9257 Guidance for External Pre-Shared Key (PSK) Usage in TLS

image_print
Internet Engineering Task Force (IETF)                        R. Housley
Request for Comments: 9257                                Vigil Security
Category: Informational                                       J. Hoyland
ISSN: 2070-1721                                          Cloudflare Ltd.
                                                                M. Sethi
                                                        Aalto University
                                                              C. A. Wood
                                                              Cloudflare
                                                               July 2022

Guidance for External Pre-Shared Key (PSK) Usage in TLS

Рекомендации по применению внешних PSK в TLS

PDF

Аннотация

В этом документе приведены рекомендации по использованию внешних, заранее распределенных ключей (Pre-Shared Key или PSK) в защите транспортного уровня (Transport Layer Security или TLS) версии 1.3, определённой в RFC 8446. Указаны свойства защиты TLS, обеспечиваемые PSK с некоторыми допущениями, и показано, как нарушение этих предположений ведёт к атакам. Даны рекомендации для приложений, помогающие соблюсти эти допущенияю В документе также обсуждаются примеры использования PSK и процессы предоставления, а также указаны свойства защиты и приватности, которые не обеспечиваются TLS 1.3 при использовании внешних PSK.

Статус документа

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Не все одобренные IESG документы являются кандидатами в Internet Standard, см раздел 2 RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9257.

Авторские права

Авторские права (Copyright (c) 2022) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML

1. Введение

В этом документе представлены рекомендации по использованию внешних ключей PSK в TLS 1.3 [RFC8446], применимые также к протоколам Datagram TLS (DTLS) 1.3 [RFC9147] и Compact TLS 1.3 [CTLS]. Для удобочитаемости все они обозначаются в документе как TLS.

Внешние PSK являются симметричными секретными ключами, предоставляемыми реализации протокола TLS извне. Внешние PSK обеспечиваются не через сеть (по внешнему каналу – out of band).

Документ перечисляет защитные свойства TLS, обеспечиваемые PSK при некоторых допущениях, и показывает, как нарушение этих предположений ведёт к атакам. В документе рассматриваются примеры использования PSK, процессы представления и поддержка реализации стека TLS в контексте этих допущений. Документ также предлагает варианты применения, способствующие соблюдению этих допущений.

Имеется много ресурсов с рекомендациями по созданию и проверке паролей в целях повышения защищенности. Однако эквивалентных документов для внешних PSK в TLS нет и здесь этот пробел заполняется.

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Обозначения

В этом документе логическим узлом (logical node) считается вычислительная сущность (computing presence), с которой другие стороны могут взаимодействовать по протоколу TLS. Логический узел может быть реализован в форме нескольких физических экземпляров (объектов) с единым административным управлением, например, серверной фермы. Конечной точкой (endpoint) называется клиент или сервер, участвующий в соединении.

4. Свойства безопасности PSK

Использование заранее созданных PSK позволяет узлам TLS проверить подлинность отождествлений конечных точек, а также обеспечивает другие преимущества, такие как устойчивость к атакам в присутствии квантовых компьютеров (см. параграф 4.2). Однако эти ключи не обеспечивают защиту приватности (конфиденциальности) отождествлений конечных точек и неотказуемость (одна из точек соединения может отвергнуть диалог), как отмечено в разделе 7.

безопасность аутентификации PSK предполагает одно фундаментальное свойство – каждый ключ PSK известен лишь одному клиенту и одному серверу, которые никогда не меняются ролями. Если это нарушается, защитные свойства TLS существенно ухудшаются, как показано ниже.

4.1. Совместное использование PSK

Как обсуждается в параграфе 5.1 для демонстрации атаки, [AASS19] описывает сценарии, где один ключ PSK используется множеством клиентов и множеством серверов. Если по наивности общий ключ предоставлен всем членам группы, TLS проверяет лишь принадлежность к группе и безопасность системы в целом становится достаточно слабой. Здесь имеется ряд указанных ниже недостатков.

  1. Любой член группы может выдать себя за другого члена этой группы.

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

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

Кроме того, не входящий в группу злоумышленник может перенаправить согласование между действительными членами группы для их соединения непредусмотренным способом, как описано ниже. Отметим, что возможно частичное смягчение этого класса атак – каждый член группы включает расширение для индикации имени сервера (Server Name Indication или SNI) [RFC6066] и прерывает соединение при насовпадении представленного SNI с известным идентификатором принимающей стороны. Подробности этого представлены в [Selfie].

Для иллюстрации атак с перенаправлением рассмотрим трёх парнтеров (A, B, C), знающих общий ключ PSK. Атака модет иметь вид, представленный ниже.

  1. A передаёт ClientHello для B.

  2. Атакующий перехватывает сообщение и перенаправляет его C.

  3. C отвечает (ServerHello, …) узлу A.

  4. A передаёт сообщение для B, завершая согласования якабы с B.

  5. Злоумышленник перенаправляет сообщение Finished узлу to C, что завершает его согласование с A.

В этой атаке проверки подлинности партнёра не происходит. Если C поддерживает более слабый набор шифров, чем B, возможны атаки на снижение (ослабление) криптографического алгоритма. Такое перенаправление является атакой с нарушением привязки отождествления [Krawczyk] [Sethi]. Атака Selfie [Selfie] является особым случаем атаки с перенаправлением против члена группы, который может выступать клиентом и сервером TLS. В этой атаке злоумышленник, не входящий в группу, перенаправляет соединение от клиента к серверу на той же конечной точке.

В дополнение к отмеченным недостаткам общий для узлов ключ PSK может негативно влиять на развёртывание. Например, отзыв отдельных элементов группы становится невозможным без создания нового PSK для оставшихся.

4.2. Энтропия PSK

Свойства энтропии внешних PSK также могут влиять на защитные свойства TLS. Например, при использовании PSK с высокой энтропией режимы организации только ключей PSK обеспечивают ожидаемые защитные свойства TLS, включая организацию одного сеансового ключа между партнёрами, секретность сеансовых ключей, проверку подлинности партнёров и защиту от снижения версии. Разъяснение этих свойств дано в приложении E.1 к [RFC8446]. Однако этим режимам не достает полной защиты (forward security), которая может быть достигнута при использовании режима PSK-DH или краткосрочных PSK.

При использовании PSK с малой энтропией режимы организации только ключей PSK подвержены пассивным атакам с исчерпывающим поиском, которые раскрывают ключи трафика. режимы PSK-DH подвержены активным атакам, в которых злоумышленник выдаёт себя за одну сторону. Фаза исчерпывающего поиска в этих атаках может быть организована в автономном режиме (offline) если атакующий перехватывает одно согласование с применением PSK, но такие атаки не ведут к раскрытию ключей трафика для данного соединения, поскольку ключи зависят также от обмена Диффи-Хеллмана (Diffie-Hellman или DH). Ключи с малой энтропией защизены от активных атак, если с TLS применяется обмен ключами с парольной аутентификацией (Password-Authenticated Key Exchange или PAKE). На момент написания этого документа исследовательская группа Crypto Forum (Crypto Forum Research Group илиCFRG) занималась подготовкой спецификации, рекомендуемых PAKE ([CPACE], [OPAQUE]) для симметричных и асимметричных ключей.

5. Внешние PSK на практике

Шифры PSK были впервые заданы для TLS в 2005 г. Сейчас PSK являются частью спецификации TLS 1.3 [RFC8446]. TLS 1.3 также использует PSK для восстановления сессий. Применяемые для восстановления PSK отличаются от внешних PSK, которые представляются по отдельному каналу (out of band0. В этой спецификации описаны известные варианты применения и процессы представляния для внешних PSK в TLS.

5.1. Примеры использования

В этом параграфе даны некоторые варианты применения, где парные внешние ключи PSK (внешние PSK, совместно применяемые одним клиентом и одним сервером) применяются для аутентификации в TLS. Порядок примеров не отражает каких-либо приоритетов.

Взаимодействие между устройствами с синхронизацией ключей по отдельному каналу

PSK предоставляются по отдельному каналу (out of band) для взаимодействия с известными отождествлениями, при этом отождествление раскрывается через другой online-протокол.

Коммуникации внутри ЦОД

Межмашинное взаимодействие в одном центре обработки данных (ЦОД) или точке присутствия (Point of Presence или PoP) может использовать представленные извне PSK. Это применяется в основном для поддержки соединений TLS с упреждающими данными (early data). Соображения об использовании упреждающих данных с внешними PSK представлены в разделе 8.

Межсерверное взаимодействие без сертификатов

При межмашинном взаимодействии могут применяться предоставленные извне PSK. Это служит в основном для организации соединений TLS без издержек на предоставление и поддержку сертификатов PKI.

Интернет вещей (IoT) и устройства с ограниченными вычислительными возможностями

[RFC7925] задаёт профили TLS и DTLS для устройств с ограниченными ресурсами и предлагает применять шифры PSK для совместимых устройств. Спецификация LwM2M (Open Mobile Alliance Lightweight Machine-to-Machine) [LwM2M] указывает, что серверы LwM2M должны поддерживать режим PSK для DTLS.

Защита RADIUS [RFC2865] с помощью TLS

Шифры PSK не обязательны для этого случая, как указано в [RFC6614].

Аутентификация между пользователем и сервером 3GPP

Базовая архитектура аутентификации (Generic Authentication Architecture или GAA), заданная в 3GPP, указывает, что шифры TLS PSK можно применять между сервером и оборудованием пользователя для аутентификации [GAA].

Смарт-карты

Немецкие карты электронной идентификации (German electronic Identity или eID) поддерживают аутентификацию держателя карты в online-службах на основе TLS PSK [SmartCard].

Квантовая устойчивость

В некоторых развёртывания могут применяться PSK (или их комбинация с аутентификацией на основе сертификатов, как описано в [RFC8773]), благодаря предоставляемой защите от квантовых компьютеров.

Имеются также случаи применения PSK, известных более чем двум объектам. Некоторые примеры приведены ниже (отмечены Ахметзяновой и др. В [AASS19]):

Групповые чаты

В этом случае участникам группы могут быть предоставлены внешние PSK по отдельному каналу (out of band) для организации аутентифицированных соединений с другими членами группы.

IoT и устройства с ограниченными вычислительными возможностями

В этом случае возможно много вариантов представления PSK. Например, а данной системе все устройства IoT могут иметь общий ключ PSK и применять его для взаимодействия с центральным сервером (один ключ на n устройств), иметь свои ключи для взаимодействия с центральным сервером (n ключей на n устройств) или иметь парные ключи для вазаимодействия каждого с каждым (n2 ключей на n устройств).

5.2. Примеры представления

Процесс представления зависит от системных требований и модели угроз. По возможности не следует совместно использовать PSK на узлах, однако иногда этого не избежать. В таких случаях следует использовать рекомендации, приведённые в разделе 6. Ниже приведены примеры процессов представления PSK.

  • Многие промышленные протоколы предполагают, что PSK распределяются и назначаются вручную путём (1) прямого ввода PSK в устройство или (2) использования доверенного при первом применении (trust-on-first-use или TOFU) подхода, когда устройство совсем не защищено до первого входа в систему (login). Многие устройства имеют очень ограниченный пользовательский интерфейс (UI). Например, у них может быть лишь цифровая клавиатура или просто несколько кнопок. Когда подход TOFU не подходит, ключ придётся вводить через ограниченный интерфейс UI.

  • Некоторые устройства представляют PSK по особому (out-of-band) протоколу синхронизации на базе облака.

  • Некоторые секреты могут быть встроены в аппаратные или программные компоненты устройства. Если это делается во время производства, секреты могут указываться на этикетке или включаться в спецификацию (Bill of Materials) для упрощения сканирования или импорта.

5.3. Ограничения при представлении

Системы представления PSK часто ограничены в зависимости от применения. Например, хотя одной из целей представления является обеспечение уникальности каждой пары ключей, некоторые системы не хотят распространять парные общие ключи для достижения этого. Другим примером служит требование некоторых систем встраивать в процессе представления зависимую от приложения информацию в PSK или иные отождествления. Для отождествлений иногда может требоваться маршрутизация, что в настоящее время обсуждается [EAP-TLS-PSK].

6. Рекомендации по использованию внешних PSK

  1. При выводе каждого PSK следует обеспечивать хотя бы 128 битов энтропии, ключ должен быть не короче 128 битов и его следует комбинировать с обменом эфемерными ключами, например, с использованием psk_dhe_ke (Pre-Shared Key Exchange Mode) в TLS 1.3 для полной защиты. Как обсуждалось в разделе 4, PSK с низкой энтропией (т. е. выведенные с использованием менее 128 битов энтропии) подвержены атакам и их следует избегать. Если доступны лишь ключи с малой энтропией, следует применять механизмы организации ключей вроде PAKE, которые могут снизить риск offline-атак по словарю. Отметим, что такие механизмы ещё не стандартизованы и не обязательно будут следовать той же архитектуре, что и процесс встраивания внешних ключей PSK, описанный в [RFC9258].

  2. Если не принято иных мер по снижению риска для PSK, известных группе, использование каждого PSK должно ограничиваться не более чем двумя логическими узлами, один из которых играет роль сервера, другой – роль клиента TLS (логические узлы могут совпадать в разных ролях). В [RFC9258] описаны две меры снижения риска: (1) обмен идентификаторами клиента и сервера через соединение TLS после согласования и (2) встраивание идентификаторов клиента и сервера в строку контекста для импортёра внешнего PSK.

  3. Узлам следует импользовать импортёров внешних PSK [RFC9258] при настройке PSK для пары клиент-сервер, когда это возможно. Импортёры упрощают представление внешних PSK и делают их меньше подверженными ошибкам, выводя уникальный импортируемый PSK из внешнего PSK для каждой поддерживаемом узлом функции вывода ключей (см. раздел «Вопросы безопасности» в [RFC9258]).

  4. По возможности основной ключ PSK (передаваемый импортёру) следует удалять после генерации импортируемых ключей. Это не позволит злоумышленнику использовать компрометацию одного узла для атак на соединения между любыми узлами. Иначе атакующий сможет восстановить основной ключ и снова запустить импортёр.

6.1. Интерфейс стека

Большинство основных реализаций TLS поддерживает внешние PSK. Стеки с поддержкой внешних PSK предоставляют интерфейс, который приложения могут использовать при настройке PSK для отдельных соединений. Детали некоторых имеющихся на момент написания документа стеков приведены ниже.

OpenSSL и BoringSSL

Приложения могут указать поддержку внешних PSK через отдельные шифры в TLS 1.2 и ниже. Они также могут настроить обратные вызовы (callback) для выбора PSK при согласовании. Эти вызовы должны обеспечивать ключ и отождествление PSK. Точный формат обратного вызова зависит от согласованной версии протокола TLS, новые функции обратного вызова специально добавлены в OpenSSL для TLS 1.3 [RFC8446] с поддержкой PSK. Размер PSK проверяется на диапазон 1-256 байтов (включительно), отождествление может иметь размер до 128 байтов.

mbedTLS

Клиентские приложения настраивают PSK до создания соединения путём предоставления встроенного отождествления и значения PSK. Серверы должны реализовать обратные вызовы как в OpenSSL. Отождествление и ключ PSK могут иметь размер от 1 до 16 байтов (включительно).

gnuTLS

Приложения настраивают PSK как необработанные (raw) строки байтов или шестнадцатеричные строки. Отождествление и ключ PSK не проверяются.

wolfSSL

Приложения настраивают PSK с обратными вызовами, подобно OpenSSL.

6.1.1. Кодирование и сравнение отождествлений PSK

Параграф 5.1 в [RFC4279] указывает, чтобы отождествление PSK сначала следует преобразовать в строку символов, а затем кодировать в октеты с применением UTF-8. Это делается для предотвращения проблем совместимости (особено при понятных человеку отождествлениях). С другой стороны, [RFC7925] рекомендует реализациям не применять структурированные форматы для отождествлений PSK и выполнять побайтовое сравнение при любых операциях. При ручной настройке отождествлений PSK важно помнить, что визуально идентичные строки могут отличаться кодировкой.

TLS 1.3 [RFC8446] следует той же практике задания отождествлений PSK последовательностью не обрабатываемых байтов (opaque identity<1..216-1> в спецификации), которые сравниваются побайтово. [RFC8446] требует отождествлений PSK не короче 1 1 и не длиннее 65535 байтов. Хотя [RFC8446] не задаёт строгих требований к формату отождествлений, этот формат может быть разным в зависимости от развёртывания, как указано ниже.

  • Отождествление PSK может быть задаваемой пользователем строкой при использовании с такими протоколами как EAP (Extensible Authentication Protocol) [RFC3748]. Например, gnuTLS считает отождествления PSK именами пользователей.

  • Отождествления PSK могут включать суффикс доменного имени для роуминга и объединения. В приложениях и установках, где суффикс домена считается конфиденциальным, такая практика не рекомендуется.

  • При развёртывании следует озаботиться, чтобы размер отождествления позволял предотвратить конфликты.

6.1.2. Конфликты отождествлений PSK

Возможны, хоть и маловероятны, конфликты отождествлений внеших PSK с отождествлениями PSK возобновления. Реализация стека TLS и последовательность обратных вызовов влияют на поведение приложений в случае конфликта. При получении сервером отождествления PSK в TLS 1.3 ClientHello, некоторые стеки TLS выполняют зарегистрированный приложением обратный вызов до проверки кэша возобновления сессий в стеке. Это значит, что при конфликте отождествлений использование внешнего PSK обычно становится предпочтительней восстановления. Поскольку отождествления PSK для восстановления задаёт реализация стека TLS, рекомендуется выделять эти значения так, чтобы можно было отличить PSK возобновления от внешних PSK во избежание конфликтов.

7. Вопросы приватности

Свойства конфиденциальности PSK ортогональны свойствам безопасности, описанным в разделе 4. TLS мало заботится о приватности отождествлений PSK. Например, получает сведения о внешнем PSK или его отождествлении за счёт того, что отождествление открыто передаётся в ClientHello. В результате пассивный противник может связать несколько соединений, использующих один внешний PSK в линии. В зависимости от отождествления PSK пассивный атакующий может также идентифицировать устройство, персону или предприятие, использующее клиент или сервер TLS. Активный злоумышленник может также применить отождествление PSK для помех согласованию или данным приложения от конкретного устройства путём блокировки, задержки или ограничения скорости трафика. Методы снижения таких рисков требуют дополнительного анализа и выходят за рамки документа. Кроме сопоставления устройств в сети внешние PSK по своей природе связаны получателями PSK. В частности, сервер может связывать друг с другом последовательные соединения с одним внешним PSK. Предотвращение этого выходит за рамки документа.

8. Вопросы безопасности

Этот документ посвящён вопросам безопасности. Следует повторить, что имеются опасения, связанные с применением внешних PSK в части подобающей идентификации конечных точек TLS 1.3 и дополнительных рисков при известности внешних PSK группе узлов.

Не рекомендуется применять один ключ PSK более чем на одном клиенте и одном сервере. Однако, как отмечено в параграфе 5.1, имеются приложения, опирающиеся на использование одного PSK множеством узлов. [RFC9258] помогает смягчить перенаправление и отражение в стиле Selfie при использовании одного PSK на множестве узлов. Это достигается корректным применением идентификаторов узлов в конструкции ImportedIdentity.context [RFC9258]. Одним из решений служит выбор каждой конечной точкой одного глобально уникального идентификатора для всех согласования PSK. Таким идентификатором может служить, например, один из MAC-адресов (Media Access Control) точки, 32-битовое случайное значение или UUID (Universally Unique IDentifier) [RFC4122]. Отметим, что такие почтоянные идентификаторы влияют на приватность (см. раздел 7). Каждой конечной точке следует знать идентификатор точки, с которой нужно соединиться и следует сравнивать его с идентификатором из ImportedIdentity.context. Важно помнить, что конечные точки с одним групповым PSK могут представляться друг другом.

Соображения по использованию внешних PSK не ограничиваются верной идентификацией. При использовании упреждающих данных с внешним PSK случайное значение в ClientHello является единственным источником энтропии, способствующим смене ключей между сессиями. В результате при неоднократном применении внешнего PSK источник случайных значений у клиента играет важную роль в защите упреждающих данных.

9. Взаимодействие с IANA

Этот документ не требует действий IANA.

10. Литература

10.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC9258] Benjamin, D. and C. A. Wood, “Importing External Pre-Shared Keys (PSKs) for TLS 1.3”, RFC 9258, DOI 10.17487/RFC9258, July 2022, <https://www.rfc-editor.org/info/rfc9258>.

10.2. Дополнительная литература

[AASS19] Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. Sokolov, “Continuing to reflect on TLS 1.3 with external PSK”, April 2019, <https://eprint.iacr.org/2019/421.pdf>.

[CPACE] Abdalla, M., Haase, B., and J. Hesse, “CPace, a balanced composable PAKE”, Work in Progress, Internet-Draft, draft-irtf-cfrg-cpace-06, 24 July 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-06>.

[CTLS] Rescorla, E., Barnes, R., Tschofenig, H., and B. M. Schwartz, “Compact TLS 1.3”, Work in Progress, Internet-Draft, draft-ietf-tls-ctls-06, 9 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-06>.

[EAP-TLS-PSK] Mattsson, J. P., Sethi, M., Aura, T., and O. Friel, “EAP-TLS with PSK Authentication (EAP-TLS-PSK)”, Work in Progress, Internet-Draft, draft-mattsson-emu-eap-tls-psk-00, 9 March 2020, <https://datatracker.ietf.org/doc/html/draft-mattsson-emu-eap-tls-psk-00>.

[GAA] ETSI, “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; 3G Security; Generic Authentication Architecture (GAA); System description”, version 12.0.0, ETSI TR 133 919, October 2014, <https://www.etsi.org/deliver/etsi_tr/133900_133999/133919/12.00.00_60/tr_133919v120000p.pdf>.

[Krawczyk] Krawczyk, H., “SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols”, DOI 10.1007/978-3-540-45146-4_24, 2003, <https://link.springer.com/content/pdf/10.1007/978-3-540-45146-4_24.pdf>.

[LwM2M] Open Mobile Alliance, “Lightweight Machine to Machine Technical Specification”, version 1.0, February 2017, <http://www.openmobilealliance.org/release/LightweightM2M/V1_0-20170208-A/OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>.

[OPAQUE] Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, “The OPAQUE Asymmetric PAKE Protocol”, Work in Progress, Internet-Draft, draft-irtf-cfrg-opaque-09, 6 July 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque-09>.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., “Extensible Authentication Protocol (EAP)”, RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.

[RFC4122] Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace”, RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.

[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, RFC 4279, DOI 10.17487/RFC4279, December 2005, <https://www.rfc-editor.org/info/rfc4279>.

[RFC6066] Eastlake 3rd, D., “Transport Layer Security (TLS) Extensions: Extension Definitions”, RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.

[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, “Transport Layer Security (TLS) Encryption for RADIUS”, RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/info/rfc6614>.

[RFC7925] Tschofenig, H., Ed. and T. Fossati, “Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things”, RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.

[RFC8773] Housley, R., “TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key”, RFC 8773, DOI 10.17487/RFC8773, March 2020, <https://www.rfc-editor.org/info/rfc8773>.

[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”, RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[Selfie] Drucker, N. and S. Gueron, “Selfie: reflections on TLS 1.3 with PSK”, DOI 10.1007/s00145-021-09387-y, May 2021, <https://eprint.iacr.org/2019/347.pdf>.

[Sethi] Sethi, M., Peltonen, A., and T. Aura, “Misbinding Attacks on Secure Device Pairing and Bootstrapping”, DOI 10.1145/3321705.3329813, May 2019, <https://arxiv.org/pdf/1902.07550>.

[SmartCard] Bundesamt für Sicherheit in der Informationstechnik, “Technical Guideline TR-03112-7 eCard-API-Framework – Protocols”, version 1.1.5, April 2015, <https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03112/TR-03112-api_teil7.pdf?__blob=publicationFile&v=1>.

Благодарности

Этот документ является результатом работы TLS External PSK Design Team, включающей Benjamin Beurdouche, Björn Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel, Russ Housley.

Документ был улучшен, благодаря высококачественным рецензиям Ben Kaduk и John Preuß Mattsson.

Адреса авторов

Russ Housley
Vigil Security, LLC
Email: housley@vigilsec.com
 
Jonathan Hoyland
Cloudflare Ltd.
Email: jonathan.hoyland@gmail.com
 
Mohit Sethi
Aalto University
Email: mohit@iki.fi
 
Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9258 Importing External Pre-Shared Keys (PSKs) for TLS 1.3

image_print
Internet Engineering Task Force (IETF)                       D. Benjamin
Request for Comments: 9258                                  Google, LLC.
Category: Standards Track                                     C. A. Wood
ISSN: 2070-1721                                               Cloudflare
                                                               July 2022

Importing External Pre-Shared Keys (PSKs) for TLS 1.3

Импорт внешних ключей PSK для TLS 1.3

PDF

Аннотация

Этот документ описывает интерфейс для импорта внешних заранее распространённых ключей (Pre-Shared Key или PSK) в TLS 1.3.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9258.

Авторские права

Copyright (c) 2022. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

TLS 1.3 [RFC8446] поддерживает аутентификацию с заранее распределенным ключом (PSK), при этом ключи PSK могут устанавливаться с помощью сеансовых квитанций (ticket) из предшествующих соединений или с помощью специального (out-of-band) механизма. Протокол требует, чтобы каждый ключ PSK использовался лишь с одной хэш-функцией. Это сделано для упрощения анализа протокола. В TLS 1.2 [RFC5246] такого требования нет и PSK может применяться с любым алгоритмом хэширования и псевдослучайной функцией (pseudorandom function или PRF) TLS 1.2. Хотя не известно способа, каким один и тот же внешний PSK может давать связанный вывод в TLS 1.3 и предшествующих версиях, был проведён лишь ограниченный анализ. Приложениям следует предоставлять раздельные PSK для (О)TLS 1.3 и прежних версий. Если это невозможно (например, внешние PSK уже развёрнуты или имеются иные ограничения), повторное использование PSK в разных версиях TLS может давать связанный вывод, который, в свою очередь, ведёт к проблемам безопасности (см. Приложение E.7 к [RFC8446]).

Для смягчения проблем этот документ задаёт интерфейс импортёра PSK. С помощью которого можно импортировать внешние PSK и потом привязать их к конкретной функции вывода ключей (key derivation function или KDF) и хэш-функции для использования в TLS 1.3 [RFC8446] и DTLS 1.3 [RFC9147]. В частности, описывается механизм для импорта PSK, выведенных из внешних PSK путём включения целевой KDF, версии протокола (D)TLS и необязательной строки контекста для обеспечения уникальности. Этот процесс даёт набор PSK-кандидатов, каждый из которых привязан к целевой KDF и протоколу, которые отличаются от применяемых в (D)TLS 1.2 и прежних версий. Это преобразует отдельный PSK и отождествление в набор PSK и отождествлений.

2. Принятые соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Терминология

Ниже приведены определения используемых в документе терминов.

External PSK (EPSK) – внешний PSK

Ключ PSK организованный или предоставленный внешними средствами (out of band), т. е не в соединении TLS, который представляет собой кортеж (Base Key, External Identity, Hash).

Base Key – базовый ключ

Секретное значение EPSK.

External Identity – внешнее отождествление (свидетельство)

Последовательность байтов, служащая для идентификации EPSK.

Target protocol – целевой протокол

Протокол, для которого импортируется PSK.

Target KDF – целевая KDF

Функция KDF, для которой импортируется PSK.

Imported PSK (IPSK) – импортированный PSK

Ключ TLS PSK выведенный из EPSK, необязательной строки контекста, целевого протокола и целевой KDF.

Non-imported PSK – неимпортированный PSK

Ключ EPSK, испольуемый в качестве TLS PSK напрямую (без импорта).

Imported Identity – импортированное отождествление

Последовательность байтов, служащая для идентификации IPSK.

В документе применяется язык представления из раздела 3 в [RFC8446].

4. Обзор

Интерфейс импортёра PSK отражает интерфейс экспортёра TLS (см. [RFC8446]) в том смысле, что он меняет ключ на основе некоторой контекстной информации. В отличие от интерфейса экспортёра, где уникальность вывода достигается за счёт явной метки и строки контекста, определённый здесь интерфейс импортёра принимает внешний ключ PSK и отождествление, «импортируя» их в TLS путём создания набора «производных» PSK и отождествлений, которые уникальны. Каждый из этих выведенных PSK привязывается к целевому протоколу, идентификатору KDF и необязательной строке контекста. Кроме того, полученные ключи изменяются с использованием новой метки вывода для предотвращения конфликтов с неимпортированными PSK. Через этот интерфейс импорт внешних PSK с разными отждествлениями даёт разные ключи привязки PSK (binder).

Использование импортированных ключей не требуется согласовывать, поскольку клиент и сервер не согласуют отождествления, если импорт был некорректен. Конечные точки могут постепенно развёртывать поддержку импортёров PSK, предлагая неимпортированные PSK для TLS версий до TLS 1.3. Неимпортированные и импортированные PSK не эквивалентны, поскольку из отождествления различаются (см. раздел 7).

Конечным точкам, импортирующим внешние ключи, недопустимо применять служащие вводом в процесс импорта ключи для каких-либо иных целей и недопустимо применять выведенные ключи для целей, отличных от TLS PSK. Кроме того, каждый внешний PSK, введенный в процесс импортёра, должен быть связан не более чем с одной хэш-функцией. Это аналогично правилам параграфа 4.2.11 [RFC8446]. Дополнительное обсуждение приведено в разделе 8.

5. Импортёр PSK

В этом разделе описан интерфейс импортёра PSK и лежащий в его основе механизм диверсификации, а также изменение расчёта связующего ключа (binder key).

5.1. Диверсификация внешнего PSK

На входе интерфейс импортёра PSK принимает EPSK с внешним отождествлением (External Identity) external_identity и базовым ключом epsk (определены в разделе 3) вместе с необязательным контекстом. Затем ввод преобразуется в набор PSK и импортированных отождествлений для использования в соединении с целевым протоколом и KDF. В частности, для каждого поддерживаемого целевого протокола target_protocol и KDF target_kdf импортёр создаёт структуру ImportedIdentity, показанную ниже.

   struct {
      opaque external_identity<1...2^16-1>;
      opaque context<0..2^16-1>;
      uint16 target_protocol;
      uint16 target_kdf;
   } ImportedIdentity;

Список значений ImportedIdentity.target_kdf поддерживается IANA, как указано в разделе 10. Внешние PSK недопустимо импортировать для (D)TLS 1.2 и более ранних версий. В разделе 7 обсыждается сосуществование импортированных PSK для TLS 1.3 с неимпортированными PSK более ранних версий при поэтапном развертывании.

Значение ImportedIdentity.context должно включать контекст, используемый для определения EPSK, если тот имеется. Например, ImportedIdentity.context может включать сведения о ролях партнёров или отождествления для смягчения атак с отражением в стиле Selfie (Selfie-style reflection attack) [Selfie] (см. Приложение A). Поскольку EPSK является ключом, выведенным из внешнего протокола или последовательности протоколов, значение ImportedIdentity.context должно включать привязку каналов для производных протоколов [RFC5056]. Детали этой привязки зависят от протокола и выходят за рамки этой спецификации.

Значение ImportedIdentity.target_protocol должно указывать версию протокола (D)TLS, для которой импортируется PSK. Например, TLS 1.3 [RFC8446] использует значение 0x0304, которое применяется также в QUICv1 [QUIC]. Отметим, что это означает зависимость числа PSK, выводимых из EPSK, от числа целевых протоколов.

На основе ImportedIdentity и соответствующего EPSK с базовым ключом epsk, импортированный PSK IPSK с базовым ключом ipskx вычисляется, как показано ниже.

epskx = HKDF-Extract(0, epsk)
ipskx = HKDF-Expand-Label(epskx, "derived psk", Hash(ImportedIdentity), L)

L соответствует размеру вывода KDF ImportedIdentity.target_kdf, как указано в разделе 10. Для основанных на хэшировании KDF, таких как HKDF_SHA256 (0x0001), это будет размер результата хэш-функции, например, 32 октета для SHA256. Ключ IPSK должен иметь размер, подхожящий для поддерживаемых шифров. Внутри HKDF-Expand-Label применяет метку, соответствующую ImportedIdentity.target_protocol (например, “tls13” для TLS 1.3 в соответствии с параграфом 7.1 [RFC8446] или “dtls13” для DTLS 1.3 в соответствии с параграфом Section 5.10 [RFC9147]).

Отождествлением ipskx при передаче в линию служит ImportedIdentity, т. е. преобразованное в последовательную форму содержимое ImportedIdentity выступает как содержимое PskIdentity.identity в расширении PSK. Соответствующим вводом PSK для планирования ключей TLS 1.3 является “ipskx”.

Поскольку максимальный размер расширения PSK составляет 216 – 1 октетов, импортированное отождествление (Imported Identity), превышающее этот размер, может вызывать ошибку декодирования. Поэтому интерфейсу импортёра PSK следует отвергать ImportedIdentity с размером, превышающим это значение.

Хэш-функция, используемая для функции вывода ключей на основе HMAC (HMAC-based Key Derivation Function или HKDF) [RFC5869], связана с EPSK. Это не хэш-функция, связанная с ImportedIdentity.target_kdf. Если EPSK не имеет связанной хэш-функции, следует применять SHA-256 [SHA2]. Диверсификация EPSK с помощью ImportedIdentity.target_kdf гарантирует, что IPSK применяется в качестве входного ключевого материала KDF не более 1 раза, что соответствует требованиям [RFC8446] (см. раздел 8).

Конечным точкам следует генерировать совместимые отождествления ipskx для каждого целевого шифра, который точка поддерживает. Например, импорт ключей для TLS_AES_128_GCM_SHA256 и TLS_AES_256_GCM_SHA384 будет давать два PSK, один для HKDF-SHA256, другой для HKDF-SHA384. При поддержке TLS_AES_128_GCM_SHA256 и TLS_CHACHA20_POLY1305_SHA256, напротив, нужен лишь 1 производный ключ. Каждый шифр однозначно указывает целевую функцию KDF. Будущие спецификации, меняющие способ согласования KDF, должны будут обновить эту спецификацию для разъяснения выбора целевых KDF в процессе импорта.

EPSK можно импортировать до начала соединения, если целевые KDF, протоколы и строки контекста известны заранее. Можно также импортировать EPSK для упреждающего использования данных, если они привязаны к настройкам протокола и конфигурации, которые требуются для упреждающей передачи данных. По минимуму это означает, что вместе с EPSK должны быть предоставлены значение согласования протокола прикладного уровня (Application-Layer Protocol Negotiation или ALPN) [RFC7301], транспортные параметры QUIC (при использовании с QUIC) и другие связанные параметры, согласуемые для упреждающих данных.

5.2. Вывод связующего ключа

Для предотвращения путаницы между импортированными и неимпортированными PSK в импортированных PSK меняется метка вывода связующего ключа PSK. В частности, вычисление стандартного связующего ключа TLS 1.3 PSK выполняется, как показано ниже.

              0
              |
              v
    PSK ->  HKDF-Extract = Early Secret
              |
              +-----> Derive-Secret(., "ext binder" | "res binder", "")
              |                     = binder_key
              V

Импортированные PSK при выводе binder_key используют строку “imp binder” вместо “ext binder” или “res binder” и расчёт связующего ключа имеет вид

              0
              |
              v
    PSK ->  HKDF-Extract = Early Secret
              |
              +-----> Derive-Secret(., "ext binder"
              |                      | "res binder"
              |                      | "imp binder", "")
              |                     = binder_key
              V

Эта новая метка гарантирует, что клиент и сервер будут согласовывать применение внешнего PSK тогда и только тогда, когда (a) обе конечные точки импортируют PSK или (b) ни одна из них не делает этого. Поскольку binder_key является ключом листа, изменение расчёта не влияет на другие ключи.

6. Отмена хэш-функций

Клиент или сервер, желающий отменить хэш-функцию и больше не применять её для TLS 1.3, удаляет соответствующую KDF из числа целевых KDF при импорет ключей. Это не влияет на работу KDF, служащих для вывода импортируемых PSK.

7. Постепенное развёртывание

В системах, где PSK уже подготовлены для применения с TLS 1.2, попытка поэтапного развёртывания механизма импорта приведёт к одновременному использованию уже предоставленных PSK напрямую как TLS 1.2 PSK и как EPSK, что, в свою очередь, означает возможность применения одних KDF и ключа а двух разных контекстах протокола. Это не рекомендуется (см. раздел 8). Однако преимущества применения TLS 1.3 и импортёров PSK могут быть достаточно убедительными для выбора в существующем развёртывании такой несовместимой конфигурации на короткий период развёртывания новых программ (использующих TLS 1.3 и импортёры). Операторам рекомендуется делать этот период как можно короче.

8. Вопросы безопасности

Цель безопасности импортёра PSK можно грубо сформулировать как предотвращение повторного применения PSK в KDF при надлежащей аутентификации конечных точек. При моделировании в качестве вычислительных экстракторов KDF предполагают, что входной ключевой материал (input keying material или IKM) отбирается из некого «источника» распределения вероятности и любые два значения IKM выбирабтся независимо одно от другого [Kraw10]. Это требование независимости от источника предполагает, что одно значение IKM не может применяться в разных KDF.

Аутентификация на базе PSK функционально эквивалентна возобновлению сессии, поскольку соединение применяет имеющийся ключевой материал для аутентификации обеих конечных точек. В соответствии с [BAA15] это является формой композитной аутентификации. Такая аутентификация, грубо говоря, является свойством, состоящим в том, что выполнение нескольких протоколов аутентификации, из которых хотя бы 1 не скомпрометирован, совместно аутентифицирует все протоколы. Поэтому аутентификации с предоставленными извне PSK в идеале следует аутентифицировать как соединение TLS, так и внешний процесс представления. Обычно этот процесс создаёт PSK и соответствующий контекст, где PSK был выведен и где его следует применять. При доступности контекст используется как значение ImportedIdentity.context. Внешний PSK без такого контекста называется безконтекстным (context-free).

Таким образом, с учётом требований независимости от источника и составной аутентификации описанный в документе интерфейс импортёра PSK направлен на достижение указанных ниже целей.

  1. Импорт предоставленных извне PSK в соединение TLS обеспечивает составную аутентификацию соединения и процесса представления.

  2. Безконтекстные PSK обеспечивают аутентификацию лишь в контексте одного соединения.

  3. Импортированные PSK не применяются в качестве IKM для двух разных KDF.

  4. Импортированные PSK не будут конфиликтовать с будущими версиями протокола и функций KDF.

Нет каких-либо известных данных или проблем безопасности, вызываемых процессом расчёта импортируемых PSK из внешниз PSK и обработки имеющихся внешних PSK, применяемых в (D)TLS 1.2 и ниже, как указано в разделе 7. Однако был проведён лишь ограниченный анализ и это является ещё одной причиной, почему приложениям следует предоствалять отдельные PSK для (D)TLS 1.3 и прежних версий даже с интерфейсом импортёра (D)TLS 1.3.

Импортёр PSK не предотвращает создание приложениями отождествлений PSK без импорта, конфликтующих с импортированными отождествлениями PSK.

9. Вопросы приватности

Внешние отождествления PSK обычно имеют статическую структуру, поэтому конечные точки могут применять их для поиска ключевого материала. В некоторых системах и вариантах применения они могут служить для отслеживания.

Отметим, что ImportedIdentity.context является открытым текстом в линии как часть отождествления PSK. Без защиты механизмами вроде TLS Encrypted ClientHello [ECH] приложениям не следует помещать в это поле приватные данные.

10. Взаимодействие с IANA

Агентство IANA создало реестр TLS KDF Identifiers в имеющемся реестре Transport Layer Security (TLS) Parameters. Записи реестра показаны в таблице 1

Таблица 1. Реестр идентификаторов TLS KDF.

 

Значение

Описание KDF

Документ

0x0000

Резерв

RFC 9258

0x0001

HKDF_SHA256

[RFC5869]

0x0002

HKDF_SHA384

[RFC5869]

 

Новые значения для целевых KDF выделяются в соответствии с указанными ниже процедурами:

  • для диапазона 0x0000-0xfeff применяется процедура Specification Required [RFC8126];

  • значения 0xff00-0xffff зарезервированы для приватного использования (Private Use) [RFC8126].

Процедуры регистрации значений в пространстве Specification Required заданы в разделе 17 [RFC8447].

11. Литература

11.1. Нормативные документы

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5056] Williams, N., “On the Use of Channel Bindings to Secure Channels”, RFC 5056, DOI 10.17487/RFC5056, November 2007, <https://www.rfc-editor.org/info/rfc5056>.

[RFC5869] Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)”, RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8447] Salowey, J. and S. Turner, “IANA Registry Updates for TLS and DTLS”, RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”, RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

11.2. Дополнительная литература

[BAA15] Bhargavan, K., Delignat-Lavaud, A., and A. Pironti, “Verified Contributive Channel Bindings for Compound Authentication”, Proceedings 2015 Network and Distributed System Security, DOI 10.14722/ndss.2015.23277, February 2015, <https://doi.org/10.14722/ndss.2015.23277>.

[ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, “TLS Encrypted Client Hello”, Work in Progress, Internet-Draft, draft-ietf-tls-esni-14, 13 February 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14>.

[Kraw10] Krawczyk, H., “Cryptographic Extraction and Key Derivation: The HKDF Scheme”, Proceedings of Crypto 2010, May 2010, <https://eprint.iacr.org/2010/264>.

[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., “QUIC: A UDP-Based Multiplexed and Secure Transport”, RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”, RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[Selfie] Drucker, N. and S. Gueron, “Selfie: reflections on TLS 1.3 with PSK”, DOI 10.1007/s00145-021-09387-y, May 2021, <https://eprint.iacr.org/2019/347.pdf>.

[SHA2] National Institute of Standards and Technology, “Secure Hash Standard (SHS)”, FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://doi.org/10.6028/NIST.FIPS.180-4>.

Приложение A. Атаки Selfie

Атаки Selfie [Selfie] основаны на злоупотреблении интерфейсом PSK, неявно предполагающим, что каждый ключ PSK известен лишь клиенту и серверу. Если несколько клиентов или серверов с разными ролями используют общий ключ PSK, TLS аутентифицирует лишь группу целиком. Узел аутентифицирует своего партнёра из группы независимо от подлинности того. Отметим, что такое возможно и в случае совместного применения PSK двумя узлами без ролей.

Приложения, требующие аутентификации по ролям при использовании общего PSK для всех узлов, могут решить проблему путём передачи сведений о ролях через соединение TLS после согласования или путём включения роли клиента и сервера в строку контекста IPSK. Например, если приложение идентифицирует каждый узел по MAC-адресу (Media Access Control), оно может использовать приведённую ниже строку контекста.

     struct {
       opaque client_mac<0..2^8-1>;
       opaque server_mac<0..2^8-1>;
     } Context;

Если злоумышленник затем переправит сообщение ClientHello, предназначенное одному узлу, на другой узел, включая создателя ClientHello, получатель определит другую строку контекста и согласование не завершится успехом.

Отметим, что в этом варианте по=прежнему применяется один общий ключ PSK для всех узлов поэтому каждый узел должен быть доверенным, чтобы он не взял на себя чужую роль (прикинулся другим узлом).

Благодарности

Авторы признательны Eric Rescorla и Martin Thomson за дискуссии, которые привели к созданию этого документа, а также Christian Huitema за вклад в соображения по приватности внешних PSK. John Preuß Mattsson предоставил сведения по части развёртывания импортёров PSK. Hugo Krawczyk предоставил рекомендации по безопасности. Martin Thomson, Jonathan Hoyland, Scott Hollenbeck, Benjamin Kaduk и другие предоставили рецензии, отклики и предложения по улучшению документа.

Адреса авторов

David Benjamin
Google, LLC.
Email: davidben@google.com
 
Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC, Безопасность | Оставить комментарий

RFC 9254 Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)

image_print
Internet Engineering Task Force (IETF)                 M. Veillette, Ed.
Request for Comments: 9254                       Trilliant Networks Inc.
Category: Standards Track                                 I. Petrov, Ed.
ISSN: 2070-1721                                  Google Switzerland GmbH
                                                                A. Pelov
                                                                  Acklio
                                                              C. Bormann
                                                  Universität Bremen TZI
                                                           M. Richardson
                                                Sandelman Software Works
                                                               July 2022

Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)

Кодирование данных модели YANG в CBOR

PDF

Аннотация

Язык моделирования данных YANG (RFC 7950) служит для моделирования данных конфигурации и состояния, параметров и результатов вызовов удалённых процедур (Remote Procedure Call или RPC) или действий и уведомлений.

Этот документ определяет представление правил YANG в CBOR (Concise Binary Object Representation) (RFC 8949).

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc9254.

Авторские права

Copyright (c) 2022. Авторские права принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML

1. Введение

Спецификация языка моделирования данных YANG 1.1 [RFC7950] определяет представление XML для экземпляров данных, т. е. содержимого хранилищ конфигурации, данных состояния, ввода и вывода RPC и действий, уведомлений о событиях. Дополнительный набор правил кодирования задан в [RFC7951] на основе The JavaScript Object Notation (JSON) Data Interchange Format” [RFC8259].

Целью этого документа является задание набора правил кодирования для краткого представления двоичных объектов (Concise Binary Object Representation или CBOR) [RFC8949], называемого YANG-CBOR. Задаваемое кодирование компактней XML и JSON и более подходит для узлов и/или сетей с ограничениями, описанных в [RFC7228].

2. Терминология и нотация

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Значения SID (и рассчитанные по ним детали SID) показаны в примерах лишь для иллюстрации.

Ниже перечислены термины, определённые в [RFC7950].

  • action – действие;

  • anydata – любые данные;

  • anyxml – любые данные XML;

  • data node – узел данных;

  • data tree – дерево данных;

  • datastore – хранилище данных;

  • feature – функция, возможность;

  • identity – отождествление

  • module – модуль;

  • notification – уведомление;

  • RPC – удаленный вызов процедуры;

  • schema node – узел схемы;

  • submodule – субмодуль.

В [RFC8040] определён термин

  • yang-data extension – расширение yang-data.

В [RFC8791] определён термин

  • YANG data structure – структура данных YANG.

Эта спецификация использует также определённые ниже термины.

YANG Schema Item iDentifier (YANG SID или SID) – идентификатор элемента схемы YANG

63-битовое целое число без знака, служащее для идентификации элемента YANG.

delta – приращение

Разница между текущим и эталонным значением YANG SID. Эталон YANG SID определён в каждом контексте, где применяется приращение.

absolute SID – абсолютный SID

Значение YANG SID, не представляемое приращением. Обычно идентификатор называется явно только в позиции, где обычно можно найти приращение.

representation tree – дерево представления

Дерево данных YANG, возможно заключённое в узел схемы, такое как структура данных YANG, уведомление, RPC, действие.

representation node – узел представления

Узел в дереве представления, т. е. узел дерева данных, или представление узла схемы, такое как структура данных YANG, уведомление, RPC, действие.

item – элемент

Узел схемы, отождествление, модуль или свойство, определённые с использованием языка моделирования YANG.

list entry – запись списка

данные, связанные с одной записью в списке (см. параграф 7.8 в [RFC7950]).

container-like instance – контейнероподобный экземпляр

Экземпляр контейнера, структура данных YANG, содержимое уведомления, ввод или вывод RPC или действия (параграф 4.2), запись в списке (параграф 4.4), узел anydata (параграф 4.5).

parent (of a representation node) – родитель узла представления

Узел схемы ближайшего охватывающего узла представления, в котором определён данный узел представления.

3. Свойства кодирования CBOR

Этот документ задаёт правила кодирования CBOR для деревьев данных YANG и их субдеревьев.

Дерево данных YANG может помещаться в представление узла схемы, такое как структура данных YANG, уведомление, RPC или действие, это называется деревом представления. Узлы дерева данных и представление узла схемы, включающего дерево, совместно называют узлами представления (representation node).

Узел представления, такой как контейнер, записи списка, структура данных YANG, уведомление, ввод или вывод RPC или действия, узел anydata, сериализуется с использованием отображения CBOR, где каждый определённый узел схемы кодируется ключом и значением. Эта спецификация поддерживает два типа ключей CBOR – идентификаторы YANG SID (YANG Schema Item iDentifier), определённые в параграфе 3.2, и имена, как указано в параграфе 3.3. Каждый из этих типов ключей кодируется с применением конкретного типа CBOR, что позволяет интерпретировать их в процессе десериализации. Протоколы и механизмы, реализующие эту спецификацию, могут предписывать применение определённого типа ключей или разрешать генератору свободный выбор для каждого ключа.

Для минимизации размера закодированных данных отображение избегает всей необязательной метаинформации, сверх представленной напрямую базовой моделью данных CBOR (раздел 2 в [RFC8949]). Например, теги CBOR применяются лишь для абсолютных SID, узлов данных anyxml и типа данных union, чтобы явно различать типы данных YANG, закодированные с использованием одного базового типа CBOR.

Если иное явно не указано в протоколе или механизме, реализующем эту спецификацию, нужно поддерживать в декодерах CBOR, реализующих YANG-CBOR, кодирование неопределённого размера, определённое в параграфе 3.2 [RFC8949]. Это позволяет реализации начинать выдачу массива или отображения до того, как станет известно точное число элементов, а также, возможно, предотвратить неоправданные блокировки и конкуренцию. С другой стороны, это лишает получателя кодированных данных возможности заранее аносировать сведения о размере, когда эти преимущества действительно возникают.

Узлы данных, реализованные с применением массивов, отображения, строк байтов или текста CBOR, могут создаваться пустыми. В этом случае они кодируются с нулевым размером.

При сериализации узлов представления по заданным этой спецификацией правилам как части данных (payload) приложения в эти данные следует включать сведения об узлах, позволяющие идентифицировать узлы без хранения состояний, например, связанный с узлом номер SID, приращение SID от другого SID в данных приложения, имя с указанием пространства имён, идентификатор экземпляра.

Примеры в разделе 4 включают корневое отображение CBOR с одной записью, имеющей в качестве ключа имя с указанием пространства имён или SID. Эти корневые отображения CBOR представлены лишь в качестве примеров использования и не являются частью правил кодирования. Обязательным является лишь значение в этом отображении CBOR.

3.1. Диагностическая нотация CBOR

В этом документе двоичное содержимое CBOR представляется с использованием эквивалентной текстовой формы, называемой диагностической нотацией CBOR, как определено в разделе 8 [RFC8949]. Эта нотация служит лишь для документации и не применяется при сериализации данных. Сводка нотации представлена в таблице 1.

Таблица 1. Сводка диагностической нотации CBOR.

Содержимое CBOR

Тип CBOR

Диагностическая нотация

Пример

Код CBOR

Целое число без знака

0

Десятичные цифры

123

18 7B

Отрицательное целое число

1

Десятичные цифры со знаком минус (-)

-123

38 7A

Строка байтов

2

Шестнадцатеричное значение в одинарных кавычках или с префиксом h

h’F15C’

42 F15C

Строка текста

3

Строка символов Unicode в двойных кавычках

“txt”

63 747874

Массив

4

Список значений через запятую, заключённых в квадратные скобки

[ 1, 2 ]

82 01 02

Отображение

5

Список пар ключ-значение через запятую, заключённых в фигурные скобки

{ 1: 123, 2: 456 }

A2 01187B 021901C8

Логическое значение

7/20
7/21

false
true

false
true

F4
F5

Null

7/22

null

null

F6

Не выделено

7/23

undefined

undefined

F7

Примечание. Двоичное содержимое CBOR в этой спецификации сопровождается комментариями, обозначенными символами /, как указано в Приложении G.6 [RFC8610].

3.2. Идентификатор элемента схемы YANG

Некоторые из элементов YANG [RFC7950] требуют применения уникального идентификатора. В протоколах настройки конфигурации сети (Network Configuration Protocol или NETCONF) [RFC6241] и RESTCONF [RFC8040] такими идентификаторами служат строки текста. Для обеспечения реализации моделей данных, определённых в YANG, устроствами или сетями с ограничениями нужен более компактный метод идентификации элементов YANG. Такой компактный идентификатор называется идентификатором элемента схемы YANG (YANG Schema Item iDentifier) и является 63-битовым целым числом без знака (0..9223372036854775807 или 0..0x7fffffffffffffff). Ниже указаны элементы, идентифицируемые с помощью YANG SID (или просто SID).

  • Отождествления;

  • узлы данных,

  • RPC и связанные с ними ввод и вывод;

  • действия и связанные с ними ввод и вывод;

  • структуры данных YANG;

  • уведомления и связанная с ними информация;

  • модули и функции (feature) YANG.

Отметим, что любое структурирование модулей по субмодулям не заметно для YANG-CBOR, SID не выделяются для имён субмодулей и любые элементы внутри субмодуля фактически получают SID при обработке содержащего их модуля.

Для минимизации размера SID, применяемые как ключи в отображениях CBOR кодируются с использованием приращения целыми числами со знаком, которые складываются с эталонным SID для отображения. Эталонный SID внешнего отображения имеет значение 0, если другой эталонный SID не задан однозначно из среды, где применяется внешнее отображение. Эталонный SID отображения, напрямую встроенного в запись отображения с ключом на основе имени имеет значение 0. Для прочих отображений эталонным SID является значение, рассчитанное для записи отображения, в которую оно встроено напрямую (встраивание может быть опосредованным, если применяется массив, например, в списке YANG). Там, где желательны абсолютные SID (целое число предполагает приращение), они должны указываться абсолютными значениями SID с использованием тега CBOR 47 (как указано в параграфе 4.2.1).

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

Механизмы и процессы назначения SID элементам YANG и обеспечения их уникальности выходят за рамки этой спецификации. Если нужно применять SID, эта спецификация используется вместе со спецификацией, определяющей управление идентификаторами. Связанный документ [CORE-SID] предназначен для указания способа назначения SID для модулей YANG, поддерживаемых IETF, и рекомендуется для остальных модулей YANG. Данная спецификация разработана для поддержки разных методов назначения в отдельных доменах (областях).

Для предоставления реализациям способа внутренней индикации отсутствия SID значение SID = 0 зарезервировано и не будет выделяться. Оно не применяется при обмене.

3.3. Имя

Эта спецификация поддерживает также представление идентификаторов элементов YANG строками текста, подобно принятому в JSON кодированию данных моделей [RFC7951]. Такой подход может избавить от издержек, связанных с выделением SID. Основным недостатком этого подхода является рост размера закодированих данных.

Идентификаторы элементов YANG по именам должны иметь одну из двух форма:

  • простой (simple) идентификатор элемента YANG (узла схемы или отождествления);

  • заданный с пространством имён (namespace-qualified) идентификатор элемента YANG с префиксом в виде имени модуля, где определён элемент, отделённым двоеточием (:).

Имя модуля задаёт пространство имён для всех элементов YANG, определённых в этом модуле. Если элемент задан в субмодуле, полное имя (с пространством имён) использует имя основного модуля, к которому относится субмодуль.

Синтаксис ABNF [RFC5234] для имени показан на рисунке 1, а создание identifier определено в разделе 14 [RFC7950].

   name = [identifier ":"] identifier

Рисунок 1. Вывод ABNF для простого имени или имени с пространством имён.


Полное (namespace-qualified) имя должно применяться для всех элементов верхнего уровня в отображении CBOR, а также во всех случаях, когда пространства имён узла представления и его родителя различаются. В остальных случаях должны использоваться простые имена.

Пример определения

   module example-foomod {
     container top {
       leaf foo {
         type uint8;
       }
     }
   }

   module example-barmod {
     import example-foomod {
       prefix "foomod";
     }
     augment "/foomod:top" {
       leaf bar {
         type boolean;
       }
     }
   }

Действительное кодирование CBOR для контейнера top показано ниже.

Диагностическая нотация CBOR

   {
     "example-foomod:top": {
       "foo": 54,
       "example-barmod:bar": true
     }
   }

Контейнер top и лист bar, определенные в другом модуле YANG как в родительском контейнере, кодируются с полными именами. Лист foo определён в том же модуле YANG, что и его родительский контейнер, кодируется простым именем.

4. Кодирование узлов представления

Узлы представления, определённые с использованием языка моделирования YANG, кодируются с применением CBOR [RFC8949] по правилам, заданным в этом разделе. Предполагается, что читатель знаком с YANG [RFC7950] и CBOR [RFC8949].

4.1. leaf

Кодирование leaf должно выполняться в соответствии с типом данных листа на основе одного из правил раздела 6.

Приведённые ниже примеры, взятые из [RFC6991] и [RFC7317], демонстрируют кодирование листа hostname с применением SID или имени.

   typedef domain-name {
     type string {
       pattern
         '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
       + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
       + '|\.';
       length "1..253";
     }
   }

   leaf hostname {
     type inet:domain-name;
   }

4.1.1. Использование SID

Как и в последующих примера приращение во внешнем отображении предполагает нулевое значение YANG SID (текущий узел схемы).

Диагностическая нотация CBOR

   {
     1752 : "myhost.example.com"     / hostname (SID 1752) /
   }

Представление CBOR

   A1                                         # map(1)
      19 06D8                                 # unsigned(1752)
      72                                      # text(18)
         6D79686F73742E6578616D706C652E636F6D # "myhost.example.com"

4.1.2. Использование имени

Диагностическая нотация CBOR

   {
     "ietf-system:hostname" : "myhost.example.com"
   }

Представление CBOR

   A1                                         # map(1)
      74                                      # text(20)
         696574662D73797374656D3A686F73746E616D65
      72                                      # text(18)
         6D79686F73742E6578616D706C652E636F6D

4.2. Контейнеры и другие узлы из дерева данных

Экземпляры контейнеров, структур данных YANG, содержимого уведомлений, ввода и вывода RPC и действий должны кодироваться с использованием элемента данных отображения CBOR (базовый тип 5). такое же кодирование применяется для элементов списка (параграф 4.4) и узлов anydata (параграф 4.5). Совместно их называют контейнероподобными экземплярами (container-like instances).

Отображение состоит из пар элементов ключ-значение. Каждому ключу с отображении CBOR назначается идентификатор узла схемы, а значению – значение узла представления в соответствии с типом данных экземпляра.

Эта спецификация поддерживает два типа ключей для отображений CBOR – SID (параграф 3.2) и имя (параграф 3.3).

В приведённых ниже применах, взятых из из [RFC6991] и [RFC7317], показано кодирование представления экземпляра контейнера system-state с использованием SID и имени.

   typedef date-and-time {
     type string {
       pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
             + '(Z|[\+\-]\d{2}:\d{2})';
     }
   }

   container system-state {
     container clock {
       leaf current-datetime {
         type date-and-time;
       }

       leaf boot-datetime {
         type date-and-time;
       }
     }
   }

4.2.1. Использование SID

В контексте контейнеров и других узлов дерева данных ключи отображений CBOR во внутренних отображениях можно кодировать с помощью приращений (целое число) или абсоютных SID (с тегом 47). Расчёт приращений показан ниже.

  • Для container приращение равно SID текущего узла представления за вычетом SID родительского контейнера.

  • Для list приращения равно SID текущего узла представления за вычетом SID родительского списка.

  • Для RPC input и RPC output приращения равны SID текущего узла представления за вычетом SID RPC.

  • Для action input и action output приращения равны SID текущего узла представления за вычетом SID action.

  • Для содержимого уведомления приращение равно SID текущего узла представления минус SID notification.

Диагностическая нотация CBOR

   {
     1720 : {                              / system-state (SID 1720) /
       1 : {                               / clock  (SID 1721) /
         2 : "2015-10-02T14:47:24Z-05:00", / current-datetime(SID 1723)/
         1 : "2015-09-15T09:12:58Z-05:00"  / boot-datetime (SID 1722) /
       }
     }
   }

Представление CBOR

   A1                                      # map(1)
      19 06B8                              # unsigned(1720)
      A1                                   # map(1)
         01                                # unsigned(1)
         A2                                # map(2)
            02                             # unsigned(2)
            78 1A                          # text(26)
               323031352D31302D30325431343A34373A32345A2D30353A3030
            01                             # unsigned(1)
            78 1A                          # text(26)
               323031352D30392D31355430393A31323A35385A2D30353A3030

Рисунок 2. Кодирование System State Clock.


4.2.2. Использование имени

Ключи отображений CBOR на основе имён должны кодироваться с использованием тектовых строк CBOR (базовый тип 3). Должны применяться полные (namespace-qualified) имена, если пространства имён узла представления и его родителя различаются. В остальных случаях должны применяться простые имена. Имена и пространства имён определены в разделе 4 [RFC7951].

Ниже приведён пример кодирования экземпляра узла представления контейнера system с использованием имени.

Диагностическая нотация CBOR

   {
     "ietf-system:system-state" : {
       "clock" : {
         "current-datetime" : "2015-10-02T14:47:24Z-05:00",
         "boot-datetime" : "2015-09-15T09:12:58Z-05:00"
       }
     }
   }

Представление CBOR

   A1                                      # map(1)
      78 18                                # text(24)
         696574662D73797374656D3A73797374656D2D7374617465
      A1                                   # map(1)
         65                                # text(5)
            636C6F636B                     # "clock"
         A2                                # map(2)
            70                             # text(16)
               63757272656E742D6461746574696D65
            78 1A                          # text(26)
               323031352D31302D30325431343A34373A32345A2D30353A3030
            6D                             # text(13)
               626F6F742D6461746574696D65
            78 1A                          # text(26)
               323031352D30392D31355430393A31323A35385A2D30353A3030

4.3. leaf-list

Для кодирования leaf-list должен использоваться элемент данных массива CBOR (базовый тип 4). Каждая запись массива должна кодироваться с использованием одного из правил, заданных в разделе 6.

Приведённые ниже примеры из [RFC6991] и [RFC7317] показывают кодирование экземпляра представления листа-списка search с записями ietf.org и ieee.org.

   typedef domain-name {
     type string {
       pattern
         '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
       + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
       + '|\.';
       length "1..253";
     }
   }

   leaf-list search {
     type domain-name;
     ordered-by user;
   }

4.3.1. Использование SID

Диагностическая нотация CBOR

   {
     1746 : [ "ietf.org", "ieee.org" ]     / search (SID 1746) /
   }

Представление CBOR

   A1                        # map(1)
      19 06D2                # unsigned(1746)
      82                     # array(2)
         68                  # text(8)
            696574662E6F7267 # "ietf.org"
         68                  # text(8)
            696565652E6F7267 # "ieee.org"

4.3.2. Использование имени

Диагностическая нотация CBOR

   {
     "ietf-system:search" : [ "ietf.org", "ieee.org" ]
   }

Представление CBOR

   A1                                         # map(1)
      72                                      # text(18)
         696574662D73797374656D3A736561726368 # "ietf-system:search"
      82                                      # array(2)
         68                                   # text(8)
            696574662E6F7267                  # "ietf.org"
         68                                   # text(8)
            696565652E6F7267                  # "ieee.org"

4.4. Списки и записи списков

Список или часть списка должны кодироваться с использованием элемента данных массива CBOR (базовый тип 4). Каждая запись списка в массиве CBOR кодируется с использованием элемента данных отображения CBOR (базовый тип 5) по правилам кодирования контейнероподобных экземляров, приведённым в параграфе 4.2.

Важно отметить, что это правило кодирования применимо и к экземплярам узла представления list с 1 элементом.

Пример определения из [RFC7317] показывает кодирование списка server с использованием SID и имени.

   list server {
     key name;

     leaf name {
       type string;
     }
     choice transport {
       case udp {
         container udp {
           leaf address {
             type host;
             mandatory true;
           }
           leaf port {
             type port-number;
           }
         }
       }
     }
     leaf association-type {
       type enumeration {
         enum server;
         enum peer;
         enum pool;
       }
       default server;
     }
     leaf iburst {
       type boolean;
       default false;
     }
     leaf prefer {
       type boolean;
       default false;
     }
   }

4.4.1. Использование SID

Правила кодирования для каждой записи list приведены в параграфе 4.2.1.

Диагностическая нотация CBOR

   {
     1756 : [                      / server (SID 1756) /
       {
         3 : "NRC TIC server",     / name (SID 1759) /
         5 : {                     / udp (SID 1761) /
           1 : "tic.nrc.ca",       / address (SID 1762) /
           2 : 123                 / port (SID 1763) /
         },
         1 : 0,                    / association-type (SID 1757) /
         2 : false,                / iburst (SID 1758) /
         4 : true                  / prefer (SID 1760) /
       },
       {
         3 : "NRC TAC server",     / name (SID 1759) /
         5 : {                     / udp (SID 1761) /
           1 : "tac.nrc.ca"        / address (SID 1762) /
         }
       }
     ]
   }

Представление CBOR

   A1                                      # map(1)
      19 06DC                              # unsigned(1756)
      82                                   # array(2)
         A5                                # map(5)
            03                             # unsigned(3)
            6E                             # text(14)
               4E52432054494320736572766572 # "NRC TIC server"
            05                             # unsigned(5)
            A2                             # map(2)
               01                          # unsigned(1)
               6A                          # text(10)
                  7469632E6E72632E6361     # "tic.nrc.ca"
               02                          # unsigned(2)
               18 7B                       # unsigned(123)
            01                             # unsigned(1)
            00                             # unsigned(0)
            02                             # unsigned(2)
            F4                             # primitive(20)
            04                             # unsigned(4)
            F5                             # primitive(21)
         A2                                # map(2)
            03                             # unsigned(3)
            6E                             # text(14)
               4E52432054414320736572766572 # "NRC TAC server"
            05                             # unsigned(5)
            A1                             # map(1)
               01                          # unsigned(1)
               6A                          # text(10)
                  7461632E6E72632E6361     # "tac.nrc.ca"

4.4.2. Использование имени

Правила кодирования для каждой записи list приведены в параграфе 4.2.2.

Диагностическая нотация CBOR

   {
     "ietf-system:server" : [
       {
         "name" : "NRC TIC server",
         "udp" : {
           "address" : "tic.nrc.ca",
           "port" : 123
         },
         "association-type" : 0,
         "iburst" : false,
         "prefer" : true
       },
       {
         "name" : "NRC TAC server",
         "udp" : {
           "address" : "tac.nrc.ca"
         }
       }
     ]
   }

Представление CBOR

   A1                                      # map(1)
      72                                   # text(18)
         696574662D73797374656D3A736572766572
      82                                   # array(2)
         A5                                # map(5)
            64                             # text(4)
               6E616D65                    # "name"
            6E                             # text(14)
               4E52432054494320736572766572
            63                             # text(3)
               756470                      # "udp"
            A2                             # map(2)
               67                          # text(7)
                  61646472657373           # "address"
               6A                          # text(10)
                  7469632E6E72632E6361     # "tic.nrc.ca"
               64                          # text(4)
                  706F7274                 # "port"
               18 7B                       # unsigned(123)
            70                             # text(16)
               6173736F63696174696F6E2D74797065
            00                             # unsigned(0)
            66                             # text(6)
               696275727374                # "iburst"
            F4                             # primitive(20)
            66                             # text(6)
               707265666572                # "prefer"
            F5                             # primitive(21)
         A2                                # map(2)
            64                             # text(4)
               6E616D65                    # "name"
            6E                             # text(14)
               4E52432054414320736572766572
            63                             # text(3)
               756470                      # "udp"
            A1                             # map(1)
               67                          # text(7)
                  61646472657373           # "address"
               6A                          # text(10)
                  7461632E6E72632E6361     # "tac.nrc.ca"

4.5. anydata

Узлы anydata служат контейнерами для произвольных наборов узлов представления, которые иначе появлялись бы как обычные данные модели YANG. Экземпляр узла представления anydata кодируется с использованием правил, применяемых для контейнеров, т. е. с применением элементов данных отображения CBOR (базовый тип 5) по правилам кодирования контейнероподобных экземпляров, указанным в параграфе 4.2.

Ниже приведён пример, показывающий возможное использование узла anydata. Здесь узел anydata служит для определения узла представления, содержащего уведомление, этот узел может быть частью списка YANG для записи событий.

   module event-log {
     ...
     anydata last-event;                // SID 60123
   }

В этом примере предполагается участие приведённого ниже уведомления.

   module example-port {
     ...

     notification example-port-fault {  // SID 60200
       leaf port-name {                 // SID 60201
         type string;
       }
       leaf port-fault {                // SID 60202
         type string;
       }
     }
   }

4.5.1. Использование SID

Диагностическая нотация CBOR

   {
     60123 : {                   / last-event (SID 60123) /
       77 : {                    / example-port-fault (SID 60200) /
         1 : "0/4/21",           / port-name (SID 60201) /
         2 : "Open pin 2"        / port-fault (SID 60202) /
       }
     }
   }

Представление CBOR

   A1                               # map(1)
      19 EADB                       # unsigned(60123)
      A1                            # map(1)
         18 4D                      # unsigned(77)
         A2                         # map(2)
            01                      # unsigned(1)
            66                      # text(6)
               302F342F3231         # "0/4/21"
            02                      # unsigned(2)
            6A                      # text(10)
               4F70656E2070696E2032 # "Open pin 2"

В некоторых реализациях может быть проще использовать кодирование абсолютных SID (тег 47) для корневого элемента anydata.

Диагностическая нотация CBOR

   {
     60123 : {                   / last-event (SID 60123) /
       47(60200) : {             / event-port-fault (SID 60200) /
         1 : "0/4/21",           / port-name (SID 60201) /
         2 : "Open pin 2"        / port-fault (SID 60202) /
       }
     }
   }

4.5.2. Использование имени

Диагностическая нотация CBOR

   {
     "event-log:last-event" : {
       "example-port:example-port-fault" : {
         "port-name" : "0/4/21",
         "port-fault" : "Open pin 2"
       }
     }
   }

Представление CBOR

   A1                                      # map(1)
      74                                   # text(20)
         6576656E742D6C6F673A6C6173742D6576656E74
      A1                                   # map(1)
         78 1F                             # text(31)
            6578616D706C652D706F72743A
            6578616D706C652D706F72742D6661756C74
         A2                                # map(2)
            69                             # text(9)
               706F72742D6E616D65          # "port-name"
            66                             # text(6)
               302F342F3231                # "0/4/21"
            6A                             # text(10)
               706F72742D6661756C74        # "port-fault"
            6A                             # text(10)
               4F70656E2070696E2032        # "Open pin 2"

4.6. anyxml

Узлы представления anyxml служат для сериализации произвольного содержимого CBOR, т. е. значением может быть любой двоичный объект CBOR (xml в названии не вполне корректно, поскольку применяется лишь к YANG-XML [RFC7950]). Значение anyxml может содержать элементы данных CBOR, помеченные одним из тегов, указанных в параграфе 9.3. Эти теги нужно поддерживать.

В приведённых ниже примерах из [RFC7951] показан действительный экземпляр узла представления anyxml с кодированием CBOR, содержащий массив CBOR с простыми значениями CBOR true, null, true.

   module bar-module {
     ...
     anyxml bar;      // SID 60000
   }

4.6.1. Использование SID

Диагностическая нотация CBOR

   {
     60000 : [true, null, true]   / bar (SID 60000) /
   }

Представление CBOR

   A1         # map(1)
      19 EA60 # unsigned(60000)
      83      # array(3)
         F5   # primitive(21)
         F6   # primitive(22)
         F5   # primitive(21)

4.6.2. Использование имени

Диагностическая нотация CBOR

   {
     "bar-module:bar" : [true, null, true]   / bar (SID 60000) /
   }

Представление CBOR

   A1                                 # map(1)
      6E                              # text(14)
         6261722D6D6F64756C653A626172 # "bar-module:bar"
      83                              # array(3)
         F5                           # primitive(21)
         F6                           # primitive(22)
         F5                           # primitive(21)

5. Кодирование расширения yang-data

Расширение yang-data [RFC8040] служит для определения в YANG структур данных, не предназначенных для реализации как части хранилища. Расширение yang-data будет задавать контейнер, который должен кодироваться по правилам для узлов дерева данных, указанным в параграфе 4.2. Как и контейнеры YANG, расширение yang-data можно кодировать с использованием SID или имени.

Пример определения из Приложения A к [CORE-COMI]

   module ietf-coreconf {
     ...

     import ietf-restconf {
       prefix rc;
     }

     rc:yang-data yang-errors {
       container error {
         leaf error-tag {
           type identityref {
             base error-tag;
           }
         }
         leaf error-app-tag {
           type identityref {
             base error-app-tag;
           }
         }
         leaf error-data-node {
           type instance-identifier;
         }
         leaf error-message {
           type string;
         }
       }
     }
   }

5.1. Использование SID

Расширения yang-data, закодированные с использованием SID, передаются в отображении CBOR с одной парой элементов. Для ключа устанавливается значение SID, выделенное контейнеру расширения yang-data, а в значение помещается CBOR-кодирование этого контейнера, как задано в параграфе 4.2.

Приведённый ниже пример сериализации экземпляра yang-errors расширения yang-data, как определено в [CORE-COMI], с использованием SID в соответствии с параграфом 3.2.

Диагностическая нотация CBOR

   {
     1024 : {                      / error  (SID 1024) /
       4 : 1011,                   / error-tag (SID 1028) /
                                   / = invalid-value (SID 1011) /
       1 : 1018,                   / error-app-tag (SID 1025) /
                                   / = not-in-range (SID 1018) /
       2 : 1740,                   / error-data-node (SID 1026) /
                                   / = timezone-utc-offset (SID 1740) /
       3 : "Maximum exceeded"      / error-message (SID 1027) /
     }
   }

Представление CBOR

   A1                                      # map(1)
      19 0400                              # unsigned(1024)
      A4                                   # map(4)
         04                                # unsigned(4)
         19 03F3                           # unsigned(1011)
         01                                # unsigned(1)
         19 03FA                           # unsigned(1018)
         02                                # unsigned(2)
         19 06CC                           # unsigned(1740)
         03                                # unsigned(3)
         70                                # text(16)
            4D6178696D756D206578636565646564 # "Maximum exceeded"

5.2. Использование имени

Расширение yang-data закодированное с использованием имени передаётся в отображении CBOR с одной парой элементов. Для ключа устанавливается полное (namespace-qualified) имя контейнера расширения yang-data, а значением служит CBOR-кодирование этого контейнера, как указано в параграфе 4.2.

Ниже приведён пример сериализации экземпляра yang-errors расширения yang-data, определённого в [CORE-COMI], с использованием имени, как указано в параграфе 3.3.

Диагностическая нотация CBOR

   {
     "ietf-coreconf:error" : {
       "error-tag" : "invalid-value",
       "error-app-tag" : "not-in-range",
       "error-data-node" : "timezone-utc-offset",
       "error-message" : "Maximum exceeded"
     }
   }

Представление CBOR

   A1                                           # map(1)
      73                                        # text(19)
         696574662D636F7265636F6E663A6572726F72 # "ietf-coreconf:error"
      A4                                        # map(4)
         69                                     # text(9)
            6572726F722D746167                  # "error-tag"
         6D                                     # text(13)
            696E76616C69642D76616C7565          # "invalid-value"
         6D                                     # text(13)
            6572726F722D6170702D746167          # "error-app-tag"
         6C                                     # text(12)
            6E6F742D696E2D72616E6765            # "not-in-range"
         6F                                     # text(15)
            6572726F722D646174612D6E6F6465      # "error-data-node"
         73                                     # text(19)
            74696D657A6F6E652D7574632D6F6666736574
                                                # "timezone-utc-offset"
         6D                                     # text(13)
            6572726F722D6D657373616765          # "error-message"
         70                                     # text(16)
            4D6178696D756D206578636565646564    # "Maximum exceeded"

6. Представление типов данных YANG в CBOR

Кодирование CBOR для экземпляра узла представления leaf или leaf-list зависит от встроенного типа этого узла представления. Ниже определяется кодирование CBOR для каждого встроенного типа, поддерживаемого в YANG (см. параграф 4.2.4 в [RFC7950]). В каждом параграфе приведён пример значения, выделенного экземпляру узла представления обсуждаемого встроенного типа.

6.1. Целочисленные типы без знака

Листья типов uint8, uint16, uint32, uint64 должны кодироваться с использованием беззнакового целочисленного элемента данных CBOR (базовый тип 0).

Пример из [RFC8344] показывает кодирование экземпляра узла представления mtu со значением 1280 байтов.

   leaf mtu {
     type uint16 {
       range "68..max";
     }
   }

Диагностическая нотация CBOR: 1280

Представление CBOR: 19 0500

6.2. Целочисленные типы

Листья типов int8, int16, int32, int64 должны кодироваться с использованием беззнакового целочисленного элемента данных CBOR (базовый тип 0) или отрицательного целого числа CBOR (базовый тип 1), в зависимости от фактического значения.

Пример из [RFC7317] показывает кодирование экземпляра узла представления timezone-utc-offset со значением -300 минут.

Пример определения из [RFC7317]

   leaf timezone-utc-offset {
     type int16 {
       range "-1500 .. 1500";
     }
   }

Диагностическая нотация CBOR: -300

Представление CBOR: 39 012B

6.3. decimal64

Листья типа decimal64 должны кодироваться с использованием десятичной дроби, как указано в параграфе 3.4.4 [RFC8949].

Пример из [RFC7317] показывает кодирование экземпляра узла представления my-decimal со значением 2,57.

   leaf my-decimal {
     type decimal64 {
       fraction-digits 2;
       range "1 .. 3.14 | 10 | 20..max";
     }
   }

Диагностическая нотация: CBOR 4([-2, 257])

Представление CBOR: C4 82 21 19 0101

6.4. string

Листья типа string должны кодироваться с использованием текстовой строки CBOR (базовый тип 3).

Пример из [RFC8343] показывает кодирование экземпляра узла представления name со значением eth0.

   leaf name {
     type string;
   }

Диагностическая нотация CBOR: “eth0”

Представление CBOR: 64 65746830

6.5. boolean

Листья типа boolean должны кодироваться с использованием простого значения CBOR true (базовый тип 7, дополнительное значение 21) или false (базовый тип 7, дополнительное значение 20).

Пример из [RFC7317] показывает кодирование экземпляра узла представления enabled со значением true.

   leaf enabled {
     type boolean;
   }

Диагностическая нотация CBOR: true

Представление CBOR: F5

6.6. enumeration

Листья типа enumeration должны кодироваться с использованием беззнакового целочисленного элемента данных CBOR (базовый тип 0) или отрицательного целого числа CBOR (базовый тип 1), в зависимости от фактического значения, или, в качестве исключения, как строка текста с тегом (см. ниже). Перечисляемые значения выделяются явно с использованием оператора YANG value или автоматически на основе алгоритма, описанного в параграфе 9.6.4.2 [RFC7950].

Пример из [RFC7317] показывает кодирование экземпляра узла представления oper-status со значением testing.

   leaf oper-status {
     type enumeration {
       enum up { value 1; }
       enum down { value 2; }
       enum testing { value 3; }
       enum unknown { value 4; }
       enum dormant { value 5; }
       enum not-present { value 6; }
       enum lower-layer-down { value 7; }
     }
   }

Диагностическая нотация CBOR: 3

Представление CBOR: 03

Значения типа enumeration, заданные в типе union должны кодироваться с использованием строки текста CBOR (базовый тип 3) и должны содержать одно из имён, назначенных оператором enum в YANG (см. параграф 6.12). Кодирование должно использовать тег перечисления CBOR, как указано в параграфе 9.3.

Пример определения из [RFC7950]

   type union {
     type int32;
     type enumeration {
       enum unbounded;
     }
   }

Диагностическая нотация CBOR: 44(“unbounded”)

Представление CBOR: D8 2C 69 756E626F756E646564

6.7. bits

С учётом того, что биты назначаются явно с помощью оператора YANG position или автоматически на основе алгоритма, заданного в параграфе 9.7.4.2 [RFC7950], каждый элемент типа bits можно рассматривать как набор битовых позиций (или смещений от позиции 0), имеющих значение 1 (бит установлен) или 0 (бит сброшен).

Листья типа bits должны кодироваться с использованием массива CBOR (базовый тип 4) или строки байтов (базовый тип 2), а в исключительных случаях – строки текста с тегом (см. ниже). При использовании массива CBOR каждый элемент является (1) положительным целым числом (базовый тип 0, дополнительное значение 0 не разрешено), которое служит для расчёта смещения следующей за ним строки байтов, или (2) строкой байтов (базовый тип 2) с информацией об установленных и сброшенных битах. Начальное смещение имеет значение 0 и каждое целое число без знака меняет смещение следующей за ним строки байтов на целое число, умноженное на 8. Например, если смещение бита равно 0 и имеется целое число 5, первый байт следующей строки байтов будет представлять битовые позиции от 40 до 47, включительно. Если строка байтов имеет второй байт, он будет содержать сведения о битах 48 – 55 и т. д. Внутри каждого байта биты назначаются от младшего к старшему. После строки байтов смещение меняется на число байтов в строке, умноженное на 8. Байты без установленных битов (0) в конце строки байтов не создаются. Если это происходит в конце массива, такие байты просто опускаются. Если же это возникает в конце строки байтов, предшествующей целому числу, байты с нулями удаляются и это целое число увеличивается на количество удалённых байтов с нулями.

В примере представлено кодирование экземпляра узла представления alarm-state с установленными флагами critical (позиция 2), warning ( позиция 8) и indeterminate (позиция 128).

   typedef alarm-state {
     type bits {
       bit unknown;
       bit under-repair;
       bit critical;
       bit major;
       bit minor;
       bit warning {
         position 8;
       }
       bit indeterminate {
         position 128;
       }
     }
   }

   leaf alarm-state {
     type alarm-state;
   }

Диагностическая нотация CBOR: [h’0401′, 14, h’01’]

Представление CBOR: 83 42 0401 0E 41 01

Во многих случаях массив будет содержать лишь 1 элемент – строку из нескольких байтов. В таком случае требуется опустить элемент массива и включать только строку (массив) байтов. В качестве примера рассмотрим приведённое выше определение YANG с кодированием лишь флагов under-repair и critical. Результат показан ниже.

Диагностическая нотация CBOR: h’06’

Представление CBOR: 41 06

Элементы массива должны быть строками байтов без нулевых байтов в конце или положительными целыми числами, которые должны чередоваться со строками байтов, т. е. два целых числа или две строки байтов подряд являются ошибкой. Массив с одной строкой байтов должен кодироваться просто как строка байтов. Массив с одним положительным целым числом является ошибкой. Отметим, что получатель может обрабатывать нулевые байты в конце по обычным правилам без каких-либо проблем, поэтому реализация может просто воспринимать их.

Значения типа bits, определённые в типе union, должны кодироваться с использованием строки текста CBOR (базовый тип 3) и должны содержать последовательность разделённых пробелами имён bits, которые установлены (см. параграф 6.12). Кодирование должно использовать тег CBOR, как указано в параграфе 9.3.

В примере показано кодирование экземпляра узла представления alarm-state, заданного с использованием типа union, где установлены флаги under-repair и critical.

   leaf alarm-state-2 {
     type union {
       type alarm-state;
       type bits {
         bit extra-flag;
       }
     }
   }

Диагностическая нотация CBOR: 43(“under-repair critical”)

Представление CBOR: D8 2B 75 756E6465722D72657061697220637269746963616C

6.8. binary

Листья типа binary должны кодироваться с использованием строки байтов CBOR (базовый тип 2).

Пример показывает кодирование экземпляра узла представления aes128-key со значением 0x1f1ce6a3f42660d888d92a4d8030476e.

   leaf aes128-key {
     type binary {
       length 16;
     }
   }

Диагностическая нотация CBOR: h’1F1CE6A3F42660D888D92A4D8030476E’

Представление CBOR 50: 1F1CE6A3F42660D888D92A4D8030476E

6.9. leafref

Листья типа leafref должны кодироваться по правилам узла представления, указанного оператором YANG path.

Приведённый пример из [RFC8343] показывает кодирование экземпляра узла представления interface-state-ref со значением eth1.

   typedef interface-state-ref {
     type leafref {
       path "/interfaces-state/interface/name";
     }
   }

   container interfaces-state {
     list interface {
       key "name";
       leaf name {
         type string;
       }
       leaf-list higher-layer-if {
         type interface-state-ref;
       }
     }
   }

Диагностическая нотация CBOR: “eth1”

Представление CBOR: 64 65746831

6.10. identityref

Спецификация поддерживает два подхода к кодированию identityref с применением YANG SID (параграф 3.2) или имени (параграф 6.8 в [RFC7951]). Исключение, требующее применять тег, описано в параграфе 6.12.

6.10.1. SID как identityref

При реализации узла представления типа identityref с применением SID он должен кодироваться целым числом без знака CBOR (базовый тип 0). Отметим, что механизм приращений для SID в качестве identityref не применяется, поскольку они не используются как ключи отображения CBOR.

Пример из [RFC7317] показывает кодирование экземпляра узла представления type со значением iana-if-type:ethernetCsmacd (SID 1880).

   identity interface-type {
   }

   identity iana-interface-type {
     base interface-type;
   }

   identity ethernetCsmacd {
     base iana-interface-type;
   }

   leaf type {
     type identityref {
       base interface-type;
     }
   }

Диагностическая нотация CBOR: 1880

Представление CBOR: 19 0758

6.10.2. Имя как identityref

Можно кодировать identityref с использованием имени, как указано в параграфе 3.3. В этом случае для кодирования identityref должна использоваться строка текста CBOR (базовый тип 3). Если отождествление задано не в том модуле, где содержится узел данных identityref, должно указываться полное (namespace-qualified) имя, в остальных случаях разрешены обе формы имён (см. параграф 3.3).

В примере показано кодирование отождествления iana-if-type:ethernetCsmacd с применением полного имени (см. параграф 6.10.1).

Диагностическая нотация CBOR: “iana-if-type:ethernetCsmacd”

Представление CBOR: 78 1B 69616E612D69662D747970653A65746865726E657443736D616364

6.11. empty

Листья типа empty должны кодироваться с использованием значения CBOR null (базовый тип 7, дополнительное значение 22).

Пример из [RFC8344] показывает кодирование экземпляра узла представления is-router, когда он имеется.

   leaf is-router {
     type empty;
   }

Диагностическая нотация CBOR: null

Представление CBOR: F6

6.12. union

Листья типа union должны кодироваться по правилам, связанным с одним из перечисленных ниже типов. При использовании в union указанные ниже типы данных YANG применяются с тегом CBOR для исключения путацицы между разными типами YANG, кодируемыми с использованием одного базового типа CBOR.

  • bits;

  • enumeration;

  • identityref;

  • instance-identifier.

Значения тегов CBOR указаны в параграфе 9.3.

Как отмечено в параграфах 6.6 и 6.7, типы enumeration и bits кодируются с помощью текстовых строк CBOR (базовый тип 3) при определении внутри типа union. Это повышает сложность, но необходимо из-за особенностей модели данных YANG для union – обходной путь обеспечивает совместимость с кодированием перекрывающихся объединений (union) в XML и JSON (см. параграф 9.12 в [RFC7950].)

Пример из [RFC6991] показывает кодирование экземпляра узла представления ip-address для значения 2001:db8:a0b:12f0::1.

   typedef ipv4-address {
     type string {
       pattern
         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
       + '(%[\p{N}\p{L}]+)?';
     }
   }

   typedef ipv6-address {
     type string {
       pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
             + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
             + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
             + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
             + '(%[\p{N}\p{L}]+)?';
       pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
             + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
             + '(%.+)?';
     }
   }

   typedef ip-address {
     type union {
       type ipv4-address;
       type ipv6-address;
     }
   }

   leaf address {
     type ip-address;
   }

Диагностическая нотация CBOR: “2001:db8:a0b:12f0::1”

Представление CBOR: 74 323030313A6462383A6130623A313266303A3A31

6.13. instance-identifier

Эта спецификация поддерживает два подхода к кодированию instance-identifier на основе YANG SID (параграф 3.2) и имён (параграф 3.3). Исключение, требующее применять тег, описано в параграфе 6.12.

6.13.1. SID как instance-identifier

SID однозначно указывает узел схемы. В случае одного экземпляра узла схемы, т. е. при его определении в корне модуля или субмодуля YANG или определении узлов схемы в контейнере, SID достаточно для идентификации экземпляра (узла представления). Отметим, что механизм приращений для SID не применяется (см. параграф 6.10.1.)

В случае узла представления, являющегося записью списка YANG значение SID комбинируется с ключами списка для идентификации каждого экземпляра в списке YANG.

В случае одного экземпляра кодирование instance-identifier должно использовать целое число без знака CBOR (базовый тип 0) со значением SID целевого узла схемы.

В списке YANG для кодирования instance-identifier должен применяться массив CBOR (базовый тип 4), как указано ниже:

  • первый элемент должен кодироваться как целое число без знака (базовый тип 0) со значением SID целевого узла схемы;

  • следующие элементы должны содержать значение ключа, требуемого для идентификации целевого узла схемы. Эти ключи должны быть упорядочены, как указано в операторе YANG key, начиная со списка верхнего уровня и продолжая подчинёнными списками.

Примеры в этом параграфе предполагают определение узла схемы типа instance-identifier. Пример определения из [RFC7950]

   container system {
     ...
     leaf reporting-entity {
       type instance-identifier;
     }

Первый пример

Пример определения из [RFC7317] показывает кодирование экземпляра узла представления reporting-entity со значением /system/contact (SID 1741).

   container system {

     leaf contact {
       type string;
     }

     leaf hostname {
       type inet:domain-name;
     }
   }

Диагностическая нотация CBOR: 1741

Представление CBOR: 19 06CD

Второй пример

Этот пример предназначен для демонстрации идентификации записи узла представления в списке YANG с использованием изменённой версии модуля YANG из [RFC7317] (добавление страны к листься и уполномоченным ключам). Пример иллюстрирует кодирование значения reporting-entity. Указывающего экземпляр списка /system/authentication/user/authorized-key/key-data (предполагается SID 1734) для имени пользователя bob и уполномоченного ключа с именем admin и страной france.

   list user {
     key name;

     leaf name {
       type string;
     }

     leaf password {
       type ianach:crypt-hash;
     }

     list authorized-key {
       key "name country";

       leaf country {
         type string;
       }

       leaf name {
         type string;
       }

       leaf algorithm {
         type string;
       }

       leaf key-data {
         type binary;
       }
     }
   }

Диагностическая нотация CBOR: [1734, “bob”, “admin”, “france”]

Представление CBOR

   84                 # array(4)
      19 06C6         # unsigned(1734)
      63              # text(3)
         626F62       # "bob"
      65              # text(5)
         61646D696E   # "admin"
      66              # text(6)
         6672616E6365 # "france"

Третий пример

Приведённый ниже пример показывает кодирование значения reporting-entity, указывающего экземпляр списка /system/authentication/user (SID 1730), соответствующий имени пользователя jack.

Диагностическая нотация CBOR: [1730, “jack”]

Представление CBOR

   82             # array(2)
      19 06C2     # unsigned(1730)
      64          # text(4)
         6A61636B # "jack"

6.13.2. Имена как instance-identifier

Значение instance-identifier кодируется как строка текста, аналогично лексическму представлению в XML (см. параграф 9.13.2 в [RFC7950]). Однако кодирование пространства имён в instance-identifier следует правилам параграфа 3.3:

  • самое левое (верхнего уровня) имя узла данных всегда имеет полную форму (namespace-qualified);

  • последующие имена узлов имеют полную форму, если узел определён не в родительском модуле, иначе применяется простая форма (это справедливо и для имён узлов в предикатах).

Например, /ietf-interfaces:interfaces/interface[name=’eth0′]/ietf-ip:ipv4/ip является действительным значением instance-identifier, поскольку узлы данных interfaces, interface, name определены в модуле ietf-interfaces, а ipv4 и ip – в ietf-ip.

Полученное в результате значение XML Path Language (XPath) должно кодироваться с использованием строки текста CBOR (базовый тип 3).

Ниже приведены примеры, описанные в параграфе 6.13.1.

Первый пример

Диагностическая нотация CBOR: “/ietf-system:system/contact”

Представление CBOR

   78 1B 2F696574662D73797374656D3A73797374656D2F636F6E74616374

Второй пример

Диагностическая нотация CBOR (the line break is inserted for exposition only)

   "/ietf-system:system/authentication/user[name='bob']/
   authorized-key[name='admin'][country='france']/key-data"

Представление CBOR

   78 6B
      2F696574662D73797374656D3A73797374656D2F61757468656E74696361
      74696F6E2F757365725B6E616D653D27626F62275D2F617574686F72697A
      65642D6B65795B6E616D653D2761646D696E275D5B636F756E7472793D27
      6672616E6365275D2F6B65792D64617461

Третий пример

Диагностическая нотация CBOR

   "/ietf-system:system/authentication/user[name='jack']"

Представление CBOR

   78 34                                   # text(52)
      2F696574662D73797374656D3A73797374656D2F61757468656E74696361
      74696F6E2F757365725B6E616D653D276A61636B275D

7. Content-Type

Эта спецификация определяет тип носителя application/yang-data+cbor, который можно использовать без параметров или с параметром id, содержащим имя (name) или SID (sid). Этот тип носителя представляет документ YANG-CBOR, содержащий дерево представления. При наличии параметра id в зависимости от его значения каждый узел представления указывается связанным с ним полным именем (namespace-qualified), как указано в параграфе 3.3 (id=name) или YANG SID (представленным, например, ключом отображения CBOR как приращение SID или с помощью тега 47), как указано в параграфе 3.2 (id=sid). При отсутствии параметра id могут применяться обе формы.

Форматом представления application/yang-data+cbor является отображение CBOR, сопоставляющее имена и/или SID (как указано выше) со значениями экземпляров (по правилам раздела 4).

В настоящее время не пердполагается использование для параметра id значений, отличающихся от имени и SID, или отсуствие параметра. Если такое расширение произойдёт, предполагается, что новые значения будут иметь форму [a-z][a-z0-9]*(-[a-z0-9]+)*.

Таким образом, документ задаёт 3 content-type, предназначенных для разных классов приложений.

  • application/yang-data+cbor, id=sid – для приложений, которым требуется экономить пространство кодирования и обработку строк текста (например, приложения на узлах с ограничениями [RFC7228] или с особыми требованиями к производительности).

  • application/yang-data+cbor, id=name – для приложений, которые не хотят поддерживать SID и располагают достаточными ресурсами для работы со строками текста (например, приложения, желающие напрямую заменить application/yang.data+json более эффективным представлением без внесения других изменений).

  • application/yang-data+cbor – для комплексных приложений, которые могут получить преимущество от повышенной эффективности идентификаторов SID, сохраняя интеграцию с базами модулей YANG, пока для них не заданы отображения SID.

Все три content-type основаны на одних механизмах представления, части которых в первом и втором случае просто не используются.

Использование одного из трёх content-type в транспортном протоколе выходит за рамки спецификации. В последнем абзаце параграфа 5.2 [RFC8040] рассматривается индикация и запрос использования конкретных content-type в RESTCONF. Похожие механизмы доступны в протоколе ограниченных приложений (Constrained Application Protocol или CoAP) [RFC7252] на основе опций Content-Format и Accept. В [CORE-COMI] показано, как можно использовать Content-Format для индикации в случае id=sid.

8. Вопросы безопасности

Применимы соображения безопасности, отмеченные в [RFC8949] и [RFC7950].

Этот документ определяет дополнительное кодирование данных, смоделированных на языке YANG. Кодирование само по себе не создаёт новых проблем безопасности в дополнение к отмеченным для конкретного проткола и контекста применения.

Для снижения рисков приложениям на приёмной стороне следует отвергать все сообщения, не соответствующие правилам этого документа, возвращая отправителю подходящее сообщение об ошибке. Например, при использовании параметра id для типа носителя важно корректно отклонять идентификаторы иного типа, чтобы избежать ситуаций, когда другие реализации по-иному интерпретируют такое содержимое.

При использовании SID интерпретация кодированных данных зависит не только от наличия корректных модулей YANG, но и от правильного отображения SID. Поэтому поддержка и развитие сведений об отображении требует такой же осторожности, как и управление модулями YANG. Процедуры [CORE-SID] учитывают это обстоятельство.

9. Взаимодействие с IANA

9.1. Реестр Media Types

Агентство IANA добавило указанный в таблице 2 тип носителя в реестр Media Types [IANA.media-types].

Таблица 2. Реестр Media Types.

 

Имя

Шаблон

Документ

yang-data+cbor

application/yang-data+cbor

RFC 9254

 

Type name: application
Subtype name: yang-data+cbor
Required parameters: N/A
Optional parameters: id (раздел 7 в RFC 9254)
Encoding considerations: binary (CBOR)
Security considerations: раздел 8 в RFC 9254
Interoperability considerations: N/A
Published specification: RFC 9254
Applications that use this media type: Приложения, которым нужно компактное и эффективное представление данных моделей YANG
Fragment identifier considerations: Синтаксис и семантика идентификатров фрагментов для application/yang-data+cbor совпадают с заданными для application/cbor (на момент публикации этого документа синтаксис идентификации фрагментов для application/cbor не был определен)
Additional information:
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: почтовая конференция CORE WG (core@ietf.org) или IETF Applications and Real-Time Area (art@ietf.org)
Intended usage: COMMON
Restrictions on usage: N/A
Author: CoRE WG
Change controller: IETF

9.2. Реестр CoAP Content-Formats

Агентство IANA добавило указанные в таблице 3 значения Content-Formats в субреестр CoAP Content-Formats реестра Constrained RESTful Environments (CoRE) Parameters [IANA.core-parameters]. Применяется процедура Expert Review для диапазона 0 – 255 и IETF Review – для 256 – 9999.

Таблица 3. Реестр CoAP Content-Format.

 

Тип носителя

Кодирование

Идентификатор

Документ

application/yang-data+cbor

340

RFC 9254

application/yang-data+cbor; id=name

341

RFC 9254

application/yang-data+cbor; id=sid

140

RFC 9254

 

9.3. Реестр CBOR Tags

Агентство IANA выделило номера тегов CBOR в реестре CBOR Tags [IANA.cbor-tags] заданнов в параграфе 9.2 [RFC8949].

Таблица 4. Реестр CBOR Tags

Тег

Элемент данных

Семантика

Документ

43

Строка текста

Тип YANG bits, параграф 6.7.

RFC 9254

44

Строка текста

Тип YANG enumeration, параграф 6.6.

RFC 9254

45

Целое число без знака или строка текста

Тип YANG identityref, параграф 6.10.

RFC 9254

46

Целое число без знака, строка текста или массив

Тип YANG instance-identifier, параграф 6.13.

RFC 9254

47

Целое число без знака

Тип YANG Schema Item iDentifier (SID), параграф 3.2.

RFC 9254

10. Литература

10.1. Нормативные документы

[IANA.cbor-tags] IANA, “Concise Binary Object Representation (CBOR) Tags”, <https://www.iana.org/assignments/cbor-tags>.

[IANA.core-parameters] IANA, “Constrained RESTful Environments (CoRE) Parameters”, <https://www.iana.org/assignments/core-parameters/>.

[IANA.media-types] IANA, “Media Types”, <https://www.iana.org/assignments/media-types/>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC7951] Lhotka, L., “JSON Encoding of Data Modeled with YANG”, RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8259] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, “Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures”, RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.

[RFC8791] Bierman, A., Björklund, M., and K. Watsen, “YANG Data Structure Extensions”, RFC 8791, DOI 10.17487/RFC8791, June 2020, <https://www.rfc-editor.org/info/rfc8791>.

[RFC8949] Bormann, C. and P. Hoffman, “Concise Binary Object Representation (CBOR)”, STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

10.2. Дополнительная литература

[CORE-COMI] Veillette, M., Ed., van der Stok, P., Ed., Pelov, A., Bierman, A., and I. Petrov, Ed., “CoAP Management Interface (CORECONF)”, Work in Progress, Internet-Draft, draft-ietf-core-comi-11, 17 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-11>.

[CORE-SID] Veillette, M., Ed., Pelov, A., Ed., Petrov, I., Ed., Bormann, C., and M. Richardson, “YANG Schema Item iDentifier (YANG SID)”, Work in Progress, Internet-Draft, draft-ietf-core-sid-18, 18 November 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-18>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, “Terminology for Constrained-Node Networks”, RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, “The Constrained Application Protocol (CoAP)”, RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

[RFC7317] Bierman, A. and M. Bjorklund, “A YANG Data Model for System Management”, RFC 7317, DOI 10.17487/RFC7317, August 2014, <https://www.rfc-editor.org/info/rfc7317>.

[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8344] Bjorklund, M., “A YANG Data Model for IP Management”, RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

Благодарности

Этот документ в значительной мере вдохновлен обширной работой Andy Bierman и Peter van der Stok над [CORE-COMI]. Докумен [RFC7951] также внёс важный вклад в эту работу. Спасибо авторам и участникам создания этих документов.

Авторы хотели бы также поблагодарить Ladislav Lhotka и Jürgen Schönwälder, а также «куратора» документа Marco Tiloca за обзор, отзывы и комментации. Обширные комментарии в процессе рецензирования IESG помогли улучшить документ и авторы хотели бы особо отметить отзывы и рекомендации от руководителя направления (AD) Francesca Palombini, а также существенные улучшения, предложенные членами IESG Benjamin Kaduk и Rob Wilton.

Адреса авторов

Michel Veillette (editor)
Trilliant Networks Inc.
610 Rue du Luxembourg
Granby Quebec J2J 2V2
Canada
Email: michel.veillette@trilliantinc.com
 
Ivaylo Petrov (editor)
Google Switzerland GmbH
Brandschenkestrasse 110
CH-8002 Zurich
Switzerland
Email: ivaylopetrov@google.com
 
Alexander Pelov
Acklio
1137A avenue des Champs Blancs
35510 Cesson-Sevigne Cedex
France
Email: a@ackl.io
 
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
 
Michael Richardson
Sandelman Software Works
Canada
Email: mcr+ietf@sandelman.ca

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

Рубрика: RFC | Оставить комментарий

RFC 9260 Stream Control Transmission Protocol

image_print
Internet Engineering Task Force (IETF)                        R. Stewart
Request for Comments: 9260                                 Netflix, Inc.
Obsoletes: 4460, 4960, 6096, 7053, 8540                         M. Tüxen
Category: Standards Track                Münster Univ. of Appl. Sciences
ISSN: 2070-1721                                               K. Nielsen
                                                            Kamstrup A/S
                                                               June 2022

Протокол SCTP

Stream Control Transmission Protocol

PDF

Аннотация

Этот документ описывает протокол управления потоковой передачей (Stream Control Transmission Protocol или SCTP) и отменяет RFC 4960. Он включает спецификацию реестра флагов блоков (chunk) из RFC 6096 и спецификацию бита I в блоках DATA из RFC 7053, поэтому отменяет также RFC 6096 и RFC 7053. Кроме того, документ отменяет RFC 4460 и RFC 8540, где указаны ошибки для SCTP.

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

SCTP представляет собой протокол транспортного уровня с гарантированной доставкой, работающий в пакетных сетях без явной организации соединений таких, как IP. Протокол обеспечивает пользователям следующие типы сервиса:

  • передача пользовательских данных с корректировкой ошибок, подтверждением доставки и отсутствием дубликатов;
  • фрагментирование данных в соответствии с определенным для пути значением MTU2;
  • упорядоченная доставка пользовательских сообщений внутри множества потоков с возможностью управления порядком доставки отдельных пользовательских сообщений;
  • возможность группировки пользовательских сообщений в один пакет SCTP;
  • устойчивость к отказам на сетевом уровне за счёт поддержки многодомных хостов на обеих сторонах соединения.

Протокол SCTP включает механизмы предотвращения gthtuheprb и устойчивости к атакам с использованием лавины пакетов (flooding) или маскированием адресов (masquerade).

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF3 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG4. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9260.

Авторские права

Авторские права (Copyright (c) 2022) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

Исключено в версии HTML.

1. Введение

В этом разделе рассматриваются причины, побудившие к разработке протокола SCTP, обеспечиваемые протоколом типы сервиса, а также базовые концепции, требуемые для детального описания протокола.

Этот документ заменяет собой [RFC4960]. Кроме того, он включает спецификацию реестра флагов блоков (chunk) из RFC 6096 и спецификацию бита I в блоках DATA из RFC 7053, поэтому отменяет также [RFC 6096] и [RFC 7053].

1.1. Мотивация

Протокол TCP [RFC0793] обеспечивает, прежде всего, гарантированную доставку данных в сетях IP. Однако многие современные приложения сталкиваются с ограниченными возможностями TCP и вынуждены реализовать свои средства обеспечения гарантированной доставки на основе транспорта UDP [RFC0768]. Ниже перечислены основные ограничения TCP, которые пользователи стремятся обойти.

  • Протокол TCP обеспечивает гарантию доставки данных с сохранением их порядка. Некоторым приложениям требуется лишь гарантированная доставка, независимо от порядка, а другим приложениям может быть достаточно частичного сохранения порядка доставки. Оба типа приложений не устраивают дополнительные задержки TCP, возникающие при нарушении порядка доставки пакетов в сети.
  • Потоковая природа протокола TCP зачастую не подходит для приложений, которым приходится вводить свои средства маркировки записей для делинеаризации передаваемых сообщений. Кроме того, приложениям приходиться явно использовать средства выталкивания данных (push) для того, чтобы сообщение было передано полностью за разумное время.
  • Ограниченные возможности сокетов TCP усложняют для приложений задачу обеспечения высокого уровня доступности при обмене данными за счёт использования многодомных5 хостов.
  • Протокол TCP достаточно слабо защищён от атак на службы6, в частности, от SYN-атак.

Передача сигнальных сообщений PSTN через сети IP является примером приложения, которое сталкивается со всеми ограничениями протокола TCP. Это послужило основным мотивом разработки протокола SCTP, но можно найти и другие приложения, для которых транспорт SCTP будет предпочтительным. Одним из примеров является использование каналов данных в инфраструктуре WebRTC.

1.2. Архитектура SCTP

Протокол SCTP размещается в многоуровневой модели между уровнем пользовательских приложений SCTP и сетевым сервисом без организации явных соединений (например, IP). В остальной части этого документа предполагается, что SCTP работает «поверх» протокола IP. Основным типом сервиса, обеспечиваемого протоколом SCTP, является гарантированная передача сообщений между пользователями SCTP. Этот сервис обеспечивается в контексте ассоциаций между парами конечных точек SCTP. В параграфе 10 данного документа приводится схематическое рассмотрение интерфейса API, который должен существовать на границе между протоколом SCTP и пользовательскими приложениями SCTP.

Протокол SCTP работает на основе явных соединений7, но ассоциация SCTP представляет собой более широкое понятие, нежели соединение TCP. Протокол SCTP обеспечивает для каждой конечной точки SCTP (см. параграф 1.4) способ обеспечения другой конечной точки (в процессе создания ассоциации) списком транспортных адресов (т. е. множеством адресов IP в комбинации с номером порта SCTP), которые конечная точка может использовать для связи и откуда она будет получать пакеты SCTP. Ассоциация может передавать данные с использованием всех возможных пар адресов отправителя и получателя, которые могут быть созданы на основе списков адресов конечных точек.

 _____________                                      _____________
| Приложения  |                                    | Приложения  |
|    SCTP     |                                    |    SCTP     |
|-------------|                                    |-------------|
|Транспортный |                                    |Транспортный |
| сервис SCTP |                                    | сервис SCTP |
|-------------|                                    |-------------|
|   Сетевой   |Один или       ----      Один или   |   Сетевой   |
|  сервис IP  |несколько       \/       несколько  |  сервис IP  |
|             |адресов IP      /\       адресов IP |             |
|_____________|               ----                 |_____________|

  SCTP-узел A |<-------- Сетевой транспорт ------->| SCTP-узел B

Рисунок 1. SCTP-ассоциация.

В дополнение к инкапсуляции пакетов SCTP в IPv4 и IPv6 возможна инкапсуляция в UDP, как указано в [RFC6951], или в DTLS, как указано в [RFC8261].

1.3. Основные термины

Некоторые термины, используемые в контексте SCTP, уже были упомянуты в предыдущих параграфах. Здесь даются определения основных терминов, связанных с протоколом.

Active destination transport address – активный транспортный адрес получателя

Адрес транспортного уровня конечной точки-партнера, который отправитель рассматривает как доступный для приёма пользовательских сообщений.

Association Maximum DATA Chunk Size (AMDCS) – максимальный размер блока DATA для ассоциации

Меньшее из значение PMDCS (Path Maximum DATA Chunk Size) среди всех адресов получателя.

Bundling of Chunks – группировка блоков

Дополнительная операция мультиплексирования, позволяющая передать в одном пакете несколько блоков SCTP.

Bundling of User messages – группировка пользовательских сообщений

Дополнительная операция мультиплексирования, позволяющая передать в одном пакете несколько сообщений SCTP. Каждое пользовательское сообщение помещается в отдельный блок DATA.

Chunk – блок

Единица информации в пакете SCTP, содержащая заголовок блока (chunk header) и данные.

Congestion window (cwnd) – окно насыщения (перегрузки)

Переменная SCTP, ограничивающая объем данных (число байтов), которые отправитель может передать в один активный адрес получателя до получения от последнего подтверждения.

Cumulative TSN Ack Point – указатель на кумулятивный номер Ack

Значение TSN для последнего блока DATA, подтверждённого с использованием поля Cumulative TSN Ack в SACK.

Flightsize – размер данных «в пути»

Число остающихся данных для конкретного транспортного адреса получателя в данный момент.

Idle destination address – неиспользуемый адрес получателя

Адрес, который не используется для передачи пользовательских сообщений в течение некоторого периода (обычно ≥ HB.interval).

Inactive destination transport address – неактивный транспортный адрес получателя

Адрес, который считается неактивным в результате обнаружения ошибки, и не доступен для доставки пользовательских сообщений.

Message (user message) – (пользовательское) сообщение

Данные, полученные протоколом SCTP от протокола вышележащего уровня (Upper Layer Protocol или ULP).

Network Byte Order – сетевой порядок байтов

Порядок передачи байтов, при котором старший байт следует первым. Синоним Big Endian.

Ordered Message – упорядоченные сообщения

Пользовательские сообщения, доставленные в том же порядке, в котором они были помещены в поток.

Outstanding Data (Data Outstanding или Data In Flight) – остающиеся данные (данные «в пути»)

Общий размер блоков DATA связанных с остающимися TSN. Повторно передаваемый блок DATA учитывается в остающихся данных один раз. Блок DATA, сочтённый потерянным, но ещё не переданный повторно не относится к остающимся данным.

Outstanding TSN (в конечной точке SCTP)

Номер TSN (и связанный с ним блок DATA), который был передан конечной точкой, но его получение ещё не подтверждено.

“Out of the Blue” (OOTB) Packet

Пакет с корректным форматом, для которого получатель не может определить ассоциацию (см. параграф 8.4).

Path – путь

Маршрут, используемый пакетами SCTP, переданными одной конечной точкой SCTP по определённому транспортному адресу другой конечной точки SCTP. Передача пакетов по различным транспортным адресам удалённой точки не обязательно ведёт к изменению пути. В этой спецификации путь указывается транспортным адресом получателя, поскольку маршрутизация считается стабильной. Это включает, в частности, выбор адреса отправителя при отправке пакета получателю.

Path Maximum DATA Chunk Size (PMDCS) – максимальный размер блока DATA для пути

Максимальный размер блока DATA (включая заголовок блока), который помещается в пакет SCTP, не превышающий по размеру PMTU для конкретного адреса получателя.

Path Maximum Transmission Unit (PMTU)

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

Primary Path – основной путь

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

Receiver Window (rwnd) – окно получателя

Переменная SCTP, которую отправитель использует для хранения последнего рассчитанного значения размера окна приёма своего партнёра по ассоциации. Размер окна приёма задаётся количеством байтов. Значение размера позволяет отправителю определить величину свободного пространства в приёмном буфере получателя.

SCTP association – ассоциация SCTP

Протокольные отношения между конечными точками SCTP, включающие пару узлов SCTP и информацию о состоянии протокола (теги Verification, активные значения TSN и т. п.). Для уникальной идентификации ассоциаций SCTP могут использоваться пары транспортных адресов конечных точек ассоциации. Между любой парой конечных точек SCTP недопустимо одновременное существование нескольких ассоциаций.

SCTP endpoint – конечная точка SCTP

Логический приёмник/передатчик пакетов SCTP. Для многодомных хостов конечная точка SCTP представляется своему партнёру как комбинация набора допустимых транспортных адресов, по которым можно передавать пакеты SCTP и набора допустимых адресов транспортного уровня, с которых могут приниматься пакеты SCTP. Все транспортные адреса, используемые конечной точкой SCTP, должны быть связаны с одним номером порта, но могут иметь различные адреса IP. Транспортные адреса, используемые конечной точкой SCTP, недопустимо устанавливать для другой конечной точки SCTP (т. е. транспортный адрес каждой конечной точки SCTP уникален).

SCTP packet (packet) – пакет SCTP

Элемент данных, передаваемый через интерфейс между SCTP и пакетной сетью без организации соединений (например, IP). Пакет SCTP включает общий заголовок SCTP, блок пользовательских данных (DATA chunk) и может включать блок управления SCTP.

SCTP user application (SCTP user) – пользовательское приложение SCTP (пользователь SCTP)

Логический объект вышележащего уровня, который использует сервис SCTP. Используется также термин Upper-layer Protocol (ULP) – протокол вышележащего уровня.

Slow-Start Threshold (ssthresh) – порог замедленного старта

Переменная SCTP, определяющая пороговое значение, по которому конечная точка будет определять необходимость использования для конкретного транспортного адреса процедуры slow start или congestion avoidance. Значение ssthresh указывается в байтах.

State Cookie – куки состояния

Контейнер со всей информацией, требуемой для создания ассоциации.

Stream – поток

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

Stream Sequence Number – порядковый номер в потоке

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

Tie-Tags

Два 32-битовых случайных значений, которые вместе образуют 64-битовое одноразовое значение nonce. Эти теги используются в State Cookie и TCB для связывания недавно перезапущенной ассоциации с её предшественником на конечной станции, которая не была перезагружена, но, тем не менее, не может найти тегов Verification существующей ассоциации.

Transmission Control Block (TCB) – блок управления передачей

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

Transmission Sequence Number (TSN)- порядковый номер при передаче

32-битовый порядковый номер, используемый протоколом SCTP для нумерации передаваемых блоков. Значение TSN связывается с каждым блоком, который содержит пользовательские данные, чтобы дать возможность конечной точке SCTP на приёмной стороне подтвердить приём блока и обнаружить дубликаты.

Transport address – транспортный адрес

Адрес транспортного уровня обычно определяется комбинацией адреса сетевого уровня, транспортным протоколом и номером порта на транспортном уровне. При использовании SCTP в сетях IP транспортный адрес представляет собой комбинацию адреса IP и номера порта SCTP (транспортным протоколом является SCTP).

Unordered Message – неупорядоченное сообщение

Неупорядоченные сообщения могут передаваться с изменением их местоположения в потоке относительно других сообщений. Неупорядоченные сообщения могут размещаться в потоке перед упорядоченными или после них.

User message – пользовательское сообщение

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

Verification Tag – тег верификации

32-битовое беззнаковое целое значение, которое обычно выбирается с использованием генератора случайных чисел. Verification Tag позволяет получателю проверить принадлежность полученного пакета SCTP к ассоциации и избавиться от старых пакетов из прежних ассоциаций.

1.4. Сокращения

MAC – Message Authentication Code [RFC2104] (код аутентификации сообщения).

RTO – Retransmission Timeout (тайм-аут повтора передачи).

RTT – Round-Trip Time (время кругового обхода).

RTTVAR – Round-Trip Time Variation (вариации времени кругового обхода).

SCTP – Stream Control Transmission Protocol (протокол управления потоковой передачей).

SRTT – Smoothed RTT (сглаженное значение RTT).

TCB – Transmission Control Block (блок управления передачей).

TLV – Type-Length-Value coding format (формат представления тип-размер-значение).

TSN – Transmission Sequence Number (порядковый номер при передаче).

ULP – Upper-Layer Protocol (протокол вышележащего уровня).

1.5. Функциональность SCTP

Транспортный сервис SCTP можно разделить на несколько функциональных групп, показанных на рисунке 2.

           Пользовательские приложения SCTP
-----------------------------------------------------
 _____________                  ____________________
|             |                |   Упорядоченная    |
|             |                | доставка в потоке  |
|  Создание   |                |____________________|
|     и       |         ____________________________
|   разрыв    |        | Фрагментация польз. данных |
| ассоциаций  |        |____________________________|
|             |         ____________________________
|             |        |      Подтверждения         |
|             |        |    и предотвращения        |
|             |        |        перегрузки          |
|             |        |____________________________|
|             |         ____________________________
|             |        |     Связывание блоков      |
|             |        |____________________________|
|             |     ________________________________
|             |    |      Проверка пакетов          |
|             |    |________________________________|
|             |     ________________________________
|             |    |     Управление путями          |
|_____________|    |________________________________|

Рисунок 2. Функциональное представление сервиса SCTP.

1.5.1. Создание и разрыв ассоциаций

Ассоциации создаются по запросам пользователей SCTP (см. описание примитива ASSOCIATE на стр. 49 или SEND на стр. 50).

В процессе создания ассоциаций используется механизм cookie, подобный предложенному Кэрном (Karn) и Симпсоном (Simpson) в [RFC2522], для обеспечения защиты от атак на синхронизацию. Этот механизм использует четырехэтапное согласование (four-way handshake), в котором два последних этапа могут использоваться для передачи пользовательских данных в целях ускорения процедуры соединения. Стартовые последовательности описаны в разделе 5. Создание ассоциации.

Протокол SCTP обеспечивает аккуратное завершение работы активных ассоциаций (shutdown) по запросу пользователя SCTP (см. описание примитива SHUTDOWN на стр. 50). Протокол SCTP позволяет также разрывать ассоциации (abort) по запросу пользователя (примитив ABORT) или в результате обнаружения ошибок на уровне SCTP. В разделе 9 описаны оба варианта завершения работы ассоциаций.

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

1.5.2. Упорядоченная доставка в потоках

Термин «поток» (stream) используется в протоколе SCTP для обозначения последовательности пользовательских сообщений, которые доставляются протоколам вышележащих уровней в том же порядке, который сообщения имели в самом потоке. Это отличается от значения термина в контексте TCP, где потоком называют последовательности байтов (в этом документе предполагается, что размер байта составляет 8 битов).

Пользователь SCTP может во время создания ассоциации задать число потоков, поддерживаемых этой ассоциацией. Это значение согласуется с удалённой стороной (см. 5.1.1. Обработка параметров потока). Пользовательские сообщения связываются с номерами потоков (см. примитивы SEND на стр. 50 и RECEIVE на стр. 51). SCTP присваивает порядковые номера в потоке каждому сообщению, полученному протоколом от пользователя SCTP. На приёмной стороне SCTP обеспечивает доставку сообщений пользователю с сохранением их последовательности в данном потоке. В силу того, что один поток может быть заблокирован ожиданием следующего по порядку пользовательского сообщения, в это время возможна доставка сообщений из других потоков.

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

1.5.3. Фрагментация пользовательских данных

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

1.5.4. Подтверждения и предотвращение перегрузки

SCTP присваивает номер TSN каждому фрагменту и нефрагментированному пользовательскому сообщению. Нумерация TSN не зависит от Stream Sequence Number, присваиваемых на уровне потока. Принимающая сторона подтверждает все полученные TSN даже при обнаружении пропуска в номерах. Если нужно повторно передать фрагмент данных пользователя или нефрагментированное сообщение, используется выделенный номер TSN. Такой подход обеспечивает независимую функциональность для гарантии доставки и сохранения порядка сообщений.

Функция подтверждения и предотвращения перегрузки отвечает за повторную передачу пакетов, когда подтверждение о доставке не приходит от получателя вовремя. Повтор передачи связан с предотвращением перегрузки подобно тому, как это сделано для протокола TCP. В разделах 6 и 7 приводится подробное описание протокольных процедур, связанных с выполнением этой функции.

1.5.5. Группировка блоков

Как описано в разделе 3, пакет SCTP, передаваемый на нижележащий уровень, содержит общий заголовок, за которым следует один или несколько информационных блоков (chunk), каждый из них содержит пользовательские данные или управляющую информацию SCTP. Реализация SCTP, поддерживающая группировку, может задержать на стороне отправителя отправку пользовательских сообщений для группировки соответствующих блоков DATA.

Пользователь SCTP может запросить у реализации передачу своих сообщений без задержки, связанной с группировкой. Однако даже при выборе пользователем этой опции реализация SCTP может задерживать передачу по другим причинам (например, связанным с контролем перегрузки или управлением потоком данных) и группировать блоки DATA, если это возможно.

1.5.6. Проверка пакетов

Обязательное поле Verification Tag и 32-битовая контрольная сумма (см. Приложение A. Расчет контрольной суммы CRC32c), передаются в общем заголовке SCTP. Значение Verification Tag выбирается каждой стороной в процессе создания ассоциации. Пакеты, полученные без ожидаемого значения Verification Tag, отбрасываются в целях защиты от атак вслепую с маскированием адресов и избавления от старых пакетов SCTP, оставшихся от предыдущей ассоциации. Контрольная сумма CRC32c помещается отправителем в каждый пакет SCTP для обеспечения дополнительной защиты от повреждения данных в сети. Получатель пакета SCTP с некорректной контрольной суммой CRC32 c отбрасывает такие пакеты без уведомления.

1.5.7. Управление путями

Передающий пакеты SCTP пользователь может манипулировать набором транспортных адресов, используемых для указания получателя пакетов SCTP с помощью примитивов, описанных в разделе 11. Функция управления путями отслеживает доступность с помощью блоков heartbeat, когда другой трафик не позволяет получить достоверных данных о доступности адресов, и сообщает пользователю об изменениях состояния доступности любых адресов транспортного уровня на удалённой стороне. Функция управления путями SCTP выбирает транспортный адрес получателя для каждого исходящего пакета SCTP на основе пользовательских инструкций и текущей информации о доступности желанного получателя. Функция управления путями отвечает также за передачу информации о доступных локальных адресах транспортного уровня партнёру в процессе создания ассоциации и за передачу пользователю SCTP сведений, полученных от партнёра.

При создании ассоциации определяется основной путь (primary path) для каждой конечной точки SCTP, который используется для нормальной передачи пакетов SCTP.

На приёмной стороне функция управления путями отвечает за проверку наличия пригодной ассоциации SCTP, к которой относятся входящие пакеты SCTP, до передачи таких пакетов на дальнейшую обработку.

Примечание. Функции Path Management и Packet Validation выполняются одновременно, хотя и описаны по отдельности (в реальности эти функции не могут выполняться независимо одна от другой).

1.6. Порядковые номера

Важно помнить, что пространство порядковых номеров TSN ограничено, хотя и достаточно велико. Значения порядковых номеров могут находиться в диапазоне от 0 до 232 – 1. Ввиду конечности пространства TSN все арифметические операции с ними должны осуществляться по модулю 232 – это обеспечит возможность после достижения максимального значения TSN снова перейти к номеру 0. При сравнении значений порядковых номеров следует принимать во внимание цикличность их изменения. Символы =< применительно к TSN означают «меньше или равно» (модуль 232).

При арифметических операциях и сравнении номеров TSN для протокола SCTP следует пользоваться арифметикой порядковых номеров, определённой в [RFC1982] для случая SERIAL_BITS = 32.

Конечным точкам не следует передавать блоки DATA со значением TSN, которое более чем на 231 – 1 превышает начальное значение TSN для текущего окна передачи. Использование таких значений может привести к возникновению проблем при сравнении TSN.

Порядковые номера TSN сбрасываются в 0 при достижении границы 232 – 1. Т. е., следующий блок DATA после блока с TSN = 232 – 1 должен иметь TSN = 0.

Во всех арифметических операциях с порядковыми номерами в потоках (Stream Sequence Number) следует использовать арифметику порядковых номеров, определённую в [RFC1982] для случая SERIAL_BITS = 16. Все прочие операции с порядковыми номерами в данном документе используют обычную арифметику.

1.7. Отличия от RFC 4960

Протокол SCTP был изначально определён в [RFC4960], который данный документ отменяет. Читателям, интересующимся подробностями отличий, рекомендуется прочесть [RFC8540].

В дополнение к этим и последующим редакторским правкам в документ внесены перечисленные ниже изменения.

  • Обновлены ссылки.
  • Улучшен язык описания уровней требований.
  • Примитиву ASSOCIATE разрешено принимать несколько удалённых адресов (см. спецификацию API сокетов).
  • Ссылка на спецификацию Packetization Layer Path MTU Discovery (PLPMTUD) для определения MTU на пути.
  • Описание обработки ICMP перенесено из приложения в основной текст.
  • Удалено приложение с описанием обработки явных уведомлений о перегрузке (ECN).
  • Более точно описана обработка размера пакетов, путём введения PMTU, PMDCS и AMDCS.
  • Добавлено определение управляющего блока (control chunk).
  • Улучшено описание обработки блоков INIT и INIT ACK с непригодными обязательными параметрами.
  • Разрешено применение L > 1 для подсчёта байтов (Appropriate Byte Counting или ABC) при замедленном старте.
  • Явно описана повторная инициализация контроллера перегрузок при смене маршрутов.
  • Улучшена терминология для более ясного представления, что данная спецификация не описывает полносвязную (full mesh) архитектуру.
  • Улучшено описание генерации номеров (Transmission Sequence Number и Stream Sequence Number).
  • Улучшено описание «отречения» (reneging).
  • Больше не требуется изменение Cumulative TSN Ack для увеличения окна перегрузки. Это улучшает согласованность с действиями по предотвращению перегрузки.
  • Улучшено описание State Cookie.
  • Исправлен API для извлечения сообщений при отказах ассоциации.

2. Соглашения о терминах

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

3. Формат пакетов SCTP

Пакет SCTP состоит из общего заголовка и блоков (chunk), содержащих пользовательские сообщения или управляющую информацию.

Формат пакетов SCTP показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Common Header                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Chunk #1                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ...                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Chunk #n                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Недопустимо группировать INIT, INIT ACK, и SHUTDOWN COMPLETE с другими блоками в один пакет SCTP. Все прочие блоки можно группировать в одном пакете SCTP, пока его размер не превышает значение PMTU. Более подробное описание группировки блоков приводится в параграфе 6.10.

Если пользовательское сообщение не помещается в пакет SCTP, оно может быть разделено на фрагменты с использованием процедуры, описанной в параграфе 6.9.

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

3.1. Описание полей общего заголовка SCTP

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Source Port Number        |     Destination Port Number   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Verification Tag                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Checksum                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Port Number – 16 битов (целое число без знака)

Номер порта SCTP, используемого отправителем. Это значение, вместе с IP-адресом отправителя, номером порта получателя и (возможно) IP-адресом получателя, может использоваться на приёмной стороне для идентификации ассоциации, к которой относится пакет. Значение 0 для номера порта недопустимо.

Destination Port Number – 16 битов (целое число без знака)

Номер порта SCTP, в который данный пакет адресован. На приёмной стороне это значение будет использоваться для демультиплексирования пакета SCTP соответствующей конечной точке или приложению. Значение 0 для номера порт недопустимо.

Verification Tag – 32 бита (целое число без знака)

Принимающая сторона использует Verification Tag для проверки отправителя пакета SCTP. На передающей стороне значение поля Verification Tag должно устанавливаться в соответствии со значением Initiate Tag, полученным от партнёра при инициализации ассоциации, за исключением перечисленных ниже случаев.

  • В пакетах, содержащих блок INIT, тег Verification должен быть установлен в 0.
  • В пакетах, содержащих блок SHUTDOWN-COMPLETE с установленным флагом T, значение тега Verification должно копироваться из пакета с блоком SHUTDOWN-ACK.
  • В пакетах, содержащих блок ABORT, тег верификации может быть копией Verification Tag из пакета, вызвавшего передачу блока ABORT. Более подробное описание приведено в параграфах 8.4 и 8.5.

Checksum – 32 бита (целое число без знака)

Это поле содержит контрольную сумму для данного пакета SCTP. Расчёт контрольных сумм описан в параграфе 6.8. Протокол SCTP использует алгоритм CRC32c, описанный в Приложении A.

3.2. Описание поля Chunk

На рисунке показан формат блоков (chunk), передаваемых в пакетах SCTP. Каждый блок содержит поле Chunk Type, зависящие от типа флаги (Chunk Flags), поле размера Chunk Length и поле данных Chunk Value.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Chunk Type  | Chunk  Flags  |        Chunk Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                          Chunk Value                          /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Type – 8 битов (целое число без знака)

Это поле указывает тип блока, содержащегося в поле Chunk Value. Поле типа может содержать значения от 0 до 254. Значение 255 зарезервировано для будущего использования в качестве расширения.

Значения идентификаторов типа приведены в таблице.

Таблица 1. Типы блоков.

ID Тип блока ID Тип блока
0 Пользовательские данные (DATA) 12 Резерв для Explicit Congestion Notification Echo (ECNE)9
1 Инициализация (INIT) 13 Резерв для Congestion Window Reduced (CWR)
2 Подтверждение инициирования (INIT ACK) 14 Окончание работы завершен0 (SHUTDOWN COMPLETE)
3 Выборочное подтверждение (SACK) 15 – 62 Не выделены
4 Запрос Heartbeat (HEARTBEAT) 63 Резерв для определённых IETF расширений
5 Подтверждение Heartbeat (HEARTBEAT ACK) 64 – 126 Не выделены
6 Прерывание (ABORT) 127 Резерв для определённых IETF расширений
7 Завершение работы (SHUTDOWN) 128 – 190 Не выделены
8 Подтверждение завершения (SHUTDOWN ACK) 191 Резерв для определённых IETF расширений
9 Ошибка при операции (ERROR) 192 – 254 Не выделены
10 State Cookie (COOKIE ECHO) 255 Резерв для определённых IETF расширений
11 Подтверждение Cookie (COOKIE ACK)

Коды Chunk Type выбраны таким образом, чтобы 2 старших бита определяли действие, которое следует предпринять конечной точке на приёмной стороне, если Chunk Type не удаётся распознать.

Таблица 2. Обработка неизвестных блоков.

00 Прекратить обработку данного пакета SCTP и отбросить нераспознанный блок и следующие за ним блоки.
01 Прекратить обработку данного пакета SCTP и отбросить нераспознанный блок и следующие за ним блоки, а также сообщить о неопознанном блоке в блоке ERROR с причиной ошибки Unrecognized Parameter Type.
10 Пропустить данный блок и продолжить обработку пакета.
11 Пропустить данный блок и продолжить обработку пакета, а также сообщить о неопознанном блоке в блоке ERROR с причиной ошибки Unrecognized Parameter Type.

Chunk Flags – 8 битов

Использование этих битов зависит от поля Chunk Type. Если в документе явно не указано иное, на передающей стороне все биты следует устанавливать в 0, а на приёмной – игнорировать.

Chunk Length – 16 битов (целое число без знака)

Размер блока в байтах с учётом полей Chunk Type, Chunk Flags, Chunk Length и Chunk Value. Для блоков с пустым Chunk Value поле размера имеет значение 4. Байты заполнения блока в поле Chunk Length не включаются, однако считаются байты заполнения имеющихся параметров переменного размера, за исключением последнего10.

Chunk Value – переменный размер

Поле Chunk Value содержит передаваемую в этом блоке информацию. Формат этого поля и способы его использования зависят от значения Chunk Type.

Общий размер блока (включая поля Type, Length и Value) должен быть кратным 4. Если размер блока не кратен 4, отправитель должен дополнить блок байтами со значением 0, не учитывая эти байты в поле Chunk Length. Заполнение размером долее 3 байтов недопустимо. Получатель должен игнорировать байты заполнения.

Подробное описание используемых в SCTP блоков приводится в параграфе 3.3. Руководства для создания расширений, определяемых IETF, приведены в параграфе 15.1.

3.2.1. Необязательные параметры и поля переменного размера

Блоки управления SCTP включают зависящий от типа блока заголовок с набором полей, за которым может следовать то или иное количество параметров. Необязательные параметры и поля переменной длины указываются в формате TLV11 как описано ниже.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Parameter Type        |      Parameter Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/                       Parameter Value                         /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Parameter Type – 16 битов (целое число без знака)

16-битовый идентификатор типа параметра и может принимать значения от 0 до 65534.

Значение 65535 зарезервировано для определяемых IETF расширений. Все значения, кроме перечисленных в данном документе при описании конкретных блоков SCTP, зарезервированы для использования IETF.

Parameter Length – 16 битов (целое число без знака)

Размер параметра в байтах с учётом полей Parameter Type, Parameter Length и Parameter Value. Для параметров с пустым полем Parameter Value поле размера имеет значение 4. Размер не учитывает байты заполнения.

Parameter Value – переменный размер

Поле Parameter Value содержит информацию, передаваемую с помощью данного параметра.

Общий размер параметра (включая поля Type, Length и Value) должен быть кратным 4. Если размер параметра не кратен 4, отправитель добавляет в конце (после Parameter Value) байты с нулевым значением. Байты заполнения не учитываются в поле размера. Для отправителя недопустимо использование более 3 байтов заполнения. Получатель должен игнорировать байты заполнения.

Поле Parameter Type кодируется так, чтобы два старших бита определяли действия, предпринимаемые обрабатывающей конечной точкой при обнаружении неизвестного типа параметра.

Таблица 3. Обработка неизвестных параметров.

00 Прекратить обработку данного параметра и следующих за ним параметров в этом блоке.
01 Прекратить обработку данного параметра и следующих за ним параметров в этом блоке, а также сообщить о неопознанном параметре, как указано в параграфе 3.2.2.
10 Пропустить данный параметр и продолжить обработку.
11 Пропустить данный параметр и продолжить обработку пакета, а также сообщить о неопознанном параметре, как указано в параграфе 3.2.2.

Следует отметить, что при получении блока INIT или INIT ACK во всех 4 случаях в ответ передаётся блок INIT ACK или COOKIE ECHO. Для случаев 00 и 01 обработка параметров после неизвестного параметра не производится, но уже обработанные параметры не отбрасываются.

Реальные параметры SCTP определяются в параграфах, посвящённых конкретным блокам SCTP. Правила для определённых IETF расширений параметров определены в параграфе 15.3. Отметим, что тип параметра должен быть уникальным для всех блоков. Например, тип параметра 5 используется для представления адресов IPv4 (см. параграф 3.3.2.1.1). Значение 5 в этом случае резервируется во всех блоках для представления адресов IPv4 и недопустимо его использование в ином смысле в любом другом блоке.

3.2.2. Уведомления о неизвестных параметрах

Если получатель блока INIT обнаруживает неизвестный параметр и сообщает о нем в соответствии с параграфом 3.2.1, он должен указать параметр(ы) в поле Unrecognized Parameter блока INIT ACK, передаваемого в ответ на INIT. Отметим, что если получатель блока INIT не организует ассоциацию (например, по причине нехватки ресурсов), поле Unrecognized Parameter не включается в блок ABORT, передаваемый в ответ на INIT.

Если получатель блока любого другого блока (например, INIT ACK) обнаруживает неизвестные параметры и сообщает о них в соответствии с параграфом 3.2.1, ему следует сгруппировать блок ERROR, содержащий поля Unrecognized Parameter с указанием причины ошибки, с блоком, передаваемым в ответ (например, COOKIE ECHO). Если получатель INIT ACK не группирует блок COOKIE ECHO с блоком ERROR, последний можно передать отдельно, но не раньше получения COOKIE ACK.

В любом случае передачи в пакете блока COOKIE ECHO он должен быть первым блоком.

3.3. Определения блоков SCTP

В этом разделе описываются форматы блоков SCTP различных типов.

3.3.1. Пользовательские данные (DATA) (0)

Для блоков DATA должен использоваться показанный на рисунке формат.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0    |  Res  |I|U|B|E|    Length                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              TSN                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Stream Identifier S      |   Stream Sequence Number n    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Payload Protocol Identifier                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/         User Data (последовательность n потока S)             /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Res – 4 бита

Отправителю следует заполнить это поле нулями, а получателю – игнорировать его.

I – 1 бит

Бит I (immediate) отправитель может устанавливать всякий раз, когда может при отправке блока DATA получить преимущество в результате отправки соответствующего блока SACK без задержки (см. раздел 4 в [RFC7053].

U – 1 бит

Флаг разупорядочения, устанавливаемый для блоков DATA, которые могут передаваться без сохранения порядка. Для таких блоков значение поля Stream Sequence Number не задаётся и получатель должен его игнорировать.

После сборки (если она требуется) неупорядоченные блоки DATA должны диспетчеризоваться на вышележащий уровень без попыток восстановления порядка, если флаг U имеет значение 1.

Если неупорядоченное пользовательское сообщение фрагментируется, для каждого фрагмента должен устанавливаться флаг U = 1.

B – 1 бит

Флаг первого фрагмента пользовательского сообщения.

E – 1 бит

Флаг последнего фрагмента пользовательского сообщения.

Length – 16 битов (целое число без знака)

Размер блока DATA в байтах от начала поля типа и до конца поля User Data (без учёта байтов заполнения). Для блока DATA с одним байтом пользовательских данных Length = 17 (17 байтов). Блок DATA с полем User Data размера L будет иметь поле Length со значением (16 + L), где L должно быть больше 0.

TSN – 32 бита (целое число без знака)

Порядковый номер TSN для блока DATA. Значения номеров TSN могут находиться в диапазоне от 0 до 4294967295 (232 – 1). После достижения TSN максимального значения 4294967295 нумерация продолжается с 0.

Stream Identifier S – 16 битов (целое число без знака)

Идентификатор потока, к которому относится блок данных.

Stream Sequence Number n – 16 битов (целое число без знака)

Порядковый номер пользовательских данных в потоке S. Допустимые значения лежат в диапазоне от 0 до 65535.

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

Payload Protocol Identifier – 32 бита (целое число без знака)

Заданный приложением или вышележащим протоколом идентификатор протокола данных. SCTP получает идентификатор от вышележащего уровня и передаёт его партнёру. Значение идентификатора не используется протоколом SCTP, но может быть использовано некоторыми сетевыми объектами и приложениями у партнёра для идентификации типа информации, передаваемой в блоке DATA. Это поле должно передаваться даже для фрагментированных блоков DATA (чтобы обеспечить доступность информации для агентов в сети). Отметим, что реализации SCTP не работают с этим полем и за преобразование между сетевым и хостовым порядком байтов в этом поле отвечает вышележащий уровень.

Значение 0 говорит, что протокол вышележащего уровня не указал идентификатор протокола для этого блока.

User Data – переменный размер

Поле переменной длины, содержащее пользовательскую информацию. Реализация протокола должна дополнять поле до 4-байтовой границе путём добавления байтов с нулевым значением. Недопустимо учитывать байты заполнения в поле размера блока. Для отправителя недопустимо использование более 3 байтов заполнения.

В нефрагментированных пользовательских сообщениях должны устанавливаться (1) оба флага B и E. Нулевые значения обоих флагов устанавливаются в средних (не первом и не последнем) фрагментах пакета, как показано в таблице 4.

Таблица 4. Состояния флагов B и E.

B E Описание
1 0 Первый фрагмент.
0 0 Один из средних фрагментов.
0 1 Последний фрагмент.
1 1 Нефрагментированное сообщение.

При фрагментировании пользовательского сообщения на множество блоков получатель использует TSN для сборки сообщения. Это означает, что TSN фрагментов должны устанавливаться в строгом порядке.

TSN в блоках DATA следует строго упорядочивать.

Примечание. Можно применять расширение, описанное в [RFC8260] для снижения блокировки head-of-line при передаче больших пользовательских сообщений.

3.3.2. Инициализация (INIT) (1)

Этот блок используется для создания ассоциации SCTP между парой конечных точек. Формат блока INIT показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 1    |  Chunk Flags  |      Chunk Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Initiate Tag                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Advertised Receiver Window Credit (a_rwnd)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Number of Outbound Streams   |  Number of Inbound Streams    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Initial TSN                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/     Необязательные параметры и параметры переменной длины     /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Блок INIT содержит перечисленные ниже параметры. Если явно не сказано иное, каждый параметр должен включаться в блок INIT в одном экземпляре.

Таблица 5. Параметры фиксированного размера в блоках INIT.

Фиксированные параметры Статус
Initiate Tag Обязательный
Advertised Receiver Window Credit Обязательный
Number of Outbound Streams Обязательный
Number of Inbound Streams Обязательный
Initial TSN Обязательный

Таблица 6. Параметры переменного размера в блоках INIT.

Переменные параметры Статус Тип
IPv4 Address12 Необязательный 5
IPv6 Address1 Необязательный 6
Cookie Preservative Необязательный 9
Reserved for ECN Capable13 Необязательный 32768 (0x8000)
Host Name Address14 Отменён 11
Supported Address Types15 Необязательный 12

Если принят блок INIT со всеми обязательными параметрами, заданными для блока INIT, получателю следует обработать блок INIT и возвратить отправителю INIT ACK. Получатель блока INIT может позднее сгруппировать блок ERROR с блоком COOKIE ACK. Однако ограниченная реализация может возвратить блок ABORT в ответ на блок INIT.

Поле Chunk Flags в INIT является резервным и отправителю следует устанавливать все его биты в 0, а получателю – игнорировать их.

Initiate Tag – 32 бита (целое число без знака)

Получатель INIT (отвечающая сторона) записывает значение параметра Initiate Tag. Это значение должно включаться в поле Verification Tag каждого пакета SCTP, который получатель данного блока INIT будет передавать через эту ассоциацию.

Поле Initiate Tag может содержать любые значения кроме 0. Рекомендации по выбору значений этого тега приводятся в параграфе 5.3.1.

Если в принятом блоке INIT значение Initiate Tag = 0, получатель должен отбрасывать пакет без иных действий.

Advertised Receiver Window Credit (a_rwnd) – 32 бита (целое число без знака)

Размер (в байтах) выделенного буферного пространства, которое отправитель INIT зарезервировал для данной ассоциации.

Для Advertised Receiver Window Credit недопустимы значения меньше 1500.

Получатель блока INIT с a_rwnd < 1500 должен отбросить пакет, ему следует передать в ответ пакет с блоком ABORT и использовать Initiate Tag как Verification Tag, а также недопустимо менять состояние оюбой имеющейся ассоциации.

В течение срока существования ассоциации не следует снижать размер этого буфера (т. е., буфер может быть удалён из ассоциации), однако конечная точка может изменить размер a_rwnd, передаваемого в SACK.

Number of Outbound Streams (OS) – 16 битов (целое число без знака)

Число исходящих потоков, которые отправитель блока INIT желает открыть для данной ассоциации. Для этого параметра недопустимо использование значения 0.

Получатель блока INIT с OS = 0 должен отбросить пакет, ему следует передать в ответ пакет с блоком ABORT и использовать Initiate Tag как Verification Tag, а также недопустимо менять состояние оюбой имеющейся ассоциации.

Number of Inbound Streams (MIS) – 16 битов (целое число без знака)

Максимальное число потоков, которые отправитель данного блока INIT готов принять от партнёра для этой ассоциации16. Использование значений 0 в данном поле недопустимо.

Получатель блока INIT с с MIS = 0 должен отбросить пакет, ему следует передать в ответ пакет с блоком ABORT и использовать Initiate Tag как Verification Tag, а также недопустимо менять состояние оюбой имеющейся ассоциации.

Initial TSN (I-TSN) – 32 бита (целое число без знака)

Определяет начальное значение TSN, которое будет использовать отправитель. Диапазон допустимых значений – от 0 до 4294967295 и следует устанавливать случайное значение из этого диапазона. Для выбора случайного значения можно использовать методы, описанные в [RFC4086].

3.3.2.1. Необязательные параметры и параметры переменного размера в блоке INIT

Перечисленные ниже параметры используют формат TLV, как описано в параграфе 3.2.1. Любые комбинации параметров TLV должны размещаться в блоке после параметров фиксированного размера, описанных в предыдущем параграфе.

3.3.2.1.1. Параметр IPv4 Address (5)
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type = 5               |      Length = 8               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        IPv4 Address                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4 Address – 32 бита (целое число без знака)

Адрес IPv4 передающей стороны в двоичном формате.

3.3.2.1.2. Параметр IPv6 Address (6)
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Type = 6           |          Length = 20          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         IPv6 Address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6 Address – 128 битов (целое число без знака)

Адрес IPv6 [RFC2460] передающей стороны в двоичном формате.

Отправителю недопустимо использовать адреса отображённые на IPv4 адреса IPv6 [RFC4291], вместо этого следует применять параметр IPv4 Address для адреса IPv4.

Вместе с Source Port Number в общем заголовке SCTP адрес IPv4 или IPv6 определяет адрес транспортного уровня, который отправитель блока INIT будет поддерживать для создаваемой ассоциации. Т. е., этот IP-адрес в течении срока действия данной ассоциации может появляться в поле отправителя дейтаграмм IP, передаваемых отправителем данного блока INIT, и может использоваться в качестве IP-адреса получателя в дейтаграммах, передаваемых получателем данного блока INIT.

В блоке INIT можно указывать более одного адреса IP, если отправитель INIT является многодомным хостом. Кроме того, многодомные хосты могут быть подключены к разнотипным сетям и в блоках INIT могут указываться одновременно адреса IPv4 и IPv6.

Если INIT содержит хотя бы один параметр IP Address, адрес отправителя в дейтаграмме, содержащей блок INIT, и любые адреса, указанные в INIT, могут использоваться партнёром при ответе в качестве адреса получателя. Если INIT не содержит параметров IP Address, получившая блок INIT конечная точка должна использовать адрес отправителя в заголовке дейтаграммы IP, содержащей блок INIT, как единственный адрес партнёра в данной ассоциации.

Отметим, что отсутствие параметров IP Address в блоках INIT и INIT ACK упрощает организацию ассоциаций при работе через системы трансляции адресов (Network Address Translation или NAT).

3.3.2.1.3. Параметр Cookie Preservative (9)

Отправителю блока INIT следует использовать этот параметр для того, чтобы предложить получателю INIT увеличение срока действия State Cookie.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type = 9             |          Length = 8           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Suggested Cookie Life-span Increment (мсек.)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Suggested Cookie Life-Span Increment – 32 бита (целое число без знака)

Показывает получателю размер увеличения срока действия cookie в миллисекундах.

Этот необязательный параметр отправителю следует добавлять в блок INIT при попытке создания ассоциации после отказа в предыдущей попытке по причине ошибки в работе stale cookie. Получатель может проигнорировать предложенное увеличение срока действия cookie в соответствии со своей политикой безопасности.

3.3.2.1.4. Параметр Host Name Address (11)

Отправителю блока INIT или INIT ACK недопустимо включать этот параметр, поскольку его использование отменено. Получатель блока INIT или INIT ACK с параметром Host Name Address должен передать блок ABORT и может включить в него причину Unresolvable Address.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type = 11            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                          Host Name                            /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Host Name – переменный размер

Это поле содержит имя хоста с использованием синтаксиса, определённого в параграфе 2.1 RFC1123 [RFC1123]. Метод преобразования имени в адрес выходит за рамки спецификации протокола SCTP.

Имя хоста должно содержать хотя бы один завершающий null-символ, который учитывается в поле размера.

3.3.2.1.5. Параметр Supported Address Types (12)
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Type = 12            |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Address Type #1        |        Address Type #2        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            ......                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Отправитель блока INIT использует этот параметр для перечисления всех поддерживаемых им типов адресов.

Address Type – 16 битов (целое число без знака)

В этом поле указываются типы адреса из соответствующих TLV (например, IPv4 = 5, IPv6 = 6). Значение, указывающее параметр Host Name Address, недопустимо использовать при передачи, а при получении оно должно игнорироваться.

3.3.3. Подтверждение инициализации (INIT ACK) (2)

Блок INIT ACK используется для подтверждения инициирования ассоциации SCTP. Формат блока показан на рисунке.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 2    |  Chunk Flags  |      Chunk Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Initiate Tag                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Advertised Receiver Window Credit                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Number of Outbound Streams   |  Number of Inbound Streams    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Initial TSN                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\                                                               \
/     Необязательные параметры и параметры переменной длины     /
\                                                               \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Параметры INIT ACK форматируются подобно параметрам блока INIT и показаны в таблицах ниже.

Таблица 7. Параметры фиксированного размера в блоках INIT ACK.

Фиксированные параметры Статус
Initiate Tag Обязательный
Advertised Receiver Window Credit Обязательный
Number of Outbound Streams Обязательный
Number of Inbound Streams Обязательный
Initial TSN Обязательный

Блоки INIT ACK содержат два дополнительных параметра – State Cookie и Unrecognized Parameter.

Таблица 8. Параметры переменного размера в блоках INIT ACK.

Переменные параметры Статус Тип
State Cookie Обязательный 7
IPv4 Address17 Необязательный 5
IPv6 Address1 Необязательный 6
Unrecognized Parameter Необязательный 8
Reserved for ECN Capable18 Необязательный 32768 (0x8000)
Host Name Address19 Отменён 11

Поле Chunk Flags в блоках INIT ACK является резервным, в нем следует устанавливать 0 при передаче и игнорировать при получении.

Initiate Tag – 32 бита (целое число без знака)

Получатель блока INIT ACK записывает значение параметра Initiate Tag. Это значение должно помещаться в поле Verification Tag каждого пакета SCTP, который получатель INIT ACK будет передавать в данной ассоциации.

Для Initiate Tag недопустимо использование значения 0. Выбор значений параметра Initiate Tag рассматривается в параграфе 5.3.1.

Если в полученном блоке INIT ACK параметр Initiate Tag = 0, приёмная сторона должна отбросить TCB и ей следует передать блок ABORT с установленным флагом T. Если такой блок INIT ACK получен в состоянии, отличном от CLOSED и COOKIE-WAIT, его следует просто отбросить (см. параграф 5.2.3).

Advertised Receiver Window Credit (a_rwnd) – 32 бита (целое число без знака)

Это значение указывает размер буфера (в байтах), выделенного отправителем INIT ACK для данной ассоциации.

Недопустимо устанавливать для этого параметра значение < 1500.

Получатель блока INIT ACK с a_rwnd < 1500 должен отбросить пакет, следует передать блок ABORT и использовать Initiate Tag в качестве Verification Tag. Менять состояние ассоциации недопустимо.

В течение срока действия ассоциации не следует уменьшать размер буфера (т. е., выделенный буфер не удаляется из ассоциациеи), однако конечная точка может изменить значение a_rwnd в блоках SACK.

Number of Outbound Streams (OS) – 16 битов (целое число без знака)

Число исходящих потоков, которые отправитель INIT ACK желает создать для данной ассоциации. Недопустимо устанавливать для этого параметра значение 0, недопустимо также устанавливать значение, превышающее значение MIS, переданное в блоке INIT.

Если конечная точка в состоянии COOKIE-WAIT получает INIT ACK с параметром OS = 0, она должна отбросить TCB и следует передать блок ABORT. Если такой блок INIT ACK получен в состоянии, отличном от CLOSED и COOKIE-WAIT, его следует просто отбросить (см. параграф 5.2.3).

Number of Inbound Streams (MIS) – 16 битов (целое число без знака)

Максимальное число потоков, которые отправитель INIT ACK позволяет создать удалённому партнёру в данной ассоциации20. Недопустимо использование нулевого значения для этого параметра.

Если конечная точка в состоянии COOKIE-WAIT получает INIT ACK с параметром MIS = 0, она должна отбросить TCB и следует передать блок ABORT. Если такой блок INIT ACK получен в состоянии, отличном от CLOSED и COOKIE-WAIT, его следует просто отбросить (см. параграф 5.2.3).

Initial TSN (I-TSN) – 32 бита (целое число без знака)

Начальный номер TSN, который отправитель INIT ACK будет использовать. Корректные значения лежат в диапазоне от 0 до 4294967295 и следует устанавливать случайное значение из этого диапазона. Для выбора случайного значения можно использовать методы, описанные в [RFC4086].

Примечание для разработчиков. Реализации должны быть готовы к получению INIT ACK достаточно большого (более 1500 байтов) размера по причине переменного размера State Cookie и списка адресов. Например, если отвечающая на INIT сторона имеет 1000 адресов IPv4, которые она желает сообщить, для них потребуется не менее 8000 байтов в блоке INIT ACK.

Если принят блок INIT ACK со всеми обязательными для него параметрами, получателю следует обработать блок INIT ACK и передать в ответ COOKIE ECHO. Получатель INIT ACK может группировать блок ERROR с блоком COOKIE ECHO. Однако ограниченные реализации могут передавать блок ABORT в ответ на INIT ACK.

Вместе с параметром Source Port Number в общем заголовке SCTP параметр IP Address в INIT ACK указывает получателю INIT ACK адрес транспортного уровня, который отправитель блока INIT ACK будет поддерживать в течение срока действия создаваемой ассоциации.

Если INIT ACK содержит хотя бы один параметр IP Address, указанные в нем адреса вместе с адресом отправителя в заголовке дейтаграммы IP, содержащей INIT ACK, могут использоваться получателем INIT ACK блока в качестве адресов получателя для этой ассоциации. Если в INIT ACK нет параметра IP Address, получатель блока INIT ACK должен использовать адрес отправителя содержащей этот блок дейтаграммы IP в качестве единственного адреса получателя для этой ассоциации.

Параметры State Cookie и Unrecognized Parameters используют формат TLV в соответствии с определением параграфа 3.2.1 и описаны ниже. Остальные поля соответствуют одноимённым полям блока INIT.

3.3.3.1. Необязательные параметры и параметры переменной длины в INIT ACK

Для State Cookie и Unrecognized Parameters применяется формат TLV, как определено в параграфе 3.2.1 и описано ниже. Параметр IPv4 Address описан в параграфе 3.3.2.1.1, а IPv6 Address – в 3.3.2.1.2. Параметр Host Name Address, описанный в параграфе 3.3.2.1.4, недопустимо включать в блок INIT ACK. Все поля TLV должны размещаться после полей фиксированного размера (они определены в предыдущем параграфе).

3.3.3.1.1. Параметр State Cookie (7)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cookie – переменный размер

Значение этого параметра должно включать всю необходимую информацию о состоянии и параметрах, требуемую отправителю данного блока INIT ACK для создания ассоциации, а также код аутентификации сообщения (Message Authentication Code или MAC). Определение State Cookie дано в параграфе 5.1.3.

3.3.3.1.2. Параметр Unrecognized Parameter (8)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Parameter / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Parameter – переменный размер

Это поле содержит нераспознанный параметр (полный TLV), скопированный из блока INIT.

3.3.4. Селективное подтверждение (SACK) (3)

Этот блок передаётся партнёру для подтверждения приёма блоков DATA и информирования партнёра о пропусках в порядковых номерах блоков DATA, представленных в TSN.

Блок SACK должен включать поля Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks и Number of Duplicate TSNs.

По определению поле Cumulative TSN Ack содержит значение последнего номера TSN, полученного до того, как была нарушена последовательность принятых TSN. Следующее за этим значение TSN (на 1 больше) ещё не получено стороной, передающей SACK. Этот параметр, следовательно, подтверждает доставку всех TSN, номера которых не превышают значение поля.

Обработка a_rwnd получателем SACK рассмотрена в параграфе 6.2.1

SACK может также содержать параметры Gap Ack Block, каждый из которых подтверждает последовательность TSN, полученных после прерывания основной последовательности номеров TSN. Блокам Gap Ack Block следует быть изолированными, т. е. TSN непосредственно перед и сразу после Gap Ack Block не получены. По определению все TSN, подтверждённые Gap Ack Block, имеют значения, превышающие Cumulative TSN Ack.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ … \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ … \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Заполняется нулями на передающей стороне и игнорируется на приёмной.

Cumulative TSN Ack – 32 бита (целое число без знака)

Наибольшее значение TSN, такое что все значения, не превышающие его, уже получены, а следующее не получено. Если блоков DATA ещё не получено, это поле содержит партнерское значение Initial TSN – 1.

Advertised Receiver Window Credit (a_rwnd) – 32 бита (целое число без знака)

Обновлённое значение размера (в байтах) приёмного буфера на стороне отправителя данного блока SACK (см. параграф 6.2.1).

Number of Gap Ack Blocks – 16 битов (целое число без знака)

Число параметров Gap Ack Block, включённых в SACK.

Number of Duplicate TSNs – 16 битов

Число дубликатов TSN, полученных конечной точкой. Каждый дубликат TSN указывается в последующем списке Gap Ack Block.

Блоки Gap Ack

Эти поля содержат параметры Gap Ack Block, число которых задано значением поля Number of Gap Ack Blocks. Все блоки DATA с номерами TSN не меньше Cumulative TSN Ack + Gap Ack Block Start и не больше Cumulative TSN Ack + Gap Ack Block End из каждого Gap Ack Block предполагаются принятыми без ошибок.

Gap Ack Block Start – 16 битов (целое число без знака)

Показывает стартовое смещение TSN данного Gap Ack Block. Для расчёта реального номера TSN это смещение добавляется к значению параметра Cumulative TSN Ack. Рассчитанное таким способом значение TSN указывает первый номер TSN в данном Gap Ack Block, который был получен.

Gap Ack Block End – 16 битов (целое число без знака)

Показывает финишное смещение TSN данного Gap Ack Block. Для расчёта реального номера TSN это смещение добавляется к значению параметра Cumulative TSN Ack. Рассчитанное таким способом значение TSN указывает последний номер TSN в данном Gap Ack Block для полученного блока DATA.

Предположим для примера, что недавно полученные блоки DATA в момент принятия решения о передаче SACK образуют последовательность, показанную на рисунке.

———- | TSN=17 | ———- | | <- не получен ———- | TSN=15 | ———- | TSN=14 | ———- | | <- не получен ———- | TSN=12 | ———- | TSN=11 | ———- | TSN=10 | ———-
Тогда часть блока SACK должна включать поля, показанные на следующем рисунке (предполагается, что новое значение a_rwnd = 4660).

+——————————–+ | Cumulative TSN Ack = 12 | +——————————–+ | a_rwnd = 4660 | +—————-+—————+ | num of block=2 | num of dup=0 | +—————-+—————+ |block #1 strt=2 |block #1 end=3 | +—————-+—————+ |block #2 strt=5 |block #2 end=5 | +—————-+—————+

Duplicate TSN – 32 бита (целое число без знака)

Показывает количество случаев, когда номер TSN был принят как дубликат, с момента передачи последнего блока SACK. При получении каждого дубликата TSN (до момента передачи SACK) этот дубликат добавляется в список. Счётчик дубликатов сбрасывается в 0 после отправки каждого блока SACK.

Например, если получатель принял TSN 19 трижды, номер 19 будет указан два раза в блоке SACK. После отправки SACK, если TSN 19 будет принят снова, он будет указан в списке следующего блока SACK.

3.3.5. Запрос Heartbeat (HEARTBEAT) (4)

Конечной точке следует передавать блок HEARTBEAT (HB) своему партнёру для проверки его доступности через конкретный транспортный адрес, заданный для данной ассоциации.

Поле параметров содержит Heartbeat Information – не анализируемую (opaque) структуру данных переменного размера, понятную только отправителю.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Chunk Flags | Heartbeat Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (переменный размер) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Heartbeat Length – 16 битов (целое число без знака)

Размер блока в байтах с учётом заголовка и поля Heartbeat Information.

Heartbeat Information – переменный размер

Параметр переменного размера, который использует формат, описанный в параграфе 3.2.1.

Таблица 9. Параметры переменного размера в блоке HEARTBEAT.

Параметр Статус Тип
Heartbeat Info Обязательный 1

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Info Type=1 | HB Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Sender-Specific Heartbeat Info / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В поле Sender-Specific Heartbeat Info обычно следует включать информацию о текущем времени отправителя на момент передачи данного блока HEARTBEAT и транспортный адрес получателя этого блока (см. параграф 8.3). Эта информация просто «отражается» получателем в его блоке HEARTBEAT ACK (см. параграф 3.3.6). Отметим также, что сообщения HEARTBEAT служат для проверки доступности и верификации пути (см. параграф 5.4). При использовании блока HEARTBEAT для проверки пути он должен включать случайное значение не менее 64 битов (см. рекомендации по созданию случайных чисел в [RFC4086]).

3.3.6. Подтверждение Heartbeat (HEARTBEAT ACK) (5)

Конечная точка должна передавать такой блок в ответ на запрос HEARTBEAT (см. параграф 8.3). Пакет с блоком HEARTBEAT ACK всегда передаётся по тому адресу IP, который был указан в заголовке дейтаграммы, содержавшей запрос HEARTBEAT, на который передаётся отклик.

Поле параметра содержит «непрозрачную» структуру данных с переменным размером.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Chunk Flags | Heartbeat Ack Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (переменный размер) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Heartbeat Length – 16 битов (целое число без знака)

Задаёт размер блока в байтах с учётом заголовка и поля Heartbeat Information.

Heartbeat Information – переменный размер

Это поле должно содержать параметр Heartbeat Information из запроса Heartbeat, на который отвечает данный блок Heartbeat Acknowledgement.

Таблица 10. Параметры переменного размера в блоке HEARTBEAT ACK.

Параметр Статус Тип
Heartbeat Info Обязательный 1

3.3.7. Разрыв ассоциации (ABORT) (6)

Блок ABORT передаётся партнёру для разрыва ассоциации. Блок ABORT может содержать параметры Error Cause, информирующие партнёра о причинах разрыва ассоциации. Недопустимо группировать блоки DATA с блоком ABORT. Блоки управления (кроме INIT, INIT ACK и SHUTDOWN COMPLETE) могут группироваться с ABORT, но эти блоки должны размещаться перед блоком ABORT в пакете SCTP, поскольку в противном случае получатель проигнорирует их.

Если конечная точка получает блок ABORT с некорректным форматом или TCB не найден, такой блок должен быть просто отброшен. Более того, в некоторых случаях для получившей такой блок ABORT конечной точки недопустимо передавать в ответ свой блок ABORT.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 |Reserved |T| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Причины ошибок (Error Cause) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Reserved – 7 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

T – 1 бит

Бит T сбрасывается в 0, если отправитель заполнил поле Verification Tag, ожидаемое партнёром. Если в Verification Tag используется «отражённое» значение, должно устанавливаться T = 1. Отражение означает, что переданное значение Verification Tag совпадает с принятым.

Length – 16 битов (целое число без знака)

Указывает размер блока в байтах с учётом заголовка и всех полей Error Cause.

Определения причин ошибки (Error Cause) приведены в параграфе 3.3.10.

Примечание. Для проверки этого типа блоков применяются специальные правила, описанные в параграфе 8.5.1.

3.3.8. Завершение ассоциации (SHUTDOWN) (7)

Конечная точка ассоциации должна использовать этот блок для аккуратного завершения работы ассоциации. Формат блока описан ниже.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Chunk Flags | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Length – 16 битов (целое число без знака)

Показывает размер параметра и имеет значение 8.

Cumulative TSN Ack – 32 бита (целое число без знака)

Этот параметр содержит номер последнего TSN, принятого без пропусков в нумерации.

Примечание. Поскольку блок SHUTDOWN не содержит параметров Gap Ack Block, он не может служить подтверждением TSN, принятых с нарушением порядка. В блоках SACK отсутствие Gap Ack Block, которые были указаны в предыдущих сообщениях, показывает, что получатель данных отказался от соответствующих блоков DATA.

Поскольку SHUTDOWN не содержит Gap Ack Block, получателю блока SHUTDOWN недопустимо интерпретировать отсутствие Gap Ack Block как отказ (см. параграф 6.2).

Отправитель блока SHUTDOWN может сгруппировать его с блоком SACK для указания пропусков в полученных TSN.

3.3.9. Подтверждение закрытия ассоциации (SHUTDOWN ACK) (8)

Этот блок должен использоваться для подтверждения приёма блока SHUTDOWN при завершении процесса закрытия, описанного в параграфе 9.2.

Блок SHUTDOWN ACK не содержит параметров.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

3.3.10. Ошибка при работе (ERROR) (9)

Конечные точки передают блоки этого типа для уведомления партнёра о некоторых типах ошибок. Блок содержит один или несколько кодов ошибок. Приём Operational Error не обязывает партнёра разрывать ассоциацию, однако такие блоки могут передаваться вместе с блоком ABORT в качестве отчёта о причине разрыва. Параметры блока описаны ниже.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Одно или несколько полей Error Cause / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Length – 16 битов (целое число без знака)

Указывает размер блока в байтах с учётом заголовка и всех полей Error Cause.

Причины ошибок указываются как параметры переменного размера в соответствии с параграфом 3.2.1.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cause-Specific Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code – 16 битов (целое число без знака)

Указывает код причины, которая вызвала передачу блока.

Таблица 11. Коды причин.

Код Описание Код Описание
1 Некорректный идентификатор потока 8 Нераспознанные параметры
2 Отсутствие обязательного параметра 9 Отсутствие пользовательских данных
3 Ошибка Stale Cookie 10 Получение Cookie в процессе закрытия
4 Нехватка ресурсов 11 Перезапуск ассоциации с новыми адресами
5 Не удалось преобразовать адрес 12 Инициированный пользователем разрыв
6 Нераспознанный тип блока 13 Протокольное нарушение
7 Некорректный обязательный параметр

Cause Length – 16 битов (целое число без знака)

Указывает размер параметра в байтах с учётом полей Cause Code, Cause Length и Cause-Specific Information

Cause-Specific Information – переменный размер

В этом поле указываются сведения об ошибке.

Причины ошибок SCTP рассматриваются в параграфах 3.3.10.1 – 3.3.10.13. Рекомендации по определению новых типов ошибок для IETF даны в параграфе 15.4.

3.3.10.1. Неприемлемый идентификатор потока (1)

Показывает, что конечная точка получила блок DATA, переданный в несуществующий поток.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=1 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stream Identifier – 16 битов (целое число без знака)

Значение Stream Identifier из блока DATA, вызвавшего ошибку.

Reserved – 16 битов

Зарезервированное поле. Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

3.3.10.2. Отсутствует обязательный параметр (2)

Говорит об отсутствии одного или нескольких обязательных параметров TLV в принятом блоке INIT или INIT ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=2 | Cause Length=8+N*2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of missing params=N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #1 | Missing Param Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #N-1 | Missing Param Type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Number of Missing params – 32 бита (целое число без знака)

Число отсутствующих параметров, перечисленных в Cause-Specific Information (поля Missing Param Type).

Missing Param Type – 16 битов (целое число без знака)

Каждое поле содержит пропущенный обязательный параметр.

3.3.10.3. Ошибка Stale Cookie (3)

Говорит о получении корректного значения State Cookie с истекшим сроком.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=3 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measure of Staleness (мксек.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Measure of Staleness – 32 бита (целое число без знака)

В этом поле указывается разница между текущим временем и временем окончания срока действия State Cookie (в микросекундах с округлением).

Отправитель этого сообщения может указать время, прошедшее после завершения срока действия State Cookie, отличным от нуля значением поля Measure of Staleness. Если отправитель не хочет передавать эти сведения, ему следует установить нулевое значение в поле Measure of Staleness.

3.3.10.4. Нехватка ресурсов (4)

Указывает нехватку ресурсов у отправителя и передаётся обычно в комбинации с блоком ABORT или в нем.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=4 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.5. Нераспознаваемый адрес (5)

Говорит о том, что отправителю не удалось распознать указанный адресный параметр (например, отправитель не поддерживает этот тип адресов) и передаётся обычно в комбинации с блоком ABORT или в нем.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=5 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unresolvable Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unresolvable Address – переменный размер

Поле Unresolvable Address содержит полное значение параметра TLV, задающего адрес (или параметра Host Name), который не удалось распознать, или имя хоста.

3.3.10.6. Не распознан тип блока (6)

Эта информация передаётся отправителю блока, если получатель не смог определить тип блока и два старших бита поля Chunk Type имеют значение 01 или 11.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=6 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Chunk – переменный размер

Поле Unrecognized Chunk содержит нераспознанный блок из пакета SCTP, включая поля Chunk Type, Chunk Flags и Chunk Length.

3.3.10.7. Недействительный обязательный параметр (7)

Это сообщение передаётся отправителю блока INIT или INIT ACK, когда один или несколько обязательных параметров имеют недействительные значения.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=7 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.8. Нераспознанные параметры (8)

Это сообщение возвращается отправителю блока INIT ACK, если получателю не удаётся распознать один или несколько необязательных параметров TLV в блоке INIT ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=8 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Parameters – переменный размер

Поле Unrecognized Parameters содержит нераспознанные параметры, скопированные из блока INIT ACK полностью в форме TLV. Это сообщение обычно передаётся в блоках ERROR, объединённых с блоком COOKIE ECHO, при отклике на INIT ACK, когда отправитель блока COOKIE ECHO желает сообщить о нераспознанных параметрах.

3.3.10.9. Нет пользовательских данных (9)

Это сообщение передаётся отправителю блока DATA, если принятый блок не содержит пользовательских данных.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=9 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / TSN value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TSN – 32 бита (целое число без знака)

Значение поля TSN из блока DATA, принятого без пользовательских данных.

Это сообщение обычно передаётся в блоке ABORT (см. параграф 6.2).

3.3.10.10. Получение Cookie во время процедуры закрытия (10)

Это сообщение говорит о приёме COOKIE ECHO в то время, когда конечная точка находилась в состоянии SHUTDOWN-ACK-SENT. Обычно этот код возвращается в блоке ERROR, сгруппированном с повторным блоком SHUTDOWN ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=10 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.11. Перезапуск ассоциации с новыми адресами (11)

Был получен блок INIT в существующей ассоциации и этот блок добавляет адреса, которые раньше не были частью данной ассоциации. Новые адреса указываются в коде ошибки. Этот сообщение обычно передаётся как часть блока ABORT, отвергающего INIT (см. параграф 5.2).

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=11 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / New Address TLVs / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Примечание. Каждый элемент New Address TLV является точной копией связанного с новым адресом TLV из блока INIT, включая Parameter Type и Parameter Length.

3.3.10.12. Разрыв по инициативе пользователя (12)

Эта причина ошибки может включаться в блоки ABORT, передаваемые по запросам вышележащего уровня. Этот уровень может указать значение Upper Layer Abort Reason, которое без изменения передаётся протоколом SCTP и может быть доставлено протоколу прикладного уровня у партнёра.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.13. Протокольное нарушение (13)

Эта причина ошибки может включаться в блоки ABORT, передаваемые в результате обнаружения конечной точкой SCTP нарушения партнёром протокола, которое не может быть описано причинами, указанными в параграфах 3.3.10.1 – 3.3.10.12. Реализация может предоставить дополнительную информацию о нарушении протокола.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=13 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Additional Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.11. Cookie Echo (COOKIE ECHO) (10)

Этот блок используется только в процессе создания ассоциации. Он передаётся инициатором удалённому партнёру для завершения процесса создания ассоциации. Такой блок должен предшествовать любому блоку DATA, передаваемому через ассоциацию, но может быть сгруппирован с одним или несколькими блоками DATA в один пакет.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 |Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Length – 16 битов (целое число без знака)

Указывает размер блока в байтах, включая 4 байта заголовка блока и размер Cookie.

Cookie – переменный размер

Это поле должно содержать точную копию параметра State Cookie, полученного в предыдущем блоке INIT ACK.

Реализациям протокола следует стремиться к уменьшению размера cookie в целях обеспечения взаимодействия.

Примечание. Блок Cookie Echo не включает параметр State Cookie, вместо этого данные из поля Parameter Value в State Cookie становятся Chunk Value в Cookie Echo. Это позволяет реализациям поменять лишь два первых байта параметра State Cookie, чтобы сделать из него блок COOKIE ECHO.

3.3.12. Подтверждение Cookie (COOKIE ACK) (11)

Этот тип блоков используется только при создании ассоциации и служит подтверждением приёма блока COOKIE ECHO. Данный блок должен предшествовать любому блоку DATA или SACK в данной ассоциации, но может группироваться с одним или несколькими блоками DATA или блоком SACK в одном пакете SCTP.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags – 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

3.3.13. Закрытие ассоциации завершено (SHUTDOWN COMPLETE) (14)

Этот тип блоков должен использоваться для подтверждения приёма блока SHUTDOWN ACK при завершении ассоциации (см. параграф 9.2).

Блок SHUTDOWN COMPLETE не содержит параметров.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 14 |Reserved |T| Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags – 8 битов

Reserved – 7 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

T – 1 бит

Бит T сбрасывается в 0, если отправитель заполнил поле Verification Tag, ожидаемое партнёром. Если в Verification Tag используется «отражённое» значение, должно устанавливаться T = 1. Отражение означает, что переданное значение Verification Tag совпадает с принятым.

Примечание. Для проверки этого типа применяются специальные правила, описанные в параграфе 8.5.1.

4. Диаграмма состояний ассоциации SCTP

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

  • вызовы пользовательских примитивов SCTP (например, [ASSOCIATE], [SHUTDOWN], [ABORT]);
  • приём управляющих блоков INIT, COOKIE ECHO, ABORT, SHUTDOWN и т. п.;
  • тайм-ауты.

—– ——– (из любого состояния) / \ / rcv ABORT [ABORT] rcv INIT | | | ———- или ———- ————— | v v удалить TCB snd ABORT генерация State \ +———+ удалить TCB Cookie и передача —| CLOSED | INIT ACK +———+ / \ [ASSOCIATE] / \ ————— | | создать TCB | | snd INIT | | запустить таймер T1-init rcv корректн. | | COOKIE ECHO | v (1) —————- | +————+ создать TCB | | COOKIE-WAIT| (2) snd COOKIE ACK | +————+ | | | | rcv INIT ACK | | —————– | | snd COOKIE ECHO | | остановить таймер T1-init | | запустить таймер T1-cookie | v | +————–+ | | COOKIE-ECHOED| (3) | +————–+ | | | | rcv COOKIE ACK | | —————– | | остановить таймер T1-cookie v v +—————+ | ESTABLISHED | +—————+

(продолжение рисунка на следующей странице)

(только из состояния ESTABLISHED) | | /——–+——–\ [SHUTDOWN] / \ ——————-| | проверить оставшиеся | | блоки DATA | | v | +———+ | |SHUTDOWN-| | rcv SHUTDOWN/проверить |PENDING | | оставшиеся блоки DATA +———+ | ———————- | | нет оставшихся блоков| | ———————| | snd SHUTDOWN | | запустить таймер | | T2-shutdown v v +———+ +———–+ (4) |SHUTDOWN-| | SHUTDOWN- | (5,6) |SENT | | RECEIVED | +———+ +———–+ | \ | (A) rcv SHUTDOWN ACK | \ | ———————-| \ | ост. таймер T2-shutd. | \ | send SHUTDOWN COMPLETE| \ | удалить TCB | \ | | \ | нет оставшихся блоков | \ | —————– | \ | send SHUTDOWN ACK (B)rcv SHUTDOWN -|- \ | запустить таймер ——————–/ | \———-\ | T2-shutdown send SHUTDOWN ACK | \ | зап. таймер T2-shutd. | \ | | \ | | | | | v | | +———–+ | | SHUTDOWN- | (7) | | ACK-SENT | | +———-+- | | (A)rcv SHUTDOWN COMPLETE | |—————– | | запустить таймер T2-shutdown | | удалить TCB | | | | (B)rcv SHUTDOWN ACK | |————– | | останов. таймер T2-shutdown | | send SHUTDOWN COMPLETE | | удалить TCB | | \ +———+ / \–>| CLOSED |<–/ +———+

Рисунок 3. Диаграмма состояний протокола SCTP (продолжение).

Приведённые ниже рисунки показывают возможные состояния ассоциации и переходы между ними вместе с вызывающими эти переходы событиями и выполняемыми при смене состояния действиями. Некоторые ошибки не показаны на схеме состояний. Полное описание всех состояний и переходов приводится в тексте документа21.

  1. Если параметр State Cookie в принятом блоке COOKIE ECHO недействителен (например, не прошла проверка целостности), получатель должен отбросить пакет без уведомления. Если получен State Cookie с истекшим сроком (см. параграф 5.1.5), получатель должен оправить в ответ блок ERROR. В обоих случаях получатель остаётся в состоянии CLOSED.
  2. Если истекло время по таймеру T1-init, конечная точка должна повторить передачу INIT и заново запустить таймер T1-init, сохраняя состояние COOKIE-WAIT. Эти действия должны повторяться до Max.Init.Retransmits раз, после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.
  3. Если истекло время по таймеру T1-cookie, конечная точка должна повторить передачу COOKIE ECHO и заново запустить таймер T1-cookie, сохраняя состояние COOKIE-ECHOE. Эта процедура должна повторяться до Max.Init.Retransmits раз, после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.
  4. В состоянии SHUTDOWN-SENT конечная точка должна подтверждать все принятые блоки DATA без задержек.
  5. В состоянии SHUTDOWN-RECEIVED для конечной точки недопустимо воспринимать любые новые запросы на передачу от пользователя SCTP.
  6. В состоянии SHUTDOWN-RECEIVED конечная точка должна передать или повторить данные и выйти из этого состояния после того, как будут переданы все данные из очереди.
  7. В состоянии SHUTDOWN-ACK-SENT для конечной точки недопустимо принимать от пользователя SCTP любые новые запросы на передачу.

Состояние CLOSED на схеме используется для того, чтобы показать, что ассоциация ещё не создана (т. е., не существует).

5. Создание ассоциации

До того, как сможет начаться передача данных от одной конечной точки SCTP (A) к другой (Z), эти две точки должны выполнить весь процесс создания ассоциации между собой.

Пользователь SCTP в конечной точке может применять примитив ASSOCIATE для создания ассоциации с другой конечной точкой SCTP.

Примечание для разработчиков. С точки зрения пользователя SCTP ассоциация может быть создана неявно без обращения к примитиву ASSOCIATE (см. параграф 11.1.2) просто путём передачи первых пользовательских данных удалённому адресату. Инициирующий ассоциацию узел SCTP будет задавать принятые по умолчанию значения для всех обязательных и дополнительных параметров INIT/INIT ACK.

После создания ассоциации организуются двухсторонние потоки данных для передачи информации в обоих направлениях (см. параграф 5.1.1).

5.1. Обычное создание ассоциации

Процесс инициализации описан ниже в предположении, что конечная точка A пытается создать ассоциацию, а точка Z воспринимает вызов.

  1. A создаёт TCB и передаёт блок INIT точке Z. В блоке INIT точка A должна указать свой Verification Tag (Tag_A) в поле Initiate Tag. Для Tag_A следует использовать случайное число из диапазона от 1 до 4294967295 (см. рекомендации по выбору значения тега в параграфе 5.3.1). После передачи блока INIT точка A запускает таймер T1-init и переходит в состояние COOKIE-WAIT.
  2. Z сразу же отвечает на запрос блоком INIT ACK. IP-адрес получателя в блоке INIT ACK должен совпадать с адресом отправителя блока INIT, для которого передаётся INIT ACK. Кроме заполнения других полей отклика точка Z должна скопировать в поле Verification Tag значение Tag_A, а также указать своё значение Verification Tag (Tag_Z) в поле Initiate Tag.
    Кроме того, точка Z должна сгенерировать и передать в INIT ACK значение State Cookie (см. параграф 5.1.3).
  3. При получении блока INIT ACK от Z точка A останавливает таймер T1-init и выходит из состояния COOKIE-WAIT. Далее A передаёт значение State Cookie из принятого блока INIT ACK в ответном блоке COOKIE ECHO, запускает таймер T1-cookie и переходит в состояние COOKIE-ECHOED.
  4. При получении блока COOKIE ECHO точка Z передаёт блок COOKIE ACK после создания TCB и перехода в состояние ESTABLISHED. Блок COOKIE ACK может объединяться с ожидающими передачи блоками DATA и/или SACK, но блок COOKIE ACK должен быть первым в пакете.
    Примечание для разработчиков. Реализация протокола может передавать уведомление Communication Up пользователю SCTP при получении корректного блока COOKIE ECHO.
  5. Приняв блок COOKIE ACK, точка A переходит из состояния COOKIE-ECHOED в состояние ESTABLISHED, останавливая таймер T1-cookie. Она может также уведомить ULP об успешном создании ассоциации с помощью Communication Up (см. раздел 11).
  6. Блок COOKIE ECHO может группироваться с любыми ожидающими передачи блоками DATA, но эти блоки должны размещаться в пакете после COOKIE ECHO. До получения ответного блока COOKIE ACK недопустима передача каких-либо пакетов удалённому партнёру.
  7. После передачи INIT ACK с параметром State Cookie точке Z недопустимо выделять какие-либо ресурсы или сохранять какие-либо состояния для новой ассоциации, поскольку это сделает её уязвимой для атак на ресурсы.

Блоки INIT и INIT ACK недопустимо группировать с другими блоками. Такой блок должен быть единственным в содержащем его пакете SCTP.

Конечная точка должна передавать блок INIT ACK по адресу IP, с которого был получен блок INIT.

Для таймеров T1-init и T1-cookie следует применять правила, описанные в параграфе 6.3. Если приложение сообщает партнёру несколько адресов IP, следует устанавливать таймеры T1-init и T1-cookie для каждого из этих адресов. При повторе блоков INIT и COOKIE ECHO следует искользовать все адреса партнёра как при повторе блоков DATA.

Если конечная точка, получившая блок INIT, INIT ACK или COOKIE ECHO, решает не создавать ассоциацию по причине отсутствия обязательных параметров в блоке INIT или INIT ACK, недействительных значений параметров или нехватки локальных ресурсов, ей следует передать в ответ блок ABORT. Этой точке также следует указать причину отказа (тип отсутствующих обязательных параметров и т. п.), включив соответствующий параметр в блок ABORT. Поле Verification Tag в общем заголовке исходящего пакета SCTP, содержащего блок ABORT, должно содержать значение Initiate Tag, полученное от партнёра в блоке INIT или INIT ACK, вызвавшего отправку блока ABORT.

Отметим, что блок COOKIE ECHO, не прошедший проверки целостности, не считается недействительным обязательным параметром и требует специальной обработки, описанной в параграфе 5.1.5.

После получения первого блока DATA в ассоциации конечная точка должна без промедления передать блок SACK для подтверждения приёма блока DATA. Последующие подтверждения передаются в соответствии с рекомендациями параграфа 6.2.

При создании TCB каждая точка должна установить для внутреннего параметра Cumulative TSN Ack Point значение переданного Initial TSN – 1.

Примечание для разработчиков. В качестве ключей поиска TCB для данного экземпляра SCTP обычно используются IP-адреса и номер порта SCTP.

5.1.1. Обработка параметров потока

В блоках INIT и INIT ACK отправитель должен указывать число исходящих потоков (OS), которые он желает поддерживать для данной ассоциации, а также максимальное число входящих потоков (MIS), которые он будет принимать от удалённого партнёра.

После получения сведений о конфигурации потоков от другой стороны каждая конечная точка должна выполнить ряд проверок. Если значение полученное от партнёра значение MIS меньше локального OS, это означает, что удалённый партнёр не сможет поддерживать все исходящие потоки и данная точка должна установить для числа исходящих потоков полученное значение MIS или может сообщить вышележащему уровню о нехватке ресурсов на удалённой стороне. На основании этого вышележащий уровень может принять решение о разрыве ассоциации, если работа при нехватке ресурсов не приемлема для него.

После того, как ассоциация инициализирована, приемлемые значения идентификаторов исходящих потоков для неё могут находиться в диапазоне [0 – min(local OS, remote MIS)-1].

5.1.2. Обработка адресов

В процессе создания ассоциации конечным точкам следует использовать перечисленные ниже правила для определения и сохранения транспортных адресов своего партнёра.

  1. Если в принятом блоке INIT или INIT ACK нет адресных параметров, конечная точка должна взять адрес отправителя из заголовка пакета IP, в котором был доставлен блок, и сохранить этот адрес вместе с номером порта SCTP, использованным отправителем пакета, как единственный транспортный адрес партнёра.
  2. Если в полученном блоке INIT или INIT ACK присутствует параметр Host Name, конечная точка должна сразу же передать блок ABORT и может указать в нем причину Unresolvable Address. Блок ABORT следует передавать по адресу IP, а которого получен последний пакет от партнёра.
  3. Если в принятом блоке INIT или INIT ACK присутствуют только адреса IPv4/IPv6, получатель должен выделить и записать все транспортные адреса из полученного блока и адреса отправителя в заголовке пакета IP, содержащего блок INIT или INIT ACK. Транспортные адреса представляют собой комбинацию номера порта SCTP (из общего заголовка) и адресов IP, переданных в блоке INIT или INIT ACK и заголовке пакета IP, доставившего блок. Получателю следует использовать только эти транспортные адреса для передачи последующих пакетов партнёру.
  4. Блок INIT или INIT ACK должен трактоваться, как относящийся к организованной ранее (или организуемой сейчас) ассоциации, если использование любого из содержащихся в нем корректных адресных параметров уже зафиксировано в существующих TCB.

Примечание для разработчиков. В некоторых случаях (например, когда реализация не контролирует IP-адреса отправителя, используемые при передаче) конечной точке может потребоваться включение в блок INIT или INIT ACK всех адресов IP, которые могут использоваться для передачи партнёру.

После выделения транспортного адреса из блока INIT или INIT ACK с использованием описанных выше правил конечная точка выбирает один из таких адресов как начальный основной путь.

Блок INIT ACK должен передаваться по адресу отправителя блока INIT.

Отправитель блока INIT может включить в этот блок параметр Supported Address Types, показывающий поддерживаемые типы адресов.

Примечание для разработчиков. В тех случаях, когда получателю блока INIT ACK не удаётся выполнить преобразование адреса вследствие отсутствия поддержки указанного типа, попытка создания ассоциации может быть прервана, после чего предпринимается попытка повторной организации с использованием параметра Supported Address Types в новом блоке INIT для индикации предпочтительных типов адресов.

Если конечная точка SCTP, поддерживающая только один из типов адресов (IPv4 или IPv6), получает адреса IPv4 и IPv6 в блоке INIT или INIT ACK от своего партнёра, она должна использовать все указанные партнёром адреса, которые относятся к поддерживаемому типу. Остальные адреса можно игнорировать. Не следует в таких случаях передавать какие-либо сообщения об ошибке.

Если конечная точка SCTP указывает в параметре Supported Address Types только один из типов IPv4 и IPv6, но использует для передачи пакета с блоком INIT другой тип или перечисляет адрес другого типа в блоке INIT, адреса не указанного в параметре Supported Address Types типа получателю блока INIT также следует считать поддерживаемыми. Не следует в таких случаях передавать какие-либо сообщения об ошибке.

5.1.3. Генерация State Cookie

При передаче блока INIT ACK в ответ на INIT отправитель INIT ACK создаёт значение State Cookie и передаёт его в одноимённом параметре блока INIT ACK. В параметр State Cookie отправитель должен включить MAC (см., например, [RFC2104]) для защиты целостности. Следует также включать временную метку генерации State Cookie и время действия параметра State Cookie, а также другую информацию, требуемую для создания ассоциации, включая номера портов и Verification Tag.

Метод, используемый для генерации MAC является строго приватным для получателя блока INIT. Использование MAC обязательно для предотвращения атак на службы. Алгоритмы MAC могут различаться по производительности в зависимости от платформы. Выбор скоростного алгоритма MAC повышает устойчивость к лавинным атакам на Cookie. Следует применять MAC с подходящими свойствами защиты. В качестве секретного ключа следует использовать случайное значение (см. рекомендации [RFC4086]) подходящего размера, которое следует менять достаточно часто (например, каждый час). Для идентификации ключа, который будет использоваться для проверки MAC, может служить временная метка момента создания State Cookie.

Если State Cookie не шифруется, недопустимо включать в него сведения, не рассчитанные на общее применение.

Для обеспечения взаимодействия реализациям протокола следует минимизировать размер cookie.

5.1.4. Обработка State Cookie

Когда конечная точка (в состоянии COOKIE WAIT) получает блок INIT ACK с параметром State Cookie, она должна незамедлительно передать своему партнёру блок COOKIE ECHO с полученным значением State Cookie. Отправитель может также добавить в пакет ожидающие обработки блоки DATA после блока COOKIE ECHO.

Конечная точка должна также запустить таймер T1-cookie после передачи блока COOKIE ECHO. По истечении заданного для таймера интервала конечная точка должна повторить передачу блока COOKIE ECHO и заново включить таймер T1-cookie. Эту процедуру следует повторять до получения блока COOKIE ACK или исчерпания числа попыток Max.Init.Retransmits (см. раздел 16). Если заданное число попыток не привело к успеху, партнёр помечается как недоступный (и ассоциация переходит в статус CLOSED).

5.1.5. Аутентификация State Cookie

Когда конечная точка получает блок COOKIE ECHO от другой конечной точки, с которой нет действующей ассоциации, ей следует выполнить перечисленные ниже операции.

  1. Рассчитать MAC с использованием данных TCB, полученных в State Cookie, и секретного ключа. Для выбора секретного ключа может использоваться временная метка из State Cookie. Если секрет хранится лишь ограниченное время и секретный ключ больше не доступен, пакет с COOKIE ECHO должен отбрасываться без уведомления. Расчёт MAC можно выполнять в соответствии с рекомендациями [RFC2104].
  2. Проверить подлинность State Cookie, сравнивая рассчитанное значение MAC с полученным в State Cookie. При наличии расхождений пакет SCTP, включающий COOKIE ECHO и любые блоки DATA, должны отбрасываться без уведомления отправителя.
  3. Сравнить номера портов и Verification Tag в блоке COOKIE ECHO с реальными номерами портов и полем Verification Tag в общем заголовке SCTP принятого пакета. При наличии расхождений пакет должен быть отброшен без уведомления отправителя.
  4. Сравнить временную метку в State Cookie с текущим временем локальной системы. Если разница превышает заданный срок существования State Cookie, пакет, содержащий COOKIE ECHO и любые блоки DATA, следует отбросить. Конечная точка в таком случае должна передать партнёру блок ERROR с причиной ошибки Stale Cookie.
  5. Если значение State Cookie действительно, создать ассоциацию с отправителем COOKIE ECHO, создать TCB с использованием данных из блока COOKIE ECHO и перевести конечную точку в состояние ESTABLISHED.
  6. Передать блок COOKIE ACK удалённому партнёру для подтверждения приёма COOKIE ECHO. Блок COOKIE ACK может группироваться с пользовательскими блоками DATA или блоком SACK, однако блок COOKIE ACK должен размещаться в пакете SCTP первым.
  7. Незамедлительно подтвердить получение любых блоков DATA, сгруппированных с COOKIE ECHO, путём передачи блока SACK (подтверждения последовательных блоков DATA передаются с использованием правил, рассмотренных в параграфе 6.2). Как было отмечено в п. 6), при группировке COOKIE ACK с блоком SACK, блок COOKIE ACK должен размещаться в пакете SCTP первым.

При получении блока COOKIE ECHO от конечной точки, с которой получатель имеет работающую ассоциацию, следует выполнять операции, рассмотренные в параграфе 5.2.

5.1.6. Пример нормального создания ассоциации

В показанном на рисунке примере точка A инициирует создание ассоциации и передаёт пользовательское сообщение точке Z, а Z, в свою очередь, передаёт точке A два пользовательских сообщения (предполагается отсутствие группировки и фрагментирования).

Точка A Точка Z {приложение создает ассоциацию с Z} (создание TCB) INIT [I-Tag=Tag_A и др. инфор.] ——–\ (запуск таймера T1-init) \ (Переход в сост. COOKIE-WAIT) \—> (созд. времен. TCB и Cookie_Z) /— INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Выкл. таймера T1-init)<——–/ Cookie_Z и др. информ.] (удаление времен. TCB) COOKIE ECHO [Cookie_Z] ——\ (Запуск таймера T1-init) \ (Переход в сост. COOKIE-ECHOED)\—> (создание TCB и переход в сост. ESTABLISHED) /—- COOKIE-ACK / (Выкл. таймера T1-init,<—–/ Переход в сост. ESTABLISHED) {прил. начинает перед. данных; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]–\ (Запуск таймера T3-rtx) \ \-> /—– SACK [TSN Ack=init (Выкл. таймера T3-rtx)<——/ TSN_A,Block=0] … {прилож. шлет 2 сообщ.; strm 0} /—- DATA / [TSN=init TSN_Z <–/ Strm=0, Seq=1 & user data 1] SACK [TSN Ack=init TSN_Z, /—- DATA Block=0] ——–\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=2 & user data 2] <——/\ \ \——>

Рисунок 4. Пример создания ассоциации.

Если закончилось время T1-init в точке A после передачи блока INIT или COOKIE ECHO, повторяется передача блока INIT или COOKIE ECHO с тем же значением Initiate Tag (т. е., Tag_A) или State Cookie и таймер запускается снова. Эта процедура повторяется до Max.Init.Retransmits раз после чего точка A принимает решение о недоступности Z и сообщает вышележащему протоколу об ошибке (ассоциация переводится в состояние CLOSED).

При повторной передаче INIT конечная точка должна следовать правилам, описанным в параграфе 6.3, для определения подходящего значения таймера.

5.2. Обработка дубликатов и неожиданных установочных блоков

В течение срока действия ассоциации (в одном из возможных состояний) конечная точка может получить от своего партнёра один из установочных блоков (INIT, INIT ACK, COOKIE ECHO, COOKIE ACK). Получателю следует трактовать такие установочные блоки, как дубликаты и обрабатывать их в соответствии с приведёнными здесь рекомендациями.

Примечание. Конечная точка не получит блок, если тот не передан по транспортному адресу SCTP с транспортного адреса SCTP, связанного с данной точкой. Следовательно, обрабатывающая такие блоки конечная точка является элементом текущей ассоциации.

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

  1. Критическая ошибка на удалённой стороне с перезапуском партнёра и передачей нового блока INIT для восстановления ассоциации.
  2. Обе стороны предприняли одновременные попытки создания ассоциации.
  3. Блок был получен в старом пакете, который использовался для предыдущей ассоциации или ассоциации, которой уже нет.
  4. Блок является фальшивым (атака).
  5. Партнёр не получил блок COOKIE ACK и повторно передаёт COOKIE ECHO.

При получении таких блоков следует применять описанные ниже правила, позволяющие идентифицировать и корректно обрабатывать подобные ситуации.

5.2.1. Блок INIT получен в состоянии COOKIE-WAIT или COOKIE-ECHOED (п. B)

Такие ситуации обычно возникают в результате конфликта при создании ассоциации, когда обе стороны начинают процесс создания одновременно.

При получении блока INIT в состоянии COOKIE-WAIT конечная точка должна ответить блоком INIT ACK, используя те же параметры, которые она передавала в исходном блоке INIT (включая параметр Initiate Tag). При ответе должны применяться приведённые ниже правила.

  1. Пакет с блоком INIT ACK должен отправляться только по тому адресу, который был передан вышележащим уровнем в запросе на создание ассоциации.
  2. Пакет с блоком INIT ACK должен отправляться только по адресу, указанному в принятом блоке INIT.
  3. Пакет с блоком INIT ACK следует передавать по адресу отправителя принятого пакета с блоком INIT.

При получении блока INIT в состоянии COOKIE-ECHOED конечная точка должна ответить блоком INIT ACK, используя те же параметры, которые она передавала в исходном блоке INIT (включая параметр Initiate Tag), чтобы в создаваемую ассоциацию не добавлялись новые адреса. Если блок INIT показывает добавление к ассоциации нового адреса, весь блок INIT должен быть отброшен и в существующую ассоциацию не следует вносить изменений. В ответ следует передать блок ABORT, который может включать информацию об ошибке Restart of an association with new addresses (перезапуск ассоциации с новыми адресами). В информацию об ошибке следует включать список адресов, которые были добавлены при перезапуске ассоциации.

При отклике INIT ACK из состояния COOKIE-WAIT или COOKIE-ECHOED исходные параметры комбинируются с параметрами из полученного недавно блока INIT. Конечная точка должна также генерировать параметр State Cookie для блока INIT ACK, используя параметры, переданные ею в блоке INIT.

После этого для конечной точки недопустимо изменение своего состояния и удаление соответствующего TCB, таймер T1-init должен продолжать отсчёт. Обычная процедура обработки State Cookie при наличии TCB позволит избавиться от дубликатов INIT в одной ассоциации.

Конечная точка, находящаяся в состоянии COOKIE-ECHOED при получении блока INIT должна заполнить поля Tie-Tag в TCB ассоциации и State Cookie (см. параграф 5.2.2).

5.2.2. INIT в состоянии, отличном от CLOSED, COOKIE-ECHOED, COOKIE-WAIT, SHUTDOWN-ACK-SENT

Если явно не указано иное, при получении блока INIT в таких случаях конечная точка должна генерировать блок INIT ACK с параметром State Cookie. Перед отправкой отклика конечная точка должна проверить, добавляет ли неожиданный блок INIT новые адреса для ассоциации. При наличии новых адресов конечная точка должна отвечать блоком ABORT, копируя Initiate Tag из неожиданного блока INIT в поле Verification Tag исходящего пакета с блоком ABORT. В блоке ABORT можно указать причину ошибки Restart of an association with new addresses (перезапуск ассоциации с новыми адресами). В информацию об ошибке следует включать список адресов, добавленных к ассоциации. Если новых адресов нет, в ответ на неожиданный блок INIT блоком INIT ACK конечная точка должна копировать свои текущие значения Tie-Tag в резервное пространство State Cookie и TCB этой ассоциации. Эти места внутри cookie по-прежнему обозначаются Peer’s-Tie-Tag и Local-Tie-Tag. Копии внутри TCB ассоциации будем обозначать Local Tag и Peer’s Tag. Исходящий пакет SCTP с блоком INIT ACK должен включать значение Verification Tag, совпадающее с Initiate Tag в неожиданном блоке INIT. Блок INIT ACK должен включать новое значение Initiate Tag (случайное, см. параграф 5.3.1). Остальные параметры для конечной точки (например, число исходящих потоков) следует скопировать из существующих параметров ассоциации в блок INIT ACK и cookie.

После передачи INIT ACK или ABORT конечная точка должна отказаться от каких-либо действий, т. е., существующую ассоциацию, включая текущее состояние и соответствующее значение TCB, изменять недопустимо.

Поля Tie-Tag заполняются отличными от 0 случайными значениями только в том случае, когда существует TCB и ассоциация не находится в состоянии COOKIE-WAIT или SHUTDOWN-ACK-SENT. При обычном создании ассоциации (конечная точка находится в состоянии CLOSED) для Tie-Tag должно устанавливаться значение 0 (это показывает отсутствие предыдущего TCB).

5.2.3. Неожиданный блок INIT ACK

При получении блока INIT ACK конечной точкой, находящейся в отличном от COOKIE-WAIT состоянии, этой точке следует отбросить блок INIT ACK. Неожиданные блоки INIT ACK обычно связаны с обработкой старых или дублированных блоков INIT.

5.2.4. Обработка COOKIE ECHO при наличии TCB

При получении блока COOKIE ECHO конечной точкой, находящейся в любом состоянии, для существующей ассоциации (состояние отлично от CLOSED) нужно следовать приведённым ниже правилам.

  1. Рассчитать MAC в соответствии с рекомендациями п. 1 в параграфе 5.1.5,
  2. Проверить подлинность State Cookie, как описано в п. 2 параграфа 5.1.5 (случай C или D в начале параграфа 5.2).
  3. Сравнить временную метку State Cookie с текущим временем. Если срок действия State Cookie истёк и значение Verification Tag, содержащееся в State Cookie, не соответствует Verification Tag для текущей ассоциации, пакет вместе с входящими в него блоками COOKIE ECHO и DATA следует отбросить. Конечная точка должна также передать партнёру блок ERROR с причиной ошибки Stale Cookie (случай C или D в параграфе 5.2).
  4. При действительном значении State Cookie распаковать TCB во временный TCB.
  5. Выполнить подходящее действие из таблицы 12.
  6. Если параметры Verification Tag в State Cookie и текущей ассоциации совпадают, следует считать параметр State Cookie действительным (случай E в параграфе 5.2) даже по истечении срока действия.

Таблица 12. Обработка COOKIE ECHO при наличии TCB.

Local Tag Peer’s Tag Local-Tie-Tag Peer’s-Tie-Tag Действие
X X M M (A)
M X A A (B)
M 0 A A (B)
X M 0 0 (C)
M M A A (D)

X – тег не соответствует существующему TCB;
M – тег соответствует существующему TCB;
0 – нет Tie-Tag в Cookie (неизвестно);
A – Все случаи (M, X, 0).

Для всех ситуаций, не рассмотренных в таблице 12, cookie следует отбрасывать без уведомления.

Действия

  1. Этот случай может быть связан с рестартом на удалённой стороне. Когда конечная точка распознает возможный рестарт, существующая сессия трактуется, как случай получения блока ABORT, за которым сразу же следовал новый блок COOKIE ECHO, с перечисленными ниже исключениями:
    • любые блоки DATA могут быть сохранены (в зависимости от реализации протокола);
    • протоколу вышележащего уровня следует передать уведомление RESTART взамен COMMUNICATION LOST.

    Все параметры контроля перегрузки (например, cwnd, ssthresh), связанные с этим партнёром, должны быть сброшены в исходное состояние (см. параграф 6.2.1).Если конечная точка находится в состоянии SHUTDOWN-ACK-SENT и определяет рестарт партнёра (п. A), для этой точки недопустимо создание новой ассоциации и следует передать своему партнёру блок SHUTDOWN ACK и ERROR с причиной ошибки Cookie Received while Shutting Down.

  2. В этой ситуации обе стороны могут пытаться организовать ассоциацию одновременно, но удалённая точка передаст свой блок INIT уже после отклика на INIT от локальной точки. В результате новое значение Verification Tag не будет включать информацию из тега, переданного ранее той же конечной точкой. Конечной точке следует сохранить состояние ESTABLISHED или перейти в него, но она должна обновить значение Verification Tag из параметра State Cookie, остановить запущенные таймеры T1-init и T1-cookie и передать блок COOKIE ACK.
  3. В этом случае информация cookie локальной точки поступает с опозданием. До этого локальная точка передала блок INIT и приняла INIT-ACK, а также передала блок COOKIE ECHO с тегом партнёра, но новый тег принадлежит локальной точке. Данные cookie следует отбросить без уведомления. Конечной точке не следует менять своё состояние, а запущенные таймеры следует сохранить.
  4. Когда теги локальной и удалённой точки совпадают, конечной точке следует перейти в состояние ESTABLISHED, если она находится в состоянии COOKIE-ECHOED. Ей следует остановить таймер T1-cookie и передать блок COOKIE ACK.
  5. После этого конечной точке следует перейти в состояние ESTABLISHED.

Примечание. Verification Tag партнёра – это тег, полученный в поле Initiate Tag блока INIT или INIT ACK.

5.2.4.1. Пример перезапуска ассоциации

В приведённом на рисунке 5 примере точка A инициирует ассоциацию после рестарта. Точка Z пока не знает о перезапуске (т. е., Heartbeat ещё не удалось обнаружить недоступность точки A). Предполагается отсутствие группировки и фрагментирования.

Точка A Точка Z <—————- Ассоциация организована ———————-> Tag=Tag_A Tag=Tag_Z <—————————————————————> {A выполняет рестарт после сбоя} {приложение организует ассоциацию с Z} (создание TCB) INIT [I-Tag=Tag_A’ и др. инф.] ——–\ (Запуск таймера T1-init) \ (Переход в сост. COOKIE-WAIT) \—> (поиск существующего TCB создание врем. TCB и Cookie_Z с Tie-Tag для предыдущ. асс.) /— INIT ACK [Veri Tag=Tag_A’, / I-Tag=Tag_Z’, (Выкл. таймера T1-init)<——/ Cookie_Z] (возврат исходного TCB) COOKIE ECHO [Veri=Tag_Z’, Cookie_Z]——-\ (Запуск таймера T1-init) \ (Перех. В сост. COOKIE-ECHOED) \—> (Найдена существ. ассоциация, Tie-Tag в Cookie_Z соотв. Tie-Tag в TCB. Теги не соотв. (случай X X M M), анонсиров. рестарта ULP и сброс ассоциации). /—- COOKIE-ACK / (Выкл. таймера T1-init,<—–/ переход в состояние ESTABLISHED) {прилож. передаёт польз. данные; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]–\ (Запуск таймера T3-init) \ \-> /—– SACK [TSN Ack=init TSN_A,Block=0] (Выкл. таймера T3-rtx)<——/

Рисунок 5. Пример перезапуска.

5.2.5. Обработка дубликатов COOKIE-ACK

Во всех состояниях, кроме COOKIE-ECHOED, конечной точке следует отбрасывать без уведомления блоки COOKIE ACK.

5.2.6. Обработка ошибок Stale COOKIE

Приём блока ERROR с причиной Stale Cookie может быть обусловлен одной из перечисленных ниже ситуаций.

  1. Создание ассоциации завершилось неудачей до того, как была выполнена обработка State Cookie.
  2. После создания ассоциации обработана старая переменная State Cookie.
  3. Получена старая переменная State Cookie от кого-то, с кем получатель не намерен создавать ассоциацию, но блок ABORT был утерян.

При обработке блока ERROR с причиной ошибки Stale Cookie конечной точке следует сначала проверить завершился ли процесс создания ассоциации (состояние отличается от COOKIE-ECHOED). Если ассоциация не находится в состоянии COOKIE-ECHOED, блок ERROR следует отбросить без уведомления.

Если ассоциация находится в состоянии COOKIE-ECHOED, конечная точка может выбрать один из перечисленных вариантов.

  1. Передать новый блок INIT удалённой конечной точке для генерации нового значения State Cookie и повторить процедуру создания ассоциации.
  2. Отбросить TCB и сообщить вышележащему уровню о невозможности создания ассоциации.
  3. Передать новый блок INIT удалённой конечной точке, добавив в него параметр Cookie Preservative, запрашивающий продление срока действия State Cookie. При расчёте дополнительного времени реализации протокола следует использовать данные RTT, полученные во время предыдущего обмена блоками COOKIE ECHO/ERROR. К полученному значению RTT следует добавлять не более 1 секунды, поскольку увеличение срока действия State Cookie подвергает конечную точку риску replay-атак.

5.3. Другие вопросы инициализации

5.3.1. Выбор значений тегов

Значения Initiate Tag следует выбирать из диапазона 1 – 232-1. Важно, чтобы значение Initiate Tag было случайным – это поможет в защите от атак извне пути22. Для создания случайных значений Initiate Tag можно использовать методы, описанные в [RFC4086]. Аккуратный подбор Initiate Tag позволяет также избавиться от появления дубликатов из предыдущих ассоциаций, которые могут быть ошибочно направлены в текущую ассоциацию.

Важно помнить, что значение Verification Tag, используемое любой из конечных точек данной ассоциации, недопустимо изменять в течение срока существования ассоциации. Каждый раз, когда конечная точка перезапускается и снова создаёт ассоциацию с тем же партнёром, должно выбираться новое значение Verification Tag.

5.4. Проверка пути

В процессе создания ассоциации партнёры обмениваются списками адресов. Чаще всего эти списки содержат адреса, принадлежащие каждому из партнёров. Однако возможны ситуации, когда некорректно ведущий себя партнёр предложит адреса, которые ему не принадлежат. Для предотвращения нежелательных последствий этого ко всем адресам в новой ассоциации применяются приведённые ниже правила.

  1. Любой адрес, переданный отправителю блока INIT его вышележащим уровнем в запросе на создание ассоциации, автоматически считается подтверждённым.
  2. Для получателя COOKIE ECHO единственным подтверждённым адресом является тот, по которому был передан блок INIT-ACK.
  3. Остальные адреса (кроме перечисленных в п. 1 и 2) считаются неподтверждёнными и должны проверяться.

Для проверки адреса конечная точка передаёт блоки HEARTBEAT, включающее 64-битовое случайное значение nonce и индикатор пути (для идентификации адреса, по которому передаётся HEARTBEAT) в параметре HEARTBEAT.

При получении HEARTBEAT ACK проверяется значение nonce в параметре Heartbeat Info на предмет совпадения с переданным по адресу, указанному в Heartbeat Info. При совпадении адрес, по которому был передан исходный блок HEARTBEAT, считается подтверждённым и может применяться для обычной передачи данных.

Эти процедуры проверки запускаются при переходе ассоциации в состояние ESTABLISHED и завершаются после проверки всех путей.

В каждый период RTO может быть отправлен пробный пакет для активного неподтверждённого пути в попытке перевести этот путь в состояние подтверждённого. Если в процессе проверки путь становится неактивным, скорость отправки проб снижается до обычной скорости передачи HEARTBEAT. По завершении отсчёта таймера RTO значения счётчика ошибок для протестированного, но не подтверждённого пути увеличивается на 1 и рассматривается вопрос отказа на этом пути (см. параграф 8.2). При проверке неподтвержденных адресов значение общего счётчика ошибок в ассоциации не инкрементируется.

Число HEARTBEAT, передаваемых в течение RTO, следует ограничивать значением параметра HB.Max.Burst. Распределение HEARTBEAT по адресам партнёра при проверке путей реализация определяет самостоятельно.

При подтверждении пути вышележащему уровняю может передаваться уведомление.

Конечной точке недопустимо передавать какие-либо блоки по неподтверждённому адресу за исключением перечисленных ниже случаев.

  • Блоки HEARTBEAT, включающие nonce, можно передавать по неподтвержденным адресам.
  • Блоки HEARTBEAT ACK можно передавать по неподтвержденным адресам.
  • Блоки COOKIE ACK можно передавать по неподтвержденным адресам, но они должны группироваться с блоками HEARTBEAT, включающими nonce. Реализациям, не поддерживающим группировку блоков, недопустимо передавать COOKIE ACK по неподтвержденным адресам.
  • Блоки COOKIE ECHO можно передавать по неподтвержденным адресам, но они должны группироваться с блоками HEARTBEAT, включающими nonce, и недопустимо использование пакетов с размером больше MTU на этом пути. Если реализация не поддерживает группировку блоков или после группировки COOKIE ECHO с HEARTBEAT (включающим nonce) размер пакета превысит MTU для пути, недопустимо передавать COOKIE ECHO по неподтвержденным адресам.

6. Передача пользовательских данных

Данные должны передаваться только в состояниях ESTABLISHED, SHUTDOWN-PENDING и SHUTDOWN-RECEIVED. Единственным исключением из этого правила является возможность включения блоков DATA в пакеты, содержащие блок COOKIE ECHO, в состоянии COOKIE-WAIT.

Блоки DATA должны приниматься только в соответствии с приведёнными ниже правилами в состояниях ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. Блок DATA, полученный в состоянии CLOSED, считается неожиданным и его следует обрабатывать в соответствии с правилами, описанными в параграфе 8.4. Блоки DATA, полученные во всех прочих состояниях, следует отбрасывать.

Подтверждения SACK должны обрабатываться в состояниях ESTABLISHED, SHUTDOWN-PENDING и SHUTDOWN-RECEIVED. Входящий блок SACK может быть обработан ассоциацией в состоянии COOKIE-ECHOED. Блок SACK в состоянии CLOSED считается неожиданным и его следует обрабатывать в соответствии с правилами, приведенными в параграфе 8.4. Во всех прочих состояниях блоки SACK следует отбрасывать.

Для эффективной передачи трафика протокол SCTP поддерживает механизм группировки мелких пользовательских сообщений и фрагментации больших сообщений. На рисунке 6 показана схема обмена пользовательскими сообщениями в SCTP.

В этом параграфе термин «отправитель» (data sender) будет указывать конечную точку, которая передаёт блок DATA, а термин «получатель» (data receiver) – точку, принимающую блок DATA. Получатель подтверждает приём данных блоком SACK.

+—————————-+ | Пользовательское сообщение | +—————————-+ Пользователь SCTP ^ | ==================|==|=================================== | v (1) +——————+ +———————-+ | Блоки SCTP DATA | |Блоки управления SCTP | +——————+ +———————-+ ^ | ^ | | v (2) | v (2) +————————–+ | Пакеты SCTP | +————————–+ SCTP ^ | =============================|==|======================== | v Пакетный сервис без организации соединений (например, IP)

Примечания.

  1. При преобразовании пользовательских сообщений в блоки DATA конечная точка должна фрагментировать большие сообщения. Размер каждого блока DATA следует делать не больше максимального размера блока данных в ассоциации (Association Maximum DATA Chunk Size или AMDCS). Получатель обычно будет собирать принятые фрагменты из блоков DATA до передачи сообщения пользователю (см. параграф 6.9).
  2. Несколько блоков DATA и блоков управления может группироваться отправителем в один пакет SCTP, пока размер результирующего пакета не будет превышать значение PMTU. Получатель будет разбирать групповой пакет, выделяя из него отдельные блоки. Блоки управления должны размещаться в пакете перед блоками DATA.

Рисунок 6. Пример передачи пользовательских данных.

Механизмы фрагментации и группировки, описанные в параграфах 6.9 и 6.10, являются необязательными для отправителя, но они должны быть реализованы на приёмной стороне (т. е., конечная точка должна принимать и обрабатывать фрагментированные и сгруппированные данные).

6.1. Передача блоков DATA

В этом параграфе приведены правила для отправки блоков DATA. В частности, определена проба нулевого окна, требуемая для предотвращения неопределённого ожидания ассоциации в случае потери пакетов с блоками SACK для обновления окна.

В этом документе предполагается использование одного таймера повторной передачи на транспортный адрес получателя, но реализации протокола могут поддерживать отдельный таймер повтора для каждого блока DATA.

Ниже приведены правила общего назначения, используемые отправителем для передачи или повтора исходящих блоков DATA.

  1. В любой момент для отправителя недопустимо передавать новые данные по какому-либо транспортному адресу партнёра, если значение rwnd, полученное от того, говорит об отсутствии свободного пространства в буфере (т. е., rwnd меньше размера следующего блока данных, см. параграф 6.2.1), за исключением пробы нулевого окна.Если отправитель продолжает принимать новые пакеты от партнёра во время проверки нулевого окна, отсутствие подтверждения проб не следует использовать для инкрементирования счётчика ошибок ассоциации или каких-либо транспортных адресов партнёра. Это связано с тем, что получатель может держать своё окно закрытым в течение неопределённого времени. Поведение получателя, анонсирующего нулевое окно, описано в параграфе 6.2. Отправителю следует передавать первую пробу нулевого окна по истечении 1 RTO с момента обнаружения закрытия окна получателем, а также следует экспоненциально увеличивать интервал между проверками. Отметим также, что значение cwnd следует подстраивать в соответствии с параграфом 7.2.1. Проверки нулевого окна не оказывают влияния на расчёт cwnd.
  2. В любой момент времени для отправителя недопустимо передавать информацию по данному транспортному адресу, если у него имеется не менее cwnd + (PMDCS – 1) неподтвержденных байтов данных для этого адреса. Если данные доступны, отправителю следует превышать cwnd на величину до PMDCS – 1 при новой передаче данных, если размер находящихся в пути данных не достигает значения cwnd. Нарушение cwnd должно составлять лишь 1 пакет.
  3. Когда приходит время отправителю передавать новые блоки DATA, перед их отправкой он должен сначала передать неподтвержденные блоки DATA, которые помечены для повтора (не более cwnd).
  4. Когда приходит время отправителю передавать новые блоки DATA, следует использовать протокольный параметр Max.Burst для ограничения числа передаваемых пакетов. Ограничение может быть реализовано путём изменения cwndif((flightsize + Max.Burst*PMDCS) < cwnd)
      cwnd = flightsize + Max.Burst*PMDCS

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

  5. Отправитель может передать столько новых блоков DATA, сколько позволяют правила A и B.
  6. Отправитель должен также поддерживать алгоритм отправки новых блоков DATA, позволяющий предотвратить синдром SWS23, как описано в [RFC1122]. Алгоритм может быть похож на описанный в параграфе 4.2.3.4 [RFC1122].
  7. Пробой нулевого окна (zero window probe) является, передаваемый, когда анонсированное получателем окно имеет нулевой размер. Это позволяет отправителю проверить изменение rwnd, которое он пропустил из-за потери блоков SACK, направленных от получателя к отправителю. Зонд нулевого окна должен передаваться лишь в том случае, когда это разрешает cwnd (см. п. B). Такие пробы следует передавать только в тех случаях, когда все остающиеся блоки DATA имеют кумулятивное подтверждение и нет находящихся в пути блоков DATA. Реализации должны поддерживать проверку нулевого окна.

Несколько блоков DATA, подготовленных для передачи, можно сгруппировать в один пакет. Кроме того, передаваемые повторно блоки DATA можно группировать с новыми блоками DATA, пока размер результирующего пакета не превышает PMTU. Протокол вышележащего уровня (ULP) может запросить передачу сообщений без группировки, но это означает лишь отключение задержек, которые реализация SCTP может использовать для повышения эффективности группировки. Группировка может происходить и в этом случае (например, при перегрузках или повторе передачи).

До того, как конечная точка передаст блок DATA, если имеются неподтвержденные блоки DATA, отправителю следует создать блок SACK для всех неподтвержденных данных и сгруппировать его с передаваемыми блоками DATA, пока размер результирующего пакета не превышает значение PMTU (см. параграф 6.2).

При заполнении окна (передача запрещена правилом A и/или B), отправитель может по-прежнему принимать запросы на передачу от вышележащего протокола, но он должен остановить передачу блоков DATA, пока некоторые или все остающиеся блоки DATA не будут подтверждены и правила A и B не будут выполнены.

При старте или перезапуске таймера T3-rtx его значение следует устанавливать в соответствии с правилами, приведёнными в параграфах 6.3.2 и 6.3.3.

Отправителю недопустимо использовать значения TSN, которые превышают стартовое значение TSN для текущего окна более, чем на 231 – 1.

Для каждого потока отправителю недопустимо иметь более 216 – 1 упорядоченных пользовательских сообщений в текущем окне передачи.

Когда отправитель блока DATA может получить преимущества от незамедлительной передачи ему соответствующего блока SACK, отправитель может установить флаг I в заголовке блока DATA. Следует отметить, что причина установки отправителем бита I не имеет значения для получателя.

Причины установки бита I включают (но не ограничиваются) указанные ниже (см. раздел 4 в [RFC7053]):

  • приложение запрашивает установку бита I в последнем блоке DATA пользовательского сообщения для представления этого сообщения реализации SCTP (параграф 11.1);
  • отправитель находится в состоянии SHUTDOWN-PENDING;
  • отправка блока DATA заполняет окно перегрузки или окно получателя.

6.2. Подтверждение приёма блоков DATA

Конечная точка SCTP всегда должна подтверждать получение каждого корректного блока DATA, когда этот блок приходит в окне приёма.

Когда получатель анонсирует размер окна 0, он должен отбрасывать все новые входящие блоки DATA со значением TSN, превышающим максимальное полученное до этого значение TSN. Если в новом входящем блоке DATA значение TSN меньше максимального из принятых до этого блоков, получателю следует отбросить наибольшее значение TSN, хранящееся для упорядочения, и воспринять новый блок DATA. В любом случае при отбрасывании блока DATA получатель должен незамедлительно вернуть блок SACK с текущим окном приёма, показывающим лишь блоки DATA, полученные и воспринятые к этому моменту. Отброшенные блоки DATA недопустимо включать в SACK, поскольку они не были восприняты. Получатель должен также иметь алгоритм анонсирования своего приёмного окна для предотвращения синдрома SWS, как описано в [RFC0813]. Это алгоритм может быть похож на описанный в параграфе 4.2.3.3 [RFC1122].

Следует придерживаться рекомендаций по использованию алгоритма отложенных подтверждений, описанного в параграфе 4.2 [RFC5681]. В частности, подтверждения следует генерировать по меньшей мере для каждого второго принятого пакета (не обязательно с блоком DATA), а также следует в течение 200 мсек генерировать подтверждение для любого ещё не подтверждённого блока DATA. В некоторых случаях для отправителя SCTP разумно быть более консервативным, нежели предлагает описанный в данном документе алгоритм подтверждения. Однако для отправителей SCTP недопустимо быть более агрессивными, нежели предлагает описанный ниже алгоритм.

Для отправителя SCTP недопустимо генерировать более 1 блока SACK для каждого входящего пакета, который не является обновлением предложенного размера окна при по мере потребления данных принимающим приложением. При расширении окна (opens up) получателю SCTP следует передавать дополнительные блоки SACK для обновления окна, даже если новых данных не получено. Получатель должен избегать передачи многочисленных обновлений окна и, в частности, больших пиков (large burst) таких обновлений. Одним из способов достижения этого является передача обновления окна лишь при его увеличении по меньшей мере на четверть размера приёмного буфера ассоциации.

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

Для реализации протокола недопустимо разрешать установку максимальной задержки (параметр SACK.Delay) более 500 мсек. Иными словами, реализация может устанавливать SACK.Delay менее 500 мсек, но в любом случае недопустимо устанавливать значение более 500 мсек.

Подтверждения должны передаваться в блоках SACK до тех пор, пока от ULP не поступит запроса на завершение ассоциации (в последнем случае подтверждение может быть передано в блоке SHUTDOWN). Блок SACK может использоваться для подтверждения доставки нескольких блоков DATA (формат блоков SACK описан в параграфе 3.3.4). Конечная точка SCTP должна заполнить поле Cumulative TSN Ack, чтобы показать последний номер TSN для полученных без пропусков корректных блоков DATA. Все принятые блоки DATA с номерами TSN, превышающими значение Cumulative TSN Ack, указываются в полях Gap Ack Block. Конечная точка SCTP должна включать столько Gap Ack Block, сколько можно поместить в один блок SACK с учётом текущего значения PMTU.

Блок SHUTDOWN не включает поля Gap Ack Block. Поэтому конечной точке следует использовать SACK, а не SHUTDOWN для подтверждения доставки блоков DATA, принятых с нарушением порядка.

При получении пакета SCTP, содержащего блок DATA с установленным битом I, получателю не следует задерживать отправку соответствующего блока SACK, т. е. ему следует передать этот блок SACK незамедлительно.

При получении пакета с дубликатом блока(ов) DATA, в котором нет нового блока(ов) DATA, конечная точка должна незамедлительно передать SACK. Если пакет с дубликатом DATA содержит также новый блоки DATA, конечная точка может передать SACK незамедлительно. Обычно получение дубликатов DATA связано с потерей исходного блока SACK и тайм-аутом RTO у партнёра. Номера TSN для дубликатов следует указывать в блоке SACK как дубликаты.

При получении блока SACK конечная точка может использовать сведения о дубликатах TSN для обнаружения потери блоков SACK. Другие варианты использования этой информации требуют дальнейшего изучения.

Получатель данных отвечает за поддержку буферов приёма. Получателю следует своевременно уведомлять отправителя об изменении своих возможностей приёма данных. Способы управления приёмными буферами в реализации протокола зависят от множества факторов (например, от операционной системы, системы управления памятью, размера ОЗУ и т. п.). Однако описанная в параграфе 6.2.1 стратегия передачи основана на предположении, что получатель использует описанный ниже алгоритм.

  1. При создании ассоциации конечная точка сообщает партнёру размер своего приёмного буфера для данной ассоциации в блоке INIT или INIT ACK. Это значение размера буфера устанавливается для переменной a_rwnd.
  2. При получении и буферизации блоков DATA значение a_rwnd уменьшается на размер принятых и помещённых в буфер данных. Это, по сути, сокращает окно rwnd у отравителя и ограничивает количество данных, которые тот может передать.
  3. Когда блоки DATA передаются ULP и буфер освобождается, значение a_rwnd увеличивается на размер данных, которые отправлены протоколу вышележащего уровня. Таким образом окно rwnd открывается снова, позволяя отправителю передавать новые данные. Получателю не следует увеличивать значение a_rwnd, пока данные не будут освобождены из буфера. Например, если получатель удерживает фрагментированные блоки DATA в очереди на сборку, ему не следует увеличивать значение a_rwnd.
  4. При передаче блока SACK получателю данных следует поместить текущее значение переменной a_rwnd в поле a_rwnd передаваемого блока. Получателю данных следует принимать во внимание, что отправитель не будет повторять передачу блоков DATA, указанных в Cumulative TSN Ack (т. е., удалит их из очереди на повтор).

В некоторых случаях получатель может отбросить блоки DATA, которые были приняты, но ещё не освобождены из приёмного буфера (т. е., не переданы ULP). Такие блоки DATA могут быть подтверждены в Gap Ack Block. Например, получатель может удерживать принятые данные в буфере для сборки фрагментов пользовательского сообщения, когда обнаружится нехватка буферного пространства. Получатель в этом случае может отбросить блоки DATA из буфера, хотя они уже подтверждены в Gap Ack Block. Если получатель отбрасывает блоки DATA, их недопустимо включать в Gap Ack Block последующих блоков SACK, пока отброшенные блоки не будут получены снова в повторных пакетах. В дополнение к сказанному конечной точке следует учитывать отброшенные блоки при расчёте a_rwnd.

Конечной точке не следует отзывать SACK и отбрасывать данные. Этой процедурой следует пользоваться только в экстремальных ситуациях (например, при нехватке памяти). Получателю данных следует учитывать, что отбрасывание данных, подтверждённых в Gap Ack Block, может привести к неоптимальной работе отправителя и потере производительности.

Приведённый на рисунке 7 пример иллюстрирует использование отложенных подтверждений.

Точка A Точка Z {Приложение передает 3 сообщения; strm 0} DATA [TSN=7,Strm=0,Seq=3] ————> (подтверждение отложено) (Запуск таймера T3-rtx) DATA [TSN=8,Strm=0,Seq=4] ————> (передача подтверждения) /——- SACK [TSN Ack=8,block=0] (Остан. таймера T3-rtx)<—–/ DATA [TSN=9,Strm=0,Seq=5] ————> (подтверждение отложено) (Запуск таймера T3-rtx) … {Прил. перед. 1 сообщ.; strm 1} (групп. SACK с DATA) /—– SACK [TSN Ack=9,block=0] \ / DATA [TSN=6,Strm=1,Seq=2] (Остан. таймера T3-rtx)<——/ (Запуск таймера T3-rtx) (подтверждение отложено) (передача подтверждения) SACK [TSN Ack=6,block=0] ————-> (Остан. таймера T3-rtx)

Рисунок 7. Пример подтверждения с задержкой.

Если конечная точка получает блок DATA без пользовательских данных (Length = 16), ей следует передать блок ABORT с причиной ошибки No User Data.

Конечной точке не следует передавать блоков DATA без пользовательских данных. Это избавляет от необходимости возврата пустых пользовательских сообщений в API сокета, как отмечено в [RFC6458].

6.2.1. Обработка подтверждений SACK

Каждый блок SACK, полученный конечной точкой, содержит значение a_rwnd. Это значение представляет объем свободного буферного пространства на приёмной стороне в момент передачи блока SACK, которое осталось от приёмного буфера, указанного в блоке INIT/INIT ACK. Используя значения a_rwnd, Cumulative TSN Ack и Gap Ack Block, отправитель может создать своё представление о буферном пространстве партнёра.

Одна из проблем, возникающих при обработке отправителем данных блока SACK, связана с тем, что подтверждения SACK могут доставляться с нарушением порядка (т. е., отправленный раньше блок SACK может быть доставлен позднее своих последователей). При нарушении порядка доставки блоков SACK у отправителя данных может сложиться превратное представление о буферном пространстве его партнёра.

Поскольку явных идентификаторов, позволяющих обнаружить нарушение порядка доставки SACK, не предусмотрено, отправитель данных должен использовать эвристические методы проверки полученных подтверждений SACK.

Конечной точке следует использовать приведённые ниже правила расчёта rwnd на основе значений a_rwnd, Cumulative TSN Ack и Gap Ack Block, полученных в блоке SACK.

  1. При создании ассоциации конечная точка устанавливает rwnd = a_rwnd24 из блока INIT или INIT ACKот партнёра.
  2. Всякий раз при передаче (или повторе) блока DATA партнёру конечная точка вычитает размер переданной информации из значения rwnd для этого партнёра.
  3. Всякий раз, когда блок DATA помечается для повтора по таймеру T3-rtx (параграф 6.3.3) или fast retransmit (параграф 7.2.4), размер этого блока добавляется к значению rwnd.
  4. Всякий раз при получении SACK конечная точка выполняет указанные ниже операции.
    1. Если Cumulative TSN Ack < Cumulative TSN Ack Point, блок SACK отбрасывается. Поскольку Cumulative TSN Ack возрастает монотонно, блок SACK, в котором Cumulative TSN Ack < Cumulative TSN Ack Point говорит о нарушении порядка доставки SACK.
    2. Для переменной rwnd устанавливается значение a_rwnd за вычетом числа байтов, остающихся не подтверждёнными, после обработки Cumulative TSN Ack и Gap Ack Block.
    3. Если в SACK отсутствует TSN, который был ранее подтверждён в Gap Ack Block (например, получатель отказался от данных), рассматривается соответствующий блок DATA, который может оказаться пропущенным. Блок считается отсутствующим для Fast Retransmit (параграф 7.2.4) и если нет запущенного таймера для адреса получателя, по которому блок DATA был передан изначально, для этого адреса запускается таймер T3-rtx.
    4. Если Cumulative TSN Ack совпадает со значением для точки выхода из процедуры Fast Recovery (параграф 7.2.4) или превышает его, процедура Fast Recovery завершается.

6.3. Управление таймером повтора передачи

Конечная точка SCTP использует таймер повтора передачи T3-rtx для обеспечения доставки данных при отсутствии обратной связи от партнёра. Время этого таймера называют тайм-аутом повтора или RTO.

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

Расчёт и обслуживание RTO для протокола SCTP осуществляются так же, как это делается для таймера повтора передачи в TCP. Для расчёта текущего значения RTO конечная точка поддерживает две переменных состояния для каждого адреса получателя – SRTT и RTTVAR.

6.3.1. Расчёт RTO

Ниже приводятся правила расчёта значений SRTT, RTTVAR и RTO.

  1. До того, как будет измерено значение RTT для пакета, переданного по данному транспортному адресу, для RTO следует использовать параметр протокола RTO.Initial.
  2. После того, как будет определено значение RTT (обозначим его R), следует установитьSRTT = R RTTVAR = R/2 RTO = SRTT + 4 * RTTVAR
  3. Когда будет получено для RTT новое значение R’, следует установитьRTTVAR = (1 – RTO.Beta) * RTTVAR + RTO.Beta * |SRTT – R’| SRTT = (1 – RTO.Alpha) * SRTT + RTO.Alpha * R’Примечание. Значение SRTT, используемое для обновления RTTVAR, представляет собой SRTT до обновления с использованием второго назначения. RTO = SRTT + 4 * RTTVAR.
  4. Когда данные находятся в процессе доставки и выполняется правило C5, для каждого кругового обхода должно быть выполнено новое измерение RTT. Новое измерение RTT следует проводить не более одного раза на круговой обход для данного транспортного адреса. Такое ограничение обусловлено 2 причинами. Во-первых, более частые измерения не имеют смысла, поскольку не дают заметных преимуществ [ALLMAN99], во-вторых, при частых измерениях значения RTO.Alpha и RTO.Beta в правиле C3 следует подбирать так, чтобы значения SRTT и RTTVAR корректировались примерно с одной же частотой (в терминах числа круговых обходов, при котором новые значения вступают в силу), как при одном измерении на круговой обход и с использованием RTO.Alpha и RTO.Beta в правиле C3. Однако точная процедура расчётов требует дополнительных исследований.
  5. Алгоритм Karn – измерение RTT недопустимо выполнять с использованием передаваемых повторно блоков, поскольку нет возможности различить, к какой из переданных копий относится полученный отклик.
  6. Если после расчёта RTO получается значение меньше RTO.Min, устанавливается RTO = RTO.Min. Причина этого заключается в том, что использование слишком малых значений RTO будет приводить к возникновению неоправданных тайм-аутов [ALLMAN99].
  7. Максимальное значение можно поместить в RTO при условии, что оно не меньше RTO.max секунд.
  8. Измерение RTT с использованием блока с TSN r следует выполнять лишь в тех случаях, когда нет блоков с номерами TSN не больше r, повторно переданными с момента первой передачи TSN r.
  9. После расчёта следует обновить

К дискретности часов (G) при измерении RTT и различных переменных состояния требований не предъявляется.

G1) Если при расчёте RTTVAR получено нулевое значение, следует установить RTTVAR = G.

Опыт показывает [ALLMAN99], что предпочтительной является дискретность часов не более 100 мсек.

Предложенные значения параметров приведены в разделе 16.

6.3.2. Правила для таймера повторной передачи

  1. Каждый раз при передаче блока DATA (включая повторы) по любому из адресов следует запустить для этого адреса таймер T3-rtx (если он не работает) на время RTO. Используемое для таймера значение RTO удваивается после каждого тайм-аута предыдущего таймера T3-rtx, связанного с этим адресом, как указано ниже в правиле E2.
  2. После подтверждения всех неподтвержденных для этого адреса данных таймер T3-rtx для адреса сбрасывается.
  3. Всякий раз при получении SACK, подтверждающего блок DATA с неподтвержденным TSN для данного адреса, таймер T3-rtx для этого адреса запускается заново с текущим значением RTO (если для этого адреса есть неподтвержденные данные).
  4. При получении SACK для пропущенного TSN, который ранее был подтверждён с помощью Gap Ack Block, включается таймер T3-rtx для адреса получателя, по которому блок DATA был передан изначально (если этот таймер ещё не запущен).

Точка A Точка Z {приложение начинает передачу} Data [TSN=7,Strm=0,Seq=3] ————> (задержка ack) (Пуск таймера T3-rtx) {Прил. перед. 1 сообщ.; strm 1} (группировка ACK и DATA) DATA [TSN=8,Strm=0,Seq=4] —-\ /– SACK [TSN Ack=7,Block=0] \ / DATA [TSN=6,Strm=1,Seq=2] \ / (Запуск таймера T3-rtx) \ / \ (Перезап. таймера T3-rtx)<—–/ \–> (задержка ACK) (задержка ACK) {передача ACK} SACK [TSN Ack=6,Block=0] ————–> (Остан. таймера T3-rtx) .. (передача ACK) (Остан. таймера T3-rtx) <————– SACK [TSN Ack=8,Block=0]

Рисунок 8. Пример правил для таймера.

На рисунке 8 показан пример использования правил для таймера (предполагается, что получатель использует отложенные подтверждения).

6.3.3. Обработка завершения отсчёта T3-rtx

При завершении отсчёта T3-rtx для адреса получателя выполняются перечисленные ниже действия.

  1. Для этого адреса изменяется значение ssthresh в соответствии с правилами, приведёнными в параграфе 7.2.3, и устанавливается cwnd = PMDCS.
  2. Для этого адреса устанавливается RTO = RTO * 2. Максимальное значение, рассмотренное в правиле C7 (RTO.max), может служить верхней границей для операций удваивания.
  3. Определяется количество более ранних (т. е., с меньшими TSN) неподтвержденных блоков DATA для этого адреса, которые можно поместить в один пакет с учётом ограничений PMTU на пути доставки по этому транспортному адресу (для разных путей могут быть разные значения, см. параграф 6.4). Обозначим найденное число блоков K. Эти K блоков DATA группируются в один пакет для получателя.
  4. Запускается таймер повтора T3-rtx для адреса, по которому был передан повторный пакет, если приведённое выше правило R1 указывает это. Используемое для таймера значение RTO следует брать для одного из адресов, по которым передаётся повтор – в случае многодомного получателя значения могут различаться для разных адресов получателя (см. параграф 6.4).

После повтора передачи, когда будет проведено новое измерение RTT (это может случиться только в том случае, когда новые данные были переданы и подтверждены в соответствии с правилом C5 или измерение сделано на основе HEARTBEAT, см. параграф 8.3), выполняется расчёт по правилу C3 (включая вычисление RTO), который может привести к «коллапсу» RTO (со снижением значения до начального уровня) после того, как это значение было удвоено (правило E2).

Любые блоки DATA, переданные по адресу, для которого истекло время T3-rtx, но не был заполнен пакет SCTP размером не более PMTU (правило E3), следует пометить для повторной передачи и передать, как только позволит cwnd (обычно при получении SACK).

Заключительное правило управления таймером повтора передачи связано с восстановлением при отказах (см. параграф 6.4.1).

  1. Всякий раз, когда конечная точка переключается с текущего транспортного адреса получателя на другой транспортный адрес, текущий таймер повтора передачи продолжает работать. Как только конечная точка передаст пакет, содержащий блок(и) DATA, по новому транспортному адресу, запускается таймер для этого адреса с использованием значения RTO для адреса получателя, по которому были переданы данные, если правило R1 указывает, что это нужно сделать.

6.4. Многодомные точки SCTP

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

ULP в конечной точке выбирает один из адресов многодомного партнёра для основного пути (параграфы 5.1.2 и 10.1).

По умолчанию конечной точке следует всегда передавать данные по основному пути, если пользователь SCTP явно не указал транспортный адрес получателя (возможно и транспортный адрес отправителя).

Конечной точке следует передавать блоки откликов (например, INIT ACK, COKIE ACK, HEARTBEAT ACK) по тому же транспортному адресу, с которого был получен управляющий блок, вызвавший передачу отклика.

Выбор транспортного адреса получателя пакетов с блоками SACK зависит от реализации. Однако конечной точке не следует менять транспортный адрес получателя SACK в случае приёма блоков DATA с тем же адресом отправителя.

При подтверждении нескольких блоков DATA, полученных в пакетах с разных адресов, в одном SACK этот блок SACK может передаваться по одному из транспортных адресов, с которых были получены подтверждаемые блоки DATA или управляющие блоки.

Когда получатель дубликата блока DATA передаёт блок SACK многодомной конечной точке, он может воспользоваться выбором адреса получателя и не применять адрес отправителя блока DATA. Причина этого заключается в том, что получение дубликата от многодомной конечной точки может указывать на то, что путь возврата, указанный в поле отправителя блока DATA, может быть недоступен (разорван) для передачи SACK.

Конечной точке, имеющей многодомного партнёра, следует пытаться повторять передачу блока по активному транспортному адресу, отличающемуся от последнего адреса получателя, по которому был передан блок.

Когда партнёр конечной точки является многодомным, ей следует передавать ускоренные повторы по тому же транспортному адресу получателя, куда данные направлялись исходно. Если основной путь сменился, а исходные данные переданы по старому основному пути до Fast Retransmit, реализация может отправить повтор по новому пути.

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

6.4.1. Переключение с неактивного адреса получателя

Некоторые транспортные адреса многодомной конечной точки SCTP могут утратить активность в результате ошибок (см. параграф 8.2) или по желанию пользователя SCTP.

Когда имеются данные для передачи и основной путь становится неактивным (например, по причине отказа) или пользователь SCTP явно запрашивает передачу данных по неактивному транспортному адресу получателя, до передачи сообщения об ошибке ULP, конечной точке SCTP следует предпринять попытку передачи данных по другому активному адресу получателя, если таковой имеется.

При повторе передачи данных в результате тайм-аута, если конечная точка является многодомной, ей следует рассматривать каждую пару адресов «отправитель-получатель» в политике выбора при повторе. Передающей конечной точке следует пытаться выбрать для повтора пару адресов, наиболее сильно отличающуюся от использованной при первой попытке пары «отправитель-получатель».

Примечание. Правила выбора максимально отличающейся пары зависят от реализации и не определяются данной спецификацией.

6.5. Идентификаторы и порядковые номера в потоке

Каждый блок DATA должен содержать действительный идентификатор потока. Если конечная точка принимает блок DATA с недействительным идентификатором, ей следует подтвердить получение данных в соответствии с обычной процедурой, незамедлительно передать блок ERROR с причиной ошибки Invalid Stream Identifier (недейсвительный идентификатор потока, см. параграф 3.3.10) и отбросить блок DATA. Конечная точка может группировать блок ERROR в один пакет с блоком SACK.

Порядковые номера во всех потоках должны начинаться с нуля при создании ассоциации. Значение Stream Sequence Number должно увеличиваться на 1 для каждого упорядоченного пользовательского сообщения, переданного в выходной поток. При достижении порядковым номером в потоке значения 65535 следующим номером снова должен быть 0. Для неупорядоченных пользовательских сообщение менять Stream Sequence Number недопустимо.

6.6. Упорядоченная и неупорядоченная доставка

Внутри потока конечная точка должна доставлять блоки DATA, полученные с флагом U = 0, на вышележащий уровень в соответствии с порядковыми номерами блоков в потоке. Если блоки DATA поступают с нарушением порядка, конечная точка должна удерживать полученные блоки DATA от передачи ULP, пока не будет восстановлен порядок.

Однако конечная точка SCTP может запросить неупорядоченную доставку для определённого блока DATA, передаваемого в потоке, установив для этого блока флаг U = 1.

При получении конечной точкой блока DATA с флагом U = 1, этот блок должен обрабатываться в обход механизма упорядочивания и незамедлительно доставляться на вышележащий уровень (после сборки фрагментов, если отправитель фрагментировал блок).

Это обеспечивает эффективный способ передачи «дополнительных» (out-of-band) данных в потоке. Кроме того, весь поток можно сделать неупорядоченным, устанавливая флаг U = 1 для каждого блока DATA в этом потоке.

Примечание для разработчиков. При передаче неупорядоченного блока DATA реализация протокола может помещать такой блок DATA в начало очереди на передачу, если такая возможность имеется.

Поле Stream Sequence Number в блоке DATA с флагом U = 1 не имеет смысла. Отправитель может указывать в этом поле произвольное значение, а получатель должен игнорировать это поле.

Примечание. При передаче упорядоченных и неупорядоченных данных, конечная точка не увеличивает своё значение поля Stream Sequence Number, передавая блок DATA с флагом U = 1.

6.7. Информация о пропусках в TSN блоков DATA

При получении нового блока DATA конечная точка проверяет непрерывность порядковых номеров TSN. Если обнаружен пропуск в порядковых номерах принятых блоков DATA, конечной точке следует незамедлительно передать блок SACK с Gap Ack Block. Получатель продолжает передачу SACK после приёма каждого пакета SCTP, который не закрывает пропуск в порядковых номерах.

На основе Gap Ack Block из полученного блока SACK конечная точка может определить пропущенные блоки DATA и принять решение о необходимости повторной передачи таких блоков (см. параграф 6.2.1).

В одном блоке SACK может передаваться информация о нескольких обнаруженных пропусках (см. параграф 3.3.4).

Если партнёр является многодомным, конечной точке SCTP всегда следует пытаться передать SACK по тому адресу, с которого был получен последний блок DATA.

При получении блока SACK конечная точка должна удалить из выходной очереди все блоки DATA, которые были подтверждены в Cumulative TSN Ack блока SACK. Передающая конечная точка должна считать «отсутствующими» все блоки DATA с номерами TSN, не включёнными в Gap Ack Block, которые меньше максимального TSN из блока SACK. Число отчётов о «потерях» для каждого неподтвержденного блока DATA должно быть записано отправителем, чтобы принять решение о повторной передаче (см. параграф 7.2.4).

На рисунке 9 приведён пример использования SACK для передачи информации о пропуске порядковых номеров.

Точка A Точка Z {Приложение передало 3 сообщения; strm 0} DATA [TSN=6,Strm=0,Seq=2] —————> (задержка ack) (Запуск таймера T3-rtx) DATA [TSN=7,Strm=0,Seq=3] ——–> X (потерян) DATA [TSN=8,Strm=0,Seq=4] —————> (обнаружен пропуск, немедленная передача ack) /—– SACK [TSN Ack=6,Block=1, / Strt=2,End=2] <—–/ (удаляем 6 из выходной очереди и помечаем 7 как отчёт о пропуске “1”)

Рисунок 9. Отчет о пропуске с использованием SACK.

Максимальное число Gap Ack Block, которые могут быть включены в один блок SACK, ограничивается текущим значением PMTU. Когда в один блок SACK невозможно включить все Gap Ack Block, которые нужно передать, по причине ограничения PMTU, конечная точка должна передать только один блок SACK, который должен включать все Gap Ack Block от младших номеров TSN к старшим, помещающиеся в блок, ограниченный PMTU, и оставить старшие номера TSN неподтвержденными.

6.8. Расчёт контрольных сумм CRC32c

При передаче пакета SCTP конечная точка должна для обеспечения возможности контроля целостности данных включить в пакет значение контрольной суммы CRC32c в соответствии с приведённым ниже описанием.

После создания пакета (общий заголовок SCTP и один или несколько управляющих блоков или блоков DATA) отправитель должен выполнить перечисленные ниже операции.

  1. Заполнить поле Verification Tag общего заголовка SCTP и установить нулевое значение в поле контрольной суммы.
  2. Рассчитать контрольную сумму CRC32c с включением общего заголовка SCTP и всех блоков из пакета. Описание алгоритма CRC32c приводится в Приложении A.
  3. Поместить полученное значение в поле контрольной суммы общего заголовка, не изменяя остальных битов.

При получении пакета SCTP принимающая конечная точка должна сначала проверить значение контрольной суммы CRC32c в заголовке, как описано ниже.

  1. Сохранить полученное в пакете значение контрольной суммы CRC32c.
  2. Заменить 32-битовое поле контрольной суммы принятого пакета SCTP значением 0 и рассчитать контрольную сумму CRC32c для полученного пакета.
  3. Сравнить сохранённое значение (из пакета) CRC32c с контрольной суммой, полученной в результате расчёта. Если значения не совпадут, получатель должен считать принятый пакет недействительным.

По умолчанию недействительные пакеты SCTP отбрасываются без уведомления.

Аппаратным реализациям следует обеспечивать возможность программной проверки контрольных сумм.

6.9. Фрагментация и сборка

Конечная точка может поддерживать фрагментацию при передаче блоков DATA и должна поддерживать сборку фрагментов для принимаемых блоков DATA. Если конечная точка поддерживает фрагментацию, она должна фрагментировать пользовательские сообщения, когда их размер приводит к созданию пакетов SCTP, превышающих по своему размеру значение PMTU. Если реализация не поддерживает фрагментацию, конечная точка должна возвращать вышележащему уровню код ошибки, когда размер пакета SCTP превышает текущее значение PMTU, передать сообщения избыточного размера недопустимо.

Реализация SCTP может обеспечивать вышележащему уровню механизм запрета фрагментирования при передаче блоков DATA. При отключённой фрагментации блоков DATA реализация SCTP должна вести себя так, будто фрагментация не поддерживается, т. е. отвергать вызовы, приводящие к созданию пактов SCTP, размер которых превышает PMTU.

Примечание для разработчиков. В случае ошибки для возврата кода вышележащему уровню нужно использовать примитив SEND, рассматриваемый в параграфе 11.1.5.

Если партнёр является многодомным, конечной точке следует выбирать размер блока DATA, не превышающий значение AMDCS.

После фрагментации сообщения оно не может быть фрагментировано ещё раз. Если же значение PMTU уменьшилось, должна использоваться фрагментация IP. Поэтому реализация SCTP может сталкиваться в отказом, если фрагментация IP не работает на каком-либо пути. Определение значений PMTU рассматривается в параграфе 7.3.

При решении вопроса о необходимости фрагментирования реализация SCTP должна принимать во внимание размер заголовка пакета SCTP и заголовков блоков DATA. Должен также приниматься во внимание размер блоков SACK, если они группируются с блоком DATA.

Фрагментация выполняется следующим образом.

  1. Отправитель должен разбить пользовательское сообщение на несколько блоков DATA. Отправителю следует выбирать размер блоков DATA, не превышающий AMDCS.
  2. Передающая сторона должна выделять по порядку номера TSN для каждого из блоков DATA, содержащих фрагменты сообщения. Всем блокам DATA, содержащим фрагменты одного сообщения, присваиваются одинаковые номера SSN. Если пользователь указал, что сообщение доставляется без соблюдения порядка, для каждого блока DATA должен быть установлен флаг U = 1.
  3. Отправитель должен также установить для битов B/E в первом блоке DATA значение 10, в последнем – 01, а в остальных – 00.

Конечная точка должна распознавать фрагментированные блоки DATA путём проверки битов B/E в каждом принятом блоке DATA и помещать фрагменты в очередь для сборки. После сборки пользовательского сообщения из фрагментов, протокол SCTP будет передавать собранное сообщение в конкретный поток для возможного упорядочивания и окончательной диспетчеризации.

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

6.10. Группировка блоков

Конечная точка группирует блоки путём простого включения множества блоков в один исходящий пакет SCTP. Суммарный размер получающейся в результате дейтаграммы IP (включая пакет SCTP и заголовок IP) должен быть не более текущего значения PMTU.

Если партнёр является многодомным, передающей стороне следует выбирать размер пакета так, чтобы он не превышал значение PMTU для текущего основного пути.

При группировке управляющих блоков с блоками DATA конечная точка должна помещать управляющие блоки в начале пакета SCTP. Отправитель должен передавать блоки DATA в пакете SCTP в соответствии с ростом TSN.

Примечание. Поскольку управляющие блоки размещаются в пакете первыми, а блоки DATA должны передаваться до управляющих блоков SHUTDOWN и SHUTDOWN ACK, блоки DATA не могут группироваться с блоками SHUTDOWN или SHUTDOWN ACK.

Недопустимо включение в пакет SCTP неполных блоков (Partial chunk). Неполным является блок, которым не помещается в пакет SCTP (пакет слишком мал для включения всех байтов, указанных в поле размера блока).

Принимающая сторона должна обрабатывать полученные блоки в порядке их следования в пакете. Получатель использует поле длины блока для определения конца данного блока и начала следующего. При определении начала блока не следует забывать о выравнивании блоков по 4-байтовой границе. Если получатель обнаруживает в пакете неполный блок, такой блок должен быть отброшен.

Недопустимо группировать блоки INIT, INIT ACK, SHUTDOWN COMPLETE с любыми другими блоками.

7. Контроль перегрузки

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

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

Алгоритмы контроля перегрузки протокола SCTP основаны на [RFC5681]. В этом разделе описано, как алгоритмы, определённые в [RFC5681], адаптированы для использования в SCTP. Сначала рассматриваются различия между протоколами TCP и SCTP, а после этого описывается схема контроля перегрузки в SCTP. В описании используется та же терминология, которая принята для протокола TCP.

Контроль перегрузки в SCTP всегда применяется ко всей ассоциации (соединению), а не к отдельным потокам.

7.1. Различия в контроле перегрузки для SCTP и TCP

Gap Ack Block в SCTP SACK имеют такой же смысл, как TCP SACK. Протокол TCP рассматривает информацию в SACK только как консультативную и в SCTP сведения из Gap Ack Blocks блоков SACK являются лишь консультативными. В SCTP любой блок DATA, подтверждённый с помощью SACK (включая блоки DATA, полученные с нарушением порядка), не считается доставленным окончательно, пока Cumulative TSN Ack Point не перейдёт значение TSN блока DATA (т. е., пока блок DATA не будет подтверждён полем Cumulative TSN Ack в SACK). Поэтому значение параметра cwnd контролирует количество неподтвержденных данных, а не (как в случае TCP без SACK) верхнюю границу между максимальным подтверждённым порядковым номером и последним блоком DATA, который может быть передан в окне перегрузки. SCTP SACK обусловливает отличие реализации механизмов ускоренного повтора (fast-retransmit) и быстрого восстановления (fast-recovery) от случая TCP без SACK. Пример этого приведён в [FALL96].

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

  • Отправитель обычно не меняет адрес получателя, пока не получит запрос на такую замену от протокола вышележащего уровня. Однако SCTP может переключиться на другой адрес получателя, если прежний адрес был помечен, как неактивный (см. параграф 8.2). Кроме того, SCTP может повторять передачу пакетов по адресам, отличающимся от тех, которые использовались для передачи исходного пакета.
  • Отправитель сохраняет отдельный набор параметров контроля перегрузки для каждого адреса получателя, по которому он может передавать данные (не для каждой пары адресов «отправитель-получатель», а для каждого адреса получателя). Параметры следует отбрасывать, если адрес не используется достаточно долго. В [RFC5681] этот период указан как тайм-аут повторной передачи.
  • Для каждого адреса получателя конечная точка выполняет процедуру замедленного старта (slow-start) при первой передаче по этому адресу.

Примечание. TCP гарантирует упорядоченную доставку данных протоколу вышележащего уровня в рамках одной сессии TCP. Это означает, что при получении протоколом TCP информации о пропуске в порядковых номерах он будет ждать заполнения пропуска и только после этого передаст данные вышележащему уровню. SCTP может доставлять данные на вышележащий уровень даже при наличии пропусков в порядковых номерах TSN, если порядковые номера в потоке (Stream Sequence Number) упорядочены в рамках данного потока (т. е., пропущенный блок DATA относится к другому потоку) или при запросе неупорядоченной доставки. Это различие не оказывает влияния на cwnd, но может влиять на расчёт rwnd.

7.2. Процедуры Slow-Start и Congestion Avoidance

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

Подобно TCP, конечная точка SCTP использует 3 указанных ниже переменных для управления скоростью передачи.

  • Анонсируемый получателем размер окна приёма (rwnd25, в байтах) устанавливается получателем данных с учётом возможностей выделения буферов для принимаемых пакетов.
  • Окно контроля перегрузки (cwnd26, в байтах) устанавливается отправителем с учётом условий в сети.
  • Порог замедленного старта (ssthresh27, в байтах) используется отправителем для принятия решения о выборе используемого алгоритма контроля перегрузки (slow start или congestion avoidance).
  • Примечание. Эта переменная поддерживается для каждого адреса получателя.
  • Примечание. Эта переменная поддерживается для каждого адреса получателя.
  • Примечание. Эта переменная имеет общее значение для всей ассоциации.

Протокол SCTP использует также одну дополнительную переменную – partial_bytes_acked, которая применяется в фазе предотвращения перегрузки для упрощения расчёта значения cwnd.

В отличие от TCP, отправитель SCTP должен хранить набор из трёх переменных (cwnd, ssthresh и partial_bytes_acked) для каждого адреса получателя у партнёра (если тот является многодомным). При расчёте этих переменных следует использовать размер блоков DATA с учётом заполнения.

Только переменная rwnd имеет общее значение для всей ассоциации (независимо от того, является ли партнёр многодомным).

7.2.1. Замедленный старт

Начиная передачу данных в сеть с неизвестными условиями или возобновляя передачу после достаточно долгого простоя, протокол SCTP должен проверить сеть на предмет пропускной способности. Для этих целей используется алгоритм slow start в начале передачи или при восстановлении потерь, обнаруженных по таймеру повтора передачи.

  • В качестве стартового значения cwnd до передачи блоков DATA или после достаточно долгого бездействия должно выбираться значение min(4*PMDS, max (2*PMDS, 4404) байт для адреса партнёра IPv4 и min(4*PMDS, max (2*PMDS, 4344) байт для IPv6.
  • Начальное значение cwnd после тайм-аута повтора передачи должно быть не более PMDS и разрешается лишь один находящийся в пути пакет без подтверждения.
  • Начальному значению ssthresh следует быть произвольно большим (например, размер наибольшего возможного анонсируемого окна).
  • При положительном значении cwnd конечная точка может иметь cwnd ожидающих подтверждения байтов данных для этого транспортного адреса. Следует поддерживать ограниченное превышение, как указано в правиле B параграфа 6.1.
  • Если cwnd не больше ssthresh, конечная точка SCTP должна использовать алгоритм slow-start для увеличения размера cwnd только в том случае, когда текущее окно перегрузки полностью использовано и отправитель данных не находится в состоянии Fast Recovery. Размер окна cwnd можно увеличивать только при выполнении обох условий, в противном случае увеличение недопустимо. Если все условия выполнены, значение cwnd должно увеличиваться не более чем на меньшее из двух значений:
    1. общий размер подтверждённых блоков DATA
    2. L раз по PMDS получателя.

    Первое ограничение обеспечивает защиту от атак ACK-Splitting, описанных в [SAVAGE99]. Положительному целому числу L следует иметь значение 1 и можно использовать большее значение. Выбор L описан в [RFC3465].

  • В случаях, когда партнёр является многодомным и конечная точка получает подтверждение SACK, ведущее к обновлению cwnd, ей следует обновить значение cwnd (или несколько значений cwnd) для адреса получателя, по которому были переданы подтверждённые данные.
  • Когда конечная точка не передаёт по данному транспортному адресу, в качестве cwnd для этого адреса следует установить max(cwnd/2, 4*PMDS) один раз за RTO. До первого обновления cwnd для параметра ssthresh следует установить значение cwnd.

7.2.2. Предотвращение перегрузки

При cwnd > ssthresh, значение cwnd следует увеличивать на PMDS за каждый период RTT, если у отправителя имеется не менее cwnd байтов неподтвержденных данных для соответствующего транспортного адреса. Базовые рекомендации по увеличению cwnd в случае предотвращения перегрузки приведены ниже.

  • SCTP может увеличивать cwnd на PMDS.
  • SCTP следует увеличивать cwnd на PMDS 1 раз за период RTT, когда у отправителя есть не менее cwnd остающихся байтов данных для соответствующего транспортного адреса.
  • SCTP недопустимо увеличивать cwnd более чем на PMDS за период RTT.

На практике эта процедура может быть реализована описанным ниже способом.

  • Устанавливается partial_bytes_acked = 0.
  • Если cwnd > ssthresh, всякий раз при получении SACK значение partial_bytes_acked увеличивается на общее число байтов (включая заголовок блока и заполнение) во всех новых блоках DATA, подтверждённых этим SACK, включая блоки, подтверждённые новым значением Cumulative TSN Ack, Gap Ack Block и и число байтов в блоках-дубликатах, указанных в Duplicate TSN.
  • Когда (1) значение partial_bytes_acked становится больше cwnd и (2) до прибытия SACK у отправителя имеется менее cwnd остающихся данных (т. е., до прибытия SACK, объем переданных, но ещё не подтверждённых данных меньше cwnd), устанавливается partial_bytes_acked = cwnd.
  • Когда (1) значение partial_bytes_acked становится равным cwnd или превышает его и до прибытия SACK у отправителя имеется не менее cwnd остающихся данных (т. е., до прибытия SACK, объем переданных, но еще не подтверждённых данных не меньше cwnd), значение partial_bytes_acked уменьшается на cwnd, а затем cwnd увеличивается на PMDS.
  • Как и при замедленном старте в качестве значения cwnd для адреса получателя следует установить max(cwnd/2, 4*PMDS) за период RTO, если отправитель не передаёт блоков DATA по данному адресу.
  • Когда все переданные отправителем данные подтверждены получателем, устанавливается partial_bytes_acked = 0.

7.2.3. Контроль перегрузки

При обнаружении потери пакета из подтверждения SACK (см. параграф 7.2.4), конечной точке следует установить

ssthresh = max(cwnd/2, 4*PMDS) cwnd = ssthresh partial_bytes_acked = 0

Обычно потеря пакета приводит к уменьшению cwnd вдвое.

По завершении отсчёта таймера T3-rtx для адреса, SCTP следует выполнить процедуру slow start, установив

ssthresh = max(cwnd/2, 4*PMDS) cwnd = PMDS partial_bytes_acked = 0

и обеспечить наличие не более одного пакета SCTP на пути от отправителя к получателю, пока конечная точка не получит подтверждения доставки данных по этому адресу.

7.2.4. Ускоренный повтор при пропуске

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

Всякий раз при получении SACK, указывающего на пропуск TSN, конечной точке следует дождаться 2 последующих индикаций потери (в следующих подтверждениях SACK) для тех же номеров, прежде, чем начать реализацию механизма ускоренного повтора (Fast Retransmit).

Для индикации пропусков следует применять алгоритм HTNA28. Для каждого входящего блока SACK значение счётчика индикации пропуска увеличивается только для пропущенных TSN до HTNA в SACK. Недавно подтверждённым блоком DATA считается блок, который не был ранее указан в SACK. Если конечная точка в состоянии Fast Recovery получает блок SACK, указывающий за пределы Cumulative TSN Ack Point, значения индикации пропуска увеличиваются для всех TSN, пропуск которых указывает этот блок SACK.

При получении третьей индикации отсутствующих TSN отправитель выполняет указанные ниже действия.

  1. Пометить указанные блоки DATA для повторной передачи.
  2. Если не введён режим Fast Recovery, изменить значения ssthresh и cwnd для адреса (или нескольких адресов) получателя, по которому были переданы утерянные данные в последний раз, согласно выражениям, приведённым в параграфе 7.2.3.
  3. Если не введён режим Fast Recovery, определить, сколько наиболее ранних (т. е., с меньшими TSN) блоков DATA может быть включено в один пакет с учётом значения PMTU для транспортного адреса получателя, по которому будут передаваться данные (обозначим это количество буквой K). Повторно передать эти K блоков DATA в одном пакете. В режиме Fast Retransmit отправителю следует игнорировать значение cwnd и не следует задерживать повтор передачи для одного данного пакета.
  4. Заново запустить таймер T3-rtx, если последнее подтверждение SACK относится к меньшему из неподтвержденных TSN для данного адреса получателя или конечная точка повторяет передачу первого из неподтвержденных блоков DATA, переданных по этому адресу.
  5. Пометить блок(и) DATA, как ускоренно повторённый и не приемлемый для последующего режима Fast Retransmit. Эти TSN маркируются для повторной передачи по причине того, что алгоритм Fast Retransmit не подходит для дейтаграммы, содержащей K других TSN, которые также отмечены неприемлемыми для последующего ускоренного повтора. Однако в результате маркировки для повтора они будут переданы заново, как только позволит cwnd.
  6. Перейти в режим Fast Recovery (если он ещё не введён) и указать старший остающийся номер TSN как точку выхода из режима быстрого восстановления. Когда блок SACK подтвердит все TSN, вплоть до указанной точки выхода, режим быстрого восстановления завершается. В режиме Fast Recovery значения ssthresh и cwnd не следует менять для каких-либо получателей в результате следующего события Fast Recovery (т. е. не следует снижать значение cwnd в результате последующего ускоренного повтора).

Примечание. Если полученный блок SACK также подтверждает новые блоки DATA за пределами Cumulative TSN Ack Point, перед выполнением перечисленных в пп. 1-6 операций сначала должно быть изменено значение cwnd в соответствии с правилами, приведёнными в параграфах 7.2.1 и 7.2.2.

7.2.5. Повторная инициализация

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

7.2.5.1. Смена кодов дифференцированного обслуживания

Реализации SCTP могут разрешать приложениям настраивать коды DSCP (Differentiated Services Code Point) для передаваемых пакетов. Если смена DSCP может приводить к размещению пакетов в разных очередях, параметры контроля перегрузок для всех затрагиваемых адресов получателя должны быть сброшены к начальным значениям.

7.2.5.2. Смена маршрутов

Реализации SCTP могут знать об изменении маршрутов, влияющем на пакеты, отправленные получателю. В частности, это включает выбор другого адреса отправителя в передаваемых пакетах. При таких изменениях маршрутов параметры контроля перегрузок для всех затрагиваемых адресов получателя должны быть сброшены к начальным значениям.

7.3. Определение PMTU

В [RFC8899], [RFC8201] и [RFC1191] описан алгоритм определения MTU на пути для уровня пакетизации (Packetization Layer Path MTU Discovery), позволяющий конечным точкам оценить PMTU для данного пути через Internet и воздерживаться от передачи по этому пути пакетов, размер которых превышает PMTU, без использования методов зондирования с целью определения изменений PMTU. В [RFC8899] подробно рассмотрен механизм определения PMTU и стратегия установки сквозного значения PMTU, а также детектирования изменений PMTU.

Конечной точке следует применять эти методы определения MTU, а также следует выполнять такое определение PMTU независимо для каждого адреса получателя.

При определении значения PMTU для протокола SCTP существуют несколько специфических аспектов.

  1. Ассоциация SCTP может включать множество адресов. Конечная точка должна поддерживать отдельную оценку значения PMTU для каждого из адресов своего партнёра.
  2. Отправителю следует отслеживать значение AMDCS, которое будет меньшим из PMDCS среди всех адресов партнёра. При фрагментации сообщений значение AMDCS следует использовать для определении размера каждого блока DATA. Такой подход позволит передавать фрагменты по любому из возможных путей без дополнительной фрагментации на уровне IP.

8. Контроль отказов

8.1. Обнаружение отказов конечных точек

Конечной точке следует подсчитывать общее количество последовательных повторов передачи своему партнёру (включая повторы по всем адресам для многодомных партнёров) с учётом неподтвержденных блоков HEARTBEAT, наблюдаемых на текущем пути передачи данных. Неподтвержденные блоки HEARTBEAT на других путях не следует учитывать в счетчике ошибок, поскольку это ведёт к закрытию ассоциации даже если текущий путь передачи данных доступен (но бездействует). Если значение этого счётчика превысит порог, указанный параметром протокола Association.Max.Retrans29, конечной точке следует рассмотреть вопрос о доступности партнёра и нужно прекратить передачу ему каких-либо данных (т. е. перевести ассоциацию в состояние CLOSED). Кроме того, конечной точке следует передать информацию об отказе (и, возможно, об оставшихся в выходной очереди данных) протоколу вышележащего уровня. Ассоциация автоматически закрывается, когда удалённый партнёр становится недоступным.

Счётчик повторов должен сбрасываться всякий раз, когда переданный партнёру блок DATA подтверждается (приём SACK) и его следует сбрасывать при получении от удалённого партнёра блока HEARTBEAT ACK. Получатель блока HEARTBEAT ACK может не сбрасывать счётчик, если имеет в ассоциации остающиеся данные. Это позволяет обрабатывать возможные различия в доступности на основе блоков DATA и HEARTBEAT.

8.2. Обнаружение отказов на пути

Если партнёр является многодомным, конечной точке следует поддерживать счётчики ошибок для каждого транспортного адреса этого партнёра.

Каждый раз, когда завершается отсчёт таймера T3-rtx для любого из адресов или передача HEARTBEAT по бездействующему адресу не подтверждается в течение RTO, значение счётчика ошибок для соответствующего адреса будет увеличиваться на 1. Когда значение счётчика превысит значение параметра протокола Path.Max.Retrans30 для данного адреса, конечной точке следует пометить этот адрес как неактивный, а также следует передать уведомление об этом протоколу вышележащего уровня.

Когда остающиеся TSN подтверждаются или блок HEARTBEAT, переданный по бездействующему адресу, подтверждается блоком HEARTBEAT ACK, конечной точке следует сбрасывать счётчик ошибок для транспортного адреса получателя, по которому был отправлен последний блок DATA (или HEARTBEAT), а также следует информировать вышележащий уровень при активизации неактивного адреса. Если партнёр является многодомным и последний блок был передан ему в качестве повтора с изменением адреса получателя, возникает неоднозначность в выборе адреса, для которого следует учитывать полученное подтверждение. Однако эта неоднозначность не оказывает существенного влияния на дальнейшее поведение SCTP. Если такие неоднозначности нежелательны, отправитель может не сбрасывать счётчик ошибок, когда последний блок передавался повторно.

Примечание. При настройке конфигурации конечной точки SCTP пользователь должен избегать установки для параметра Association.Max.Retrans значения, превышающего любое из значений Path.Max.Retrans для адресов партнёра. В противном случае все адреса удалённого партнёра могут стать неактивными, а данная точка будет по-прежнему считать этого партнёра доступным. При возникновении такой ситуации поведение протокола SCTP будет зависеть от реализации.

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

8.3. Проверка жизнеспособности пути

По умолчанию конечной точке SCTP следует вести мониторинг доступности бездействующих транспортных адресов своего партнёра путём периодической отправки по таким адресам блоков HEARTBEAT. Передача HEARTBEAT может начинаться с момента перехода в состояние ESTABLISHED и завершаться после отправки блока SHUTDOWN или SHUTDOWN-ACK. Получатель HEARTBEAT должен отвечать на него блоком HEARTBEAT-ACK после перехода в состояние COOKIE-ECHOED (отправитель INIT) или ESTABLISHED (получатель INIT), пока не перейдёт в состояние SHUTDOWN-SENT (отправитель SHUTDOWN) или SHUTDOWN-ACK-SENT (получатель SHUTDOWN).

Транспортный адрес рассматривается как бездействующий (idle), если нет новых блоков, которые можно использовать для обновления периода RTT на пути (обычно, первая передача DATA, INIT, COOKIE ECHO, HEARTBEAT и т. п.), и в течение текущего периода «проверки пульса»31 по этому адресу не было передано блоков HEARTBEAT. Эта трактовка относится как к активным адресам, так и к неактивным.

Вышележащий уровень может дополнительно инициировать перечисленные ниже функции.

  1. Запрет HEARTBEAT для определённого транспортного адреса в данной ассоциации.
  2. Изменение HB.interval.
  3. Восстановление передачи HEARTBEAT для указанного адреса в данной ассоциации.
  4. Запрос на передачу HEARTBEAT по указанному адресу в данной ассоциации.

Конечной точке следует увеличивать значение соответствующего счётчика ошибок для транспортного адреса партнёра всякий раз, когда переданный по этому адресу блок HEARTBEAT не подтверждён в течение периода RTO.

Когда значение счётчика достигает значения протокольного параметра Path.Max.Retrans, конечной точке следует пометить соответствующий адрес получателя как неактивный (если он ещё не помечен). Кроме того, конечной точке следует уведомить вышележащий уровень об изменении состояния доступности данного адреса. После этого конечной точке следует продолжать передачу блоков HEARTBEAT по этому адресу, но без увеличения значения счётчика ошибок.

Отправителю блока HEARTBEAT следует включать в поле Heartbeat Information этого блока текущее время в момент передачи пакета и адрес получателя пакета.

Примечание для разработчиков. Можно использовать иной механизм, при котором значение счётчика увеличивается при передаче каждого блока HEARTBEAT. В таких случаях по прибытию подтверждения HEARTBEAT ACK следует сбрасывать счётчик для того адреса, по которому был передан подтверждённый блок HEARTBEAT. Такое уменьшение будет компенсировать рост значения счётчика при передаче каждого блока, а также сбрасывать результаты увеличения счётчика вследствие других ошибок.

Получателю блока HEARTBEAT следует незамедлительно передать в ответ подтверждение HEARTBEAT ACK, содержащее Heartbeat Information TLV из полученного блока HEARTBEAT.

При получении блока HEARTBEAT ACK отправителю блока HEARTBEAT следует сбросить счётчик ошибок для транспортного адреса получателя, по которому был отправлен подтверждённый блок HEARTBEAT, и пометить адрес как активный (если он не был помечен ранее). Конечной точке следует сообщать вышележащему уровню об активизации транспортного адреса в результате получения последнего блока HEARTBEAT ACK. Получателю блока HEARTBEAT ACK следует также сбросить значение общего счётчика ошибок для ассоциации (см. параграф 8.1).

Получателю HEARTBEAT ACK следует также выполнить определение RTT для транспортного адреса партнёра, используя значение времени из блока HEARTBEAT ACK.

Для бездействующего транспортного адреса, по которому разрешено передавать блоки HEARTBEAT, рекомендуется передавать один блок HEARTBEAT в каждый период RTO для данного адреса + HB.interval с вариациями ± 50% от RTO и экспоненциальным откатом RTO, если доставка предыдущего блока HEARTBEAT не подтверждена.

Для пользователей SCTP обеспечивается примитив, позволяющий изменять значение HB.interval и включать/выключать передачу HEARTBEAT для данного адреса. Интервал HB.interval, заданный пользователем SCTP, добавляется к RTO для данного адресата (с учётом экспоненциального отката RTO). Следует передавать только один блок HEARTBEAT в течение каждого периода отсчёта heartbeat-таймера (если бездействует множество адресов). Разработчики вольны определить способ выбора кандидата для передачи блока при наличии множества бездействующих адресов.

При подстройке HB.interval может возникать побочный эффект, который следует принимать во внимание. Когда этот интервал возрастает (блоки HEARTBEAT передаются реже), обнаружение потери блоков ABORT также замедляется. Если партнёр прервёт (ABORT) ассоциацию по какой-либо причине и блок ABORT будет потерян, локальная точка обнаружит прерывание ассоциации только при передаче блока DATA или HEARTBEAT (это вынудит партнёра передать ABORT повторно). Такой эффект следует учитывать при установке значения для таймера HEARTBEAT. Если передача HEARTBEAT запрещена, потеря блока ABORT будет обнаружена только после передачи блока DATA.

8.4. Обработка неожиданных пакетов

Пакет SCTP называется неожиданным (OOTB32), если он правильно сформирован (т. е. включает корректное значение CRC32c, см. параграф 6.8), но получатель не может идентифицировать ассоциацию, к которой этот пакет относится.

Получатель пакета OOTB выполняет перечисленные ниже операции с соблюдением их порядка.

  1. Если в пакете OOTB указан отличный от индивидуального (non-unicast) адрес отправителя или получателя, такой пакет следует отбрасывать без уведомления.
  2. Если пакет OOTB содержит блок ABORT, получатель должен отбросить пакет без уведомления и выполнения каких-либо иных действий.
  3. Если пакет содержит блок INIT с Verification Tag = 0, он обрабатывается, как описано в параграфе 5.1. Если по той или иной причине нормальная обработка INIT невозможна и в ответ передаётся блок ABORT, поле Verification Tag в пакете с блоком ABORT должно иметь значение Initiate Tag из полученного блока INIT, а бит T в блоке ABORT должен быть сброшен (0) для индикации того, что значение Verification Tag не отражено.
  4. Если пакет содержит COOKIE ECHO в первом блоке, он должен обрабатываться в соответствии с параграфом 5.1.
  5. Eсли пакет содержит блок SHUTDOWN ACK, получателю следует передать отправителю пакета OOTB блок SHUTDOWN COMPLETE. При передаче блока SHUTDOWN COMPLETE получатель пакета OOTB должен заполнить поле Verification Tag, скопировав в него значение Verification Tag из блока SHUTDOWN ACK, и установить бит T в поле флагов блока для индикации отражения Verification Tag.
  6. Если пакет содержит блок SHUTDOWN COMPLETE, получателю следует отбросить пакет без уведомления и выполнения каких-либо иных действий.
  7. Если пакет содержит блок ERROR с причиной ошибки Stale cookie или блок COOKIE ACK, пакет SCTP следует отбросить без уведомления.
  8. В остальных случаях получателю следует ответить отправителю OOTB пакетом с блоком ABORT. При передаче блока ABORT получатель пакета OOTB должен указать в поле Verification Tag значение Verification Tag из пакета OOTB и установить бит T в поле флагов для индикации отражения Verification Tag. После передачи блока ABORT получатель пакета OOTB должен отбросить этот пакет, не выполняя каких-либо иных действий.

8.5. Тег верификации

Правила Verification Tag, определённые в этом параграфе, применяются для передачи и приёма пакетов SCTP, не содержащих блоков INIT, SHUTDOWN COMPLETE, COOKIE ECHO (см. параграф 5.1), ABORT или SHUTDOWN ACK. Для перечисленных блоков правила рассмотрены отдельно в параграфе 8.5.1.

При передаче пакета SCTP конечная точка должна заполнить поле Verification Tag, указав в нем значение параметра Initiate Tag из полученного от партнёра блока INIT или INIT ACK.

При получении пакета SCTP конечная точка должна проверить соответствие полученного значения Verification Tag своему значению тега. Если полученное значение Verification Tag не соответствует тегу локальной точки, получатель должен отбросить пакет без уведомления и недопустимо выполнять каких-либо иные операции за исключением случаев, описанных в параграфе 8.5.1.

8.5.1. Исключения из правил для Verification Tag

  1. Правила для пакетов с блоками INIT.
  • Отправитель должен установить Verification Tag = 0.
  • Когда конечная точка получает пакет SCTP с Verification Tag = 0, ей следует убедиться, что пакет содержит только блок INIT. В противном случае пакет должен быть отброшен без уведомления.
  1. Правила для пакетов с блоками ABORT.
  • Конечная точка всегда должна указывать в поле Verification Tag передаваемых пакетов значение тега адресата, если этот тег известен.
  • Если блок ABORT передаётся в ответ на пакет OOTB, конечная точка должна выполнить процедуру, описанную в параграфе 8.4.
  • Получатель блока ABORT должен воспринять пакет, если значение Verification Tag соответствует его собственному тегу при сброшенном бите T или тегу партнёра при установленном бите T. В иных случаях пакет должен отбрасываться без уведомления и выполнения каких-либо других действий.
  1. Правила для пакетов с блоками SHUTDOWN COMPLETE.
  • При передаче блока SHUTDOWN COMPLETE, если получатель блока SHUTDOWN ACK имеет TCB, в поле верификации должен использоваться тег адресата, а установка флага T недопустима. При отсутствии TCB отправителю следует использовать значение Verification Tag из блока SHUTDOWN ACK и он должен установить флаг T.
  • Получатель SHUTDOWN COMPLETE должен воспринять пакет, если поле Verification Tag соответствует его собственному тегу при сброшенном флаге T или тегу партнёра при установленном бите T. В противном случае получатель должен отбрасывать пакет без уведомления и выполнения каких-либо иных действий. Конечная точка должна игнорировать SHUTDOWN COMPLETE, если она не находится в состоянии SHUTDOWN-ACK-SENT.
  1. Правила для пакетов с блоками COOKIE ECHO.
  • При передаче COOKIE ECHO конечная точка должна использовать Initiate Tag из принятого блока INIT ACK.
  • Получателю COOKIE ECHO следует выполнить процедуры, описанные в разделе 5.
  1. Правило для пакетов с блоками SHUTDOWN ACK.
    1. Если получатель находится в состоянии COOKIE-ECHOED или COOKIE-WAIT, следует выполнить процедуры, описанные в параграфе 8.4 (т. е., пакет должен трактоваться как OOTB).

9. Прекращение работы ассоциации

Конечной точке следует прерывать ассоциацию, когда сервис более не требуется. Ассоциация может быть прервана путём разрыва (abort) или завершения (shutdown). Разрыв ассоциации представляет собой прекращение всякой передачи данных с отбрасыванием всех оставшихся не доставленными данных. Завершение ассоциации представляет собой процесс контролируемого прекращения обмена данными с доставкой партнёру всех данных, остающихся в очередях. Однако в случае завершения (shutdown) протокол SCTP не поддерживает полуоткрытых состояний (как в TCP), когда одна сторона может продолжать передачу данных в то время, как другая уже закрыла ассоциацию. Когда конечная точка выполняет процедуру завершения, обе партнёра прекращают приём новых данных от пользователя и доставляются лишь данные, которые были в очередях на момент приёма или передачи блока SHUTDOWN.

9.1. Разрыв ассоциации (Abort)

Когда конечная точка принимает решение о разрыве существующей ассоциации, она должна передать своему партнёру блок ABORT. Отправитель должен включить значение Verification Tag своего партнёра в исходящий пакет. Недопустимо группировать блок ABORT с блоками DATA. Если ассоциация прерывается по запросу вышележащего уровня, в блоке ABORT следует указать причину User-Initiated Abort (см. параграф 3.3.10.12).

Для конечной точки недопустима передача откликов на любой принятый пакет с блоком ABORT (см. параграф 8.4).

Конечная точка, получившая блок ABORT, должна выполнить специальную проверку Verification Tag в соответствии с правилами параграфа 8.5.1.

После проверки Verification Tag принявшая ABORT конечная точка должна удалить ассоциацию из своих записей и ей следует также сообщить о разрыве ассоциации на вышележащий уровень. Если в блоке ABORT указана причина User-Initiated Abort, её следует сделать доступной вышележащему уровню.

9.2. Завершение ассоциации (Shutdown)

Используя примитив SHUTDOWN (параграф 10.1), вышележащий уровень конечной точки ассоциации может выполнить аккуратное завершение работы ассоциации. В этом случае все остающиеся блоки DATA от партнёра инициатора завершения будут доставлены до прерывания ассоциации.

При получении от вышележащего уровня примитива SHUTDOWN конечная точка переходит в состояние SHUTDOWN-PENDING и продолжает находиться в этом состоянии, пока все остающиеся данные не будут подтверждены партнёром. Конечная точка не принимает новых данных от вышележащего уровня, но будет повторять передачу данных партнёру, если в этом возникает необходимость (заполнение пропуска в порядковых номерах).

После того, как все остающиеся данные будут подтверждены партнёром, конечная точка передаёт партнёру блок SHUTDOWN, содержащий в поле Cumulative TSN Ack последний номер TSN, полученный от партнёра. После этого ей следует запустить таймер T2-shutdown и перейти в состояние SHUTDOWN-SENT. По завершении отсчёта таймера конечная точка должна повторно передать блок SHUTDOWN с обновлённым значением последнего порядкового номера TSN, полученного от партнёра.

Должны быть выполнены правила параграфа 6.3 для определения корректного значения таймера T2-shutdown. Для индикации пропусков в TSN конечная точка может группировать блоки SACK и SHUTDOWN в одном пакете SCTP.

Конечной точке следует ограничивать число повторов передачи блока SHUTDOWN с помощью протокольного параметра Association.Max.Retrans. После превышения этого порога конечной точке следует уничтожить TCB, а также следует передать информацию о недоступности партнёра на вышележащий уровень (тем самым ассоциация переводится в состояние CLOSED). При получении любых пакетов от партнёра (блоки DATA из очереди) следует сбрасывать счётчик повтора передачи и заново запускать таймер T2-Shutdown, давая партнёру дополнительную возможность передачи остающихся блоков DATA из его очередей.

При получении блока SHUTDOWN конечная точка:

  • переходит в состояние SHUTDOWN-RECEIVED;
  • прекращает приём новых данных от своего пользователя SCTP;
  • проверяет по полю Cumulative TSN Ack, что все блоки DATA приняты отправителем блока SHUTDOWN.

После перехода конечной точки в состояние SHUTDOWN-RECEIVED она должна игнорировать запросы ULP на завершение и должна отвечать на блоки SHUTDOWN от партнёра.

При наличии остающихся блоков DATA получатель SHUTDOWN должен продолжать обычные процедуры передачи, описанные в разделе 6, пока все остающиеся блоки DATA не будут подтверждены; однако для получателя блока SHUTDOWN недопустимо принимать новые данные от своего пользователя SCTP.

Находясь в состоянии SHUTDOWN-SENT, отправитель блока SHUTDOWN должен незамедлительно передавать в ответ на каждый принятый пакет, содержащий хотя бы один блок DATA, подтверждение SACK и блок SHUTDOWN, а также заново запускать таймер T2-shutdown. Если блок SHUTDOWN сам по себе не может подтвердить все принятые блоки DATA (т. е., имеются номера TSN, которые могут быть подтверждены, но больше кумулятивного значения TSN и в последовательности TSN возникает пропуск) или получены дубликаты TSN, должен передаваться также блок SACK.

Отправитель блока SHUTDOWN может также запустить таймер T5-shutdown-guard для ограничения общей продолжительности процедуры завершения ассоциации. По завершению отсчёта этого таймера отправителю следует разорвать ассоциацию передачей блока ABORT. При использовании таймера T5-shutdown-guard для него следует устанавливать рекомендуемое значение 5 * RTO.Max.

Если у получателя блока SHUTDOWN больше не остаётся блоков DATA, он должен передать блок SHUTDOWN ACK и запустить таймер T2-shutdown, перейдя в состояние SHUTDOWN-ACK-SENT. По завершении отсчёта таймера конечная точка должна повторить передачу SHUTDOWN ACK.

Отправителю SHUTDOWN ACK следует ограничивать число повторов передачи SHUTDOWN ACK с помощью протокольного параметра Association.Max.Retrans. После превышения заданного порога конечной точке следует уничтожить TCB, а также следует сообщить вышележащему уровню о недоступности партнёра (тем самым ассоциация переводится в состояние CLOSED).

При получении блока SHUTDOWN ACK отправитель SHUTDOWN должен остановить таймер T2-shutdown, передать своему партнёру блок SHUTDOWN COMPLETE и удалить все записи для данной ассоциации.

При получении блока SHUTDOWN COMPLETE конечная точка проверяет, что она находится в состоянии SHUTDOWN-ACK-SENT и ей следует отбросить полученный блок, если состояние отличается от указанного. Если же конечная точка находится в состоянии SHUTDOWN-ACK-SENT, ей следует остановить таймер T2-shutdown и удалить все сведения об ассоциацией (тем самым ассоциация переводится в состояние CLOSED).

Конечной точке перед началом процедуры завершения ассоциации следует удостовериться, что все остающиеся блоки DATA были подтверждены.

Конечной точке, находящейся в состоянии SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED или SHUTDOWN-ACK-SENT, следует отвергать все новые запросы данных от вышележащего уровня.

Если конечная точка в состоянии SHUTDOWN-ACK-SENT получает блок INIT (например, при утере блока SHUTDOWN COMPLETE) с транспортными адресами отправителя и получателя (в заголовке IP или блоке INIT), относящимися к данной ассоциации, ей следует отбросить блок INIT и повторить передачу блока SHUTDOWN ACK.

Примечание. Получение пакета с блоком INIT с теми же адресами IP отправителя и получателя, которые назначены конечной точке, но другим номером порта говорит о попытке создания новой ассоциации.

Отправителю блока INIT или COOKIE ECHO следует отвечать на получение блока SHUTDOWN-ACK пакетом SCTP, содержащим только блок SHUTDOWN COMPLETE, а в поле Verification Tag общего заголовка следует включать значение тега из полученного пакета с SHUTDOWN ACK. Такой пакет рассматривается, как OOTB (см. параграф 8.4). Отправитель INIT оставляет работать свой таймер T1-init и сохраняет состояние COOKIE-WAIT или COOKIE-ECHOED. Завершение отсчёта T1-init будет приводить к повтору передачи блока INIT или COOKIE и созданию новой ассоциации.

Если получатель блока SHUTDOWN находится в состоянии COOKIE WAIT или COOKIE ECHOED, блок SHUTDOWN следует отбрасывать без уведомления.

Если конечная точка находится в состоянии SHUTDOWN-SENT и получает от своего партнёра блок SHUTDOWN, ей следует незамедлительно ответить блоком SHUTDOWN ACK и перейти в состояние SHUTDOWN-ACK-SENT с перезапуском своего таймера T2-shutdown.

Если конечная точка находится в состоянии SHUTDOWN-ACK-SENT и получает от партнёра блок SHUTDOWN ACK, она должна остановить таймер T2-shutdown, передать партнёру блок SHUTDOWN COMPLETE и удалить все связанные с ассоциацией записи.

10. Обработка ICMP

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

ICMP1)

Реализация может игнорировать все сообщения ICMPv4 с полем типа, отличным от Destination Unreachable.

ICMP2)

Реализация может игнорировать все сообщения ICMPv6 с полем типа, отличным от Destination Unreachable, Parameter Problem, Packet Too Big.

ICMP3)

Реализации следует игнорировать все сообщения ICMP с кодом Port Unreachable.

ICMP4)

Реализация может игнорировать все сообщения ICMPv6 с полем типа Parameter Problem, если код отличается от Unrecognized Next Header Type Encountered.

ICMP5)

Реализация должна использовать содержимое сообщения ICMP (v4 или v6) для нахождения ассоциации, передавшей сообщение, на которое получен отклик ICMP. Если ассоциация не найдена реализации следует игнорировать сообщение ICMP.

ICMP6)

Реализация должна проверить совпадение Verification Tag в сообщении ICMP значению Verification Tag партнёра. Если Verification Tag отличается от 0 и не совпадает, сообщение ICMP отбрасывается. Если тег имеет значени 0 и сообщение ICMP содержит достаточно байтов для проверки того, что блок имеет тип INIT, а значение Initiate Tag совпадает с тегом партнёра, выполняется ICMP7. Если сообщение ICMP слишком короткое, тип блока или Initiate Tag не совпадает, пакет просто отбрасывается.

ICMP7)

Если сообщение является ICMPv6 типа Packet Too Big или ICMPv4 типа Destination Unreachable с кодом Fragmentation Needed, реализации следует обработать эти сведения как задано для определения PMTU.

ICMP8)

Если сообщение ICMP имеет код Unrecognized Next Header Type Encountered или Protocol Unreachable, реализация должна трактовать его как прерывание с установленным битом T, когда в нем не содержится блока INIT. Если сообщение включает блок INIT и ассоциация находится в состоянии COOKIE-WAIT, сообщение ICMP обрабатывается подобно блоку ABORT.

ICMP9)

Если сообщение ICMP имеет тип Destination Unreachable, реализация может перевести получателя в число недоступных или увеличить счётчик ошибок для пути. SCTP может передавать вышележащему уровню сведения о приёме сообщений ICMP при указании смены состояния сети.

Эти процедуры отличаются от [RFC1122], требований по обработке сообщений о недоступности порта и требований, в соответствии с которыми реализация должна разрывать ассоциации в ответ на сообщение о недоступности протокола. Сообщения о недоступности порта не обрабатываются, поскольку реализации передают блок ABORT вместо port-unreachable. Более строгая обработка сообщений о недоступности протокола обусловлена соображениями безопасности хостов, не поддерживающих SCTP.

11. Интерфейс с вышележащим уровнем

Протоколы вышележащих уровней (ULP) запрашивают сервис путём передачи примитивов протоколу SCTP и получают уведомления о различных событиях от SCTP.

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

Отметим, что этот раздел предназначен лишь для информации (не нормативный).

[RFC6458] и раздел 7 (Socket API Considerations) в [RFC7053] определяют расширение API сокетов для SCTP, как описано в этом документе.

11.1. ULP -> SCTP

В последующих параграфах приведены функциональные характеристики интерфейса ULP-SCTP. Используемая нотация похожа на описания вызовов процедур или функций в большинстве языков высокого уровня.

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

11.1.1. Initialize – инициализация

INITIALIZE ([local port],[local eligible address list]) -> local SCTP instance name

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

SCTP будет возвращать ULP имя локального экземпляра SCTP.

Необязательные атрибуты

С примитивом могут передаваться следующие типы атрибутов:

  • local port – номер порта SCTP, если ULP хочет задать порт;
  • local eligible address list – список адресов, с которыми следует связать локальную точку SCTP. По умолчанию при отсутствии списка локальная точка связывается со всеми адресами IP, присвоенными данной точке.

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

11.1.2. Associate – создать ассоциацию

ASSOCIATE(local SCTP instance name, initial destination transport addr list, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]

Этот примитив позволяет инициировать создание ассоциации с указанным партнёром.

Конечная точка партнёра указывается одним или несколькими из её транспортных адресов (см. параграф 1.3). Если локальный экземпляр SCTP ещё не инициализирован, вызов ASSOCIATE считается ошибкой.

При успешном создании ассоциации возвращается идентификатор ассоциации SCTP. Если SCTP не может создать ассоциацию с удаленным партнёром, возвращается код ошибки.

При создании ассоциации могут возвращаться другие параметры ассоциации, включая полные транспортные адреса партнёра, а также число исходящих потоков локальной точки. Один из транспортных адресов удалённого партнёра выбирается локальной точкой в качестве первичного (используемого по умолчанию) транспортного адреса для передачи пакетов SCTP этому партнёру. Возвращаемый список транспортных адресов партнёра (destination transport addr list) может использоваться ULP для смены первичного пути или задания передачи по определённому транспортному адресу партнёра.

Примечание для разработчиков. Если примитив ASSOCIATE реализован как блокируемый вызов функции, он может возвращать кроме идентификатора ассоциации дополнительные параметры. Если примитив ASSOCIATE реализован как неблокируемый вызов, возвращается только идентификатор ассоциации, а параметры созданной ассоциации передаются с использованием уведомления COMMUNICATION UP.

Обязательные атрибуты

  • local SCTP instance name – возвращается операцией INITIALIZE.
  • initial destination transport addr list – непустой список транспортных адресов партнёра, с которым создаётся ассоциация.
  • outbound stream count – число исходящих потоков, которые ULP будет открывать для обмена данными с партнёром.

11.1.3. Shutdown – завершение ассоциации

SHUTDOWN(association id) -> result

Завершает работу ассоциации с доставкой партнёру всех данных из локальных очередей. Ассоциация будет разрываться лишь после того, как будут подтверждены все переданные пакеты SCTP. При успешном завершении ассоциации будет возвращаться код завершения, а при отказе – код ошибки.

Обязательный атрибут

association id – локальный идентификатор ассоциации SCTP.

11.1.4. Abort – разрыв ассоциации

ABORT(association id [, cause code]) -> result

Прерывает работу ассоциации без завершения процесса передачи данных из очередей. Все пользовательские данные из локальных очередей отбрасываются, а партнёру передаётся блок ABORT. При успешном разрыве ассоциации возвращается код разрыва, а при отказе – код ошибки.

Обязательный атрибут

association id – локальный идентификатор ассоциации SCTP.

Необязательный атрибут

Upper Layer Abort Reason – причина разрыва ассоциации, передаваемая партнёру.

11.1.5. Send – передача данных

SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unorder flag] [,no-bundle flag] [,payload protocol-id] [,sack-immediately flag]) -> result

Этот примитив обеспечивает основной метод передачи пользовательских данных по протоколу SCTP.

Обязательные атрибуты

  • association id – локальный идентификатор ассоциации SCTP;
  • buffer address – адрес, по которому сохраняется передаваемое пользовательское сообщение;
  • byte count – размер пользовательских данных в байтах.

Необязательные атрибуты

  • context – необязательное 32-битовое целое число, которое будет передаваться в уведомлении SEND FAILURE
  • stream id – идентификатор потока, используемого для передачи данных (по умолчанию используется поток 0).
  • life time – задаёт время действия пользовательских данных. По истечении заданного времени SCTP уже не будет пытаться передавать эти данные. Параметр может использоваться для предотвращения передачи устаревших пользовательских сообщений. SCTP уведомляет ULP, если данные не удаётся передать с помощью примитива SEND в течение заданного этим параметром времени. Однако пользовательские данные будут переданы, если протокол SCTP начал попытки отправки блока данных до истечения заданного времени.
  • протоколу ULP, если при передаче пользовательского сообщения произойдёт ошибка.

Примечание для разработчиков. Для более эффективной поддержки опции времени действия данных отправитель может присваивать передаваемому блоку DATA номер TSN в последний момент. Для упрощения реализации после присвоения номера TSN отправителю следует рассматривать передачу блока DATA как начавшееся событие, не принимая уже во внимание ограничение времени действия, заданное для блока DATA.

  • destination transport address – задаёт один из транспортных адресов получателя, по которому пакет должен передаваться. По возможности протокол SCTP использetn заданный адрес вместо адреса первичного пути.
  • unorder flag – этот флаг указывает что пользовательские данные доставляются партнёру без соблюдения порядка (т. е., устанавливается U = 1 во всех блоках DATA, содержащих это сообщение).
  • no-bundle flag – указывает протоколу SCTP, что эти данные не должны группироваться с другими блоками DATA. SCTP может выполнять в целях предотвращения перегрузки группировку блоков, игнорируя этот флаг.
  • payload protocol-id – 32-битовое целое число без знака, которое будет передаваться партнёру для индикации типа передаваемых данных. Отметим, что вышележащий уровень отвечает за преобразование порядка байтов этого поля из хостового в сетевой; SCTP передаёт поле как 4 необрабатываемых (opaque) байта.
  • sack-immediately flag – установить флаг I в последнем блоке DATA передаваемого пользовательского сообщения.

11.1.6. Set Primary – выбор основного пути

SETPRIMARY(association id, destination transport address, [source transport address]) -> result

Задаёт для локальной точки SCTP использование указанного транспортного адреса в качестве первичного пути передачи пакетов.

Примитив должен возвращать результат попытки задания первичного пути. Если заданного адреса нет в destination transport address list, возвращённом ранее примитивом ASSOCIATE или уведомлением COMMUNICATION UP, возвращается код ошибки.

Обязательные атрибуты

  • association id – локальный идентификатор ассоциации SCTP;
  • destination transport address – задаёт один из транспортных адресов партнёра для использования в качестве основного пути передачи пакетов. Это значение заменяет собой адрес первичного пути, поддерживавшегося до этого локальной точкой SCTP.

Необязательный атрибут

source transport address – некоторые реализации могут поддерживать задание адреса отправителя, который будет по умолчанию включаться во все исходящие дейтаграммы IP.

11.1.7. Receive – приём данных

RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,payload protocol-id]

Этот примитив считывает первое пользовательское сообщение из входной очереди SCTP в буфер, указанный ULP, если такой буфер имеется. После выполнения команды возвращается размер прочитанных данных в байтах. В зависимости от реализации может также возвращаться такая информация, как адрес отправителя, идентификатор потока, из которого получены данные, сведения о наличии дополнительных данных для прочтения и т. п. Для упорядоченных сообщений может также возвращаться порядковый номер в потоке (Stream Sequence Number).

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

Обязательные атрибуты

  • association id – локальный идентификатор ассоциации SCTP;
  • buffer address – адрес в памяти, указанный ULP для считывания сообщения;
  • buffer size – максимальный размер считываемых данных в байтах.

Необязательные атрибуты

  • stream id – для индикации потока, из которого были получены данные.
  • Stream Sequence Number – порядковый номер в потоке, присвоенный передающим партнёром SCTP.
  • partial flag – наличие этого флага говорит о том, что данный примитив возвращает лишь часть данных сообщения. Установка этого флага сопровождается возвратом идентификатора потока и порядкового номера в потоке. Нулевое значение флага показывает, что для этого порядкового номера в потоке больше нет данных.
  • payload protocol-id – 32-битовое целое число без знака, полученное от партнёра и указывающее тип данных в принятом сообщении. Отметим, что вышележащий уровень отвечает за преобразование порядка байтов этого поля из хостового в сетевой; SCTP передаёт поле как 4 необрабатываемых (opaque) байта.

11.1.8. Status – статус

STATUS(association id) -> данные о состоянии

Этот примитив возвращает блок данных, содержащий:

  • состояние соединения для ассоциации;
  • список адресов транспортного уровня для получателя;
  • состояния доступности транспортных адресов получателя;
  • текущий размер окна приёма;
  • текущий размер окна перегрузки;
  • число неподтвержденных блоков DATA;
  • число блоков DATA ожидающих приёма;
  • основной путь;
  • самое новое значение SRTT на основном пути;
  • значение RTO для основного пути;
  • значения SRTT и RTO для других путей и т. п.

Обязательный атрибут

association id – локальный идентификатор ассоциации SCTP.

11.1.9. Change Heartbeat – смена режима Heartbeat

CHANGEHEARTBEAT(association id, destination transport address, new state [,interval]) -> result

Говорит локальной точке о необходимости включить или отключить функцию heartbeat для указанного адреса получателя, возвращая результат операции.

Примечание. Даже при включённой функции heartbeat реальных проверок может не выполняться, если указанный адрес не относится к бездействующим.

Обязательные атрибуты

  • association id – локальный идентификатор ассоциации SCTP;
  • destination transport address – один из транспортных адресов партнёра;
  • new state – новое состояние heartbeat для данного транспортного адреса (enabled или disabled).

Необязательный атрибут

interval – определяет частоту передачи heartbeat, если эта функция включена для транспортного адреса партнёра. Значение параметра добавляется к RTO транспортного адреса. Параметр действует для всех транспортных адресов получателя.

11.1.10. Request Heartbeat – запрос на выполнение Heartbeat

REQUESTHEARTBEAT(association id, destination transport address) -> result

Говорит локальной точке о необходимости выполнения Heartbeat для указанного транспортного адреса в данной ассоциации. Возвращаемый результат показывает, была ли передача блока HEARTBEAT по заданному транспортному адресу успешной.

Обязательный атрибут

  • association id – локальный идентификатор ассоциации SCTP;
  • destination transport address – транспортный адрес, для которого запрашивается передача блока HEARTBEAT.

11.1.11. Get SRTT Report – запрос значения SRTT

GETSRTTREPORT(association id, destination transport address) -> srtt result

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

Обязательные атрибуты

  • association id – локальный идентификатор ассоциации SCTP;
  • destination transport address – транспортный адрес партнёра, для которого определяется значение SRTT.

11.1.12. Set Failure Threshold – задать порог детектирования отказа

SETFAILURETHRESHOLD(association id, destination transport address, failure threshold) -> result

Этот примитив позволяет локальному модулю SCTP задать значение порога детектирования отказа Path.Max.Retrans для заданного транспортного адреса. Отметим, что это можно сделать с помощью примитива SETPROTOCOLPARAMETERS (параграф 11.1.13).

Обязательные атрибуты

  • association id – локальный идентификатор ассоциации SCTP;
  • destination transport address – транспортный адрес партнёра в данной ассоциации, для которого задаётся порог;
  • failure threshold – новое значение параметра Path.Max.Retrans для транспортного адреса.

11.1.13. Set Protocol Parameters – установить параметры протокола

SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list) -> result

Этот примитив позволяет локальному модулю SCTP установить параметры протокола.

Обязательные атрибуты

  • association id – локальный идентификатор ассоциации SCTP;
  • protocol parameter list – список имён и значений протокольных параметров (например, Association.Max.Retrans, см. раздел 16 или таких параметров как DSCP), которые пользователь SCTP желает установить.

Необязательный атрибут

destination transport address – некоторые параметры протокола могут независимо устанавливаться для каждого транспортного адреса партнёра.

11.1.14. Receive unsent message – получить неотправленное сообщение

RECEIVE_UNSENT(data retrieval id, buffer address, buffer size [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])

Обязательные атрибуты

  • data retrieval id – идентификатор, переданный ULP в уведомлении SEND FAILURE.
  • buffer address – адрес буфера, указанный ULP для записи полученного сообщения.
  • buffer size – максимальный размер принимаемых данных в байтах.

Необязательные атрибуты

  • stream id – идентификатор потока, в который были переданы данные.
  • Stream Sequence Number – порядковый номер в потоке, связанный с сообщением.
  • partial flag – указывает на частичную доставку сообщения. При установке этого флага также возвращаются идентификатор потока и порядковый номер в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет получено данных.
  • payload protocol-id – 32-битовое целое число без знака, которое было задано для передачи партнёру с целью идентификации протокола полученных данных.

11.1.15. Receive Unacknowledged Message – приём неподтвержденного сообщения

RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])

Обязательные атрибуты

  • data retrieval id – идентификатор, переданный ULP в уведомлении SEND FAILURE.
  • buffer address – адрес буфера, указанный ULP для записи полученного сообщения.
  • buffer size – максимальный размер принимаемых данных в байтах.

Необязательные атрибуты

  • stream id – идентификатор потока, в который были переданы данные.
  • Stream Sequence Number – порядковый номер в потоке, связанный с сообщением.
  • partial flag – указывает на частичную доставку сообщения. При установке этого флага также возвращаются идентификатор потока и порядковый номер в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет получено данных.
  • payload protocol-id – это 32-битовое целое число без знака, которое было передано для идентификации протокола полученных данных.

11.1.16. Destroy SCTP instance – уничтожить экземпляр SCTP

DESTROY(local SCTP instance name)

Обязательный атрибут

local SCTP instance name – значение, переданное приложению из примитива инициализации; указывает уничтожаемый экземпляр SCTP.

11.2. SCTP -> ULP

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

Примечание для разработчиков. В некоторых случаях передача на верхний уровень может выполняться через отдельный сокет или канал вывода ошибок.

11.2.1. Уведомление DATA ARRIVE

SCTP передаёт такое уведомление ULP, когда пользовательское сообщение получено и готово для считывания. Уведомление может включать следующие необязательные параметры:

  • association id – локальный идентификатор ассоциации SCTP;
  • stream id – идентификатор потока, в котором были получены данные.

11.2.2. Уведомление SEND FAILURE

Если сообщение не может быть доставлено, протокол SCTP передаёт это уведомление ULP. Уведомление может включать следующие необязательные параметры:

  • association id – локальный идентификатор ассоциации SCTP;
  • data retrieval id – идентификатор, используемый для считывания неотправленных или неподтвержденных данных;
  • cause code – указывает причину отказа (например, слишком большой размер сообщения, завершение срока действия сообщения и т. п.);
  • mode – указывает, была ли какая-либо часть сообщения отправлена, но не подтверждена полностью;
  • context – дополнительная информация, связанная с сообщением (см. параграф 11.1.5).

11.2.3. Уведомление NETWORK STATUS CHANGE

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

  • association id – локальный идентификатор ассоциации SCTP;
  • destination transport address – транспортный адрес партнёра, для которого зафиксировано изменение состояния;
  • new-status – новое состояние.

11.2.4. Уведомление COMMUNICATION UP

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

Примечание для разработчиков. Если примитив ASSOCIATE реализован, как блокируемый вызов функции, параметры ассоциации возвращаются самим примитивом ASSOCIATE. В таких случаях на стороне инициатора ассоциации уведомления COMMUNICATION UP становятся необязательными.

В уведомлении содержится следующая информация:

  • association id – локальный идентификатор ассоциации SCTP;
  • status – указывает тип события, с которым связано уведомление;
  • destination transport address list – полный набор транспортных адресов партнёра;
  • outbound stream count – максимальное число исходящих потоков, которые ULP может использовать в данной ассоциации;
  • inbound stream count – число потоков, запрошенных партнёром (может отличаться от outbound stream count).

11.2.5. Уведомление COMMUNICATION LOST

Это уведомление передаётся протоколом SCTP в случае полной утраты связи с удалённой точкой (например, через Heartbeat) или обнаружения вызова удалённой точкой операции прерывания ассоциации (abort). В уведомлении содержится следующая информация:

  • association id – локальный идентификатор ассоциации SCTP;
  • status – указывает тип события, с которым связано уведомление; этот параметр может говорить об отказе или обычном прекращении работы ассоциации с помощью запроса shutdown или abort.

Уведомление может включать следующие необязательные параметры:

  • last-acked – последний номер TSN, подтверждённый партнёром;
  • last-sent – последний номер TSN, переданный партнёру;
  • Upper Layer Abort Reason – причина прерывания указывается в случае разрыва по инициативе пользователя.

11.2.6. Уведомление COMMUNICATION ERROR

Когда SCTP получает блок ERROR от партнёра и решает уведомить об ошибке ULP, этот тип служит для передачи уведомления. Уведомление может включать следующие параметры:

  • association id – локальный идентификатор ассоциации SCTP;
  • error info – указывает тип ошибки и может содержать дополнительную информацию из блока ERROR.

11.2.7. Уведомление RESTART

При обнаружении рестарта на стороне партнёра SCTP может использовать этот тип для передачи уведомления ULP. Уведомление может включать параметр association id – локальный идентификатор ассоциации SCTP.

11.2.8. Уведомление SHUTDOWN COMPLETE

Это уведомление SCTP передаёт на вышележащий уровень при завершении процедуры SHUTDOWN (параграф 9.2). Уведомление может включать параметр association id – локальный идентификатор ассоциации SCTP.

12. Вопросы безопасности

12.1. Цели защиты

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

  • доступность сервиса с гарантией своевременной доставки;
  • целостность пользовательской информации, передаваемой через SCTP.

12.2. Реакция SCTP на потенциальные угрозы

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

Операторам систем, применяющих SCTP, следует использовать [RFC2196] в качестве руководства по обеспечению безопасности своего сайта.

12.2.1. Учёт возможности атак изнутри

Следует использовать принципы, изложенные в [RFC2196] для минимизации риска утечки информации или саботажа со стороны сотрудников. Такие процедуры включают публикацию политики безопасности, контроль доступа к оборудованию, программам и сети, а также разделение служб.

12.2.2. Защита от повреждения данных в сети

Если риск возникновения незаметных ошибок в дейтаграммах, доставляемых с помощью транспорта нижележащих уровней, слишком велик, нужны дополнительные меры по обеспечению целостности данных. Если дополнительная защита обеспечивается на прикладном уровне, заголовок SCTP остаётся уязвимым для преднамеренных атак с целью повреждения данных. Хотя существующих механизмов обнаружения подмены пакетов в SCTP вполне достаточно для работы в нормальных условиях, требуется более сильная защита SCTP в тех случаях, когда рабочая среда характеризуется высоким уровнем риска преднамеренных атак со стороны изощрённых противников.

Можно использовать расширение SCTP-AUTH [RFC4895], если среда с угрозами требует сильной защиты целостности, не требуя защиты конфиденциальности.

12.2.3. Защита конфиденциальности

В большинстве случаев вопросы конфиденциальности относятся к данным, передающим сигнальную информацию, а не к заголовкам SCTP или протоколов нижележащих уровней. В этом случае можно ограничиться шифрованием пользовательских данных SCTP. Как и дополнительные контрольные суммы, шифрование данных может выполняться пользовательским приложением SCTP. Для этого можно воспользоваться [RFC6083]. Как вариант, пользовательское приложение может применять специфические для реализации API для запроса сервиса IP ESP [RFC4303], обеспечивающего конфиденциальность и целостность.

Практические требования конфиденциальности для мобильных пользователей могут включать маскирование адресов IP и номеров портов. В таких случаях следует использовать ESP вместо обеспечения конфиденциальности на уровне приложений. При использовании ESP для обеспечения конфиденциальности трафика SCTP должно применяться криптографическое преобразование ESP, которое включает криптографическую защиту целостности, поскольку в таких случаях кроме угрозы конфиденциальности данных имеется достаточно серьёзная угроза их целостности.

Независимо от способа защиты конфиденциальности следует использовать механизмы IKEv2 [RFC7296] для управления ключами ESP.

Операторы могут обратиться к [RFC4301] для получения дополнительной информации по средствам обеспечения безопасности непосредственно поверх уровня IP.

12.2.4. Защита от атак на службы вслепую (Blind DoS)

Атака вслепую представляет собой случай, когда атакующий не может перехватывать и просматривать содержимое потока данных, передаваемых узлу SCTP или от него. Атаки вслепую на службы могут иметь форму лавинной рассылки (flooding), маскирования (masquerade) или недозволенного монопольного захвата сервиса.

12.2.4.1. Лавинная атака (Flooding)

Целью лавинной атаки является выведение сервиса из строя и некорректное поведение системы из-за истощения ресурсов, интерференции с легитимными транзакциями или использования связанных с буферами программных ошибок. Лавинная атака может быть направлена на узел SCTP, каналы доступа или Internet. В последних случаях лавинная атака будет проявляться как прекращение работы сетевых служб при наличии межсетевых экранов.

В общем случае защита от лавинной атаки начинается при разработке оборудования и включает такие меры, как:

  • предотвращение выделения ограниченных ресурсов до проверки легитимности сервисного запроса;
  • предоставление более высокого приоритета уже выполняющимся процессам по сравнению с новыми;
  • идентификация и удаление дубликатов и просроченных запросов из очередей;
  • игнорирование неожиданных пакетов, переданных по адресам, не являющимся индивидуальными (non-unicast).

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

Протокол SCTP устойчив к лавинным атакам, в частности, благодаря использованию четырёхэтапного согласования при старте ассоциации, механизма cookie для блокирования ресурсов отвечающего узла до тех пор, пока не будет завершено согласование, и тегов верификации (Verification Tag) для защиты от вставки дополнительных пакетов в поток данных действующей ассоциации.

Механизм ESP может также оказаться полезным для снижения риска при некоторых типах атак на службы.

Поддержка параметра Host Name исключена из протокола. Конечная точка, получившая блок INIT или INIT ACK с параметром Host Name, должна передать в ответ блок ABORT и может включить в него код причины Unresolvable Address.

12.2.4.2. Слепое маскирование

Маскирование (Masquerade) может использоваться для атак на службы несколькими способами.

  • Путём связывания ресурсов целевого узла SCTP, к которому ролевой (impersonated) узел имеет ограниченный доступ. Например, политика целевого узла может разрешать не более одной ассоциации SCTP с ролевым узлом SCTP. Замаскированный атакующий может попытаться организовать ассоциацию и прикинуться ролевым узлом, чтобы впоследствии настоящий ролевой узел не мог подключиться к сервису.
  • Посредством преднамеренного раскрытия подмены для провоцирования блокировки ролевого узла целевым узлом SCTP.
  • Путём взаимодействия с действующей ассоциацией посредством вставки в поток добавочного содержимого (например, блока SHUTDOWN).

SCTP снижает риск слепого маскирования с подменой адресов (IP spoofing) за счёт использования четырёхэтапного согласования при старте ассоциации. Поскольку начальный обмен не занимает памяти, атаки с маскированием вслепую не вызывают никакой блокировки. Кроме того, подтверждение INIT ACK, содержащее State Cookie, передаётся по адресу IP, с которого был получен блок INIT. Таким образом атакующий не получит блок INIT ACK, содержащий State Cookie. SCTP обеспечивает защиту от вставки дополнительных пакетов в поток данных ассоциации за счёт использования тегов верификации (Verification Tag).

Запись (log) полученных запросов INIT и аномалий вроде неожиданных блоков INIT ACK может быть полезна в целях обнаружения враждебных действий. Однако пользу от такого протоколирования нужно сопоставить с усложнением обработки при старте ассоциации SCTP, которое к тому же делает узел SCTP более уязвимым к лавинным атакам. Запись не имеет смысла без создания рабочих процедур повседневного просмотра и анализа журнальных файлов.

12.2.4.3. Неправомерная монополизация

Атаки этого типа выполняются злоумышленником открыто с использованием легитимного доступа. Они направлены против других пользователей узла SCTP или ресурсов, разделяемых между атакующим и целевым узлом. Возможные атаки включают создание большого числа ассоциаций между атакующим узлом и объектом атаки или перенос больших объёмов данных в рамках легитимных ассоциаций.

Следует вводить административные ограничения на число ассоциаций, создаваемых узлами. Пользовательским приложениям SCTP следует обеспечивать возможность обнаружения передачи больших объёмов информации или сообщений no-op в данной ассоциации, а также другие механизмы фиксации и разрыва ассоциаций в соответствии с принятой локальной политикой.

12.3. Взаимодействие SCTP с межсетевыми экранами

Для некоторых межсетевых экранов будет полезна возможность проверки первого фрагмента фрагментированного пакета SCTP и однозначного определения его соответствия блоку INIT (см. дополнительную информацию в [RFC1858]). Поэтому ещё раз подчёркиваются требования, приведённые в параграфе 3.1, – (1) блок INIT недопустимо группировать с каким-либо другим блоком в одном пакете, (2) пакет с блоком INIT должен иметь Verification Tag = 0. Получатель INIT должен отбрасывать этот блок и все последующие блоки, если INIT сгруппирован с другими блоками или имеет отличный от нуля тег верификации.

12.4. Защита хостов, не поддерживающих SCTP

Для обеспечения не поддерживающим SCTP хостам такого же уровня защиты от атак, как для хостов SCTP, все реализации протокола SCTP должны поддерживать обработку ICMP, описанную в разделе 10.

Когда стек SCTP получает пакет, содержащий несколько блоков управления или DATA, и обработка такого пакета ведёт к передаче в ответ нескольких блоков, отправителю этих блоков недопустимо передавать более одного пакета с блоками, отличными от DATA. Это защищает сеть от передачи «пика» пакетов в ответ на единственный пакет. Если поддерживается группировка, несколько блоков отклика можно собрать в один пакет отклика. Если группировка блоков не поддерживается, отправителю недопустимо передавать более одного блока-отклика, а остальные он должен отбросить. Отметим, что это правило не применимо к блокам SACK, поскольку они сами по себе являются откликами на блоки DATA, и SACK не требует передачи в ответ блоков DATA.

Реализация SCTP должна прерывать ассоциацию при получении блока SACK с подтверждением номера TSN, который не был передан.

Реализация SCTP, получающая блок INIT, для отклика на который требуется большой пакет по причине включения в него множества параметров Unrecognized Parameter, может (по своему усмотрению) опустить часть или все такие параметры для снижения размера INIT ACK. С учётом размера параметра State Cookie и множества адресов, которые получатель INIT может указывать своему партнёру, размер блока INIT ACK может превышать размер исходного блока INIT. Реализациям SCTP следует пытаться максимально сократить размер блоков INIT ACK для снижения возможности организации «атак с усилением» (byte amplification attack).

13. Вопросы управления сетью

Модуль MIB для протокола SCTP, определённый в [RFC3873], применим для описанной здесь версии протокола.

14. Рекомендуемые параметры TCB

В этом разделе описываются рекомендуемые параметры, которые предполагаются в TCB. Раздел имеет иллюстративное значение и его содержимое не следует трактовать, как требования к реализациям или исчерпывающий список параметров, включаемых в SCTP TCB. Конкретной реализации для обеспечения оптимальной работы может потребоваться свой набор параметров.

14.1. Параметры, требуемые для экземпляра SCTP

Associations

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

Secret Key

Секретный ключ используется данной конечной точкой для расчёта MAC. В качестве ключа следует использовать случайное число криптографического качества и достаточной длины. Для выбора ключей могут быть полезны рекомендации [RFC4086].

Address List

Список адресов IP, с которыми связан данный экземпляр. Эти сведения передаются партнёру в блоках INIT и INIT ACK.

SCTP Port

Локальный номер порта, с которым связана конечная точка SCTP.

14.2. Параметры, требуемые для ассоциации в целом (например, TCB)

Peer Verification Tag

Значение тега партнёра, передаваемое в каждом пакете и полученное из блока INIT или INIT ACK.

My Verification Tag

Значение тега, ожидаемое в каждом входящем пакете и передаваемое партнёру в блоке INIT или INIT ACK.

State

COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, SHUTDOWN-ACK-SENT.

Примечание. Состояние CLOSED не указано, поскольку для ассоциации в этом состоянии TCB следует удалять.

Peer Transport Address List

Список транспортных адресов SCTP, с которыми связан партнёр. Эта информация извлекается из блоков INIT или INIT ACK и используется для связывания входящих пакетов с данной ассоциацией. Обычно эта информация хэшируется или индексируется (keyed) для быстрого поиска и доступа к TCB.

Primary Path

Текущее значение основного транспортного адреса партнёра. Это значение может также указывать адрес источника пакетов от этой точки.

Overall Error Count

Общий счётчик ошибок для всей ассоциации.

Overall Error Threshold

Значение числа ошибок для ассоциации, при достижении которого данная ассоциация будет разорвана.

Peer Rwnd

Текущее значение окна приёма (rwnd), рассчитанное для партнёра.

Next TSN

Значение следующего номера TSN, которое будет присвоено новому блоку DATA. Начальный номер передаётся партнёру в блоке INIT или INIT ACK и далее номер увеличивается каждый раз, когда блоку DATA выделяется значение TSN (обычно непосредственно перед передачей или в процессе фрагментации).

Last Rcvd TSN

Последний номер TSN, полученный с сохранением порядка. Начальное значение устанавливается на основе параметра Initial TSN в блоке INIT или INIT ACK, путём вычитания 1 из полученного значения.

Mapping Array

Массив битов или байтов, показывающий, какие переупорядоченных номеров TSN были получены (относительно Last Rcvd TSN). При отсутствии пропусков (т. е., все пакеты получены с сохранением порядка доставки), этот массив может содержать только нули. Эта структура может быть кольцевым буферои или битовым массивом.

Ack State

Этот флаг показывает, будет ли передано подтверждение SACK при получении следующего пакета. Начальное значение равно 0. При получении пакета значение инкрементируется. При достижении значения 2 или более в ответ на получение пакета передаётся SACK и значение сбрасывается в 0. Отметим, что описанный механизм используется лишь при отсутствии нарушений в порядке доставки блоков DATA. Если имеется нарушение порядка доставки DATA, подтверждения SACK не задерживаются (см. раздел 6).

Inbound Streams

Массив структур для отслеживания входящих потоков. Обычно данные о потоках включают следующий (ожидаемый) порядковый номер и могут включать номер потока.

Outbound Streams

Массив структур для отслеживания исходящих потоков. Обычно данные о потоках включают следующий порядковый номер для передачи в поток.

Reasm Queue

Очередь сборки.

Local Transport Address List

Список локальных адресов IP, связанных с данной ассоциацией.

Association Maximum DATA Chunk Size

Наименьшее значение Path Maximum DATA Chunk Size среди всех адресов партнёра.

14.3. Данные для транспортного адреса

Для каждого транспортного адреса партнёра из списка, полученного в блоке INIT или INIT ACK, поддерживается группа параметров, включающая перечисленные ниже.

Error count

Текущее значение счётчика ошибок для данного получателя.

Error Threshold

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

cwnd

Текущий размер окна перегрузки.

ssthresh

Текущее значение порога Slow Start (ssthresh).

RTO

Текущее значение тайм-аута повтора передачи.

SRTT

Текущее значение сглаженного времени кругового обхода.

RTTVAR

Вариации текущего значения RTT.

partial bytes acked

Метод слежения, используемый для увеличения размера cwnd в режиме предотвращения перегрузки (congestion avoidance, см. параграф 7.2.2).

state

Текущее состояние адресата (DOWN, UP, ALLOW-HB, NO-HEARTBEAT и т. п.).

PMTU

Текущее известное значение PMTU.

PMDCS

Текущее известное значение PMDCS.

Per Destination Timer

Таймер, используемый для каждого получателя.

RTO-Pending

Флаг, указывающий на то, что один из блоков DATA, переданных по этому адресу, в данный момент используется для расчёта RTT. Если флаг сброшен (0), ближайший блок DATA, отправляемый по этому адресу, следует использовать для расчёта RTT и установить данный флаг. При завершении расчёта RTT (получение подтверждения SACK для блока DATA) флаг сбрасывается.

last-time

Время передачи адресату последнего пакета. Это значение может использоваться для определения необходимости передачи HEARTBEAT.

14.4. Требуемые параметры общего назначения

Out Queue

Очередь исходящих блоков DATA.

In Queue

Очередь входящих блоков DATA.

15. Взаимодействие с IANA

SCTP определяет пять реестров, поддерживаемых агентством IANA:

  • типы блоков;
  • флаги блоков;
  • типы параметров;
  • коды причины ошибки в блоках ERROR;
  • идентификаторы протоколов данных.

Агентство IANA внесло в упомянутые реестры перечисленные ниже изменения.

  • В реестре Chunk Types ссылки на [RFC4960] и [RFC6096] заменены ссылками на этот документ. В разделе Notes ссылка на параграф 3.2 в [RFC6096] заменена ссылкой на параграф 15.2 этого документа. Кроме того, ссылки на [RFC4960] были заменены ссылками на данный документ для типов:
    • Payload Data (DATA);
    • Initiation (INIT);
    • Initiation Acknowledgement (INIT ACK);
    • Selective Acknowledgement (SACK);
    • Heartbeat Request (HEARTBEAT);
    • Heartbeat Acknowledgement (HEARTBEAT ACK);
    • Abort (ABORT);
    • Shutdown (SHUTDOWN);
    • Shutdown Acknowledgement (SHUTDOWN ACK);
    • Operation Error (ERROR);
    • State Cookie (COOKIE ECHO);
    • Cookie Acknowledgement (COOKIE ACK);
    • Reserved for Explicit Congestion Notification Echo (ECNE);
    • Reserved for Congestion Window Reduced (CWR);
    • Shutdown Complete (SHUTDOWN COMPLETE);
    • Reserved for IETF-defined Chunk Extensions.
  • В реестре Chunk Parameter Types ссылки на [RFC4960] заменены ссылками на этот документ. Агентство IANA сменило имя Unrecognized Parameters для типа параметров блока на Unrecognized Parameter в реестре Chunk Parameter Types. Кроме того, ссылки на [RFC4960] были заменены ссылками на данный документ для типов:
    • Heartbeat Info;
    • IPv4 Address;
    • IPv6 Address;
    • State Cookie;
    • Unrecognized Parameter;
    • Cookie Preservative;
    • Host Name Address;
    • Supported Address Types

    Агентство IANA добавило ссылку на данный документ для типа параметров блока:

    • Reserved for ECN Capable (0x8000).

    Кроме того, агентство IANA добавило значение 65535 к зарезервированным для заданных IETF расширений.

  • В реестре Chunk Flags ссылки на [RFC6096] заменены ссылками на данный документ. Кроме того, ссылки на [RFC4960] были заменены ссылками на данный документ для следующих флагов блока DATA:
    • E;
    • B;
    • U.

    Агентство IANA заменило ссылку на [RFC7053] ссылкой на этот документ для флага блока DATA:

    • I.

    Агентство IANA заменило ссылку на [RFC4960] ссылкой на этот документ для флага блока ABORT:

    • T.

    Агентство IANA заменило ссылку на [RFC4960] ссылкой на этот документ для флага блока SHUTDOWN COMPLETE:

    • T.
  • В реестре Error Cause Codes ссылки на [RFC4960] заменены ссылками на этот документ. Имя причины ошибки User Initiated Abort заменено на User-Initiated Abort. А Stale Cookie Error – на Stale Cookie. Кроме того, ссылки на [RFC4960] были заменены ссылками на данный документ для следующих кодов причин:
    • Invalid Stream Identifier;
    • Missing Mandatory Parameter;
    • Stale Cookie;
    • Out of Resource;
    • Unresolvable Address;
    • Unrecognized Chunk Type;
    • Invalid Mandatory Parameter;
    • Unrecognized Parameters;
    • No User Data;
    • Cookie Received While Shutting Down;
    • Restart of an Association with New Addresses.

    Агентство IANA заменило ссылку на [RFC4460] ссылкой на этот документ для следующих кодов причин:

    • User-Initiated Abort;
    • Protocol Violation.
  • В реестре SCTP Payload Protocol Identifiers ссылки на [RFC4960] заменены ссылками на этот документ. Агентство IANA заменило ссылку на [RFC4460] ссылкой на этот документ для следующих идентификаторов протоколов в данных SCTP:
    • Reserved by SCTP

Протокол SCTP требует, чтобы реестр IANA Port Numbers был открыт для регистрации портов SCTP, как описано в параграфе 15.6. Назначенный IESG эксперт поддерживает IANA при оценке запросов на выделение порта SCTP.

В реестре Service Name and Transport Protocol Port Number Registry ссылки на [RFC4960] заменены ссылками на этот документ для портов SCTP:

  • 9 (discard);
  • 20 (ftp-data);
  • 21 (ftp);
  • 22 (ssh);
  • 80 (http);
  • 179 (bgp);
  • 443 (https).

В реестре Hypertext Transfer Protocol (HTTP) Digest Algorithm Values ссылка на приложение B к [RFC4960] заменена ссылкой на приложение A к данному документу.

В реестре ONC RPC Netids (Standards Action) каждая ссылка на [RFC4960] заменена ссылкой на данный документ для:

  • sctp;
  • sctp6.

В реестре IPFIX Information Elements каждая ссылка на [RFC4960] заменена ссылкой на данный документ для:

  • sourceTransportPort;
  • destinationTransportPort;
  • collectorTransportPort;
  • exporterTransportPort;
  • postNAPTSourceTransportPort;
  • postNAPTDestinationTransportPort.

15.1. Расширения для блоков, определяемые IETF

Выделение новых кодов для блоков SCTP выполняется по процедуре IETF Review, определённой в [RFC8126]. Документация для нового блока должна включать:

  1. полное и сокращённое имя нового типа блоков;
  2. подробное описание структуры блока, которое должно соответствовать базовой структуре, определённой в параграфе 3.2;
  3. определение и подробное описание каждого поля блока, включая флаги, если они используются; определённые флаги блока будут служить начальными значениями таблицы флагов для нового типа блока;
  4. подробное описание процедур использования нового типа блоков в работе протокола.

Последний номер типа (255) зарезервирован для будущих расширений.

Для каждого нового типа блоков IANA создаёт таблицу регистрации флагов нового блока. Процедура регистрации флагов конкретного блока описана в параграфе 15.2.

15.2. Регистрация определённых IETF флагов блока

Выделение новых флагов блоков выполняется по процедуре RFC Required [RFC8126]. Документация для флагов блока должна включать:

  1. имя нового флага блока;
  2. подробное процедурное описание использования нового в работе протокола; должно учитываться, что не поддерживающие флаг реализации будут устанавливать значение 0 при отправке и игнорировать флаг при получении.

IANA выбирает значение для нового флага. Это должно быть одно из значений 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, которое должно быть уникальным среди значений флагов для конкретного типа блока.

15.3. Определяемые IETF расширения для типа параметров блоков

Выделение новых кодов для типа параметров блоков SCTP (chunk parameter type code) выполняется по процедуре IETF Review, определённой в [RFC8126]. Документация для параметров блока должна включать:

  1. имя типа параметра;
  2. подробное описание структуры поля параметра, которая должна соответствовать базовому форматы TLV, определённому в параграфе 3.2.1;
  3. подробное описание каждого элемента значения параметра;
  4. подробное описание предполагаемого использования этого типа параметра и возможности присутствия в одном блоке множества экземпляров данного параметра;
  5. каждый тип параметров должен быть уникальным для всех блоков.

15.4. Определяемые IETF дополнительные коды причин ошибок

Дополнительные значения кодов ошибок выделяются по процедуре Specification Required, определённой в [RFC8126]. Представляемая документация должна включать:

  1. имя ошибки;
  2. подробное описание условий, при которых конечной точке SCTP следует генерировать блок ERROR (или ABORT) с этим кодом ошибки;
  3. ожидаемые действия конечной точки SCTP при получении блока ERROR (или ABORT) с этим кодом ошибки;
  4. подробное описание структуры и содержимого полей данных, сопровождающих этот код.

Первое слово кода причина (32 бита) должно соответствовать формату, определённому в параграфе 3.3.10:

  • первые 2 байта содержат значение кода причины ошибки;
  • последние два байта указывают размер причины ошибки.

15.5. Идентификаторы протоколов (Payload)

Идентификаторы протокола выделяются по процедуре First Come First Served [RFC8126].

За исключением значения 0, зарезервированного в SCTP для индикации неуказанного протокола в блоке DATA, реализация SCTP не отвечает за стандартизацию или проверку идентификаторов протоколов. SCTP просто получает идентификатор от вышележащего уровня и передаёт его с соответствующими элементами данных.

Вышележащему уровню (пользователю SCTP) следует стандартизовать SHOULD идентификаторы конкретных протоколов через IANA, если такая стандартизация желательна. Использование каких-либо конкретных идентификаторов протоколов в элементах данных выходит за рамки спецификации.

15.6. Реестр номеров портов

Службы SCTP могут использовать контактные номера портов для предоставления услуг незнакомым абонентам, как это делается в TCP и UDP. Назначенные IESG эксперты поддерживают запрос в IANA на выделение портов SCTP в соответствии с процедурами, описанными в [RFC8126]. Детали процесса описаны в [RFC6335].

16. Предлагаемые параметры протокола SCTP

Рекомендуется использовать следующие значения параметров протокола:

RTO.Initial – 1 секунда

RTO.Min – 1 секунда

RTO.Max – 60 секунд

Max.Burst – 4

RTO.Alpha – 1/8

RTO.Beta – 1/4

Valid.Cookie.Life – 60 секунд

Association.Max.Retrans – 10 попыток

Path.Max.Retrans – 5 попыток (для каждого адреса получателя)

Max.Init.Retransmits – 8 попыток

HB.interval – 30 секунд

HB.Max.Burst – 1

SACK.Delay – 200 миллисекунд

Примечание для разработчиков. Реализация SCTP может разрешать ULP изменение некоторых параметров протокола (см. раздел 11).

Для RTO.Min следует использовать приведённое выше значение.

17. Литература

17.1. Нормативные документы

[ITU.V42.1994] International Telecommunications Union, “Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion”, ITU-T Recommendation V.42, 1994.

[RFC1122] Braden, R., Ed., “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.

[RFC1123] Braden, R., Ed., “Requirements for Internet Hosts – Application and Support”, STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC1982] Elz, R. and R. Bush, “Serial Number Arithmetic”, RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4303] Kent, S., “IP Encapsulating Security Payload (ESP)”, RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, “Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)”, RFC 4895, DOI 10.17487/RFC4895, August 2007, <https://www.rfc-editor.org/info/rfc4895>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, “TCP Congestion Control”, RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, “Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry”, BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, “Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)”, RFC 6083, DOI 10.17487/RFC6083, January 2011, <https://www.rfc-editor.org/info/rfc6083>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, “Internet Key Exchange Protocol Version 2 (IKEv2)”, STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., “Path MTU Discovery for IP version 6”, STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, “Packetization Layer Path MTU Discovery for Datagram Transports”, RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.

17.2. Дополнительная литература

[FALL96] Fall, K. and S. Floyd, “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP”, SIGCOM 99, V. 26, N. 3, pp 5-21, July 1996.

[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, “TCP Congestion Control with a Misbehaving Receiver”, ACM Computer Communications Review 29(5), October 1999.

[ALLMAN99] Allman, M. and V. Paxson, “On Estimating End-to-End Network Path Properties”, SIGCOM 99, October 1999.

[WILLIAMS93] Williams, R., “A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS”, SIGCOM 99, August 1993, <https://archive.org/stream/PainlessCRC/crc_v3.txt>.

[RFC0768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0793] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

[RFC1858] Ziemba, G., Reed, D., and P. Traina, “Security Considerations for IP Fragment Filtering”, RFC 1858, DOI 10.17487/RFC1858, October 1995, <https://www.rfc-editor.org/info/rfc1858>.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication”, RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2196] Fraser, B., “Site Security Handbook”, FYI 8, RFC 2196, DOI 10.17487/RFC2196, September 1997, <https://www.rfc-editor.org/info/rfc2196>.

[RFC2522] Karn, P. and W. Simpson, “Photuris: Session-Key Management Protocol”, RFC 2522, DOI 10.17487/RFC2522, March 1999, <https://www.rfc-editor.org/info/rfc2522>.

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “Stream Control Transmission Protocol”, RFC 2960, DOI 10.17487/RFC2960, October 2000, <https://www.rfc-editor.org/info/rfc2960>.

[RFC3465] Allman, M., “TCP Congestion Control with Appropriate Byte Counting (ABC)”, RFC 3465, DOI 10.17487/RFC3465, February 2003, <https://www.rfc-editor.org/info/rfc3465>.

[RFC3873] Pastor, J. and M. Belinchon, “Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)”, RFC 3873, DOI 10.17487/RFC3873, September 2004, <https://www.rfc-editor.org/info/rfc3873>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4301] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.

[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, “Stream Control Transmission Protocol (SCTP) Specification Errata and Issues”, RFC 4460, DOI 10.17487/RFC4460, April 2006, <https://www.rfc-editor.org/info/rfc4460>.

[RFC4960] Stewart, R., Ed., “Stream Control Transmission Protocol”, RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.

[RFC6096] Tuexen, M. and R. Stewart, “Stream Control Transmission Protocol (SCTP) Chunk Flags Registration”, RFC 6096, DOI 10.17487/RFC6096, January 2011, <https://www.rfc-editor.org/info/rfc6096>.

[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, “Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)”, RFC 6458, DOI 10.17487/RFC6458, December 2011, <https://www.rfc-editor.org/info/rfc6458>.

[RFC6951] Tuexen, M. and R. Stewart, “UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication”, RFC 6951, DOI 10.17487/RFC6951, May 2013, <https://www.rfc-editor.org/info/rfc6951>.

[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, “SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol”, RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.

[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, “Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol”, RFC 8260, DOI 10.17487/RFC8260, November 2017, <https://www.rfc-editor.org/info/rfc8260>.

[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, “Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets”, RFC 8261, DOI 10.17487/RFC8261, November 2017, <https://www.rfc-editor.org/info/rfc8261>.

[RFC8540] Stewart, R., Tuexen, M., and M. Proshin, “Stream Control Transmission Protocol: Errata and Issues in RFC 4960”, RFC 8540, DOI 10.17487/RFC8540, February 2019, <https://www.rfc-editor.org/info/rfc8540>.

Приложение A. Расчет контрольной суммы CRC32c

Мы определяем «отраженное значение», как значение с порядком битов, обратным по отношению к используемому в машине. 32-битовое значение CRC рассчитывается, как описано для CRC32c и использует полиномиальный код 0x11EDC6F41 (Castagnoli93) или x32+x28+x27+x26+x25+x23+x22+x20+x19+x18+x14+x13+x11+x10+x9+x8+x6+x0. Значение CRC рассчитывается с помощью процедуры, похожей на ETHERNET CRC [ITU32], которая изменена с учетом применения на транспортном уровне.

Расчёт CRC использует полиномиальное деление. Битовая строка сообщения (M) преобразуется в полином M(X) и значение CRC рассчитывается по M(X) с использованием полиномиальной арифметики.

При использовании CRC на канальном уровне полином строится с использованием естественного порядка битов – первый бит сигнала в линии является коэффициентов старшего порядка. Поскольку SCTP является протоколом транспортного уровня, он не может знать порядка передачи битов в физическую среду. Более того, на разных участках пути между конечными точками SCTP может на канальном уровне применяться разный порядок битов.

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

Значение CRC для транспортного уровня SCTP следует рассчитывать в соответствии с приведённым ниже описанием.

  • Входными данными CRC является поток байтов с номерами 0 – N-1.
  • Байтовый поток транспортного уровня отображается на полиномиальное значение. PDU размером N байтов с номерами j от 0 до N-1 рассматривается, как коэффициенты полинома M(x) порядка 8N-1 и бит 0 байта j будет коэффициентом x(8(N-j)-8), а бит 7 этого байта – x(8(N-j)-1).
  • Оставшаяся часть регистра CRC заполняется единицами и рассчитывается значение CRC с помощью умножения на x32 и деления на полином CRC.
  • Полином умножается на x32 и делится на G(x), что порождает полином степени не более 31, образующий оставшуюся часть R(x).
  • Коэффициенты R(x) рассматриваются, как 32-битовая последовательность.
  • Последовательность битов дополняется и результат является полиномом CRC.
  • Полином CRC отображается обратно на байты транспортного уровня SCTP. Коэффициент x31 даёт значение биты 7 в байте SCTP 0, а коэффициент x24 даёт значение бита 0 в байте 0. Коэффициент x7 даёт значение бита 7 в байте 3, а коэффициент x0 – значение бита 0 в байте 3. Результирующая 4-байтовая последовательность является последовательностью транспортного уровня для 32-битовой контрольной суммы SCTP.

Примечание для разработчиков. В стандартах, книгах и литературе от производителей для CRC зачастую приводятся иные формулировки, где используется регистр для хранения остатка алгоритма деления long-division, инициализируемый нулями, а не 1 и первые 32 бита сообщения дополняются. Алгоритм long-division, используемый в нашей формулировке совмещает начальное умножение на 232 и «длинное деление» в одной операции. Для таких алгоритмов и сообщений, размер которых превышает 64 бита, две спецификации полностью эквивалентны. Обеспечение эквивалентности является одной из целей данного документа.

Следует предупредить разработчиков SCTP о том, что в литературе можно найти обе спецификации и иногда без ограничений для алгоритма long-division. Выбор формулировки в этом документе обусловлен возможностью применения не только для SCTP, когда тот же алгоритм CRC может применяться для сообщений меньше 64 битов.

Можно несколько снизить вычислительные издержки, проверяя ассоциацию по значению Verification Tag до расчета контрольной суммы, чтобы не рассчитывать контрольные суммы для пакетов с некорректными тегами. Исключением из этого правила являются блоки INIT и некоторые обмены SHUTDOWN-COMPLETE, а также устаревшие блоки COOKIE ECHO. Однако в этих случаях пакеты достаточно малы и расчет контрольных сумм не требует значительных ресурсов.

Ниже приведён (ненормативный) пример кода, заимствованный из генератора CRC с открытым кодом [WILLIAMS93], использующего метод «отражения» и таблицу для SCTP CRC32c с 256 записями по 32 бита в каждой. Этот метод не слишком быстрый и не слишком медленный по сравнению с поиском в таблицах CRC, но его преиуществом является возможность работы с процессами, использующими порядок big-endian и little-endian, при просмотре общих таблиц (с хост-порядком), а также использование лишь предопределенных операций ntohl() и htonl(). Код несколько отличается от [WILLIAMS93] для обеспечения переносимости между архитектурами big-endian и little-endian (отметим, что в тех случаях, когда известно, что целевая архитектура использует порядок little-endian, финальные операции bit-reversal и byte-reversal могут быть объединены).

<CODE BEGINS>
   /*************************************************************/
   /* Для генератора таблиц Ross Williams устанавливаются       */
   /* значения TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE   */
   /* Для прямого расчета Mr. Williams используются значения    */
   /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF,      */
   /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000        */
   /*************************************************************/

   /* Пример файла с таблицей crc */
   #ifndef __crc32cr_table_h__
   #define __crc32cr_table_h__

   #define CRC32C_POLY 0x1EDC6F41
   #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])

   unsigned long  crc_c[256] =
   {
   0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L,
   0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL,
   0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL,
   0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L,
   0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL,
   0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L,
   0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L,
   0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL,
   0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL,
   0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L,
   0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L,
   0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL,
   0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
   0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL,
   0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL,
   0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L,
   0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L,
   0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L,
   0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L,
   0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L,
   0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L,
   0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L,
   0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L,
   0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L,
   0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L,
   0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L,
   0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L,
   0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L,
   0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L,
   0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L,
   0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L,
   0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L,
   0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL,
   0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L,
   0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L,
   0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL,
   0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L,
   0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL,
   0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL,
   0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L,
   0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L,
   0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL,
   0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL,
   0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L,
   0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL,
   0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L,
   0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L,
   0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL,
   0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L,
   0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL,
   0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL,
   0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L,
   0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL,
   0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L,
   0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L,
   0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL,
   0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL,
   0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L,
   0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L,
   0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL,
   0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
   0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL,
   0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL,
   0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L,
   };

   #endif

    /* Пример программы построения таблицы */
   #include <stdio.h>
   #include <stdlib.h>

   #define OUTPUT_FILE   "crc32cr.h"
   #define CRC32C_POLY    0x1EDC6F41L
   FILE *tf;
   unsigned long
   reflect_32 (unsigned long b)
   {
     int i;
     unsigned long rw = 0L;

     for (i = 0; i < 32; i++){
         if (b & 1)
           rw |= 1 << (31 - i);
         b >>= 1;
     }
     return (rw);
   }

   unsigned long
   build_crc_table (int index)
   {
     int i;
     unsigned long rb;

     rb = reflect_32 (index);

     for (i = 0; i < 8; i++){
         if (rb & 0x80000000L)
          rb = (rb << 1) ^ CRC32C_POLY;
         else
          rb <<= 1;
     }
     return (reflect_32 (rb));
   }

   main ()
   {
     int i;

     printf ("\nGenerating CRC-32c table file <%s>\n",
     OUTPUT_FILE);
     if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
         printf ("Unable to open %s\n", OUTPUT_FILE);
         exit (1);
     }
     fprintf (tf, "#ifndef __crc32cr_table_h__\n");
     fprintf (tf, "#define __crc32cr_table_h__\n\n");
     fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
     CRC32C_POLY);
     fprintf (tf,
     "#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
     fprintf (tf, "\nunsigned long  crc_c[256] =\n{\n");
     for (i = 0; i < 256; i++){
         fprintf (tf, "0x%08lXL, ", build_crc_table (i));
         if ((i & 3) == 3)
           fprintf (tf, "\n");
     }
     fprintf (tf, "};\n\n#endif\n");

     if (fclose (tf) != 0)
       printf ("Unable to close <%s>." OUTPUT_FILE);
     else
       printf ("\nThe CRC-32c table has been written to <%s>.\n",
         OUTPUT_FILE);
   }

   /* Пример вставки crc */
   #include "crc32cr.h"

   unsigned long
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     unsigned long crc32 = ~0L;
     unsigned long result;
     unsigned char byte0,byte1,byte2,byte3;

     for (i = 0; i < length; i++){
         CRC32C(crc32, buffer[i]);
     }

     result = ~crc32;

     /*  В result храниться «негативный» остаток полинома,
      *  поскольку таблица и алгоритм являются «зеркальными [williams95].
      *  Т. е., result имеет такое же значение, как будто мы отобразили сообщение
      *  на полином, рассчитали остаток полинома для хостового порядка битов
      *  выполнили финальную смену знака (negation) и сквозное обращение битов.
      *  Отметим, что 32-битовое обращение битов идентично 4 восьмибитовым обращениям 
      *  с последующим обращением порядка байтов. На машинах little-endian 
      *  такое обращение байтов и финальная операция ntohl cancel не нужны.
      */
     byte0 = result & 0xff;
     byte1 = (result>>8) & 0xff;
     byte2 = (result>>16) & 0xff;
     byte3 = (result>>24) & 0xff;
     crc32 = ((byte0 << 24) |
              (byte1 << 16) |
              (byte2 << 8)  |
              byte3);
     return ( crc32 );
   }

   int
   insert_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     unsigned long crc32;
     message = (SCTP_message *) buffer;
     message->common_header.checksum = 0L;
     crc32 = generate_crc32c(buffer,length);
     /* and insert it into the message */
     message->common_header.checksum = htonl(crc32);
     return 1;
   }

   int
   validate_crc32(unsigned char *buffer, unsigned int length)
   {
     SCTP_message *message;
     unsigned int i;
     unsigned long original_crc32;
     unsigned long crc32 = ~0L;

     /* сохраним и обнулим контрольную сумму */
     message = (SCTP_message *) buffer;
     original_crc32 = ntohl(message->common_header.checksum);
     message->common_header.checksum = 0L;
     crc32 = generate_crc32c(buffer,length);
     return ((original_crc32 == crc32)? 1 : -1);
   }
<CODE ENDS>

Благодарности

Представленный в этом документе протокол является серьёзным достижением, основанным на результатах работы авторов исходного [RFC2960] – Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson.

Кроме того, следует отметить всех, кто внес вклад в создание исходного RFC – Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll и многих других, кто дал свои значимые комментарии.

Добавим в этот список соавторов [RFC4460] – I. Arias-Rodriguez, K. Poon, A. Caro.

Отметим усилия участников всех семи проверок совместимости SCTP и тех, кто представил комментарии к [RFC4460], как отмечено здесь – Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani и Ronnie Sellar.

Отдельная благодарность Mark Allman, который реально должен был стать соавтором [RFC4460] по max-burst, но сумел уклониться по причине занятости. Благодарим также Lyndon Ong и Phil Conrad за их полезный вклад в работу.

Отметим также тех, кто подготовил [RFC4460] и комментировал его, включая Alfred Hoenes и Ronnie Sellars.

Добавим сюда соавтора [RFC8540]: Maksim Proshin и тех, кто представил замечания к [RFC8540]: Pontus Andersson, Eric W. Biederman, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, Mirja Kühlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff Morriss, Tom Petch, Kacheong Poon, Julien Pourtet, Irene Rüngeler, Michael Welzl, Qiaobing Xie.

Наконец, добавим тех, кто представил комментарии к этому документу, включая Gorry Fairhurst, Martin Duke, Benjamin Kaduk, Tero Kivinen, Eliot Lear, Marcelo Ricardo Leitner, David Mandelberg, John Preuß Mattsson, Claudio Porfiri, Maksim Proshin, Ines Robles, Timo Völker, Magnus Westerlund, Zhouming.

Благодарность в адрес участников кодирования, тестирования и обновления документа непросто выразить словами. Спасибо Вам!

Адреса авторов

Randall R. Stewart

Netflix, Inc.

2455 Heritage Green Ave

Davenport, FL 33837

United States of America

Email: randall@lakerest.net

Michael Tüxen

Münster University of Applied Sciences

Stegerwaldstrasse 39

48565 Steinfurt

Germany

Email: tuexen@fh-muenster.de

Karen E. E. Nielsen

Kamstrup A/S

Industrivej 28

DK-8660 Skanderborg

Denmark

Email: kee@kamstrup.com


Перевод на русский язык

Николай Малых

nmalykh@protokols.ru


1Public Switched Telephone Network – коммутируемая телефонная сеть общего пользования. Прим. перев.

2Максимальный размер передаваемых пакетов. Прим. перев.

3Internet Engineering Task Force – комиссия по решению инженерных задач Internet.

4Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.

5Имеющих несколько сетевых интерфейсов. Прим. перев.

6Denial of service attack.

7Connection-oriented.

8Соотношения между номерами потоков в противоположных направлениях сильно зависят от того, как приложения используют эти потоки. Ответственность за поддержку корреляции между порядковыми номерами (если она нужна) ложится на пользовательское приложение SCTP.

9Типы типы ECNE и CWR зарезервированы для использования в будущем явных уведомлений о перегрузке (ECN).

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

11Type-Length-Value – Тип-Размер-Значение.

12Блоки INIT могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.

13Поле ECN capable зарезервировано для будущего использования с ECN.

14Недопустимо включение в блок INIT параметра Host Name Address. Получатель блока INIT с Host Name Address должен передать блок ABORT и может включить в него причину ошибки Unresolvable Address.

15Этот параметр (при наличии) задаёт все типы адресов, которые может поддерживать передающая сторона. Отсутствие данного параметра говорит о поддержке передающей стороной адресов всех типов.

16Здесь не используется согласование числа потоков – каждая сторона просто выбирает меньшее из двух значений – предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.

17Блоки INIT ACK могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.

18Поле ECN capable зарезервировано для будущего использования с ECN.

19Недопустимо включение в блок INIT ACK параметра Host Name Address. Получатель блока INIT с Host Name Address должен передать блок ABORT и может включить в него причину ошибки Unresolvable Address.

20Здесь не используется согласование числа потоков – каждая сторона просто выбирает меньшее из двух значений – предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.

21Имена блоков указаны заглавными буквами, а в именах параметров только первая буква является заглавной (например, блок COOKIE ECHO и параметр State Cookie). Если смену состояния могут вызвать несколько событий или сообщений, они помечаются (A), (B) и т. д.

22off-path.

23Silly window syndrome – синдром неразумного окна.

24Advertised Receiver Window Credit – анонсированное окно приёма.

25Receiver advertised window size. Прим. перев.

26Congestion control window. Для краткости будем называть его просто окном перегрузки. Прим. перев.

27Slow-start threshold. Прим. перев.

28Highest TSN Newly Acknowledged – максимальный недавно подтверждённый номер.

29Максимальное число повторов передачи для ассоциации.

30Максимальное число повторов для пути.

31Heartbeat period.

32Out of the blue – совершенно неожиданный.

Рубрика: RFC | Оставить комментарий

RFC 9244 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry

image_print
Internet Engineering Task Force (IETF)                 M. Boucadair, Ed.
Request for Comments: 9244                                        Orange
Category: Standards Track                                T. Reddy.K, Ed.
ISSN: 2070-1721                                                   Akamai
                                                                E. Doron
                                                            Radware Ltd.
                                                                 M. Chen
                                                                    CMCC
                                                              J. Shallow
                                                               June 2022

Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry

Телеметрия распределенной сигнализации об угрозах DoS-атак

PDF

Аннотация

Этот документ нацелен на обогащение протокола сигнального канала распределенной сигнализации об угрозе отказа в обслуживании (Distributed Denial-of-Service Open Threat Signaling или DOTS) различными атрибутами телеметрии для оптимального смягчения распределенных атак на службы (Distributed Denial-of-Service или DDoS). Документ задаёт базовый уровень обычного трафика, атрибуты телеметрии трафика атаки, которые DOTS-клиент может передать своему серверу DOTS в запросе на смягчение последствий атаки, атрибуты смягчения атаки, которые сервер DOTS может передать клиенту, атрибуты телеметрии эффективности, которые клиент может передать серверу DOTS. Атрибуты телеметрии могут способствовать системе смягчения атак при выборе методов защиты от DDoS и эффективном смягчении DDoS-атак.

Документ задаёт два модуля YANG для представления типов сообщений телеметрии DOTS и обмена данными данными об отображениях атак по каналу данных DOTS.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9244.

Авторские права

Авторские права (Copyright (c) 2022) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в варианте HTML

1. Введение

IT-организации и сервис-провайдеры сталкиваются с распределёнными атаками на службы (Distributed Denial-of-Service или DDoS), которые делятся на две большие категории.

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

    Основой таких атак является передача большого объёма трафика в направлении инфраструктуры жертвы. Обычно объем трафика атаки может составлять от нескольких сотен Мбит/с до сотен Гбит/с и даже Тбит/с. Атаки обычно организуются с использованием бот-сетей (botnet) и рефлекторов для усиления атаки (параграф 3.1 в [RFC4732]), таких как NTP (Network Time Protocol), DNS (Domain Name System), SNMP (Simple Network Management Protocol), SSDP (Simple Service Discovery Protocol).

  2. Атаки прикладного уровня нацелены на разные приложения. Типичными примерами служат атаки на HTTP/HTTPS, DNS, SIP (Session Initiation Protocol), SMTP (Simple Mail Transfer Protocol). Однако для таких атак открыты и все прочие приложения на периметре сети, для которых известны номера применяемых портов.

    Атаки на прикладном уровне считаются более сложными и их труднее классифицировать, следовательно – обнаруживать и эффективно ослаблять.

Для усугубления проблем злоумышленники применяют многовекторные атаки, которые состоят из динамических атак сетевого и прикладного уровня и могут включать иную тактику. Таким способом формируется многовекторная атака с разными типами и объёмами, одновременно нацеленными на жертву. Многовекторные атаки сложнее в обнаружении и защите от них. Для защиты от таких атак требуется применять одновременно множество методов ослабления атак. Злоумышленники часто меняют векторы атак сразу после успешного ослабления атаки, заставляя менять используемые методы защиты.

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

Протокол сигнального канала Distributed Denial-of-Service Open Threat Signaling (DOTS) [RFC9132] служит для передачи сведений о сетевом ресурсе или сети (части сети), подвергающейся DDoS-атаке. Такая информация передаётся клиентами DOTS одному или нескольким серверам DOTS для принятия соответствующих действий по смягчению последствий со стороны трафика, сочтенного подозрительным. Примеры использования представлены в [RFC8903].

Клиенты DOTS могут интегрироваться с детекторами атак DDoS или элементами сети или системы защиты, которые активно вовлечены в текущие атаки. Среда смягчения атак клиента DOTS определяет, что она больше не способна ослаблять атаки самостоятельно. Это может быть обусловлено нехваткой ресурсов или средств защиты с учётом сложности и интенсивности атак. В таких обстоятельствах клиент DOTS обладает бесценными сведениями о фактических атаках, которые должны быть обработаны его серверами DOTS. Предоставляя клиенту DOTS возможность делиться всеобъемлющими сведениями о происходящей атаке, сервер DOTS может значительно повысить свои возможности в части смягчения атаки. Когда атака обрабатывается средствами смягчения, связанными с сревером DOTS, этот сервер знает способы смягчения атаки. Сервер DOTS может делиться такой информацией с клиентом DOTS, чтобы тот мог лучше оценить используемые методы и средства смягчения атаки.

Клиент DOTS могут передавать серверам советы по смягчению атаки, полученные на основе сведений об атаке, отдавая себе отчето в том, что серверы могут игнорировать эти советы, как описано в [RFC8612] (Gen-004). Советы передаются по сигнальному каналу DOTS, поскольку каналы данных могут быть недоступны во время атаки. Способы обработки серверами DOTS атрибутов обычного трафика и трафика атак, а также советов по смягчению зависят от реализации.

Клиенты и серверы DOTS могут извлечь выгоду из этих сведений, представляя различные детали информации в соответствующие системы управления, отчётов и порталов.

Этот документ определяет атрибуты телеметрии DOTS, которые могут передаваться между клиентами и серверами DOTS. Эти атрибуьы не являются обязательными для протокола сигнального канала DOTS [RFC9132]. Если для агента DOTS не заданы ограничения, он может передать своему партнёру доступные атрибуты телеметрии для оптимизации службы смягчения атак, предоставляемой DOTS. Упомянутая политика может быть согласована, например, при подписке на сервис (это выходит за рамки документа) для указания набора клиентов DOTS, развёрнутых в клиентском домене DOTS, которым разрешено передавать или принимать данные телеметрии.

В параграфе 11.2 задан модуль YANG, дополняющий канал данных DOTS [RFC8783] сведениями, относящимися к деталям атаки. Совместное использование таких деталей в период «бездействия» предназначено для оптимизации обмена данными по сигнальному каналу DOTS.

2. Терминология

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.

Читателю следует ознакомиться с терминами, определёнными в [RFC8612].

Телеметрия DOTS определена как набор атрибутов, используемых для характеризации базового уровня обычного трафика, трафика атак и мер по их смягчению, а также других сведений, которые могут помочь в применении контрмер. Телеметрия DOTS – это необязательный набор атрибутов, которые могут передаваться по сигнальному каналу DOTS.

Идентификатор установки телеметрии (Telemetry Setup Identifier или tsid) создаётся клиентом DOTS для однозначного указания данных конфигурации телеметрии DOTS (см. 7.1.2. Передача конфигурации телеметрии DOTS).

Идентификатор телеметрии (Telemetry Identifier или tmid) создаётся клиентом DOTS для однозначного указания данных телеметрии DOTS, передаваемыми до или в процессе смягчения атаки (см. 8.2. От клиентов к серверам DOTS).

«Перекрытие» младшей части tsid (или tmid) указывает младшую часть перекрывающихся запросов телеметрии.

Термин «труба» (pipe) обозначает максимальный уровень трафика, который может получать клиентский домен DOTS. Сопоставление трубы с одним или группой сетевых интерфейсов зависит от развёртывания. Например, каждый межсетевой канал может рассматриваться как отдельная труба, если сервер DOTS размещается у каждого восходящего (upstream) провайдера или все соединения с восходящими провайдарами могут считаться клиентским доменом DOTS одной трубой, если серверы DOTS не размещаются у этих провайдеров.

В документе используются выделенные IANA Enterprise Number, известные как Private Enterprise Numbers и SMI (Structure of Management Information) Network Management Private Enterprise Codes [Private-Enterprise-Numbers].

Значение символов на диаграммах деревьев YANG определено в [RFC8340] и [RFC8791].

В соответствии с соглашениями раздела 2 в [RFC8783] примеры параграфа 8.1.6 используют /restconf как обнаруженный корневой путь RESTCONF API. В этих примерах символ \ в конце строки означает перенос длинной строки в целях форматирования. Предполагается, что такие строки объединяются с удалением символов \, перевода строки и начального пробела в следующей строке.

3. Телеметрия DOTS – обзор и назначение

Своевременная и эффективная передача актуальных данных телеметрии DDoS всем элементам, вовлеченным в процесс смягчения атак, важна и повышает общую эффективность систем смягчения DDoS-атак. Двухсторонний обмен между агентами DOTS необходим для повышения уровня осведомлённости каждой стороны об атаках и усилиях по их смягчению в поддержке высокоэффективных услуг по ослаблению атак.

3.1. Улучшение видимости атак

При передаче запроса на смягчение атаки для клиентов DOTS безусловно полезно сообщить серверам DOTS все сведения о происходящих атаках. Это может происходить в случаях, когда клиенты DOTS запрашивают поддержку у серверов DOTS для защиты от атак, которые уже обнаружены и/или (частично) смягчены.

Если атаки уже обнаружены и классифицированы в клиентском домене DOTS, сервер DOTS и связанные с ним службы смягчения могут проактивно использовать эти сведения для оптимизации предоставления услуг. Важно отметить, что клиентские и серверные домены DOTS используют разные подходы к обнаружению и смягчению атак, что может приводить к разным результатам обнаружения и классификации атак. Служба смягчения DDoS рассматривает сведения об имеющейся атаке от клиентов DOTS как советы и не может полностью полагаться или доверять им.

В дополнение к тому, что сервер DOTS напрямую использует данные телеметрии в качестве оперативных советов, команда обеспечения безопасности сервера DOTS также может получить пользу от данных телеметрии. Основным требованием групп по обеспечению безопасности является осведомлённость об атаках и видимость атак, с которыми нужно работать. Это особенно актуально для происходящих атак, где телеметрия DOTS предоставляет данные о текущем статусе атаки. Даже при возможности автоматического смягчения команды защиты могут применять данные телеметрии DOTS для подготовки смягчения атаки и выделения нужных ресурсов (например, специалистов, ресурсов среды и средств смягчения) для конкретного сервиса. Точно так же персонал на стороне клиента DOTS запрашивает обратную связь для своих запросов защиты, поэтому для серверов DOTS важно делиться с клиентами данными телеметрии DOTS.

Таким образом, взаимный обмен информацией имеет решающее значение для «замыкания контура смягчения» между клиентами и серверами DOTS. Для команд на стороне сервера важно понимать, что атаки, видимые ресурсами сервера по смягчению атак, – это те же атаки, для которых клиент DOTS запрашивает смягчение. Команде на стороне клиента DOTS важно понимать, что предоставляется именно требуемая услуга, например, «я запросил смягчение двух атак, но мой сервер DOTS обнаружил и смягчает лишь одну из них». Несоответствие в классификации атак между клиентами и серверами DOTS можно выявить и, может быть, обработать с помощью атрибутов телеметрии DOTS.

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

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

3.2. Улучшенное обнаружение

Телеметрия DOTS может также служить входными данными для определения значений при настройке параметров, доступных на ресурсах смягчения атак. За последние несколько лет технологии обнаружения DdoS-атак развились от детектирования по порогу (когда весь трафик или его определённые части превышают заданный порог) до обнаружения аномалий. В последнем случае требуется поддерживать строгое изучение обычного поведения, а аномалия (или атака) идентифицируется и классифицируется но основе сведений о нормальном трафике и отклонений от него. Статистические алгоритмы и искусственный интеллект (например, машинное обучение) применяются так, что пороги рассчитываются автоматически путём изучения нормального трафика в период «бездействия» (смягчение не применяется). Полученные характеристики обычного трафика называют также базовым уровнем (normal traffic baseline), а атакой считаются случаи, когда фактический трафик жертвы отличается от базового уровня.

Кроме того, последующие действия по смягчению атак являются значительно более сложными. Способность различать легитимный трафик и атаки на уровне пакетов является сложной задачей. Например, пакет может казаться легитимным, а сигнатура атаки не может быть обнаружена. Аномалии можно выявить лишь после детального статистического анализа. Средства смягчения атак DDoS применяют базовый уровень трафика в процессе смягчения атак для идентификации и классификации ожидаемого появления определённой картины трафика. В частности, средства смягчения используют базовый уровень для определения «степени нормальности», которой нужно достичь в разных процессах смягчения атак.

Расчёт базового уровня выполняется на основе непрерывного изучения нормального поведения защищаемых объектов. Минимальный период изучения варьируется от часов до дней и даже недель, в зависимости от поведения защищаемых приложений. Базовый уровень не может изучаться во время атак, поскольку в этом случае поведение защищаемого объекта отличается от обычного.

Если клиент DOTS рассчитал базовый уровень для защищаемых объектов, передача такой информации серверу DOTS вместе с параметрами трафика атаки представляет ценность. Сервер DOTS с учётом этой телеметрии настраивает свои ресурсы смягчения атаки. Системы смягчения серверов DOTS используют базовый уровень для понимания обычного поведения жертвы атаки и стремятся восстановить нормальную работу жертвы. Предполагается, что смягчение атаки будет в результате более эффективным, точным и без ложных срабатываний или пропусков.

Смягчение атак без знания обычного трафика будет в лучшем случае неточным. Это особенно верно для рекурсивной сигнализации (см. параграф 3.2.3 в [RFC8811]). С учётом возможности интеграции клиентов DOTS в самые разные системы и варианты применения, это повышает важность сведений о поведении каждого клиентского домена DOTS, особенно из-за того, что глобальные пороги обнаружения атак практически не реализуются. Каждый клиентский домен DOTS имеет свой уровень трафика и своё поведение. Без сведений о базовых уровнях серверам DOTS в некоторых случаях может быть очень трудно обнаружить и эффективно смягчить атаки.

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

Конечно, такие сведения можно предоставить по отдельному каналу (out-of-band) или настроить вручную с риском того, что информация станет неточно результате изменения сети и обычной картины трафика. Применение динамических и кооперативных мер между клиентами и серверами DOTS для идентификации и обмена ключевыми параметрами обеспечит более эффективную защиту от DDoS-атак.

3.3. Эффективное ослабление атак

Во время сильной атаки каналы клиента DOTS могут быть загружены полностью. Клиенты DOTS запрашивают у своих серверов DOTS обработку атаки в восходящем направлении, чтобы вернуть каналам клиента приемлемый уровень загрузки (в идеале, нормальный). На этом этапе важно обеспечить, чтобы система смягчения не перегрузила каналы клиента DOTS, отправляя тому большие объёмы «чистого» или кажущегося чистым трафика. Такое может случиться, если система смягчения не может обнаружить и ослабить все атаки, направленные в клиентский домен DOTS.

В таких случаях для клиентов DOTS важно сообщить серверам DOTS общую пропускную способность каналов, определяющую уровень трафика, который клиентский домен DOTS может воспринять из восходящей сети (провайдера). Необходимо динамически обновлять состояния каналов между агентами DOTS, находящимися в условиях DDoS-атаки (например, при использовании несколькими клиентами DOTS общих физических каналов). Серверу DOTS следует активировать другие механизмы, чтобы гарантированно предотвратить ненамеренное насыщение каналов клиентского домена. Для этого разумным решением будет применение ограничения скорости, описанного в [RFC8783]. Клиент DOTS может указать типы трафика (например, ICMP, UDP, TCP через порт 80), который он предпочитает ограничить. Действиями по ограничению скорости можно управлять по каналу сигнализации [RFC9133] даже при перегрузке «трубы».

4. Внутреннее устройство

4.1. Обзор операций телеметрии

Стек протоколов DOTS делится на две логических части: сигнальный канал [RFC9132] и канал данных [RFC8783]. Это разделение обусловлено совершенно разными требованиями к передаваемому по этим каналам трафику. Сигнальный канал DOTS должен оставаться доступным и пригодным для использования даже в случае атаки, которая, например, может перегрузить одно из направлений охваченных каналов, что делает ненадёжными механизмы на основе подтверждений и настоятельно требует делать сообщения достаточно малыми, чтобы передать в одном пакете IP (параграф 2.2 в [RFC8612]). Напротив, канал данных DOTS доступен для высокоскоростной передачи данных до или после атаки с использованием более традиционных методов доставки (параграф 2.3 в [RFC8612]). Обычно предпочтительно заранее настраивать конфигурацию по каналу данных DOTS, включая настройку псевдонимов для статических или почти статических наборов данных, таких как множество сетевых адресов/префиксов, которые могут быть атакованы. Это помогает оптимизировать использование сигнального канала DOTS для небольших сообщений, которые важно доставить даже во время атаки. Напомним, что для сигнализации и данных DOTS требуются защищённые каналы (раздел 11 в [RFC9132] и раздел 10 в [RFC8783]).

Данные телеметрии имеют аспекты, соответствующие обоим режимам работы (сигнализация и данные). Безусловно необходимо передавать обновляемые сведения о трафике происходящей атаки и целях атаки, чтобы иметь детальные сведения о статусе смягчения и обновлять стратегию защиты от адаптивных атак. Однако полезно также предоставлять службам смягчения картину нормального (базового уровня) трафика в направлении возможных целей атак, чтобы помочь в обнаружении отклонений в поведении трафика при возникновении атак. Кроме того, можно поддерживать «базу данных» с классификацией известных типов атак, чтобы можно было применять краткий идентификатор атаки в период её действия для описания данной атаки. Эта спецификация предусматривает использование канала данных DOTS для последней функции (параграф 8.1.6), но большая часть функций телеметрии реализуется по сигнальному каналу DOTS.

Отметим, что передача сведений о трафике происходящей атаки является функциональным требованием, а сведения о базовом уровне трафика представляют идентичную структуру данных, которая естественным образом определена вместе с описанием атаки. Связанные с этим данные о настройке телеметрии служат для параметризации сведений о фактическом трафике данных, также передаются по каналу управления из соображений целесообразности.

Этот документ задаёт расширение протокола сигнального канала DOTS, установка, поддержка и использование которого заданы в [RFC9132].

После организации сигнального канала DOTS клиенты, поддерживающие телеметрию DOTS, выполняют настройку конфигурации телеметрии (например, интервалы измерения и уведомления, ёмкость трубы, базовый уровень трафика), как описано в разделе 7. Затем агенты DOTS могут включать атрибуты телеметрии DOTS с использованием сигнального канала DOTS (параграф 8.1). Клиент DOTS может использовать раздельные сообщения для обмена со своими серверами DOTS набором данных телеметрии, связанных с текущими мерами смягчения атак (параграф 8.2). Заинтересованный в телеметрических уведомлениях, связанных с некоторыми из его ресурсов, клиент следует процедуре, описанной в параграфе 8.3. Клиент DOTS, получающий такие уведомления, может принять решение об отправке запроса на смягчение атаки, если он не может смягчить её локально внутри клиентского домена DOTS.

Совокупные данные телеметрии DOTS могут также включаться в сообщения об обновлении эффективности (параграф 9.1) или смягчения (параграф 9.2).

4.2. Поблочная передача

Клиенты DOTS могут использовать поблочную передачу [RFC7959] в соответствии с рекомендациями параграфа 4.4.2 в [RFC9132] для управления размером отклика, когда возвращаемые данные не помещаются в одну дейтаграмму.

Клиенты DOTS могут также применять опцию Block1 протокола CoAP (Constrained Application Protocol) в запросах PUT (параграф 2.5 в [RFC7959]) для инициирования больших передач, но эти передачи Block1 скорее всего приведут к отказу, если входная «труба» заполнена, поскольку для передачи требуется сообщение от сервера для каждого блока, которое скорей всего будет потеряно во входном потоке. Необходимо рассмотреть попытку уместить PUT в одну передачу или разделить PUT на несколько дискретных запросов PUT, каждый из которых умещается в один пакет.

Опции Q-Block1 и Q-Block2 похожи на опции CoAP Block1 и Block2, но обеспечивают надёжную передачу больших блоков данных с меньшим числом обменов пакетами, используя сообщения NON, определённые в [RFC9177]. Реализации DOTS могут рассмотреть использование опций Q-Block1 и Q-Block2 [DOTS-Robust-Blocks].

4.3. Многодомные системы DOTS

Вопросы выбора многодомными клиентами DOTS серверов для контакта и префиксов IP для включения в телеметрию для данного партнёрского сервера DOTS рассмотрены в [DOTS-Multihoming]. Например, если каждая из восходящих сетей раскрывает сервер DOTS и клиент DOTS поддерживает каналы DOTS со всеми из них, по каналам DOTS будет передаваться лишь информация, относящаяся к префиксам, назначенным клиентскому домену восходящей сетью.

Соображения, связанные с тем, собирает ли (и как) клиент DOTS ту или иную телеметрию (например, детали атаки), которую он получает от первого сервера DOTS и передаёт её второму серверу, зависят от реализации и развёртывания.

4.4. Вопросы YANG

Сообщения телеметрии между агентами DOTS сериализуются с использованием краткого представления двоичных объектов (Concise Binary Object Representation или CBOR) [RFC8949]. Данные в кодировке CBOR служат для передачи относящихся к каналу сигнализации сообщений, которые содержат параметры запросов и данные откликов, такие как ошибки.

Этот документ задаёт модель YANG [RFC7950] для представления типов сообщений телеметрии DOTS (параграф 11.1). Все параметры в полях данных сигнального канала DOTS отображаются на типы CBOR, как указано в разделе 12. Напомним, что правила отображения данных из модели YANG на CBOR даны в разделе 3 [RFC9132].

Модуль телеметрии (параграф 11.1) не предназначен для использования по протоколам NETCONF (Network Configuration Protocol) и RESTCONF с целью управления серверами DOTS. Он задаёт модель данных и кодирование в соответствии с [RFC8791]. Серверные отклонения (параграф 5.6.3 в [RFC7950]) настоятельно не рекомендуются, поскольку партнерский агент DOTS не может получить список отклонений и могут возникать проблемы совместимости.

Модуль телеметрии DOTS (параграф 11.1) использует enumeration вместо identity для определения единиц, выборок и интервалов, поскольку в ином случае нужно включать идентификатор пространства имён ietf-dots-telemetry при включении атрибута телеметрии (например, при обновлении эффективности смягчения). Применение identity неоптимально с точки зрения компактности сообщений, которая очень важна для сигнального канала DOTS.

Модуль телеметрии DOTS (параграф 11.1) включает списки без оператора key. Это соответствует [RFC8791]. Причина отсутствия ключей состоит в том, что они не включаются в тело запросов DOTS, эти ключи обязательны лишь в запросах Uri-Paths (разделы 7 и 8). Иначе при каждом включении оператора key предполагается такое же определение, как в параграфе 7.8.2 [RFC7950].

Некоторые параметры (например, значения low-percentile) могут быть связаны с разными типами YANG (например, decimal64 и yang:gauge64). Чтобы проще было различать типы этих параметров и сохранить осмысленность имён, применяются суффиксы, показанные в таблице 1.

Таблица 1. Суффиксы и типы YANG.

Суффикс

Тип YANG

Пример

-g

yang:gauge64

low-percentile-g

-c

container

connection-c

-ps

per second

connection-ps

 

Диаграмму полного дерева телеметрии DOTS можно создать с помощью pyang [PYANG]. Дерево не включено в документ из-за слишком большого размера (параграф 3.3 а [RFC8340]) и представлено лишь частями.

Для оптимизации обмена данных по сигнальному каналу DOTS в этом документе определён второй модуль YANG (ietf-dots-mapping, параграф 11.2), дополняющий канал данных DOTS [RFC8783]. Это дополнение можно использовать в период «бездействия» для обмена сведениями о сопоставлениях атак (параграф 8.1.5). Клиенты DOTS могут применять инструменты, такие как YANG Library [RFC8525], для получения списка свойств и отклонений, поддерживаемых сервером по каналу данных.

5. Базовые вопросы

5.1. Идентификация клиентов DOTS

В соответствии с правилами параграфа 4.4.1 в [RFC9132] клиент DOTS создаёт уникальный идентификатор cuid для предотвращения конфликтов. Напомним, что параграф 4.4.1.3 в [RFC9132] запрещает возврат cuid в теле откликов.

5.2. Шлюзы DOTS

Между клиентами и серверами DOTS могут размещаться шлюзы DOTS. Необходимо следовать соображениям, изложенным в параграфе 4.4.1 [RFC9132]. В частности, атрибут cdid служит для однозначной идентификации клиентского домена DOTS. Напомним, что параграф 4.4.1.3 в [RFC9132] запрещает возврат cuid (при наличии) в теле откликов.

5.3. Параметры Uri-Path и пустые значения

Параметры Uri-Path и атрибуты с пустыми значениями недопустимо включать в запрос. Наличие пустого значения делает всё сообщение недействительным.

5.4. Управление данными конфигурации

Сервер DOTS руководствуется теми же соображениями, которые изложены в параграфе 4.5.3 [RFC9132], для поддержки актуальности и уведомлений конфигурации телеметрии DOTS.

Аналогично, клиент DOTS может управлять выбором конфигурационных и неконфигурационных узлов данных при отправке запроса GET с помощью опции Uri-Query c (content – содержимое), следуя процедуре, заданной в параграфе 4.4.2 [RFC9132]. В последующих параграфах эти соображения не повторяются.

5.5. Проверка сообщения

Полномочными для проверки сообщений, передаваемых по сигнальному каналу DOTS являются разделы 7 – 9 и таблица сопоставлений в разделе 12. Структура тела сообщений представлена в модуле YANG (параграф 11.1).

5.6. Замечания о примерах

Примеры представлены для иллюстрации и не представляют полный набор сообщений.

JSON-кодирование данных модели YANG служит для демонстрации операций телеметрии. Для удобочитаемости в примерах применяются имена параметров и их типы JSON, а не значение ключей CBOR и типы CBOR (см. раздел 12). Эти соглашения заимствованы из [RFC9132].

В примерах применяется значение Enterprise Number = 32473, выделенное для документации (см. [RFC5612]).

6. Пути операций телеметрии

Как отмечено в параграфе 4.2 [RFC9132], каждая операция DOTS указывается суффиксом пути, который задаёт предусмотренную операцию. Путь операции добавляется в конце префикса пути для создания URI, применяемого с запросом CoAP для выполнения нужной операции DOTS. Суффиксы путей телеметрии приведены в таблице 2.

Таблица 2. Операции телеметрии DOTS.

Операция

Путь операции

Описание

Telemetry Setup

/tm-setup

Раздел 7

Telemetry

/tm

Раздел 8

 

Модуль YANG ietf-dots-telemetry, заданный в параграфе 11.1, определяет структуру данных для представления новых типов сообщений DOTS – telemetry-setup и telemetry. Структура дерева показана на рисунке 1, а описания даны в разделах 7 и 8 с указанием точной структуры типов сообщений telemetry-setup и telemetry.

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     ...
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             ...

Рисунок 1. Новые типы сообщений DOTS (дерево YANG).


Реализации DOTS должны поддерживать Observe Option [RFC7641] для tm (раздел 8).

7. Конфигурация установки телеметрии DOTS

Как показано на рисунке 1, сообщение установки телеметрии DOTS должно включать лишь относящиеся к телеметрии параметры конфигурации (параграф 7.1), сведения о «емкости трубы» клиентского домена DOTS (параграф 7.2) или данные о базовом уровне трафика телеметрии (параграф 7.3). Поэтому запросы, включающие комбинацию настроек телеметрии, ёмкости трубы и данные о базовом уровне трафика, должны отвергаться серверами DOTS с кодом отклика 4.00 (Bad Request – недопустимый запрос).

Клиент DOTS может сбросить все установленные данные конфигурации телеметрии DOTS в соответствии с параграфом 7.4.

Сервер DOTS может обнаруживать конфликты при обработке запросов, относящихся к ёмкости трубы клиентского домена DOTS или данным о базовом трафике телеметрии, с запросами от других клиентов из того же домена (см. параграф 7.5).

Конфигурация установки телеметрии привязана к клиентскому домену DOTS. Серверам DOTS недопустимо ожидать от клиентов DOTS регулярной отправки запросов на обновление конфигурации телеметрии. Доступная конфигурация установки телеметрии действительна, пока сервер DOTS не прекратит обслуживание клиентского домена DOTS. Серверам DOTS недопустимо сбрасывать tsid из-за отказа сессии с клиентом DOTS. Клиенты DOTS обновляют свою конфигурацию установки телеметрии при смене параметров, способных влиять на смягчение атак.

Запросы и отклики конфигурации телеметрии DOTS помечаются как сообщения Confirmable (параграф 2.1 [RFC7252]).

7.1. Конфигурация телеметрии

В телеметрии DOTS применяется несколько значений процентилей для представления общего распределения картины трафика, а не моментального снимка в конкретное время. Моделирование необработанных данных о потоке трафика в форме распределения и описание такого распределения влечёт за собой выбор периода измерений, описываемого распределением, и числа интервалов выборки или «сегментов» (bucket) в этом интервале измерений. Трафик в каждом сегменте считается одним событием (усредняется), а распределение сегментов служит для описания распределения трафика в интервале измерений. Распределение можно характеризовать статистически (например, среднее значение, медиана, стандартное отклонение), а также указанием значений на разных уровнях процентилей рассматриваемого набора данных (например, квартили для 25-го, 50-го и 75-го процентиля). Значения процентилей и их расчёт подробно описаны в параграфе 11.3 [RFC2330].

В телеметрии DOTS применяется 3 значения процентилей и общий пик для описания распределений трафика. Значения для low-percentile, mid-percentile и high-percentile настраиваются. Принятые по умолчанию значения указаны в параграфе 7.1.2. Клиент DOTS может согласовать с серверами набор используемых параметров конфигурации телеметрии, включая указанные ниже.

  • Связанные с процентилями параметры измерений. В частности, measurement-interval задаёт период, в течение которого рассчитываются процентили, а measurement-sample определяет распределение по времени измерений, служащих для расчёта процентилей.

  • Единицы измерения.

  • Допустимые значения процентилей.

  • Интервал уведомлений телеметрии.

  • Допустимая телеметрия от сервера.

7.1.1. Извлечение текущей конфигурации телеметрии DOTS

Запрос GET служит для получения приемлемых и текущих параметров телеметрии от сервера DOTS. Запрос может включать Uri-Path cdid при трансляции шлюзом DOTS. Пример запроса (без шлюза) показан на рисунке 2.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

Рисунок 2. GET для извлечение текущей и приемлемой конфигурации телеметрии DOTS.


При получении такого запроса и отсутствии ошибок при его обработке сервер DOTS возвращает отклик 2.05 (Content — содержимое) с параметрами телеметрии, которые подходят для сервера, сведениями о трубе (параграф 7.2) и текущими данными о базовом уровне (параграф 7.3), которые сервер поддерживает для этого клиента DOTS. Структура дерева тела отклика показана на рисунке 3.

Серверы DOTS, поддерживающие передачу клиентам сведений телеметрии до или в процессе смягчения атаки (параграф 9.2) устанавливают для server-originated-telemetry в max-config-values значение true (false в ином случае). Если server-originated-telemetry отсутствует в отклике, это эквивалентно отклику в server-originated-telemetry = false.

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  +-- (direction)?
          |  |  +--:(server-to-client-only)
          |  |     +-- max-config-values
          |  |     |  +-- measurement-interval?          interval
          |  |     |  +-- measurement-sample?            sample
          |  |     |  +-- low-percentile?                percentile
          |  |     |  +-- mid-percentile?                percentile
          |  |     |  +-- high-percentile?               percentile
          |  |     |  +-- server-originated-telemetry?   boolean
          |  |     |  +-- telemetry-notify-interval?     uint16
          |  |     +-- min-config-values
          |  |     |  +-- measurement-interval?        interval
          |  |     |  +-- measurement-sample?          sample
          |  |     |  +-- low-percentile?              percentile
          |  |     |  +-- mid-percentile?              percentile
          |  |     |  +-- high-percentile?             percentile
          |  |     |  +-- telemetry-notify-interval?   uint16
          |  |     +-- supported-unit-classes
          |  |     |  +-- unit-config* [unit]
          |  |     |     +-- unit           unit-class
          |  |     |     +-- unit-status    boolean
          |  |     +-- supported-query-type*  query-type
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  +-- current-config
          |        |     +-- measurement-interval?          interval
          |        |     +-- measurement-sample?            sample
          |        |     +-- low-percentile?                percentile
          |        |     +-- mid-percentile?                percentile
          |        |     +-- high-percentile?               percentile
          |        |     +-- unit-config* [unit]
          |        |     |  +-- unit           unit-class
          |        |     |  +-- unit-status    boolean
          |        |     +-- server-originated-telemetry?   boolean
          |        |     +-- telemetry-notify-interval?     uint16
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             ...

Рисунок 3. Структура дерева конфигурации телеметрии.


При наличии атрибутов min-config-values и max-config-values значения в max-config-values должны быть больше значений в соответствующих атрибутах min-config-values.

7.1.2. Передача конфигурации телеметрии DOTS

Запрос PUT служит для передаси конфигурационных параметров данных телеметрии (например, значений процентилей). К примеру, клиент DOTS может обратиься к своему серверу DOTS для смены принятых по умолчанию значений процентилей, служащих базой для данных телеметрии. На рисунке 3 показаны атрибуты, которые клиент DOTS может установить таким запросом PUT. Пример изменения значений процентилей приведён на рисунке 4.

Примечание. Содержимое сообщения на рисунке 4 представлено в кодировке CBOR, как указано Content-Format application/dots+cbor (см. параграф 10.3 в [RFC9132]). Однако для удобочитаемости этот пример (и другие рисунки, показывающие сообщения телеметрии DOTS) следует параграфу 5.6, используя имена и типы JSON из раздела 12.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=123"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "current-config": {
             "low-percentile": "5.00",
             "mid-percentile": "65.00",
             "high-percentile": "95.00"
           }
         }
       ]
     }
   }

Рисунок 4. PUT для доставки конфигурации телеметрии DOTS.


Параметр cuid является обязательным в Uri-Path запросов PUT.

Ниже приведено определение дополнительного параметра Uri-Path.

tsid

Идентификатор установки телеметрии (Telemetry Setup Identifier) служит для представления конфигурационных данных установки телеметрии DOTS целым числом и должен создаваться клиентами DOTS. Значения tsid должны монотонно возрастать по мере необходимости передачи клиентом новых (а не просто изменённых) параметров конфигурации.
При достижении максимального значения (rollover) параметра tsid должна применяться процедура, заданная в параграфе 4.4.1 [RFC9132] для параметра mid.
Этот атрибут является обязательным и должен размещаться в опциях Uri-Path после атрибута cuid.

Атрибуты cuid и tsid недопустимо включать в тело запросов PUT.

В запросе PUT должен присутствовать хотя бы один настраиваемый атрибут.

Запрос PUT с большим значением tsid переопределяет установленные запросом с меньшим tsid данные конфигурации телеметрии DOTS. Чтобы не поддерживать слишком длинные списки tsid для доставки данных конфигурации телеметрии от клиента DOTS, наименьшее значение tsid должно автоматически удаляться без доступности серверу.

Сервер DOTS указывает результат обработки запроса PUT с помощью приведённых ниже кодов отклика.

  • Если в запросе отсутствуют обязательные атрибуты, не включён параметр Uri-Path cuid или tsid или имеется хотя бы один недействительный или неизвестный параметр, должен возвращаться отклик с кодом 4.00 (Bad Request – непригодный запрос).

  • Если сервер DOTS не находит в своей конфигурации значение параметра tsid, переданное в запросе PUT, и воспринимает параметры конфигурации, в отклике должен указываться код 2.01 (Created – создано).

  • Если сервер DOTS находит в своей конфигурации значение параметра tsid, переданное в запросе PUT, и воспринимает параметры конфигурации, в отклике должен указываться код 2.04 (Changed – изменено).

  • Если какое-либо из включённых значений атрибутов не приемлемо для сервера DOTS (параграф 7.1.1), должен возвращаться отклик 4.22 (Unprocessable Entity – необрабатываемый элемент).

    Клиент DOTS может повторить и передать запрос PUT с другими значениями атрибутов, приемлемыми для сервера DOTS.

По умолчанию для представления данных телеметрии служат значения low-percentile (10-й), mid-percentile (50-й), high-percentile (90-й) и peak (100-й). Клиент DOTS может отменить некоторые типы процентилей (low, mid, high). В частности, low-percentile = 0.00 указывает, что клиенту DOTS не нужны значения low-percentile. Аналогично, установка для mid-percentile (или high-percentile) таклго же значения, как для low-percentile (или mid-percentile) указывает, что клиенту не нужны значения mid-percentile (или high-percentile). Например, клиент DOTS может отправить запрос. Показанный на рисунке 5, для информирования сервера о желании получать лишь значения high-percentile. Это предполагает, что клиент будет применять этот тип процентилей при совместном с сервером использовании данных телеметрии.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=124"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "current-config": {
             "low-percentile": "0.00",
             "mid-percentile": "0.00",
             "high-percentile": "95.00"
           }
         }
       ]
     }
   }

Рисунок 5. PUT для отключения Low и Mid процентилей.


Клиенты DOTS могут также настраивать класс единиц измерения для относящихся к трафику данных телеметрии, а также другие классы единиц измерения, такие как пакет/сек, бит/сек, байт/сек. Для одного набора данных телеметрии можно применять одновременно классы бит/сек и байт/сек. Однако получение конфликтующих значений считается недействительным параметром и отвергается с кодом 4.00 (Bad Request).

Клиенты DOTS, заинтересованные в получении от сервера данных телеметрии до и в процессе смягчения атак (pre-or-ongoing-mitigation, см. параграф 9.2), должны установить для server-originated-telemetry значение true. Отсутствие server-originated-telemetry в запросе PUT эквивалентно установке для атрибута значения false. Пример запроса для включения телеметрии pre-or-ongoing-mitigation от сервера DOTS показан на рисунке 6.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=125"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "current-config": {
             "server-originated-telemetry": true
           }
         }
       ]
     }
   }

Рисунок 6. PUT для включения телеметрии до или в процессе смягчения от сервера DOTS.


7.1.3. Извлечение установленной конфигурации телеметрии DOTS

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=123"

Рисунок 7. GET для извлечения текущей конфигурации телеметрии DOTS.


Клиент DOTS может передать сообщение GET с параметром Uri-Path tsid для извлечения текущей конфигурации телеметрии DOTS. Пример такого запроса показан на рисунке 7.

Если сервер DOTS не находит полученного значения Uri-Path tsid в своих данных конфигурации, он должен передать отклик с кодом 4.04 (Not Found – не найдено).

7.1.4. Удаление конфигурации телеметрии DOTS

Запрос DELETE служит для удаления установленных данных конфигурации телеметрии DOTS (Рисунок 8). Параметры Uri-Path cuid и tsid обязательны для таких запрсов DELETE.

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=123"

Рисунок 8. Удаление конфигурации телеметрии.


Сервер DOTS сбрасывает конфигурацию телеметрии DOTS в принятые по умолчанию значения и подтверждает запрос клиента DOTS откликом с кодом 2.02 (Deleted – удаллено). Код 2.02 (Deleted) возвращается даже в том случае, когда значение параметра tsid из запроса DELETE отсутствовало в данных конфигурации до запроса.

В параграфе 7.4 описана процедура сброса всех конфигурационных данных установки телеметрии DOTS.

7.2. Общая «ёмкость» трубы

Клиент DOTS может сообщать серверам DOTS сведения о трубе (pipe) в свой домен DOTS. Структура дерева таких сведений показана на рисунке 9.

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  +-- total-pipe-capacity* [link-id unit]
          |        |     +-- link-id     nt:link-id
          |        |     +-- capacity    uint64
          |        |     +-- unit        unit
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             ...

Рисунок 9. Структура дерева данных о «трубе».


Труба клиентского домена DOTS определена как список ограничений на (входящий) трафик (total-pipe-capacity), который может пересылаться в домен по входящим каналам, каждый из которых указывается link-id [RFC8345].

Единицы, применяемые клиентом DOTS при передаче информации о трубе, указываются в атрибуте unit. Клиент DOTS должен автоматически приводить значения к соответствующим единицам. Т. е. для данного класса unit клиент DOTS использует наибольшую единицу измерения, дающую значение больше 1. Таким образом, разрешён лишь 1 класс unit.

7.2.1. Передача «ёмкости трубы» клиентского домена DOTS

Применимы соображения параграфа 7.1.2 с одним исключением.

Относительный порядок двух запросов PUT с атрибутами трубы клиентского домена DOTS от клиента DOTS определяется сравнением значений tsid. Если в двух запросах установки link-id и unit перекрываются, PUT с большим значением tsid будет иметь преимущество. Перекрывающиеся значения с меньшим tsid должны автоматически удаляться с утратой доступности.

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

Примечание. Это предполагает, что все сведения о каналах помещаются в одно сообщение.

Пример настройки сведений о каналах для однодомного домена DOTS показан на рисунке 10, где клиент передаёт запрос PUT (Рисунок 11) с ёмкостью канала link1, подключённого к его ISP.

    ,--,--,--.             ,--,--,--.
 ,-'          `-.       ,-'          `-.
(Клиентский домен)=====(     ISP#A      )
 `-.   DOTS   ,-'канал1 `-.          ,-'
    `--'--'--'             `--'--'--'

Рисунок 10. Однодомный клиентский домен DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=126"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "link1",
               "capacity": "500",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 11. Пример запроса PUT для передачи сведений о трубе (однодомной).


Клиентам DOTS можно задать указание совокупных сведений вместо отдельных каналов. Например, клиент с 2 каналами к восходящим ISP (Рисунок 12) может передать запрос PUT (Рисунок 13) для информирования сервера о суммарной пропускной способности каналов к ISP. Информирование об отдельных каналах определяет реализация.

    ,--,--,--.             ,--,--,--.
 ,-'          `-.===== ,-'          `-.
(Клиентский домен)    (     ISP#C      )
 `-.   DOTS   ,-'====== `-.          ,-'
    `--'--'--'             `--'--'--'

Рисунок 12. Клиентский домен DOTS с двумя соединительными каналами.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin"
   Uri-Path: "tsid=896"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "aggregate",
               "capacity": "700",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 13. Пример запроса PUT для передачи сведений о трубе (агрегат).


Рассмотрим клиентский домен DOTS подключенный к дополнительному ISP (например, ISP#B на рисунке 14). Клиент может информировать сервер DOTS, расположенный вне ISP#A и ISP#B о таком подключении, передавая запрос PUT, показанный на рисунке 15. Этот запрос включает сведения о канале link1, даже если этот канал не обновлён. При получении запроса сервер DOTS удалит запрос с tsid=126 и обновит конфигурацию, включив в неё link1 и link2.


   ,--,--,--.
 ,-'          `-.
(     ISP#B      )
 `-.          ,-'
    `--'--'--'
        ||
        || канал2
   ,--,--,--.             ,--,--,--.
 ,-'          `-.       ,-'         `-.
(Клиентский домен)=====(     ISP#A     )
 `-.   DOTS   ,-'канал1 `-.         ,-'
    `--'--'--'             `--'--'--'

Рисунок 14. Многодомный клиентский домен DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=127"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "link1",
               "capacity": "500",
               "unit": "megabit-ps"
             },
             {
               "link-id": "link2",
               "capacity": "500",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 15. Пример запроса PUT для передачи сведений о трубе (многодомный).


Клиент DOTS может исключить канал, передав запрос PUT с атрибутом capacity = 0, если для того же домена DOTS другие каналы сохраняются. Например, клиентский домен DOTS может сменить ISP и тогда клиент DOTS сообщает своему серверу DOTS об этом (например, смена конфигурации с рисунка 10 на конфигурацию с рисунка 16) в запросе PUT, показанном на рисунке 17. При получении этого запроса (если при его обработке не будет ошибок) сервер удалит канал link1 из своей конфигурации для этого клиентского домена DOTS. Отметим, что при получении сервером DOTS запроса PUT с capacity 0 для всех каналов он должен отклонить запрос с возвратом кода 4.00 (Bad Request). Для удаления всех каналов клиент DOTS может передать запрос DELETE (параграф 7.2.3).


   ,--,--,--.
 ,-'          `-.
(     ISP#B      )
 `-.          ,-'
    `--'--'--'
        ||
        || канал2
   ,--,--,--.  
 ,-'          `-.
(Клиентский домен)
 `-.   DOTS   ,-'
    `--'--'--' 

Рисунок 16. Однодомный клиентский домен DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=128"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "total-pipe-capacity": [
             {
               "link-id": "link1",
               "capacity": "0",
               "unit": "megabit-ps"
             },
             {
               "link-id": "link2",
               "capacity": "500",
               "unit": "megabit-ps"
             }
           ]
         }
       ]
     }
   }

Рисунок 17. Пример запроса PUT для передачи сведений о трубе (многодомный).


7.2.2. Извлечение сведений о ёмкости установленной трубы клиентского домена DOTS

Запрос GET с параметром Uri-Path tsid служит для извлечения конкретных сведений об установленной трубе клиентского домена DOTS в соответствии с процедурой, описанной в параграфе 7.1.3.

Для получения всех данных о трубе, связанных с клиентом DOTS клиент выполняет процедуру из параграфа 7.1.1.

7.2.3. Удаление установленной ёмкости трубы клиентского домена

Запрос DELETE служит для удаления конкретных сведений об установленной трубе клиентского домена DOTS по процедуре, описанной в параграфе 7.1.4.

7.3. Базовый уровень телеметрии

Клиент DOTS может сообщать серверам DOTS базовый уровень трафика и пропускную способность соединений.

Total traffic normal baseline – общий базовый уровень трафика

Данные о суммарном базовом уровне трафика обеспечивают значения процентилей, представляющие общий базовый уровень трафика. Их можно представить для цели с использованием total-traffic-normal.
Нормальный уровень трафика по протоколам (total-traffic-normal-per-protocol) представляется для цели и зависит от транспортного протокола.
Нормальный уровень трафика по номерам портов (total-traffic-normal-per-port) представляется для каждого порта, связанного с целью.
Если клиент DOTS согласует значения процентилей и единицы измерения (параграф 7.1), эти согласованные параметры применяются взамен принятых по умолчанию. Для каждого используемого класса единиц клиент DOTS должен обеспечивать автоматическое приведение к соответствующим единицам.

Total connection capacity – общая пропускная способность соединений

Если цель подвержена истощающим ресурсы DDoS-атакам, полезны указанные ниже атрибуты на уровне транспортного протокола для обнаружения таких DdoS-атак.
  • Максимальное число разрешённых для цели одновременных соединений.
  • Максимальное число разрешённых для цели одновременных соединений на клиента.
  • Максимальное число разрешённых для цели «эмбриональных» соединений. Этим термином обозначают соединения, в которых ещё не завершено согласование. Такие соединения возможны лишь в ориентированных на соединения протоколах, таких как TCP или (SCTP) [RFC9260].
  • Максимальное число разрешённых для цели «эмбриональных» соединений на клиента.
  • Максимальное число разрешённых для цели соединений в секунду.
  • Максимальное число разрешённых для цели соединений в секунду на клиента.
  • Максимальное число разрешённых для цели запросов (например, HTTP/DNS/SIP) в секунду.
  • Максимальное число разрешённых для цели запросов в секунду на клиента.
  • Максимальное число разрешённых для цели остающихся неполных запросов. Атаки на основе неполных запросов создают соединения с жертвой, но не передают полного запроса (например, HTTP).
  • Максимальное число разрешённых для цели остающихся неполных запросов на клиента.
Совокупные данные для транспортного протокола выражаются в total-connection-capacity, а возможности порта – в total-connection-capacity-per-port.

Отметим, что целевой ресурс указывается с использованием атрибутов target-prefix, target-port-range, target-protocol, target-fqdn, target-uri, alias-name, как указано в параграфе 4.4.1.1 [RFC9132].

Структура дерева для базового уровня трафика показана на рисунке 18.

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           +-- baseline* [id]
          |              +-- id                     uint32
          |              +-- target-prefix*
          |              |       inet:ip-prefix
          |              +-- target-port-range* [lower-port]
          |              |  +-- lower-port    inet:port-number
          |              |  +-- upper-port?   inet:port-number
          |              +-- target-protocol*                      uint8
          |              +-- target-fqdn*
          |              |       inet:domain-name
          |              +-- target-uri*
          |              |       inet:uri
          |              +-- alias-name*
          |              |       string
          |              +-- total-traffic-normal* [unit]
          |              |  +-- unit                 unit
          |              |  +-- low-percentile-g?    yang:gauge64
          |              |  +-- mid-percentile-g?    yang:gauge64
          |              |  +-- high-percentile-g?   yang:gauge64
          |              |  +-- peak-g?              yang:gauge64
          |              +-- total-traffic-normal-per-protocol*
          |              |       [unit protocol]
          |              |  +-- protocol             uint8
          |              |  +-- unit                 unit
          |              |  +-- low-percentile-g?    yang:gauge64
          |              |  +-- mid-percentile-g?    yang:gauge64
          |              |  +-- high-percentile-g?   yang:gauge64
          |              |  +-- peak-g?              yang:gauge64
          |              +-- total-traffic-normal-per-port* [unit port]
          |              |  +-- port                 inet:port-number
          |              |  +-- unit                 unit
          |              |  +-- low-percentile-g?    yang:gauge64
          |              |  +-- mid-percentile-g?    yang:gauge64
          |              |  +-- high-percentile-g?   yang:gauge64
          |              |  +-- peak-g?              yang:gauge64
          |              +-- total-connection-capacity* [protocol]
          |              |  +-- protocol                     uint8
          |              |  +-- connection?                  uint64
          |              |  +-- connection-client?           uint64
          |              |  +-- embryonic?                   uint64
          |              |  +-- embryonic-client?            uint64
          |              |  +-- connection-ps?               uint64
          |              |  +-- connection-client-ps?        uint64
          |              |  +-- request-ps?                  uint64
          |              |  +-- request-client-ps?           uint64
          |              |  +-- partial-request-max?         uint64
          |              |  +-- partial-request-client-max?  uint64
          |              +-- total-connection-capacity-per-port*
          |                      [protocol port]
          |                 +-- port
          |                 |       inet:port-number
          |                 +-- protocol                     uint8
          |                 +-- connection?                  uint64
          |                 +-- connection-client?           uint64
          |                 +-- embryonic?                   uint64
          |                 +-- embryonic-client?            uint64
          |                 +-- connection-ps?               uint64
          |                 +-- connection-client-ps?        uint64
          |                 +-- request-ps?                  uint64
          |                 +-- request-client-ps?           uint64
          |                 +-- partial-request-max?         uint64
          |                 +-- partial-request-client-max?  uint64
          +--:(telemetry)
             ...

Рисунок 18. Структура дерева базового уровня телеметрии.


Клиент DOTS может использовать один или несколько базовых уровней трафика (например, совокупный или по префиксам), каждый из которых указывается в клиентском домене DOTS идентификатором id, позволяющим обновить базовый уровень, удалить конкретную запись и т. п.

7.3.1. Передача сведений о базовом уровне клиентского домена DOTS

Здесь применимы соображения из параграфа 7.1.2 с одним исключением.

Относительный порядок двух запросов PUT с атрибутами базового уровня клиентского домена DOTS от клиента DOTS определяется сравнением значений tsid. Если в двух запросах установки цели перекрываются, PUT с большим значением tsid будет иметь преимущество. Перекрывающиеся значения с меньшим tsid должны автоматически удаляться с утратой доступности.

Два запроса PUT от клиента DOTS имеют перекрывающиеся цели если у них общие адреса или префиксы IP, FQDN, URI или псевдонимы. Кроме того, цели запросов PUT от клиента DOTS имеют пересекающиеся цели с точки зрения сервера DOTS, если адреса, связанные с FQDN, URI, псевдонимами перекрываются между собой или с target-prefix.

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

Если в запросе нет атрибута target это указывает применение данных о базовом уровне ко всему клиентскому домену.

Пример запроса PUT для передачи сведения о базовом уровне приведён на рисунке 19.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=129"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "baseline": [
             {
               "id": 1,
               "target-prefix": [
                 "2001:db8:6401::1/128",
                 "2001:db8:6401::2/128"
               ],
               "total-traffic-normal": [
                 {
                   "unit": "megabit-ps",
                   "peak-g": "60"
                 }
               ]
             }
           ]
         }
       ]
     }
   }

Рисунок 19. Запрос PUT для передачи сведений о базовом уровне DOTS.


Клиенты DOTS могут совместно использовать связанные с протоколом данные, как показано на рисунке 20.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tsid=130"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry-setup": {
       "telemetry": [
         {
           "baseline": [
             {
               "id": 1,
               "target-prefix": [
                 "2001:db8:6401::1/128",
                 "2001:db8:6401::2/128"
               ],
               "total-traffic-normal-per-protocol": [
                 {
                   "unit": "megabit-ps",
                   "protocol": 6,
                   "peak-g": "50"
                 },
                 {
                   "unit": "megabit-ps",
                   "protocol": 17,
                   "peak-g": "10"
                 }
               ]
             }
           ]
         }
       ]
     }
   }

Рисунок 20. Запрос PUT для передачи сведений о базовом уровне DOTS (2).


Сведения о базовом уровне трафика следует обновлять для отражения легитимных перегрузок (например, большое скопление людей), чтобы предотвратить ненужные «смягчения атак».

7.3.2. Получение сведений об установленном базовом уровне трафика

Запрос GET с параметром Uri-Path tsid служит для извлечения сведений об установленном в домене базовом уровне. Применяется такая же процедура, как описано а параграфе 7.1.3. Для получения сведений обо всех базовых уровнях, связанных с клиентом DOTS, клиент DOTS выполняет процедуру, описанную в параграфе 7.1.1.

7.3.3. Удаление установленных сведений о базовом уровне трафика

Запрос DELETE служит для удаления сведений об установленном в клиентском домене DOTS обычном уровне трафика. Процедура описана в параграфе 7.1.4.

7.4. Сброс установленной телеметрии

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm-setup"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

Рисунок 21. Удаление конфигурации телеметрии.


При загрузке (перезагрузке или ином событии, которое может изменить установки клиента DOTS) клиент может передать запрос DELETE для установки принятых по умолчанию значений параметров телеметрии. Такие запросы не включают параметр tsid. Пример запроса показан на рисунке 21.

7.5. Конфликт с другими клиентами DOTS из того же домена

Сервер DOTS может сталкиваться с конфликтами запросов, содержащих сведения о трубе или базовом уровне от разных клиентов одного клиентского домена DOTS. Для уведомления клиентов о конфликте применяется атрибут conflict-information, следуя рекомендациям по устранению конфликта, подобным описанным в параграфе 4.4.1 [RFC9132]. В качестве причины конфликта может быть указано одно из двух значений:

1 – перекрытие целей (параграф 4.4.1 в [RFC9132]);
5 – перекрытие области действия трубы (раздел 13).

8. Телеметрия DOTS до и во время смягчения атак

Имеется два обширных класса атак DDoS: атаки с расходом пропускной способности и ресурсов цели. В этом разделе описаны атрибуты телеметрии DOTS (параграф 8.1), охватывающие оба типа атак. Эти атрибуты предназначены для обеспечения полных сведений об атаках и различных аспектов, наиболее полно характеризующих атаки.

В модуле ietf-dots-telemetry (параграф 11.1) задана структура данных нового типа сообщений telemetry (Рисунок 22).

     structure dots-telemetry:
       +-- (telemetry-message-type)?
          +--:(telemetry-setup)
          |  ...
          |  +-- telemetry* []
          |     +-- (direction)?
          |     |  +--:(server-to-client-only)
          |     |     +-- tsid?                  uint32
          |     +-- (setup-type)?
          |        +--:(telemetry-config)
          |        |  ...
          |        +--:(pipe)
          |        |  ...
          |        +--:(baseline)
          |           ...
          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 22. Структура дерева типов сообщений.


Атрибуты телеметрии до и во время атаки указываются суффиксом пути /tm, который добавляется после префикса пути для формирования URI, применяемого с запросом CoAP для сигналов телеметрии DOTS. Атрибуты телеметрии pre-or-ongoing-mitigation, указанные в параграфе 8.1, могут передаваться между агентами DOTS и их могут передавать клиенты и серверы DOTS.

+-----------+                                         +-----------+
|Клиент DOTS|                                         |Сервер DOTS|
+-----------+                                         +-----------+
      |                                                     |
      |===============Запрос смягчения (mid)===============>|
      |                                                     |
      |=============Телеметрия (mid-list{mid})=============>|
      |                                                     |

Рисунок 23. Пример запроса сопоставления с использованием mid.


Агентам DOTS следует привязывать атрибуты pre-or-ongoing-mitigation к запросам на смягчение, связанным с атакованными ресурсами. В частности, запрос PUT после запроса смягчения может включать ссылку на запрос смягчения (mid-list) как показано на рисунке 23. Пример сопоставления запросов через target-prefix дан на рисунке 24.

Большинство данных телеметрии pre-or-ongoing-mitigation использует единицы измерения, относящиеся к классу unit, заданному процедурой, описанной в параграфе 7.1.2. При генерации данных телеметрии агент DOTS должен автоматически приводить данные к корректным единицам измерения.

+-----------+                                         +-----------+
|Клиент DOTS|                                         |Сервер DOTS|
+-----------+                                         +-----------+
      |                                                     |
      |<==============Телеметрия (target-prefix)============|
      |                                                     |
      |==========Запрос смягчения (target-prefix)==========>|
      |                                                     |

Рисунок 24. Пример запроса сопоставления с использованием target-prefix.


Агентам DOTS недопустимо передавать уведомления телеметрии pre-or-ongoing-mitigation одному партнёру чаще, чем 1 раз за telemetry-notify-interval (параграф 7.1). Если уведомление телеметрии передаётся в режиме подобном блочному (например,, [RFC9177]), этому правилу ограничения скорости недопустимо считать блоки отдельными сообщениями.

Запросы и отклики телеметрии DOTS до и во время смягчения атак должны помечаться как неподтверждаемые сообщения (параграф 2.1 в [RFC7252]).

8.1. Атрибуты телеметрии Pre-or-Ongoing-Mitigation

В разделе 3 описаны мотивы применения атрибутов телеметрии DOTS, описанных в последующих параграфах.

8.1.1. Цель

Ресурс target (Рисунок 25) идентифицируется с использованием атрибутов target-prefix, target-port-range, target-protocol, target-fqdn, target-uri, alias-name или указателя на запрос смягчения (mid-list).

          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  +-- target-prefix*       inet:ip-prefix
                |  +-- target-port-range* [lower-port]
                |  |  +-- lower-port    inet:port-number
                |  |  +-- upper-port?   inet:port-number
                |  +-- target-protocol*     uint8
                |  +-- target-fqdn*         inet:domain-name
                |  +-- target-uri*          inet:uri
                |  +-- alias-name*          string
                |  +-- mid-list*            uint32
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 25. Структура дерева цели.


В определении цели должен присутствовать хотя бы один из атрибутов target-prefix, target-fqdn, target-uri, alias-name, mid-list.

Если цель восприимчива к атакам на пропускную способность, включаются атрибуты, представляющие значения процентилей трафика атаки attack-id. Для целей, восприимчивых к DDoS-атакам с потреблением ресурсов, атаки можно представлять с помощью атрибутов, определённых в параграфе 8.1.4.

В сообщении телеметрии DOTS должен присутствовать хотя бы атрибут target и ещё один иной атрибут pre-or-ongoing-mitigation.

8.1.2. Суммарный трафик

Атрибут total-traffic (Рисунок 26) передаёт значения процентилей (включая пиковое и наблюдаемые в данный момент) для общего наблюдаемого трафика. Более детальные сведения о суммарном трафике можно передать в атрибутах total-traffic-protocol и total-traffic-port. Атрибут total-traffic-protocol представляет суммарный трафик для цели и зависит от транспортного протокола, атрибут total-traffic-port представляет суммарный трафик для номера порта цели.

          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-traffic-protocol* [unit protocol]
                |  +-- protocol             uint8
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-traffic-port* [unit port]
                |  +-- port                 inet:port-number
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 26. Структура дерева суммарного трафика.


8.1.3. Суммарный трафик атаки

Атрибут total-attack-traffic (Рисунок 27) указывает суммарный наблюдаемый трафик атаки. Более детальные сведения могут передавать атрибуты total-attack-traffic-protocol и total-attack-traffic-port. Атрибут total-attack-traffic-protocol представляет суммарный трафик атаки для цели и зависит от транспортного протокола, атрибут total-attack-traffic-port представляет суммарный трафик атаки для номера порта цели.

          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-traffic-protocol* [unit protocol]
                |  +-- protocol             uint8
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-traffic-port* [unit port]
                |  +-- port                 inet:port-number
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 27. Структура дерева суммарного трафика атаки.


8.1.4. Суммарные соединения атаки

Если цель восприимчива к DDoS-атакам на поглощение ресурсов, атрибут total-attack-connection-protocol служит для передачи значений процентилей (включая пиковое и наблюдаемые текущие значения) различных атрибутов, связанных с общим числом соединений атаки. Ниже перечислены субатрибуты для цели по транспортным протоколам, представляющие характеристики атаки.

  • Число одновременных соединений с целью.
  • Число одновременных эмбриональных соединений с целью.
  • Число соединений с целью за секунду.
  • Число запросов для цели за секунду.
  • Число неполных запросов для цели.
          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  +-- protocol              uint8
                |  +-- connection-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- embryonic-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- connection-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- request-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- partial-request-c
                |     +-- low-percentile-g?    yang:gauge64
                |     +-- mid-percentile-g?    yang:gauge64
                |     +-- high-percentile-g?   yang:gauge64
                |     +-- peak-g?              yang:gauge64
                |     +-- current-g?           yang:gauge64
                +-- total-attack-connection-port* [protocol port]
                |  +-- protocol              uint8
                |  +-- port                  inet:port-number
                |  +-- connection-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- embryonic-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- connection-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- request-ps-c
                |  |  +-- low-percentile-g?    yang:gauge64
                |  |  +-- mid-percentile-g?    yang:gauge64
                |  |  +-- high-percentile-g?   yang:gauge64
                |  |  +-- peak-g?              yang:gauge64
                |  |  +-- current-g?           yang:gauge64
                |  +-- partial-request-c
                |     +-- low-percentile-g?    yang:gauge64
                |     +-- mid-percentile-g?    yang:gauge64
                |     +-- high-percentile-g?   yang:gauge64
                |     +-- peak-g?              yang:gauge64
                |     +-- current-g?           yang:gauge64
                +-- attack-detail* [vendor-id attack-id]
                   ...

Рисунок 28. Структура дерева соединений атаки.


Общее число соединений на порт представляется атрибутом total-attack-connection-port.

8.1.5. Детали атаки

Этот атрибут (Рисунок 29) служит для передачи подробных характеристик атаки. Субатрибуты происходящих атак перечислены ниже.

vendor-id

Идентификатор производитель (систем защиты) в форме номера предприятия из реестра IANA Private Enterprise Numbers [Private-Enterprise-Numbers].

attack-id

Уникальный идентификатор, присвоенный атаке производителем. Этот параметр должен присутствовать независимо от наличия attack-description.

description-lang

Указывает тег языка, используемого в тексте атрибута attack-description. Кодирование атрибута определяется правилами параграфа 2.1 в [RFC5646]. По умолчанию применяется кодировка en-US.

attack-description

Текстовое описание атаки, относящееся скорее к классу атак, нежели к конкретному экземпляру. Методы обработки естественных языков (например, встраивание слов) могут оказаться полезными для сопоставления описания атаки с её типом. Текстовое представление атаки решает две задачи, избавляя от необходимости (a) создавать вручную таблицы сопоставления между производителями и (b) стандартизировать типы атак, которые со временем меняются.

attack-severity

Уровень серьёзности атаки (значения определены в параграфе 3.12.2 [RFC7970]).

start-time

Время начала атаки в секундах с 1970-01-01T00:00Z (параграф 3.4.2 в [RFC8949]). Кодирование CBOR изменено и ведущий тег 1 (дата и время на основе эпохи) должен быть опущен.

end-time

Время завершения атаки в секундах с 1970-01-01T00:00Z (параграф 3.4.2 в [RFC8949]). Кодирование CBOR изменено и ведущий тег 1 (дата и время на основе эпохи) должен быть опущен.

source-count

Цисло источников, вовлечённых в нацеленную на жертву атаку.

top-talker

Список источников, вовлечённых в атаку и генерирующих важную часть трафика атаки. Источники представляются с помощью source-prefix.
Атрибут spoofed-status указывает, использует ли источник фиктивный адрес IP (например, в атаке с отражением). Если узел spoofed-status не включён, это означает, что статус подмены адреса не известен.
Если цель подвергается атаке на поглощение пропускной способности, включается статистический профиль атаки для каждого из основных участников (total-attack-traffic, см. параграф 8.1.3).
Если цель подвергается DDoS-атаке на поглощение ресурсов, применимы заданные в параграфе 8.1.4 атрибуты для характеризации по участникам атаки.
          +--:(telemetry)
             +-- pre-or-ongoing-mitigation* []
                +-- (direction)?
                |  +--:(server-to-client-only)
                |     +-- tmid?                      uint32
                +-- target
                |  ...
                +-- total-traffic* [unit]
                |  ...
                +-- total-traffic-protocol* [unit protocol]
                |  ...
                +-- total-traffic-port* [unit port]
                |  ...
                +-- total-attack-traffic* [unit]
                |  ...
                +-- total-attack-traffic-protocol* [unit protocol]
                |  ...
                +-- total-attack-traffic-port* [unit port]
                |  ...
                +-- total-attack-connection-protocol* [protocol]
                |  ...
                +-- total-attack-connection-port* [protocol port]
                |  ...
                +-- attack-detail* [vendor-id attack-id]
                   +-- vendor-id             uint32
                   +-- attack-id             uint32
                   +-- description-lang?     string
                   +-- attack-description?   string
                   +-- attack-severity?      attack-severity
                   +-- start-time?           uint64
                   +-- end-time?             uint64
                   +-- source-count
                   |  +-- low-percentile-g?    yang:gauge64
                   |  +-- mid-percentile-g?    yang:gauge64
                   |  +-- high-percentile-g?   yang:gauge64
                   |  +-- peak-g?              yang:gauge64
                   |  +-- current-g?           yang:gauge64
                   +-- top-talker
                      +-- talker* [source-prefix]
                         +-- spoofed-status?            boolean
                         +-- source-prefix              inet:ip-prefix
                         +-- source-port-range* [lower-port]
                         |  +-- lower-port    inet:port-number
                         |  +-- upper-port?   inet:port-number
                         +-- source-icmp-type-range* [lower-type]
                         |  +-- lower-type    uint8
                         |  +-- upper-type?   uint8
                         +-- total-attack-traffic* [unit]
                         |  +-- unit                 unit
                         |  +-- low-percentile-g?    yang:gauge64
                         |  +-- mid-percentile-g?    yang:gauge64
                         |  +-- high-percentile-g?   yang:gauge64
                         |  +-- peak-g?              yang:gauge64
                         |  +-- current-g?           yang:gauge64
                         +-- total-attack-connection-protocol*
                                 [protocol]
                            +-- protocol              uint8
                            +-- connection-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- embryonic-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- connection-ps-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- request-ps-c
                            |  +-- low-percentile-g?    yang:gauge64
                            |  +-- mid-percentile-g?    yang:gauge64
                            |  +-- high-percentile-g?   yang:gauge64
                            |  +-- peak-g?              yang:gauge64
                            |  +-- current-g?           yang:gauge64
                            +-- partial-request-c
                               +-- low-percentile-g?    yang:gauge64
                               +-- mid-percentile-g?    yang:gauge64
                               +-- high-percentile-g?   yang:gauge64
                               +-- peak-g?              yang:gauge64
                               +-- current-g?           yang:gauge64

Рисунок 29. Структура дерева деталей атаки.


Для оптимизации размера сообщений телеметрии в сигнальном канале DOTS агенты DOTS могут применять канал данных DOTS [RFC8783] при обмене зависящими от производителей деталями атак (т. е. {vendor identifier, attack identifier} ==> текстовое описание атаки). Таким образом, агенты DOTS не передают систематически описаний атаки в сообщениях телеметрии по сигнальному каналу DOTS.

8.1.6. Отображения атак

Можно использовать несколько отображений для разных идентификаторов производителей – агент DOTS, передающий данные телеметрии, может выбрать для использования одно или несколько отображений даже в одном сообщении.

Примечание. Сервер DOTS может использовать несколько средств смягчения атак от разных производителей. Способы обмена телеметрическими данными и отображениями производителей между серверами и средствами смягчения DOTS выходят за рамки этого документа.

У клиентов и серверов DOTS могут быть отображения от разных производителей и свои наборы отображений атак. Агент DOTS должен воспринимать данные телеметрии с идентификаторами производителя, отличными от тех, которые он принимает для передачи данных телеметрии. Кроме того, клиент и сервер DOTS могут иметь средства от одного производителя, но с разными выпусками таблиц отображения. Клиенту DOTS следует передавать данные телеметрии с использованием любых отображений производителя, которые он предоставил серверу (например, в запросе POST, показанном на рисунке 30), а серверу DOTS следует использовать предоставленные клиенту DOTS отображения производителя при передаче данных телеметрии партнёрскому агенту DOTS.

   POST /restconf/data/ietf-dots-data-channel:dots-data\
        /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json

   {
     "ietf-dots-mapping:vendor-mapping": {
       "vendor": [
         {
           "vendor-id": 345,
           "vendor-name": "mitigator-c",
           "last-updated": "1629898958",
           "attack-mapping": [
             {
               "attack-id": 1,
               "attack-description":
                  "Описание атаки"
             },
             {
               "attack-id": 2,
               "attack-description":
                  "Описание атаки"
             }
           ]
         }
       ]
     }
   }

Рисунок 30. POST для установки деталей Vendor Attack Mapping.


Модуль YANG ietf-dots-mapping, определённый в параграфе 11.2, дополняет модуль ietf-dots-data-channel [RFC8783]. Структура ietf-dots-mapping показана на рисунке 31.

   module: ietf-dots-mapping
     augment /data-channel:dots-data/data-channel:dots-client:
       +--rw vendor-mapping {dots-telemetry}?
          +--rw vendor* [vendor-id]
             +--rw vendor-id         uint32
             +--rw vendor-name?      string
             +--rw description-lang?   string
             +--rw last-updated      uint64
             +--rw attack-mapping* [attack-id]
                +--rw attack-id             uint32
                +--rw attack-description    string
     augment /data-channel:dots-data/data-channel:capabilities:
       +--ro vendor-mapping-enabled?   boolean {dots-telemetry}?
     augment /data-channel:dots-data:
       +--ro vendor-mapping {dots-telemetry}?
          +--ro vendor* [vendor-id]
             +--ro vendor-id         uint32
             +--ro vendor-name?      string
             +--ro description-lang?   string
             +--ro last-updated      uint64
             +--ro attack-mapping* [attack-id]
                +--ro attack-id             uint32
                +--ro attack-description    string

Рисунок 31. Структура дерева Vendor Attack Mapping.


Клиент DOTS передаёт запрос GET по каналу данных DOTS для получения списка поддерживаемых сервером DOTS возможностей, как указано в параграфе 7.1 [RFC8783]. Этот запрос позволяет проверить, поддерживает ли сервер совместное использование деталей отображения атак от производителя (проверка vendor-mapping-enabled).

Если vendor-mapping-enabled имеет значение true, клиент DOTS может передавать запрос GET для получения от сервера деталей отображения атак. Пример такого запроса GET представлен на рисунке 32.

   GET /restconf/data/ietf-dots-data-channel:dots-data\
       /ietf-dots-mapping:vendor-mapping HTTP/1.1
   Host: example.com
   Accept: application/yang-data+json

Рисунок 32. GET для получения Vendor Attack Mapping от сервера DOTS.


Клиент DOTS может извлечь лишь список производителей, поддерживаемых сервером DOTS, устанавливая для параметра depth (параграф 4.8.2 в [RFC8040]) значение 3 в запросе GET, как показано на рисунке 33. Пример тела отклика сервера DOTS на такой запрос приведён на рисунке 34. GET /restconf/data/ietf-dots-data-channel:dots-data\ /ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1 Host: example.com Accept: application/yang-data+json

Рисунок 33. GET для извлечения Vendors List, используемого сервером DOTS.

  {
     "ietf-dots-mapping:vendor-mapping": {
       "vendor": [
         {
           "vendor-id": 32473,
           "vendor-name": "mitigator-s",
           "last-updated": "1629898758",
           "attack-mapping": []
         }
       ]
     }
   }

Рисунок 34. Тело отклика на запрос GET для Vendors List.


Клиент DOTS регулярно (например, каждую неделю) повторяет процедуру обновления отображений атак производителями с сервера DOTS.

Если клиент DOTS видит, что у сервера DOTS нет ссылок на детали конкретного отображения атак, он использует запрос POST для установки своего отображения атак от производителя. Пример такого запроса показан на рисунке 30.

Сервер DOTS указывает результат обработки запроса POST в строке состояния. Если сервер воспринимает предложенное в запросе отображение, он должен возвращать строку «201 Created». Если в запросе нет обязательного атрибута или имеется недействительный или неизвестный параметр, сервер должен возвращать в отклике строку «400 Bad Request», устанавливая тег ошибки missing-attribute, invalid-value или unknown-element.

Если запрос получен через шлюз серверного домена DOTS, а сервер DOTS не поддерживает указанное значение cdid тогда как cuid ожидается, сервер должен вернуть строку «403 Forbidden» с тегом ошибки access-denied. При получении такого отклика клиент DOTS должен зарегистрироваться (параграф 5.1 в [RFC8783]).

Клиент DOTS использует запрос PUT для обновления деталей отображения атак от производителя на сервере DOTS (например, для добавления нового или обновления имеющегося отображения). Клиент DOTS использует запрос GET для получения дателей отображения атак от производителей на сревере (Рисунок 35).

   GET /restconf/data/ietf-dots-data-channel:dots-data\
       /dots-client=dz6pHjaADkaFTbjr0JGBpw\
       /ietf-dots-mapping:vendor-mapping?\
       content=all HTTP/1.1
   Host: example.com
   Accept: application/yang-data+json

Рисунок 35. GET для извлечения Installed Vendor Attack Mapping Details.


При передаче деталей атак в сообщениях телеметрии DOTS (параграфы 8.2, 8.3 и раздел 9) агентам DOTS недопустимо включать атрибут attack-description, если соответствующие детали отображения атак ранее не были обобщены с партнерским агентом DOTS.

8.2. От клиентов к серверам DOTS

Клиенты DOTS применяют запрос PUT (Рисунок 36) для передачи телеметрии pre-or-ongoing-mitigation серверам DOTS.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=123"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry": {
       "pre-or-ongoing-mitigation": [
         {
           "target": {
             "target-prefix": [
               "2001:db8::1/128"
             ]
           },
           "total-attack-traffic-protocol": [
             {
               "protocol": 17,
               "unit": "megabit-ps",
               "mid-percentile-g": "900"
             }
           ],
           "attack-detail": [
             {
               "vendor-id": 32473,
               "attack-id": 77,
               "start-time": "1608336568",
               "attack-severity": "high"
             }
           ]
         }
       ]
     }
   }

Рисунок 36. PUT для отправки телеметрии до и во время смягчения атак.


Параметр cuid является обязательным в Uri-Path запросов PUT.

Ниже приведено определение дополнительного параметра Uri-Path.

tmid

Идентификатор телеметрии (Telemetry Identifier) служит для представления данных телеметрии DOTS до и во время смягчения атак целым числом и должен создаваться клиентами DOTS. Значения tmid должны монотонно возрастать по мере необходимости передачи клиентом новых данных телеметрии pre-or-ongoing-mitigation.
При достижении максимального значения (rollover) параметра tmid должна применяться процедура, заданная в параграфе 4.4.1 [RFC9132] для параметра mid.
Этот атрибут является обязательным и должен размещаться в опциях Uri-Path после атрибута cuid.

Атрибуты cuid и tmid недопустимо включать в тело запросов PUT.

В запросе PUT должен присутствовать хотя бы один атрибут target и иной атрибут pre-or-ongoing-mitigation (параграф 8.1). При наличии лишь атрибута target, запрос обрабатывается в соответствии с параграфом 8.3.

Относительный порядов пары запросов PUT с телеметрией pre-or-ongoing-mitigation от клиента DOTS определяется сравнением значений tmid. Если в двух запросах перекрываются атрибуты target, преимущество имеет запрос с большим tmid, а запрос с меньшим tmid должен автоматически удаляться, теряя доступность.

Сервер DOTS указывает результат обработки запроса PUT кодом отклика CoAP. В частности, возвращается код 2.04 (Changed), если сервер воспринял телеметрию pre-or-ongoing-mitigation. При возникновении ошибки на сервере возвращается код 5.03 (Service Unavailable) с использованием опции Max-Age для указания числа секунд, по истечении которых можно повторить запрос.

Продолжительность поддержки сервером DOTS активности tmid или регистрации вложенных данных телеметрии зависит от реализации. Если идентификатор tmid остаётся активным, данные журнала обновляются сервером DOTS в зависимости от полученных от клиента-партнера сведений.

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=123"

Рисунок 37. Удаление конкретных данных телеметрии Pre-or-Ongoing-Mitigation.


Клиент DOTS, который потерял статус своих активных tmid или должен сбросить tmid в 0 (например, при аварии или перезапуске) должен передать запрос GET серверам DOTS для получения списка активных tmid. Затем клиент DOTS может удалить tmid, которым больше не нужно быть активными (Рисунок 37). Передача запроса DELETE без tmid указывает, что нужно деактивировать все tmid (Рисунок 38).

   Header: DELETE (Code=0.04)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

Рисунок 38. Удаление всех данных телеметрии Pre-or-Ongoing-Mitigation.


8.3. От серверов DOTS к клиентам

Данные pre-or-ongoing-mitigation (в частности, детали атаки) могут передаваться от серверов DOTS клиентам. Например, сервер DOTS, размещённый вместе с детектором DDoS, может вести мониторинг целевых сетей и обнаруживать DDoS-атаки путём статистического анализа или глубокого изучения, сообщая детали атак клиентам DOTS. Клиент может использовать эти сведения для решения вопроса о потребности в смягчении атак. Кроме того, персонал служб безопасности клиентских доменов DOTS может применять детали атак для определения стратегии защиты и выбора подходящего сервера DOTS для ослабления атаки.

Для получения уведомлений телеметрии до и во время смягчения от сервера DOTS клиент DOTS должен передать запрос PUT (затем GET) с фильтром цели. Пример такого запроса PUT показан на рисунке 39. Чтобы не поддерживать длинный список таких запросов, клиентам DOTS рекомендуется включать в один запрос все цели (в предположении, что эти сведения помещаются в одну дейтаграмму). Серверам DOTS можно задать ограничение числа запросов pre-or-ongoing-mitigation на клиентский домен DOTS. Запросы pre-or-ongoing-mitigation должны поддерживаться в активном состоянии сервером DOTS до получения от того же клиента DOTS запроса DELETE, отменяющего эту телеметрию pre-or-ongoing-mitigation, или пока клиент DOTS не будет сочтён неактивным (см., например, параграф 3.5 в [RFC8783]).

Относительный порядов пары запросов PUT для телеметрии pre-or-ongoing-mitigation от клиента DOTS определяется сравнением значений tmid. Если в двух запросах перекрываются атрибуты target, преимущество имеет запрос с большим tmid, а запрос с меньшим tmid должен автоматически удаляться, теряя доступность.

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=567"
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-telemetry:telemetry": {
       "pre-or-ongoing-mitigation": [
         {
           "target": {
             "target-prefix": [
               "2001:db8::/32"
             ]
           }
         }
       ]
     }
   }

Рисунок 39. PUT для запроса телеметрии Pre-or-Ongoing-Mitigation.


Клиенты DOTS из одного домена могут запросить получение телеметрии pre-or-ongoing-mitigation, привязанной к одной цели, без возникновения «перекрытий» и конфликтов.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "tmid=567"
   Observe: 0

Рисунок 40. GET для подписки на асинхронные уведомления телеметрии для tmid.


После успешного выполнения запроса PUT для создания статуса запроса на сервере клиент DOTS передаёт запрос GET для получения обновлений телеметрии. Клиент использует опцию Observe = 0 (регистрация) в запросе GET для получения асинхронных уведомлений с данными телеметрии до и во время смягчения атак от сревреа DOTS. Запрос GET может указывать конкретное значение tmid (Рисунок 40) или не включать tmid (Рисунок 41) для получения обновления по всем запросам от этого клиента.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Observe: 0

Рисунок 41. GET для подписки на асинхронные уведомления телеметрии для всех tmid.


Клиент DOTS может задать фильтр для запроса части асинхронных уведомлений от сервера DOTS, включив одну или несколько опций Uri-Query в свой запрос GET. Опция Uri-Query может включать параметры target-prefix, target-port, target-protocol, target-fqdn, target-uri, alias-name, mid и c (content – содержимое) (параграф 5.4).

  • При наличии в запросе нескольких опций Uri-Query они интерпретируются так же, как при включении нескольких атрибутов target в тело сообщения (параграф 4.4.1 в [RFC9132]).

  • Если в запрос включается несколько значений параметра, эти значения должны размещаться в одной опции Uri-Query через запятую без пробелов.

  • Диапазоны значений (непрерывный блок с включением границ) можно применять в параметрах target-port, target-protocol и mid, указывая границы через дефис (-).

  • Шаблоны имён (левая часть имени заменена символом *) можно включать в параметры target-fqdn и target-uri. Клиентам DOTS недопустимо указывать шаблоны, где символ * не является первым. Примером корректного шаблона служит *.example.com и такие шаблоны можно включать в параметр target-fqdn опции Uri-Query.

Клиенты DOTS могут также филтровать асинхронные уведомления от сервера DOTS, указывая информацию о конкретном источнике атаки с помощью атрибутов source-prefix, source-port, source-icmp-type в опции Uri-Query. Здесь применяется такой же подход (диапазоны, множество значений) как для атрибутов цели. При использовании этих фильтров следует соблюдать особую осторожность, поскольку фильтры могут скрывать некоторые атаки от запрашивающего клиента DOTS (например, при смене информации об источнике атаки).

Запросы с недействительными (например, не поддерживаемыми или некорректно сформированными) типами сервер DOTS должен отвергать с кодом 4.00 (Bad Request).

Пример запроса подписки на асинхронные уведомления, относящиеся к трафику UDP, показан на рисунке 42. Этот фильтр применяется для всех tmid.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "tm"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Query: "target-protocol=17"
   Observe: 0

Рисунок 42. GET для получения асинхронных уведомлений с фильтром Uri-Query.


Сервер DOTS будет передавать асинхронные уведомления клиентам DOTS при обнаружении связанных с атакой событий, следуя процедурам, подобным описанным в параграфе 4.4.2.1 [RFC9132]. Пример асинхронного уведомления телеметрии pre-or-ongoing-mitigation показан на рисунке 43.

   {
     "ietf-dots-telemetry:telemetry": {
       "pre-or-ongoing-mitigation": [
         {
           "tmid": 567,
           "target": {
             "target-prefix": [
               "2001:db8::1/128"
             ]
           },
           "target-protocol": [
             17
           ],
           "total-attack-traffic": [
             {
               "unit": "megabit-ps",
               "mid-percentile-g": "900"
             }
           ],
           "attack-detail": [
             {
               "vendor-id": 32473,
               "attack-id": 77,
               "start-time": "1618339785",
               "attack-severity": "high"
             }
           ]
         }
       ]
     }
   }

Рисунок 43. Тело уведомления телеметрии Pre-or-Ongoing-Mitigation от сервера DOTS.


Сервер DOTS передаёт совокупные данные для цели, используя атрибут total-attack-traffic. Агрегирование предполагает применение для цели фильтров Uri-Query. Сервер DOTS при необходимости может включить более подробные сведения (т. е. total-attack-traffic-protocol и total-attack-traffic-port). Если в запрос включён фильтр по протоколу (или порту), применяется total-attack-traffic-protocol (или total-attack-traffic-port).

Сервер DOTS может агрегировать данные pre-or-ongoing-mitigation (например, top-talker) для всех целей домена или (когда это задано) передавать конкретные сведения (например, top-talker) для указанной цели.

Клиент DOTS может регистрировать данные телеметрии pre-or-ongoing-mitigation с передачей сигналов администратору или сетевому контроллеру. Клиент DOTS может передавать запросы на смягчение, если атаку не удаётся обработать локально. Клиент DOTS, не заинтересованный в телеметрии pre-or-ongoing-mitigation, передаёт запрос DELETE, подобно показанному на рисунке 37 запросу DELETE.

9. Обновление статуса телеметрии смягчения DOTS

9.1. От клиентов к серверам DOTS – телеметрия эффективности смягчения

Атрибуты телеметрии эффективности смягчения атак могут передаваться серверам от клиентов DOTS как часть периодических обновления эффективности смягчения, отправляемых серверу (параграф 4.4.3 в [RFC9132]).

Total attack traffic – суммарный трафик атаки

Суммарный трафик с точки зрения клиента DOTS в процессе смягчения атаки (см. Рисунок 27).

Attack details – детали атаки

Детали атаки с точки зрения клиента DOTS в процессе смягчения атаки (см. параграф 8.1.5).

Модуль YANG ietf-dots-telemetry (параграф 11.1) дополняет тип mitigation-scope из модуля ietf-dots-signal-channel [RFC9132], чтобы клиент DOTS мог передавать эти атрибуты в обновлениях эффективности смягчения (Рисунок 44).

     augment-structure /dots-signal:dots-signal/dots-signal:message-type
                       /dots-signal:mitigation-scope/dots-signal:scope:
       +-- total-attack-traffic* [unit]
       |  +-- unit                 unit
       |  +-- low-percentile-g?    yang:gauge64
       |  +-- mid-percentile-g?    yang:gauge64
       |  +-- high-percentile-g?   yang:gauge64
       |  +-- peak-g?              yang:gauge64
       |  +-- current-g?           yang:gauge64
       +-- attack-detail* [vendor-id attack-id]
          +-- vendor-id             uint32
          +-- attack-id             uint32
          +-- attack-description?   string
          +-- attack-severity?      attack-severity
          +-- start-time?           uint64
          +-- end-time?             uint64
          +-- source-count
          |  +-- low-percentile-g?    yang:gauge64
          |  +-- mid-percentile-g?    yang:gauge64
          |  +-- high-percentile-g?   yang:gauge64
          |  +-- peak-g?              yang:gauge64
          |  +-- current-g?           yang:gauge64
          +-- top-talker
             +-- talker* [source-prefix]
                +-- spoofed-status?            boolean
                +-- source-prefix              inet:ip-prefix
                +-- source-port-range* [lower-port]
                |  +-- lower-port    inet:port-number
                |  +-- upper-port?   inet:port-number
                +-- source-icmp-type-range* [lower-type]
                |  +-- lower-type    uint8
                |  +-- upper-type?   uint8
                +-- total-attack-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-connection
                   +-- connection-c
                   |  +-- low-percentile-g?    yang:gauge64
                   |  +-- mid-percentile-g?    yang:gauge64
                   |  +-- high-percentile-g?   yang:gauge64
                   |  +-- peak-g?              yang:gauge64
                   |  +-- current-g?           yang:gauge64
                   +-- embryonic-c
                   |  ...
                   +-- connection-ps-c
                   |  ...
                   +-- request-ps-c
                   |  ...
                   +-- partial-request-c
                      ...

Рисунок 44. Структура дерева обновления эффективности телеметрии.


Для передачи данных телеметрии в обновлениях эффективности смягчения атаки рекомендуется, чтобы клиент DOTS уже организовал сессию установки телеметрии DOTS с сервером в период «бездействия». Эта сессия предназначена в первую очередь для оценки поддержки партнёром DOTS расширений телеметрии и, таким образом, предотвращения отказов при обработке сообщений (параграф 3.1 в [RFC9132]).

   Header: PUT (Code=0.03)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "mitigate"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "mid=123"
   If-Match:
   Content-Format: "application/dots+cbor"

   {
     "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
         {
           "alias-name": [
             "https1",
             "https2"
           ],
           "attack-status": "under-attack",
           "ietf-dots-telemetry:total-attack-traffic": [
             {
               "unit": "megabit-ps",
               "mid-percentile-g": "900"
             }
           ]
         }
       ]
     }
   }

Рисунок 45. Пример обновления эффективности телеметрии с атрибутами телеметрии.


Пример обновления эффективности смягчения с атрибутами телеметрии показан на рисунке 45.

9.2. От серверов к клиентам – атрибуты телеметрии статуса смягчения DOTS

Атрибуты телеметрии статуса смягчения атак могут передаваться от сервера DOTS клиентам как часть периодического обновления статуса смягчения (параграф 4.4.2 в [RFC9132]). В частности, клиенты DOTS могут получать асинхронные уведомления о деталях атаки от сервера с использованием опции Observe, определённой в [RFC7641]. Для использования этой возможности клиенты DOTS должны организовать сеанс телеметрии с сервером в состоянии «бездействия» и должны установить для атрибута server-originated-telemetry значение true. Серверам DOTS недопустимо включать атрибуты в обновления статуса смягчения для клиентов DOTS в сессиях телеметрии, где для server-originated-telemetry задано значение false.

Как задано в [RFC8612], фактические действия по смягчению атак могут включать несколько мер противодействия. Сервер DOTS передаёт текущий статус соответствующих мер и может включать список обнаруженных атак. Атрибуты, заданные в параграфе 8.1.5, применимы к описанию атак, обнаруженных и смягчаемых в домене сервера DOTS.

Модуль YANG ietf-dots-telemetry (параграф 11.1) дополняет тип сообщений mitigation-scope из модуля ietf-dots-signal-channel [RFC9132] данными телеметрии, как показано на рисунке 46.

     augment-structure /dots-signal:dots-signal/dots-signal:message-type
                       /dots-signal:mitigation-scope/dots-signal:scope:
       +-- (direction)?
       |  +--:(server-to-client-only)
       |     +-- total-traffic* [unit]
       |     |  +-- unit                 unit
       |     |  +-- low-percentile-g?    yang:gauge64
       |     |  +-- mid-percentile-g?    yang:gauge64
       |     |  +-- high-percentile-g?   yang:gauge64
       |     |  +-- peak-g?              yang:gauge64
       |     |  +-- current-g?           yang:gauge64
       |     +-- total-attack-connection
       |        +-- connection-c
       |        |  +-- low-percentile-g?    yang:gauge64
       |        |  +-- mid-percentile-g?    yang:gauge64
       |        |  +-- high-percentile-g?   yang:gauge64
       |        |  +-- peak-g?              yang:gauge64
       |        |  +-- current-g?           yang:gauge64
       |        +-- embryonic-c
       |        |  ...
       |        +-- connection-ps-c
       |        |  ...
       |        +-- request-ps-c
       |        |  ...
       |        +-- partial-request-c
       |           ...
       +-- total-attack-traffic* [unit]
       |  +-- unit                 unit
       |  +-- low-percentile-g?    yang:gauge64
       |  +-- mid-percentile-g?    yang:gauge64
       |  +-- high-percentile-g?   yang:gauge64
       |  +-- peak-g?              yang:gauge64
       |  +-- current-g?           yang:gauge64
       +-- attack-detail* [vendor-id attack-id]
          +-- vendor-id             uint32
          +-- attack-id             uint32
          +-- attack-description?   string
          +-- attack-severity?      attack-severity
          +-- start-time?           uint64
          +-- end-time?             uint64
          +-- source-count
          |  +-- low-percentile-g?    yang:gauge64
          |  +-- mid-percentile-g?    yang:gauge64
          |  +-- high-percentile-g?   yang:gauge64
          |  +-- peak-g?              yang:gauge64
          |  +-- current-g?           yang:gauge64
          +-- top-talker
             +-- talker* [source-prefix]
                +-- spoofed-status?            boolean
                +-- source-prefix              inet:ip-prefix
                +-- source-port-range* [lower-port]
                |  +-- lower-port    inet:port-number
                |  +-- upper-port?   inet:port-number
                +-- source-icmp-type-range* [lower-type]
                |  +-- lower-type    uint8
                |  +-- upper-type?   uint8
                +-- total-attack-traffic* [unit]
                |  +-- unit                 unit
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- total-attack-connection
                   +-- connection-c
                   |  +-- low-percentile-g?    yang:gauge64
                   |  +-- mid-percentile-g?    yang:gauge64
                   |  +-- high-percentile-g?   yang:gauge64
                   |  +-- peak-g?              yang:gauge64
                   |  +-- current-g?           yang:gauge64
                   +-- embryonic-c
                   |  ...
                   +-- connection-ps-c
                   |  ...
                   +-- request-ps-c
                   |  ...
                   +-- partial-request-c
                      ...

Рисунок 46. Структура дерева телеметрии статуса смягчения от сервера к клиенту.


На рисунке 47 приведён пример асинхронного уведомления о статусе смягчения атак от сервера DOTS. Это уведомления содержит значение mid-percentile трафика обрабатываемой атаки и пиковые значения уникальных участников атаки.

   {
     "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
         {
           "mid": 12332,
           "mitigation-start": "1507818434",
           "alias-name": [
             "https1",
             "https2"
           ],
           "lifetime": 1600,
           "status": "attack-successfully-mitigated",
           "bytes-dropped": "134334555",
           "bps-dropped": "43344",
           "pkts-dropped": "333334444",
           "pps-dropped": "432432",
           "ietf-dots-telemetry:total-attack-traffic": [
             {
               "unit": "megabit-ps",
               "mid-percentile-g": "752"
             }
           ],
           "ietf-dots-telemetry:attack-detail": [
             {
               "vendor-id": 32473,
               "attack-id": 77,
               "source-count": {
                 "peak-g": "12683"
               }
             }
           ]
         }
       ]
     }
   }

Рисунок 47. Тело отклика со статусом смягчения и атрибутами телеметрии.


Клиенты DOTS могут фильтровать асинхронные уведомления от сервера DOTS, указывая опцию Uri-Query в запросе GET. Опция Uri-Query может включать параметры target-prefix, target-port, target-protocol, target-fqdn, target-uri, alias-name, c (content) (параграф 5.4). Должны применяться приведённые в параграфе 8.3 соображения в части включения нескольких значений, диапазонов (target-port, target-protocol) и шаблонов (target-fqdn, target-uri). Пример запроса подписки на асинхронные уведомления для псевдонима https1 приведён на рисунке 48.

   Header: GET (Code=0.01)
   Uri-Path: ".well-known"
   Uri-Path: "dots"
   Uri-Path: "mitigate"
   Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
   Uri-Path: "mid=12332"
   Uri-Query: "target-alias=https1"
   Observe: 0

Рисунок 48. GET для получения асинхронных уведомлений с фильтром Uri-Query.


Если запрос не соответствует цели встроенного mid на сервере DOTS, сервер должен возвращать отклик 4.04 (Not Found). Серверу DOTS недопустимо добавлять новую запись Observe, если запрос перекрывается с имеющейся записью Observe. В таком случае сервер должен возвращать отклик 4.09 (Conflict).

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

Список ошибок CoAP, поддерживаемых серверами DOTS, представлен в разделе 9 [RFC9132]. Ниже указаны ошибки, относящиеся к расширению для телеметрии.

  • 4.00 (Bad Request) сервер DOTS возвращает при получении от клиента запросов, нарушающих расширение телеметрии DOTS.

  • 4.04 (Not Found) сервер DOTS возвращает при получении от клиента запросов с недействительным tsid или tmid.

  • 4.00 (Bad Request) сервер DOTS возвращает при получении от клиента недействительных запросов (например, не поддерживаемых или некорректно сформированных).

  • 4.04 (Not Found) сервер DOTS возвращает при получении от клиента запросов с целью, не соответствующей вложенному mid на сервере DOTS.

Как указано в разделе 9 [RFC9132], в теле отклика возвращается дополнительный текст (параграф 5.5.2 в [RFC7252]), помогающий в поиске неполадок.

11. Модули YANG

11.1. Модуль телеметрии сигнального канала DOTS

Этот модуль использует типы, определённые в [RFC6991] и [RFC8345], а также группировки из [RFC8783].

   <CODE BEGINS> file "ietf-dots-telemetry@2022-06-20.yang"
   module ietf-dots-telemetry {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
     prefix dots-telemetry;

     import ietf-dots-signal-channel {
       prefix dots-signal;
       reference
         "RFC 9132: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Signal Channel Specification";
     }
     import ietf-dots-data-channel {
       prefix data-channel;
       reference
         "RFC 8783: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Data Channel Specification";
     }
     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types, Section 3";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types, Section 4";
     }
     import ietf-network-topology {
       prefix nt;
       reference
         "RFC 8345: A YANG Data Model for Network Topologies,
                    Section 6.2";
     }
     import ietf-yang-structure-ext {
       prefix sx;
       reference
         "RFC 8791: YANG Data Structure Extensions";
     }

     organization
       "IETF DDoS Open Threat Signaling (DOTS) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dots/> 
        WG List:  <mailto:dots@ietf.org> 

        Author:   Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com> 

        Author:   Konda, Tirumaleswar Reddy.K
                  <mailto:kondtir@gmail.com>"; 
     description
       "Этот модуль содержит определения YANG для сигналов телеметрии
        DOTS, передаваемых между клиентами и серверами DOTS по 
        сигнальному каналу DOTS.

        Авторские права (Copyright (c) 2022) принадлежат IETF Trust и
        лицам, указанным как авторы. Все права защищены.

        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Simplified BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions Relating to IETF Documents
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9244, где правовые
        аспекты приведены более полно.";

     revision 2022-06-20 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9244: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Telemetry";
     }

     typedef attack-severity {
       type enumeration {
         enum none {
           value 1;
           description
             "Без влияния на клиентский домен DOTS.";
         }
         enum low {
           value 2;
           description
             "Минимальное влияние на клиентский домен DOTS.";
         }
         enum medium {
           value 3;
           description
             "Часть ресурсов клиентского домена DOTS не обслуживается.";
         }
         enum high {
           value 4;
           description
             "Клиентский домен DOTS находится в крайне тяжёлых условиях.";
         }
         enum unknown {
           value 5;
           description
             "Влияние атаки не известно.";
         }
       }
       description
         "Перечисляемые значения для уровня атак.";
       reference
         "RFC 7970: The Incident Object Description Exchange
                    Format Version 2, Section 3.12.2";
     }

     typedef unit-class {
       type enumeration {
         enum packet-ps {
           value 1;
           description
             "Пакетов в секунду (pps).";
         }
         enum bit-ps {
           value 2;
           description
             "Бит в секунду (bps).";
         }
         enum byte-ps {
           value 3;
           description
             "Байт в секунду (Bps).";
         }
       }
       description
         "Перечисляемые значения для классов единиц измерения.
          Поддерживаются классы pps, bps, Bps.";
     }

     typedef unit {
       type enumeration {
         enum packet-ps {
           value 1;
           description
             "Пакетов в секунду (pps).";
         }
         enum bit-ps {
           value 2;
           description
             "Бит в секунду (bps).";
         }
         enum byte-ps {
           value 3;
           description
             "Байт в секунду (Bps).";
         }
         enum kilopacket-ps {
           value 4;
           description
             "Килопакетов в секунду (kpps).";
         }
         enum kilobit-ps {
           value 5;
           description
             "Килобит в секунду (kbps).";
         }
         enum kilobyte-ps {
           value 6;
           description
             "Килобайт в секунду (kBps).";
         }
         enum megapacket-ps {
           value 7;
           description
             "Мегапакетов в секунду (Mpps).";
         }
         enum megabit-ps {
           value 8;
           description
             "Мегабит в секунду (Mbps).";
         }
         enum megabyte-ps {
           value 9;
           description
             "Мегабайт в секунду (MBps).";
         }
         enum gigapacket-ps {
           value 10;
           description
             "Гигапакетов в секунду (Gpps).";
         }
         enum gigabit-ps {
           value 11;
           description
             "Гигабит в секунду (Gbps).";
         }
         enum gigabyte-ps {
           value 12;
           description
             "Гигабайт в секунду (GBps).";
         }
         enum terapacket-ps {
           value 13;
           description
             "Терапакетов в секунду (Tpps).";
         }
         enum terabit-ps {
           value 14;
           description
             "Терабит в секунду (Tbps).";
         }
         enum terabyte-ps {
           value 15;
           description
             "Терабайт в секунду (TBps).";
         }
         enum petapacket-ps {
           value 16;
           description
             "Петапакетов в секунду (Ppps).";
         }