1 РАЗРАБОТАНЫ Акционерным обществом "ЭЛВИС-ПЛЮС" (АО "ЭЛВИС-ПЛЮС") при участии специалистов Общества с ограниченной ответственностью "Фактор-ТС" (ООО "Фактор-ТС"), Общества с ограниченной ответственностью "КРИПТО-ПРО" (ООО "КРИПТО-ПРО") и Общества с ограниченной ответственностью "С-Терра СиЭсПи" (ООО "С-Терра СиЭсПи")

2 ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 026 "Криптографическая защита информации"

3 УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 января 2021 г. N 27-ст

4 ВВЕДЕНЫ ВПЕРВЫЕ

Настоящие рекомендации содержат описание протокола защиты информации ESP (Encapsulating Security Payload) при использовании в нем российских криптографических алгоритмов, определенных в ГОСТ Р 34.12-2015, Р 50.1.113-2016 и Р 1323565.1.026-2019.

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

Протокол ESP (Encapsulating Security Payload) входит в семейство протоколов IPsec и предназначен для защиты информации в сетях TCP/IP. Данные рекомендации описывают применение ESP при использовании в нем криптографических алгоритмов, определяемых документами национальной системы стандартизации Российской Федерации. Протокол позволяет обеспечить такие свойства безопасности, как конфиденциальность и имитозащита передаваемых данных, а также защита от атак повторной передачи пакетов. Протокол может применяться при защите информации, не содержащей сведений, составляющих государственную тайну, в частности, для построения виртуальных частных сетей (Virtual Private Network).

Настоящие рекомендации базируются на [1] и расширяют их в плане применения российских криптографических алгоритмов.

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

ГОСТ Р 34.12-2015 Информационная технология. Криптографическая защита информации. Блочные шифры

Р 50.1.113-2016 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов электронной цифровой подписи и функции хэширования

Р 1323565.1.026-2019 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров, реализующие аутентифицированное шифрование

Примечание - При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных документов в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю "Национальные стандарты", который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя "Национальные стандарты" за текущий год. Если заменен ссылочный документ, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого документа с учетом всех внесенных в данную версию изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящих рекомендаций в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

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

3.1.1 трансформ (transform): Набор правил, в соответствии с которыми происходит обработка пакета в протоколе ESP; трансформ характеризуется типом, определяющим вид обработки (например, трансформ типа ENCR определяет алгоритм шифрования, режим его использования, способ формирования вектора инициализации и т.д.) и уникальным идентификатором, используемым в протоколе IKEv2 при согласовании трансформов в процессе создания защищенного соединения.

3.1.2 защищенное соединение (Security Association; SA): Логическое объединение используемых трансформов, а также сеансовых ключей, позволяющее осуществлять защиту трафика.

3.1.3 селектор трафика (traffic selector): Совокупность сетевых характеристик, позволяющих выделить некоторое подмножество IP-пакетов; в общем случае является списком элементов, каждый из которых включает диапазон IP-адресов назначения и источника, сетевой протокол (или "любой" протокол) и диапазон портов назначения и источника (для протоколов TCP и UDP).

3.1.4 инкапсуляция (encapsulation): Упаковка сообщений протокола в сообщения другого протокола.

3.1.5 декапсуляция (decapsulation): Извлечение сообщений протокола из сообщений другого протокола.

3.1.6 соль (salt): Непредугадываемая величина, используемая при построении одноразового вектора для трансформов шифрования, описываемых в настоящих рекомендациях.

В настоящих рекомендациях использованы следующие обозначения:

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

Примечания

1 Если это не оговаривается отдельно, в настоящих рекомендациях предполагается, что при передаче по каналу связи все числа представляются в виде строк в формате big-endian (сетевой порядок байт).

2 В настоящих рекомендациях предполагается, что все приведенные строковые константы представляются в кодировке ASCII.

3 Байтовое представление данных, соответствующих группе полей, задается конкатенацией байтовых представлений значений полей группы. Байтовое представление значения поля, являющегося вектором элементов некоторого типа, задается конкатенацией байтовых представлений элементов данного вектора в порядке их нумерации (слева направо).

Семейство протоколов IPsec предназначено для обеспечения безопасной передачи IP-пакетов между узлами IP-сети. Оно включает в себя два основных протокола:

- протокол ESP, обеспечивающий непосредственную защиту IP-пакетов;

- протокол IKEv2, обеспечивающий обмен ключами, взаимную аутентификацию сторон и создание/удаление защищенных соединений; создание защищенного соединения ESP включает в себя согласование его параметров (включая используемые трансформы), выбор SPI и вычисление сеансовых ключей.

Примечание - Протокол IKEv2 используется только для создания защищенных соединений между двумя участниками (unicast).

Настоящий документ описывает работу протокола ESP и использование в нем российских криптографических алгоритмов. Конкретная комбинация свойств безопасности, которые позволяет обеспечить протокол ESP, зависит от используемых трансформов и определяется политикой безопасности абонентов на этапе создания защищенного соединения (Security Association, SA) протоколом управления ключами.

Примечание - Хотя все перечисленные выше свойства безопасности, которые позволяет обеспечить протокол ESP, являются опциональными, недопустима ситуация, когда для конкретного защищенного соединения не обеспечивается ни конфиденциальность, ни имитозащита.

Протокол ESP работает с IP-пакетами. В случае исходящей обработки данных на вход подается IP-пакет, формируется ESP-пакет с защищенными данными и на его основе формируется новый IP-пакет, в котором данные уже содержатся в защищенном виде. Порядок формирования нового IP-пакета определяется режимом протокола ESP (туннельный или транспортный, подробнее см. 4.2). В случае транспортного режима заголовок протокола ESP добавляется в IP-пакет после IP-заголовка и перед заголовком транспортного уровня (TCP, UDP и т.п.), а в случае туннельного режима - перед внутренним IP-заголовком. Для входящего IP-пакета происходит обратная операция: при наличии в нем ESP-пакета содержащиеся в ESP-пакете данные извлекаются, и восстанавливается исходный IP-пакет.

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

