Приложение 19. ПРАВИЛА ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ СЕТЕЙ ПОДВИЖНОЙ РАДИОТЕЛЕФОННОЙ СВЯЗИ. ЧАСТЬ VII. ПРАВИЛА ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ СТАНДАРТА LTE

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.

Рисунок 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.

Таблица N 1.

Примечание:

"Flags" (1 октет) должен указывать на наличие специфических опций в сообщении при установлении соответствующего бита флага в "1";

"Message ID" (4 октета) должен содержать идентификатор сообщения и использоваться для управления повторной передачей потерянных пакетов и связывания запросов с откликами;

"Length" (4 октета) должен содержать размер всего сообщения (заголовок и элементы данных) в октетах;

2.3. структура базового заголовка элемента данных (payload) IKEv2 приведена на рисунке 2.

Рисунок 2

Примечание:

поле "Идентификатор следующего элемента" (Next Payload) (1 октет) должно указывать тип следующего элемента данных в сообщении, должно быть равно "0", если текущий элемент является последним, и не должно использоваться для элемента типа Encrypted (всегда должен быть последним в сообщении). Указанный элемент должен содержать структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле "Next Payload" должно устанавливаться в соответствии с типом первого вложенного элемента (вместо "0").

Значения идентификаторов следующих элементов сообщения приведены в таблице N 2.

Таблица N 2.

Примечание:

поле "C" (1 бит) должно быть равно "0" для обеспечения заявленной отправителем возможности по пропуску получателем элемента данных, когда получатель не идентифицирует код в поле "Next Payload" предыдущего элемента. Получатель должен игнорировать этот флаг при идентификации типа элемента. Флаг "C" должен относиться к текущему элементу данных;

поле "Резерв" (7 битов) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Размер текущего элемента" (Payload Length) (2 октета) должно содержать размер текущего элемента данных в октетах с учетом базового заголовка;

2.4. структура элемента данных "Предложения" (SA) приведена на рисунке 3.

Рисунок 3

Данные контекста безопасности (Security Association Payload, далее - SA) должны использоваться для согласования атрибутов защищенной связи. Элемент SA может включать несколько предложений, упорядоченых в порядке снижения приоритета. Каждое предложение может включать несколько протоколов IPsec (IKEv2, ESP, AH), каждый протокол может включать множество преобразований, а каждое преобразование может включать несколько атрибутов.

Примечание:

первый октет должен содержать информацию о том, является ли предложение последним в субструктуре предложений элемента SA (предложение должно быть последним при значении первого октета равном "0" и не должно являться последним при значении равном "2");

поле "Длина предложения" (2 октета) должно указывать размер предложения, включая все входящие в него преобразования и атрибуты;

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

поле "Идентификатор протокола" (1 октет) должно задавать идентификатор протокола IPsec для текущего согласования;

поле "Значение SPI" (1 октет) должно использоваться для начального согласования IKE_SA и должно быть равно "0". Значение SPI следует получать из внешнего заголовка и при последующих согласованиях поле "Значение SPI" должно показывать размер SPI (в октетах) для соответствующего протокола (8 для IKEv2, 4 для ESP и AH);

поле "Число преобразований" (1 октет) должно содержать информацию о числе преобразований в предложении;

поле "SPI передающей стороны" должно быть переменного размера;

поле "Структура преобразования" должно быть переменного размера.

Формат поля "Структура преобразования" приведен на рисунке 4.

Рисунок 4

Примечание:

первый октет должен должен содержать информацию о том, является ли преобразование последним в предложении. Преобразование должно быть последним при значении первого октета равном "0" и не должно являться последним при значении равном "3";

поле "Резерв" (1 октет) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Длина преобразования" (2 октета) должно содержать информацию о размере поля "Структура преобразования" (в октетах) с учетом заголовка и атрибутов;

поле "Тип преобразования" (1 октет) должно содержать тип преобразования, задаваемого этим элементом. Преобразование не должно включаться в предложение, если оно является необязательным и инициатор предлагает его пропустить. Инициатор должен включать субструктуру преобразования с идентификатором Transform ID равном "0" в качестве одной из опций при передаче вопроса об использовании необязательного преобразования ответчику.

Типы преобразований приведены в таблице N 3.

Таблица N 3.

Примечание:

поле "Идентификатор преобразования" (2 октета) должно содержать идентификатор конкретного преобразования указанного типа.

Число и тип преобразований в элементах данных SA должны зависеть от типа протокола в самой SA.

Обязательные и опциональные типы преобразований приведены в таблице N 4.

Таблица N 4.

Примечание:

поле "Атрибуты преобразования" должно содержать атрибуты, представляющие собой пары "тип-значение" для каждого преобразования элемента данных SA, приведенные в таблице N 5.

Таблица N 5.

Примечание:

Значение атрибута должно иметь фиксированную (2 октета) или переменную длину. Для представления атрибута переменной длины должен использоваться формат "тип-размер-значение".

