Части I, II, V, VI Правил применения оборудования коммутации систем подвижной радиотелефонной связи введены в информационный банк отдельными документами.

Приложение N 19

к Правилам применения оборудования

коммутации сетей подвижной

радиотелефонной связи. Часть VII.

Правила применения оборудования

коммутации стандарта LTE,

утвержденным приказом Министерства

цифрового развития, связи

и массовых коммуникаций

Российской Федерации

от 25.06.2018 N 319

ТРЕБОВАНИЯ К ПРОТОКОЛУ IKEV2

1. Протокол обмена ключами в Интернет (Internet Key Exchange) версия 2 (далее - IKEv2) должен пользоваться услугами протокола UDP через порты 500 и 4500. В дейтаграмме UDP должна осуществляться передача одного сообщения IKEv2. Адреса IP и номера портов UDP в заголовках должны сохраняться и использоваться для передачи ответных пакетов. Сообщение IKEv2 должно начинаться непосредственно после заголовка UDP при передаче через порт UDP 500, а при передаче через порт UDP 4500 перед сообщением IKEv2 должны помещаться четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKEv2 и не должны учитываться в размерах и контрольных суммах IKEv2.

2. Требования к заголовкам протокола IKEv2:

2.1. сообщение протокола IKEv2 должно начинаться с заголовка. После заголовка должен следовать один или несколько элементов данных IKEv2, идентифицируемых значением поля "Next Payload" предыдущего элемента данных. Элементы данных должны обрабатываться в порядке их следования в сообщении IKEv2 путем вызова соответствующей процедуры, определяемой значением поля "Next Payload" в заголовке IKEv2, затем значением поля "Next Payload" в первом элементе данных IKEv2 и далее, пока в поле "Next Payload" не будет обнаружено нулевое значение, указывающее на отсутствие следующего элемента данных. Элемент данных типа Encrypted при приеме должен быть дешифрован, а результат расшифровки необходимо разбирать как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете. В зашифрованные элементы недопустимо включать другие элементы типа Encrypted;

2.2. формат заголовка IKEv2 приведен на рисунке 1.

Initiator's SPI

Responder's SPI

Next Payload

MjVer

MnVer

ExchType

Flags

Message ID

Length

Рисунок 1.

Примечание:

поле "Initiator's SPI" (8 октетов) должно содержать значение, выбранное инициатором для уникальной идентификации параметров безопасности (Security Parameter Index, далее - SPI) IKEv2 и не должно быть равно "0";

поле "Responder's SPI" (8 октетов) должно содержать значение, выбранное ответчиком для уникальной идентификации защищенной связи IKE и должно быть равно "0" в первом сообщении начального обмена IKEv2 (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений не должно быть равно "0";

поле "Next Payload" (1 октет) должно содержать информацию о типе элемента данных, расположенного сразу после заголовка.

Формат и значения типа элемента данных:

"Mj Ver" (4 бита) должен задавать старшую часть номера версии используемого протокола IKE. Реализации на основе IKEv2 должны устанавливать значение Major Version равное "2". Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим "2";

"Mn Ver" (4 бита) должен задавать младшую часть номера версии IKE. Реализации на основе IKEv2 должны устанавливать значение Minor Version равное "0" и игнорировать младшую часть номера в принимаемых сообщениях;

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

Типы обмена приведены в таблице N 1.