Формат ESP-пакета приведен на рисунке 1. Заголовок протокола, непосредственно предшествующего заголовку ESP в IP-пакете (например, IPv4, IPv6 и т.п.), должен содержать значение 50 в поле, идентифицирующем следующий протокол (то есть ESP).

В состав ESP-пакета входят следующие поля:

Поля ESP-пакета (см. рисунок 1) сгруппированы в четыре группы: заголовок (ESP Header), тело (ESP Payload), завершающая часть (ESP Trailer) и имитовставка (ESP ICV). Если используемый трансформ типа ENCR обеспечивает конфиденциальность, то поля Payload Data, Padding, Pad Length и Next Header передаются в зашифрованном виде и в таком виде совокупно обозначаются как ESP Data.

Математически ESP-пакет представляется следующим образом:

Примечание - Далее считается, что строки ESP Header, ..., ESP ICV являются байтовыми представлениями значений групп полей ESP Header, ..., ESP ICV соответственно. Строки SPI, SN, ..., ICV являются байтовыми представлениями значений полей SPI, SN, ..., ICV соответственно.

Идентификатор защищенного соединения SPI служит уникальным идентификатором SA на стороне получателя ESP-пакета. Поле содержит произвольное 32-битное значение. Значения SPI в диапазоне 1 - 255 (при представлении этого поля в виде 32-битного числа в сетевом порядке байт) зарезервированы для специальных целей и не должны использоваться в IPsec. Кроме того, значение 0 является запрещенным для SPI и не должно использоваться.

Значение SPI выбирается на этапе создания SA таким образом, чтобы получатель ESP-пакета мог однозначно определить, к какому защищенному соединению относится полученный пакет. Рекомендуется, чтобы значения SPI выбирались непредугадываемо для внешнего наблюдателя. При создании пары ESP SA протоколом IKEv2 каждый из участников выбирает SPI для того защищенного соединения, в котором он будет являться получателем пакетов, и делает это таким образом, чтобы при получении ESP-пакета он всегда мог однозначно найти ESP SA по SPI.

Порядковый номер пакета (Sequence Number) представляет собой беззнаковое 32-битное число в сетевом порядке байт. Первый пакет, посланный по вновь созданному защищенному соединению SA, должен иметь номер 1, каждый последующий пакет - на 1 (единицу) больше. Порядковый номер пакета не должен переполняться, то есть если не согласован расширенный порядковый номер, то после отсылки (2³² - 1) пакетов данное защищенное соединение не должно далее использоваться.

4.1.2.1 Расширенный порядковый номер пакета (ESN)

При необходимости передачи в рамках одного защищенного соединения более (2³² - 1) пакетов может быть использован расширенный порядковый номер пакета (Extended Sequence Number). Использование расширенного номера согласовывается абонентами на этапе создания SA. Расширенный порядковый номер представляет собой 64-битное беззнаковое число. Только младшие 32 бита передаются в пакете (в поле Sequence Number), старшие 32 бита хранятся абонентами как часть состояния SA, при этом они включаются в вычисление имитовставки. При использовании расширенного порядкового номера после отсылки (2⁶⁴ - 1) пакетов данное защищенное соединение не должно далее использоваться.

4.1.2.2 Обработка порядкового номера пакета на приемной стороне

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

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

В процессе передачи по сети пакеты могут перемешиваться, исчезать и множиться. Для корректной обработки порядкового номера пакета приемная сторона должна поддерживать "скользящее окно", содержащее информацию о порядковых номерах последних успешно обработанных пакетов. Минимальный размер окна - 32. Правая граница окна отражает самое большое значение порядкового номера пакета из полученных и успешно обработанных ESP-пакетов. Левая граница окна определяется таким образом: правая граница окна минус размер окна плюс один. При создании SA окно инициализируется таким образом, что левая граница устанавливается равной единице, правая - размеру окна, а окно заполняется элементами, указывающими, что соответствующий пакет еще не обработан. Пакеты с номерами меньшими, чем значение левой границы окна, отбрасываются. Пакеты с номерами, попадающими в границы окна, отбрасываются, если в соответствующем элементе окна стоит отметка, что такой пакет уже был обработан, в противном случае - обрабатываются. После успешной обработки такого пакета соответствующий элемент окна помечается как обработанный. Пакеты с номерами большими, чем значение правой границы окна, обрабатываются. В случае если они обработаны успешно, правая граница окна устанавливается равной номеру полученного пакета, соответственно сдвигается и левая граница.

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

4.1.2.3 Особенности обработки расширенного порядкового номера пакета на приемной стороне

При использовании расширенного порядкового номера пакета проверка на повторный пакет осуществляется аналогично тому, как это описано в 4.1.2.2, за исключением того, что все величины должны быть 64-битными. Поскольку в пакете в поле SN передаются только младшие 32 бита расширенного номера, то для получения полного 64-битного номера входящего пакета старшие 32 бита определяются эмпирически следующим образом. Обозначим:

Возможны две ситуации расположения скользящего окна:

(1) R_l >= W_sz - 1,

(2) R_l < W_sz - 1.

Для ситуации (1): если S_l >= L_l, где L_l = R_l - W_sz + 1, то S_h = R_h, иначе S_h = R_h + 1.

Для ситуации (2): если S_l >= L_l, где L_l = R_l - W_sz + 1, то S_h = R_h - 1, иначе S_h = R_h.

Данный алгоритм позволяет восстановить расширенный номер пакета S (путем комбинации S_l из пакета и полученного S_h), после чего должен использоваться алгоритм, описанный в 4.1.2.2 с поправкой на то, что все величины являются 64-битными. Приложение В содержит формализованное описание алгоритма обработки расширенного номера пакета на приемной стороне.