Формат поля "Атрибута преобразования" приведен на рисунке 5.

Рисунок 5

Примечание:

поле "Тип атрибута" (2 октета) должно содержать идентификатор атрибута. Для атрибута должен использоваться полный формат атрибута (тип/размер/значение) при установлении старшего бита поля "Тип атрибута" - флага формата атрибута (AF), равного "0" или сокращенный формат атрибута (тип/значение) при AF равном "1";

поле "Длина атрибута (значение)" (2 октета) должно содержать информацию о размере атрибута, содержащийся в поле "Значение атрибута" (переменная длина), при AF равном "0" или содержать значение атрибута при AF равном "1";

2.5. формат элемента данных Обмен ключами (Key Exchange, далее - KE) приведен на рисунке 6.

Рисунок 6

Элемент данных KE должен использоваться для обмена открытыми номерами протокола (Diffie-Hellman, далее - DH) при обмене ключами DH.

Элемент данных KE должен создаваться путем копирования открытого значения DH в поле "Данные обмена ключами". Размер открытого значения DH должен быть равен размеру первичного модуля, для которого выполняется возведение в степень, дополненного при необходимости нулями в начале.

Поле "Номер группы DH" (2 байта) должно идентифицировать группу DH, в которой было рассчитано значение поля "Данные обмена ключами". Сообщение должно игнорироваться с возвратом элемента "Уведомление типа INVALID_KE_PAYLOAD" при выборе предложения, использующего другую группу DH;

2.6. формат элементов Идентификатор инициатора (IDi) и Идентификатор отвечающего (IDi) приведен на рисунке 7.

Рисунок 7

Примечание:

поле "Тип идентификации" (1 байт) должен задавать тип используемых идентификаторов;

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

2.7. формат элемента данных Сертификат приведен на рисунке 8.

Рисунок 8

Примечание:

поле "Тип сертификата" (1 октет) должно содержать информацию о способе кодирования сертификата;

поле "Данные сертификата" должно иметь переменный размер.

Элемент данных Сертификат должен обеспечивать способ передачи сертификатов или другой, связанной с идентификацией информации через IKE. Элемент данных Сертификат следует включать в обмен, если сертификат доступен отправителю до указания партнером возможности получения идентификационной информации иным путем с использованием элемента Уведомление типа HTTP_CERT_LOOKUP_SUPPORTED. Требования к

Значения поля "Тип сертификата" приведены в таблице N 6.

Таблица N 6.

2.8. формат элемента данных Запрос сертификата приведен на рисунке 9.

Рисунок 9

Примечание:

поле "Тип сертификата" (1 октет) должно содержать информацию о способе кодирования сертификата;

поле "Удостоверяющий центр" должно иметь переменный размер.

2.9. элемент данных Идентификация должен содержать данные, используемые для идентификации.

Формат элемента данных Идентификация приведен на рисунке 10.

Рисунок 10

Примечание:

поле "Метод идентификации" (1 октет) должно содержать информацию о используемом методе идентификации и принимать значения:

RSA цифровая подпись (1) (должно рассчитываться с использованием приватного ключа RSA и хэш-значения PKCS N 1 с заполнением);

Shared Key Message Integrity Code (2) (должно рассчитываться с использованием разделяемого ключа, связанного с объектом из элемента Тип идентификации и согласованной функции prf);

