Требования к протоколу 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 Туре" (1 октет) должен указывать тип используемого обмена, ограничивающий набор элементов данных в каждом сообщении и порядок сообщений в обмене.
Типы обмена приведены в таблице N 1.
Таблица N 1.
Тип обмена | Значение |
IKE_SA_INIT | 34 |
IKE_AUTH | 35 |
CREATE_CHILD_SA | 36 |
INFORMATIONAL | 37 |
Резерв IANA | 38-239 |
Резерв для частного использования | 240-255 |
Примечание:
"Flags" (1 октет) должен указывать на наличие специфических опций в сообщении при установлении соответствующего бита флага в "1";
"Message ID" (4 октета) должен содержать идентификатор сообщения и использоваться для управления повторной передачей потерянных пакетов и связывания запросов с откликами;
"Length" (4 октета) должен содержать размер всего сообщения (заголовок и элементы данных) в октетах;
2.3. структура базового заголовка элемента данных (payload) IKEv2 приведена на рисунке 2.