Примечания

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

2 Описанный алгоритм восстановления старших 32 бита расширенного номера пакета обладает следующей особенностью: любой входящий пакет, не попадающий в окно, считается новым, а не отставшим пакетом. Иными словами, пакет, отправленный с расширенным номером S и задержавшийся в канале настолько, что в момент его получения на приемной стороне справедливо условие R - S > W_sz, в результате применения описанного алгоритма будет воспринят на приемной стороне как пакет с расширенным номером S' = S + 2³². В результате такой пакет будет отброшен не на этапе проверки на повторный пакет, а на этапе проверки имитовставки.

3 Описанный алгоритм восстановления старших 32 бита расширенного номера пакета не будет работать в ситуации, когда происходит потеря 2³² и более последовательных пакетов. Хотя такое событие является маловероятным, если оно все же произойдет, то все последующие входящие пакеты данного защищенного соединения будут отбрасываться из-за неверного восстановления S_h, и, соответственно, нарушения имитозащиты. Если приемная сторона обнаружит, что в течение определенного времени все входящие пакеты с ESN были отброшены по причине нарушения имитозащиты, то она может попытаться провести ресинхронизацию следующим образом: берется произвольный отброшенный входной пакет, для него восстанавливается S_h описанным выше способом и далее инкрементируется в цикле с попыткой каждый раз проверить имитовставку пакета, используя очередное значение S_h. Количество итераций цикла должно быть ограничено. После исчерпания итераций цикла при отсутствии положительного результата можно повторить всю процедуру, используя другой отброшенный пакет. Если в какой-то момент имитовставка пакета успешно проверится, то параметры окна необходимо обновить, используя полученное значение S. Кроме того, если в процессе выполнения ресинхронизации придет пакет, который будет успешно обработан, процесс ресинхронизации следует прекратить.

При использовании расширенного номера пакета рекомендуется использовать размер окна не менее 64. Для высокоскоростных сетей или сетей с повышенными потерями рекомендуется использовать значения.

В протоколе ESP может использоваться дополнительное заполнение, называемое TFC Padding (Traffic Flow Confidentiality Padding) и входящее в состав поля Payload Data. Оно применяется с целью сокрытия истинной длины передаваемых данных для усложнения задачи анализа сетевого трафика. Использование TFC Padding является опциональным и согласуется на этапе создания ESP SA. Опция не должна использоваться, если она не была согласована.

Технически TFC Padding осуществляется путем увеличения размеров поля Payload Data за счет добавления к нему на передающей стороне до шифрования произвольных данных таким образом, чтобы по результирующей длине пакета невозможно было определить длину передаваемых данных (как правило, все пакеты формируются одинаковой длины). На приемной стороне после расшифрования пакета эти данные отбрасываются. Содержимое добавляемых данных не регламентируется.

Поскольку длина TFC Padding в ESP-пакете не передается, то принимающая сторона должна определить, где заканчиваются исходные данные и начинается заполнение, которое надо отбросить. Это можно сделать, только если в самих исходных данных в явном виде присутствует их длина. В частности, TFC Padding можно использовать:

- в туннельном режиме;

- в транспортном режиме при условии, что транспортным протоколом является UDP или ICMP (или другой протокол, явно содержащий длину передаваемых данных).

Использование заполнения TFC Padding является опциональным в протоколе ESP. Другим опциональным способом достижения свойства TFC является периодическая отсылка "пустых" (dummy) пакетов, не несущих полезной информации, но, с точки зрения стороннего наблюдателя, неотличимых от других ESP-пакетов. Такие пакеты должны иметь корректные значения всех полей, кроме поля Payload Data, которое может содержать произвольные данные. Поле Next Header для таких пакетов должно иметь значение 59. На приемной стороне ESP-пакеты, которые после расшифрования содержат значение 59 в поле Next Header, должны отбрасываться без дальнейшей обработки.

Протокол ESP может быть использован в двух режимах - туннельном и транспортном. Конкретный режим является параметром ESP SA.

В туннельном режиме ESP защищает весь исходный пакет, включая его заголовок. Для этого исходный (защищаемый) IP-пакет целиком помещается в поле Payload Data ESP-пакета вместе со своим IP-заголовком (см. рисунок 2). После этого формируется новый IP-пакет с новым IP-заголовком, включающим новые значения IP-адресов, обычно другие, чем в исходном IP-заголовке. Полезной нагрузкой нового IP-пакета становится ESP-пакет. В туннельном режиме поле Next Header в ESP-пакете должно иметь значение 4 для протокола IPv4 или значение 41 для протокола IPv6, указывая, что полезной нагрузкой ESP-пакета является IP-пакет. На приемной стороне после обработки ESP-пакета внешний IP-заголовок отбрасывается.

В туннельном режиме допустимо применение ESP к фрагментированным IP-пакетам. Кроме того, допускается ситуация, когда версии внутреннего и внешнего IP-заголовков различаются.

В транспортном режиме ESP защищает только полезную нагрузку исходного IP-пакета, то есть только она помещается в поле Payload Data протокола ESP (см. рисунок 3). При этом в результирующем пакете используется исходный IP-заголовок с исходными адресами, но со скорректированной длиной, с указанием на ESP как на следующий протокол и с пересчитанной контрольной суммой. В этом случае поле Next Header в ESP-пакете должно иметь значение, скопированное из соответствующего поля исходного IP-заголовка. В транспортном режиме протокол ESP защищает только данные исходного пакета, но не его IP-заголовок.

При использовании транспортного режима ESP с протоколом IPv6 расширенные заголовки IPv6 типа "hop-by-hop", "routing" и "fragmentation" не должны защищаться протоколом ESP (то есть должны размещаться в IP-пакете до заголовка ESP). Расширенные заголовки типа "destination options" в зависимости от желаемой семантики могут как защищаться протоколом ESP (то есть помещаться внутри ESP-пакета), так и нет. В общем случае предпочтительно помещать расширенные заголовки типа "destination options" в ESP-пакет, обеспечивая тем самым их защиту.