DSS (Digital Signature Standard) цифровая подпись (3) (должно рассчитываться с использованием закрытого ключа DSS и хэш-значения алгоритма криптографического хеширования SHA-1 (Secure Hash Algorithm);

Значение 0 и 4 - 200 должны быть зарезервированы IANA, 201 - 255 должны быть выделены для частных приложений;

поле "Идентификационные данные" должно иметь переменный размер;

2.10. элемент данных Случайное число должно иметь одно поле переменного размера, содержащее созданное передающей стороной случайное значение, размер элемента должен находиться в диапазоне (16 - 256) октетов включительно, повторное использование значения Случайного числа не допускается;

3. элемент данных Уведомление должен использоваться для передачи служебной информации.

Формат элемента данных Уведомление приведен на рисунке 11.

Рисунок 11

Примечание:

поле "Идентификатор протокола" (1 октет) должно показывать тип SA, если уведомление относится к существующей SA, должно быть равно "1" для уведомлений IKE_SA, "2" для протокола AH или "3" для протокола ESP для уведомлений, касающихся IPsec, и "0" при передаче и игнорироваться на приеме для уведомлений, не относящихся к существующим SA. Все остальные значения должны быть зарезервированы IANA для использования в будущем.

поле "Размер SPI" (Security Parameter Index) (1 октет) должно указывать размер SPI в октетах;

поле "Тип уведомления" (2 октета) должен задавать тип уведомления;

поле "SPI" должно иметь переменный размер и содержать идентификатор параметров защиты;

поле "Данные уведомления" должно иметь переменный размер и содержать дополнительную информацию к типу уведомления;

3.1. формат элемента данных Удаление приведен на рисунке 12.

Рисунок 12

Примечание:

поле "Идентификатор протокола" (1 октет) должно быть равно "1" для IKE_SA, з "2" - для AH, "3" - для ESP;

поле "Размер SPI" (1 октет) должно содержать размер SPI указанного протокола (в октетах);

поле "Количество SPI" (2 октета) должно содержать количество SPI в элементе данных Удаление;

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

3.2. элемент данных Идентификатор реализации должен имееть одно поле переменного размера, содержащее уникальный идентификатор производителя;

3.3. элементы данных Селектор трафика - Инициатор, Селектор трафика - Ответчик.

Формат элемента Селектор трафика приведены на рисунке 13.

Рисунок 13

Примечание:

поле "Количество селекторов трафика" должно иметь размер 1 октет;

поле "Резерв" (3 октета) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Селектор трафика" должно иметь переменный размер и содержать один или несколько отдельных указателей типа трафика;

3.4. элемент данных Кодирование (Encrypted - далее E), должен содержать другие элементы в зашифрованном виде. При наличии в сообщении элемента Кодирование он должен быть последним в сообщении.

Формату элемента данных Кодирование приведен на рисунке 14.

Рисунок 14

Примечание:

поле "Initialization Vecto" должно содержать случайное значение, совпадающее с размером блока используемого алгоритма шифрования. Получатели должны воспринимать любые значения этого поля, а отправителям следует генерировать псевдослучайное значение независимо для каждого сообщения или использовать для выбора значений шифрованный блок предыдущего сообщения;

поле "Данные IKE" должно быть переменной длины, содержать шифрованные элементы IKE и шифроваться с использованием согласованного алгоритма;

поле "Padding" может содержать любое значение, выбранное отправителем, должно иметь размер, который делает суммарный размер шифрованных элементов, поля "Padding" и поля "Pad Length" кратным размеру блока шифрования "Initialization Vecto" и шифроваться с использованием согласованного алгоритма;

поле "Pad Length" (1 октет) должно содержать информацию о размере поля Padding и шифроваться с использованием согласованного алгоритма. Отправителю следует устанавливать в поле "Pad Length" минимальное значение, которое делает размер полей шифрованных элементов "Padding" и "Pad Length" кратными размеру блока шифрования. Получатель должен принимать любые значения, обеспечивающие требуемое выравнивание. Это поле шифруется с использованием согласованного алгоритма;

поле "Integrity Checksum Data" должно содержать криптографическую контрольную сумму всего сообщения, начиная с фиксированного заголовка IKE и заканчивая полем "Pad Length". Контрольная сумма должна рассчитываться для зашифрованного сообщения. Размер поля должен определяться согласованным алгоритмом защиты целостности;

3.5. элемент данных Конфигурация (CP) должен использоваться для обмена конфигурационными параметрами между партнерами IKE.

Требования к формату элемента данных Конфигурация приведены на рисунке 15.

Рисунок 15

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

поле "Тип обмена" (1 октет) должно содержать информацию о типе обмена данными Конфигурации (REQUEST-1, REPLY-2, SET-3, ACK-4);

поле "Резерв" (3 октета) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Атрибуты конфигурации" должно иметь переменный размер и содержать атрибуты конфигурации в формате "тип-размер-значение".

Элемент данных Конфигурация может содержать несколько атрибутов или не содержит атрибуты;

3.6. элемент данных Расширяемая идентификация (EAP) должен позволять выполнять идентификацию IKE_SA с использованием протокола EAP. Формат элемента данных EAP приведен на рисунке 16.

Рисунок 16

Примечание:

поле "Код" (1 октет) должно показывать тип сообщение и должно быть рано "1" при запросе (Request), "2" при отклике (Response), "3" при успешном завершением (Success) или "4" при отказе (Failure);

поле "Идентификатор" (1 октет) должно использоваться в протоколе PPP, чтобы отличить повторное использование сообщений от повторной передачи. В откликах поле "Идентификатор" должно быть равно значению идентификатора в соответствующем запросе, а в остальных сообщениях может принимать любое значение;

поле "Длина" (2 октета) должно содержать информацию о размере сообщения EAP и быть в 4 раза меньше значения поля "Размер текущего элемента (Payload Lenqth) базового заголовка";

поле "Тип" (1 октет) должно быть только в сообщениях с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должно составлять четыре октета, а поля "Тип" и "Данные" должны отсутствовать. В запросах (1) поле "Тип" должно указывать запрашиваемые данные, а в откликах (2) поле "Тип" должно быть пустым или соответствовать типу запрошенных данных.

Значения поля "Тип":

1 - тождественность;

2 - уведомление;

3 - только отклики;

4-MD5 - вызов;

5 - однократный пароль;

6 - маркерная карта базового типа.

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