В транспортном режиме ESP не может применяться к отдельным IP-фрагментам, поэтому в случае защиты фрагментированного IP-пакета перед применением ESP следует из IP-фрагментов восстановить исходный IP-пакет.

Протокол ESP определен непосредственно поверх протокола IP и выглядит как транспортный протокол (поле в IP-заголовке, идентифицирующее следующий протокол, указывает на ESP). Такая схема плохо совместима с устройствами трансляции сетевых адресов (NAT), которые в большинстве случаев полагаются на присутствие заголовка TCP или UDP после заголовка IP и при трансляции изменяют некоторые поля этих заголовков (порты). В случае с ESP это невозможно, и NAT-устройства в большинстве случаев блокируют прохождение ESP-пакетов. Чтобы обеспечить работу протокола ESP в сетях с NAT, используется инкапсулирование ESP-пакетов в UDP или в TCP.

При инкапсулировании ESP-пакета в UDP заголовок UDP помещается между внешним IP-заголовком и заголовком ESP. При этом поле в IP-заголовке, идентифицирующее следующий протокол, имеет значение 17 (UDP), а порт назначения UDP заголовка должен быть равен 4500. При этом ESP-пакеты приходят на тот же порт, что и IKEv2-пакеты. Принимающая сторона может различить их, проанализировав первые 4 байта: IKEv2-пакеты, приходящие на порт 4500, всегда начинаются с четырех байт нулей, в то время как первые 4 байта ESP-заголовка содержат SPI, значение которого никогда не равно нулю. Заголовок UDP никак не защищен и отбрасывается на принимающей стороне после успешной обработки полученного пакета. На рисунке 4 показан формат ESP при инкапсулировании его в UDP.

При использовании транспортного режима совместно с UDP-инкапсуляцией и при наличии NAT на пути следования пакета в пришедшем пакете значения IP-адресов будут отличаться от исходных вследствие трансляции сетевых адресов. Поскольку поле контрольной суммы в транспортных заголовках TCP и UDP включает в себя значения сетевых адресов из IP-заголовка, то после успешной декапсуляции на приемной стороне необходимо пересчитать значение контрольной суммы транспортных заголовков таким образом, чтобы она была корректной. Исходные значения IP-адресов для пересчета контрольной суммы приемная сторона получает в момент создания SA посредством протокола IKEv2.

Инкапсулирование ESP в UDP согласовывается абонентами посредством протокола IKEv2 при создании ESP SA.

Инкапсулирование ESP-пакетов в TCP может быть использовано как альтернатива инкапсулированию в UDP в тех случаях, когда протокол UDP заблокирован на промежуточных межсетевых экранах. По сравнению с инкапсулированием в UDP инкапсулирование в TCP может иметь ряд побочных эффектов; в частности, может наблюдаться существенное снижение скорости передачи данных в тех случаях, когда защищаемым протоколом тоже является TCP. В связи с этим инкапсулирование ESP в TCP должно быть использовано только в тех случаях, когда использование UDP является невозможным. Инкапсулирование ESP в TCP согласовывается абонентами посредством протокола IKEv2 при создании ESP SA.

Инкапсулирование ESP в TCP выполняется аналогично инкапсулированию в UDP: заголовок TCP помещается между внешним IP-заголовком и заголовком ESP. При этом поле в IP-заголовке, идентифицирующее следующий протокол, имеет значение 6 (TCP), а порт назначения TCP заголовка должен быть равен 4500. Заметим, что в этом случае ESP-пакеты приходят на тот же порт, что и IKEv2-пакеты. Принимающая сторона может различить их, проанализировав первые 4 байта: IKEv2-пакеты, приходящие на порт 4500, всегда начинаются с четырех нулевых байт, в то время как первые 4 байта ESP-заголовка содержат SPI, значение которого никогда не равно нулю. Заголовок TCP никак не защищен и отбрасывается на принимающей стороне после успешной обработки полученного пакета. Для разделения отдельных ESP-пакетов и IKEv2-пакетов в потоке TCP перед каждым пакетом добавляется поле LEN размером в 2 байта, которое содержит в сетевом порядке байт длину следующего за ним ESP-пакета или IKEv2-пакета плюс размер самого поля (2 байта). На рисунке 5 показан формат ESP при инкапсулировании его в TCP.

Примечание - На рисунках 2 - 5 для упрощения показано, что поле IV явно включается в данные, защищаемые имитовставкой. В реальности это зависит от используемого трансформа. В частности, для AEAD-трансформов, реализующих шифрование, поле IV не включается в данные, защищаемые имитовставкой, его защита от искажения осуществляется неявным образом. Для AEAD-трансформов, реализующих только имитозащиту, поле IV явно включается в данные, защищаемые имитовставкой. См. также 6.2.8.

Как и в случае с инкапсулированием в UDP, при использовании TCP-инкапсуляции в транспортном режиме на приемной стороне необходимо корректировать контрольную сумму в заголовках TCP и UDP, подробнее см. 5.4.

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

- селектор трафика (определяет, какой сетевой трафик попадает под действие данного правила);

- действие с трафиком, подпадающим под селектор ("пропустить", "отбросить", "защитить");

- динамический список защищенных соединений, созданных данным правилом (для действия "защитить");

- возможные режимы инкапсуляции (для действия "защитить");

- список наборов трансформов, которые могут быть использованы для защиты трафика (для действия "защитить");

- иные параметры, не относящиеся к безопасности (например, уровень журналирования и т.п.).

Такой список называется Security Policy Database (SPD).

Каждый пакет обрабатывается в некотором контексте, называемом защищенным соединением (Security Association, SA). В данном документе рассматриваются только защищенные соединения, связанные с протоколом ESP - ESP SA. Защищенные соединения создаются и удаляются динамически протоколом согласования ключей и содержат такие данные, как:

- идентификатор защищенного соединения (SPI);

- используемые трансформы:

Примечание - В данном документе описывается использование только AEAD-алгоритмов для трансформа типа ENCR, поэтому трансформ типа INTEG не используется.

- ключ для трансформа шифрования (K_encr);

- опционально ключ для трансформа имитозащиты;

Примечание - В данном документе описывается использование только AEAD-трансформов шифрования, поэтому ключ для трансформа имитозащиты отсутствует.

- селектор трафика (определяет, какой трафик должен защищаться данным защищенным соединением);

- порядковый номер следующего исходящего пакета (SN или ESN);

- скользящее окно номеров пакетов (на приемной стороне);

- режим инкапсуляции (туннельный/транспортный);

- туннельный IP-адрес (для туннельного режима);

- иные параметры, не относящиеся к безопасности (например, уровень журналирования и т.п.).

Протокол ESP является однонаправленным, то есть одно защищенное соединение обеспечивает защиту трафика, идущего только в одном направлении. Для защиты двунаправленного трафика (типичного в сети Интернет) абонентам необходимо создать два защищенных соединения. Протокол IKEv2 всегда создает ESP SA попарно, вне зависимости от того, будет ли защищаться однонаправленный трафик или двунаправленный.

Защищенное соединение идентифицируется значением SPI (Security Parameter Index) в заголовке ESP (см. 4.1.1).

Каждая из сторон хранит динамическую таблицу активных защищенных соединений, называемую SAD (Security Association Database).

На вход протокола ESP поступает IP-пакет. Правила SPD просматриваются от первого к последнему с целью поиска такого из них, селектор трафика которого включает сетевые параметры пакета. Если правило не найдено или содержит действие "отбросить", пакет уничтожается. Если найденное правило содержит действие "пропустить", пакет пропускается.

Если найденное правило содержит действие "защитить", то просматривается список ESP SA, созданных данным правилом, с целью поиска уже установленного защищенного соединения, селектор трафика которого включает сетевые параметры пакета. Если такового не найдено, делается запрос протоколу управления ключами для создания нового ESP SA с теми параметрами, которые заданы в правиле, а сам пакет ставится в лист ожидания. Обработка такого пакета возобновится после того, как защищенное соединение ESP будет создано.

Примечание - В данном документе предполагается использование протокола управления ключами IKEv2 для создания однонаправленных (unicast) ESP SA.

Если подходящее ESP SA найдено, то пакет защищается в соответствии с указанными в нем параметрами. В частности:

а) осуществляется инкапсуляция пакета в соответствии с указанным в ESP SA режимом; при этом происходит формирование и добавление необходимых заголовков - ESP и, опционально, нового IP-заголовка;

б) данные пакета дополняются опциональным (TFC Padding) и обязательным (Padding) заполнениями, заполняются поля Pad Length и Next Header;

в) вычисляется номер (или расширенный номер) для данного пакета (путем увеличения на единицу его значения по отношению к номеру предыдущего отправленного пакета);

г) заполняются поля ESP-заголовка SPI и SN;

д) вычисляется вектор инициализации для данного пакета в соответствии с указанным в SA криптографическим преобразованием, его значение записывается в поле IV;

е) определяется ключ защиты пакета, при необходимости инициируется процесс обновления ключей (см. 6.2.10);

ж) пакет зашифровывается и имитозащищается с использованием трансформа ENCR, указанного в ESP SA, ключа защиты пакета и вычисленного вектора инициализации; значение ESP ICV добавляется к пакету.

Примечание - В данном документе описывается использование только AEAD-алгоритмов для трансформа типа ENCR, поэтому имитозащита данных пакета осуществляется вместе с их шифрованием;

и) опционально пакет инкапсулируется в UDP или TCP в соответствии с параметрами ESP SA;

к) происходит обновление динамических полей ESP SA, таких как:

- порядковый номер (или расширенный номер) данного пакета как последнего отправленного;

- количество защищенных пакетов;

- объем защищенных данных;

- IV (при необходимости);

- прочие динамические поля SA.

Примечание - Данный алгоритм предполагает, что обработка пакетов происходит в один поток. В случае многопоточной обработки пакетов в рамках одного защищенного соединения необходимо принять дополнительные меры для синхронизации проверки и изменения общих данных SA между потоками.

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

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

Примечания

1 Функции getKey и getNonce зависят от используемого трансформа ENCR.

2 Формирование AAD в общем случае зависит от используемого трансформа ENCR.

5.3.1.1 Исходный пакет IP Packet представляется в виде

где IP Header - заголовок исходного IP-пакета,

IP Data - полезная нагрузка исходного IP-пакета.

5.3.1.2 Формируется ESP Header.

где SPI - полагается равным значению SPI данного защищенного соединения,

SN - вычисляется путем увеличения на единицу номера предыдущего пакета, отправленного по данному защищенному соединению.

5.3.1.3 Формируется IV.

Если ESP SA подразумевает использование вектора инициализации, то значение IV вычисляется в соответствии с требованиями трансформа типа ENCR, согласованного в ходе создания ESP SA (см. подробнее 6.2.5).

5.3.1.4 Формируется ESP Data и ESP ICV.

а) Формируются поля Payload Data и ESP Trailer.

Если в ESP SA определен туннельный режим работы протокола ESP, то Payload Data формируется следующим образом:

где , s >= 0.

Если в ESP SA определен транспортный режим работы протокола ESP, то Payload Data формируется следующим образом

где , s >= 0.

б) ESP Trailer формируется следующим образом

где Padding формируется следующим образом: первый байт имеет значение 1, каждый последующий - на 1 (единицу) больше. Длина заполнения выбирается таким образом, чтобы суммарная длина Payload Data, Padding, Pad Length и Next Header была кратна четырем байтам и была одновременно кратной размеру блока используемого трансформа типа ENCR (если трансформ накладывает такие ограничения); рекомендуется выбирать минимальный размер дополнения, удовлетворяющий этому условию;

Примечание - Данный алгоритм является рекомендуемым способом заполнения поля Padding, однако [1] допускает использование других способов формирования дополнения; приемная сторона не должна отбрасывать пакет, если дополнение сформировано иным способом.

Pad Length содержит длину Padding;

Next Header в случае использования туннельного режима полагается равным 4 в случае IPv4 или 41 в случае IPv6; для транспортного режима значение копируется из поля для транспортного протокола исходного IP-заголовка; при формировании пустого (dummy) пакета Next Header полагается равным 59.

в) Пакет защищается с использованием параметров, указанных в ESP SA, в результате чего получаются значения Ciphertext и ESP ICV

где алгоритм аутентифицированного шифрования AEAD-Encrypt задается согласованным трансформом ENCR (см. 6.2.2).

Примечание - В рамках данного документа предполагается, что в ходе выработки параметров ESP SA для трансформа ENCR согласован AEAD-алгоритм;

значения K_msg и vonce вырабатываются из ключа K_encr и вектора инициализации IV в соответствии с алгоритмами, определенными в трансформе ENCR (см. 6.2.6 и 6.2.7);

значение AAD формируется в зависимости от согласованного трансформа ESN и от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 5);

значение Plaintext формируется в зависимости от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 1).

г) Результирующее значение ESP Data формируется в зависимости от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 2).

5.3.1.5 Результирующий пакет IP' Packet формируется следующим образом:

где IP' Header - либо новый IP-заголовок с новыми значениями IP-адресов (обычно другими, чем в исходном IP-заголовке IP Header), если в ESP SA определен туннельный режим работы протокола, либо исходный заголовок IP Header со скорректированной длиной, с указанием на ESP как на следующий протокол и с пересчитанной контрольной суммой, если в ESP SA определен транспортный режим работы протокола;

ESP Header, IV, ESP Data, ESP ICV - поля ESP-пакета (см. 4.1), формирование которых описано в 5.3.1.2 - 5.3.1.4.

Если IP-пакет при пересылке был разбит на фрагменты, то первоначально выполняется восстановление целого IP-пакета из полученных IP-фрагментов.

При получении ESP-пакета, адресованного данному абоненту, он обрабатывается следующим образом:

а) Если пакет был инкапсулирован в UDP или в TCP, то осуществляется его декапсуляция с отбрасыванием этих заголовков.

б) Из полученного IP пакета выделяется ESP-пакет и выполняется поиск SA в SAD по значению SPI из ESP-заголовка; если защищенное соединение не найдено, пакет отбрасывается.

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

в) Номер полученного ESP-пакета проверяется с использованием скользящего окна из SA; если пакет идентифицирован как повторный или устаревший, он отбрасывается.

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

д) Проводится проверка ICV пакета; если она прошла успешно, то выполняется расшифрование пакета с использованием трансформа ENCR, указанного в ESP SA, ключа защиты пакета и вектора инициализации из пакета, иначе пакет отбрасывается.

Примечание - В данном документе описывается использование только AEAD-алгоритмов для трансформа типа ENCR, поэтому расшифрование данных происходит параллельно с проверкой ICV-пакета.

е) Отбрасываются обязательное (Padding) и опциональное (TFC Padding) дополнения.

ж) Исходный пакет реконструируется в соответствии с режимом инкапсуляции, прописанным в ESP SA, с использованием значения поля Next Header; если режим инкапсуляции пакета не совпадает с режимом инкапсуляции, указанным в ESP SA, пакет отбрасывается, как нарушающий политику безопасности.

и) Сетевые параметры полученного пакета проверяются на вхождение в селектор трафика ESP SA; если они не входят, то пакет отбрасывается, как нарушающий политику безопасности.

к) Происходит обновление динамических полей SA, таких как:

- границы и/или содержимое скользящего окна номеров пакетов;

- количество обработанных входящих пакетов;

- объем обработанных данных;

- прочие динамические поля SA.

л) Если полученный пакет был инкапсулирован в UDP или TCP и адрес или порт источника не совпадают с указанными в SA значениями и SA допускает обновление туннельного адреса, то туннельный адрес и порт TCP/UDP инкапсуляции обновляются значениями адреса и порта источника из пакета.

Полученный пакет отправляется в TCP/IP стек системы.

Примечание - Данный алгоритм предполагает, что обработка пакетов происходит в один поток. В случае многопоточной обработки пакетов в рамках одного защищенного соединения необходимо принять дополнительные меры для синхронизации проверки и изменения общих данных SA между потоками.

5.4.1.1 Проводится проверка ICV полученного пакета и его расшифрование. Если проверка ICV не прошла, то пакет отбрасывается.

где алгоритм расшифрования и проверки имитовставки AEAD-Decrypt задается согласованным трансформом ENCR (см. 6.2.2);

значения K_msg и nonce вырабатываются из ключа K_encr и вектора инициализации IV в соответствии с алгоритмами, согласованными трансформом ENCR (см. 6.2.6 и 6.2.7);

значение AAD формируется в зависимости от согласованного трансформа ESN и от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 5);

значение Ciphertext формируется в зависимости от того, согласует ли трансформ ENCR использование шифрования (см. таблицу 3).

5.4.1.2 Если поле Next Header в ESP Trailer содержит значение 59, пакет отбрасывается.

5.4.1.3 От полученного значения Plaintext (при отсутствии шифрования - от ESP Data) отбрасывается ESP Trailer, получая значение Payload Data.

5.4.1.4 От значения Payload Data отбрасывается TFC Padding (при его наличии).

5.4.1.5 Полученная величина интерпретируется как IP Data; при этом:

а) если ESP SA использует туннельный режим, то IP Data интерпретируется как IP Packet;

б) если ESP SA использует транспортный режим, то IP Packet формируется следующим образом:

где IP Header - заголовок исходного IP-пакета, в котором скорректирована длина, а поле, определяющее транспортный протокол, заменено на значение поля Next Header.

В соответствии с настоящими рекомендациями в процессе согласования параметров ESP SA в протоколе IKEv2 для трансформа типа ENCR следует использовать только параметры, представленные в 6.3. Поскольку для трансформов типа ENCR используются AEAD-алгоритмы, при согласовании параметров SA трансформ типа INTEG не должен использоваться. Данные рекомендации не накладывают ограничений на согласование прочих параметров ESP SA.

Настоящие рекомендации определяют четыре трансформа типа ENCR:

ENCR_KUZNYECHIK_MGM_KTREE

ENCR_MAGMA_MGM_KTREE

ENCR_KUZNYECHIK_MGM_MAC_KTREE

ENCR_MAGMA_MGM_MAC_KTREE

Все описанные трансформы представляют собой AEAD-алгоритмы с диверсификацией ключей. Трансформы базируются на алгоритмах "Кузнечик" (ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE) и "Магма" (ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE), описанных в ГОСТ Р 34.12-2015 (разделы 4 и 5). Алгоритмы используются в режиме MGM, описанном в Р 1323565.1.026-2019.

Трансформы ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE обеспечивают конфиденциальность и имитозащиту передаваемых данных (путем аутентифицированного шифрования), трансформы ENCR_KUZNYECHIK_MGM_MAC_KTREE и ENCR_MAGMA_MGM_MAC_KTREE обеспечивают только имитозащиту (т.е. шифрование не применяется).

Примечание - Использование трансформа типа ENCR с AEAD-алгоритмом для обеспечения свойства имитозащиты без конфиденциальности вместо трансформа типа INTEG обусловлено тем, что в протоколе ESP только трансформ типа ENCR может иметь вектор инициализации, то есть только для трансформа типа ENCR можно построить дерево ключей, обеспечивающее их диверсификацию.

В протоколе IKEv2 при согласовании параметров SA трансформы ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE представлены как AEAD-алгоритмы с длиной ключа K_encr 352 бита, из которых первые 256 бит используются как корневой ключ SA (K), а последующие 96 бит - в качестве соли (salt). В свою очередь, трансформы ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE представлены как AEAD-алгоритмы с длиной ключа 288 бит, из которых первые 256 бит используются как корневой ключ SA (K), а последующие 32 бита - в качестве соли (salt). Для всех трансформов длины ключей являются фиксированными, поэтому при их согласовании в IKEv2 атрибут Key Length не должен использоваться.

Данные трансформы не накладывают требований на выравнивание длины защищаемых данных (см. 4.1).

Определенные в настоящих рекомендациях трансформы ENCR в качестве блочного шифра используют шифры "Магма" и "Кузнечик", определенные в ГОСТ Р 34.12-2015 (см. таблицу 4). Длина блока составляет 128 бит для шифра "Кузнечик" и 64 бита для шифра "Магма", длина ключа K в обоих случаях составляет 256 бит.

Определенные в настоящих рекомендациях трансформы ENCR в качестве AEAD-алгоритма используют блочный шифр в режиме MGM, описанном в Р 1323565.1.026-2019. Для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE длина имитовставки S полагается равной 96 битам, для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE используется полная имитовставка, т.е. S = 64.

Функция зашифрования AEAD-Encrypt задается в соответствии со следующей формулой:

где

Функция расшифрования AEAD-Decrypt задается в соответствии со следующей формулой:

где

Длина ключа трансформа K_encr составляет 352 бита (klen = 44) для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE и 288 бит (klen = 36) для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE.

Настоящие рекомендации предполагают, что из ключа трансформа K_encr формируется корневой ключ и строка :

Ключ защиты сообщения K_msg вычисляется на основании корневого ключа K и величин i₁, i₂ и i₃, передаваемых в векторе инициализации, следующим образом:

где , i₂, - параметры диверсификации ключа;

l₁, l₂, l₃ - константные ASCII строки длиной 6 байт (без нулевого байта в конце строки): l₁ = "level1", l₂ = "level2", l₃ = "level3";

Divers(K, L, D) - алгоритм диверсификации ключа по данным диверсификации и метке , который задается с помощью алгоритма KDF_GOSTR3411_2012_256, описанного в Р 50.1.113-2016 (подраздел 4.4): Divers(K, L, D) = KDF₂₅₆(K_in, label, seed).

Каждое защищенное сообщение содержит вектор инициализации. Вектор инициализации представляет собой конкатенацию четырех величин:

где , i₂, - параметры диверсификации ключа;

- порядковый номер сообщения, зашифрованного на данном ключе.

l₂, l₃ и PNUM являются представлением в сетевом порядке байт величин i₂, i₃ и pnum соответственно (см. рисунок 8). Суммарная длина вектора инициализации - 8 байт.

Значение вектора инициализации должно быть уникальным для каждого ESP-пакета в рамках защищенного соединения. То есть для данного ключа K должно быть обеспечено различие векторов инициализации IV = i₁ | l₂ | l₃ | PNUM для всех передаваемых пакетов.

Ключ шифрования и имитозащиты сообщения вычисляется следующим образом:

где K - корневой ключ трансформа ENCR;

, i₂, - параметры диверсификации ключа, передаваемые в векторе инициализации (см. 6.2.5).

Для защиты сообщения используется одноразовый вектор. Формат одноразового вектора зависит от используемого трансформа.

Для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 128 бит и формируется, как показано на рисунке 9.

где zero - 8 бит нулей (, );

PNUM - порядковый номер сообщения (24 бита) из вектора инициализации (см. рисунок 8);

salt - соль (96 бит), берется из ключа трансформа K_encr (см. 6.2.3).

Для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 64 бита и формируется, как показано на рисунке 10.

где zero - 8 бит нулей (, );

PNUM - порядковый номер сообщения (24 бита) из вектора инициализации (см. рисунок 8);

salt - соль (32 бита), берется из ключа трансформа K_encr (см. 6.2.3).

Иными словами, одноразовый вектор nonce вычисляется на основании строки и порядкового номера пакета следующим образом:

Для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZNYECHIK_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 128 бит, для трансформов ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE одноразовый вектор nonce имеет размер 64 бита.

Формат AAD (дополнительных имитозащищаемых данных) зависит от применяемого трансформа шифрования и от того, используется ли ESN (расширенный номер пакета) или нет. В случае применения трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE без использования ESN AAD формируется, как показано на рисунке 11.

Для этих же трансформов в случае использования ESN AAD формируется, как показано на рисунке 12.

В случае применения трансформов ENCR_KUZNYECHIK_MGM_MAC_KTREE и ENCR_MAGMA_MGM_MAC_KTREE без использования ESN AAD формируется, как показано на рисунке 13.

Для этих же трансформов в случае использования ESN AAD формируется, как показано на рисунке 14.

Таблица 5 описывает формирование AAD в зависимости от заданных параметров защищенного соединения.

В случае использования расширенных номеров пакетов в AAD включаются все 64 бита номера пакета, однако поле SN в составе ESP-пакета включает только 32 младших бита ESN, а старшие 32 бита не передаются.

Примечание - Заметим, что для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_MAGMA_MGM_KTREE AAD не включает в себя IV, так как имитозащита IV происходит неявным образом: значение IV определяет конкретный ключ защиты сообщения и одноразовый вектор, при их несоответствии исходным значениям пакет не будет успешно проверен на приемной стороне. Однако для трансформов ENCR_KUZNYECHIK_MGM_MAC_KTREE и ENCR_MAGMA_MGM_MAC_KTREE AAD включает в себя IV, чтобы AAD представлял собой один неразрывный блок данных.

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

Предполагается, что передающая сторона ведет учет объема данных, защищенных на одном ключе K_msg (ключ определяется значениями i₁, i₂, i₃). Если при обработке очередного IP-пакета объем трафика будет превышен либо произойдет переполнение счетчика pnum, то до обработки данного пакета вырабатывается новый ключ K_msg путем увеличения параметра i₃ на единицу, pnum при этом обнуляется. При возможном превышении нагрузки на ключ второго уровня или при переполнении i₃ параметр i₂ увеличивается на единицу, а при возможном превышении нагрузки на ключ первого уровня или при переполнении i₂ параметр i₁ увеличивается на единицу. При превышении i₁ своего максимального значения данное защищенное соединение удаляется и взамен него создается новое с новым ключом K_encr.

где значения , и определяются политикой безопасности, но в любом случае ограничены величинами: , и .

Передающая сторона не должна пересчитывать K_msg заново при отправке очередного пакета, последнее значение ключа должно сохраняться и использоваться, если значения параметров диверсификации i₁, i₂, i₃ не изменились по сравнению с предыдущим отправленным пакетом. Это справедливо и для промежуточных ключей в дереве.

Предполагается, что на приемной стороне также ведется учет объема данных, защищенных на одном ключе K_msg (ключ определяется значениями i₁, i₂, i₃). Если при приходе очередного ESP-пакета объем трафика, защищенного на данном ключе K_msg, достигнет максимально допустимого для абонента значения нагрузки на ключ или произойдет превышение нагрузки на промежуточные ключи дерева, то обработка пакета продолжается как обычно, но при этом инициируется создание нового защищенного соединения с новым ключом K_encr, которое должно использоваться взамен текущего.

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

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

Если на приемной стороне фиксируется получение значительного числа искаженных пакетов за короткий промежуток времени в контексте какого-то защищенного соединения, то это может служить признаком проведения атаки, особенно если при этом наблюдается хаотичное изменение значений i₁, i₂, i₃ и pnum в получаемых пакетах. В этом случае приемная сторона может удалить данное защищенное соединение и создать идентичное ему, но с новым значением SPI и с новым ключом K_encr.

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

Ниже приведены идентификаторы российских алгоритмов, используемых в настоящих спецификациях. Эти идентификаторы используются в протоколе IKEv2 при согласовании параметров ESP SA.

Идентификаторы для трансформа типа ENCR приведены в таблице 6.

Таблица А.1 содержит рекомендуемые значения максимально допустимого суммарного объема трафика, который обрабатывается на одном ключе K_msg. При достижении максимального объема должен вырабатываться новый ключ K_msg из дерева ключей по процедуре, описанной в 6.2.10.

Примечания

1 Указанные значения носят рекомендательный характер.

2 Учитывая то, что максимальное число пакетов, защищаемых на одном ключе K_msg, не может превысить 2²⁴, а максимальный размер IP-пакета не превышает 2¹⁶ байт (это ограничение действует как на защищаемый пакет, так и на IP-пакет, получающийся в результате применения к защищаемому пакету протокола ESP), суммарный объем трафика, защищаемого на одном ключе K_msg, не может превысить 2⁴⁰ байт. Таким образом, ограничение 2⁴¹ байт для трансформов ENCR_KUZNYECHIK_MGM_KTREE и ENCR_KUZMYECHIK_MGM_MAC_KTREE является недостижимым.

При использовании трансформов, базирующихся на шифре "Магма" (ENCR_MAGMA_MGM_KTREE и ENCR_MAGMA_MGM_MAC_KTREE), рекомендуется ограничивать количество допустимых ключей K_msg для каждого корневого ключа K значением меньшим, чем размер дерева ключей при полном переборе i₁, i₂, i₃ (например, путем введения ограничений на максимальные значения этих счетчиков).

Данное приложение содержит тестовые векторы. Значения тестовых векторов приведены в шестнадцатеричном виде.