RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 4306, Страница 33 из 62

3. Форматы заголовков и данных

3.1. Заголовок IKE

Сообщения IKE используют протокол UDP через порты 500 и/или 4500; передается по одному сообщению IKE в дейтаграмме UDP datagram. Информация от начала пакета до завершения заголовка UDP большей частью игнорируется; исключения составляют адреса IP и номера портов UDP в заголовках, которые сохраняются и используются для передачи ответных пакетов. При передаче через порт UDP 500 сообщение IKE начинается непосредственно после заголовка UDP. При передаче через порт UDP 4500 перед сообщением IKE помещается четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKE и не учитываются в размерах и контрольных суммах IKE. Каждое сообщение IKE начинается с заголовка IKE, обозначаемого в данном документе HDR. После заголовка следует один или множество элементов данных IKE, каждый из которых идентифицируется полем Next Payload в предыдущем элементе данных. Элементы данных обрабатываются в порядке их следования в сообщении IKE путем вызова соответствующей процедуры, согласно значению поля Next Payload в заголовке IKE, потом согласно значению Next Payload в первом элементе данных IKE и так далее, пока в поле Next Payload не будет обнаружено нулевое значение, показывающее отсутствие следующего элемента данных. При обнаружении элемента данных типа Encrypted этот элемент дешифруется и результат расшифровки разбирается, как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете и включать в зашифрованные элементы другие элементы типа Encrypted недопустимо.

Значение Recipient SPI в заголовке идентифицирует экземпляр защищенной связи IKE. Следовательно, один экземпляр IKE может мультиплексровать различные сессии с множеством партнеров.

Многооктетные поля, представляющие собой целые числа используют сетевой порядок байтов (или big endian — старший байт сначала).

Рисунок 4 показывает формат заголовка IKE.

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Initiator's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                       IKE_SA Responder's SPI                  !
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                          Message ID                           !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                            Length                             !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 4: Формат заголовка IKE
  • Initiator's SPI (8 октетов) — значение, выбранное инициатором для уникальной идентификации защищенной связи IKE. Нулевое значение недопустимо.
  • Responder's SPI (8 октетов) — значение, выбранное ответчиком для уникальной идентификации защищенной связи IKE. Это значение должно быть нулевым в первом сообщении начального обмена IKE (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений нудлевое значение недопустимо.
  • Next Payload (1 октет) — показывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.
  • Major Version (4 бита) — задает старшую часть номера версии используемого протокола IKE. Реализации на основе данной версии IKE, должны устанавливать Major Version=2. Реализации, основанные на предыдущих версиях IKE и ISAKMP, должны устанавливать Major Version=1. Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим 2.
  • Minor Version (4 бита) — задает младшую часть номера версии IKE. Реализации на основе этого документа должны устанавливать Minor Version = 0 и игнорировать младшую часть номера в принимаемых сообщениях.
  • Exchange Type (1 октет) — Показывает тип обмена, который будет использоваться. Тип ограничивает набор элементов данных в каждом сообщении и порядок сообщений в обмене. Типы показаны в таблице.
    Тип обмена Значение
    Резерв 0-33
    IKE_SA_INIT 34
    IKE_AUTH 35
    CREATE_CHILD_SA 36
    INFORMATIONAL 37
    Резерв IANA 38-239
    Резерв для частного использования 240-255
  • Flags (1 октет) — показывает специфические опции, установленные для сообщения. Наличие опции указывается установкой соответствующего флага. Биты флагов начинаются с младшего, т. е. Бит 0 является младшим битом октета Flags. В приведенном ниже описании термин «установлен» означает значение бита 1, а термин «сброшен» — значение 0.
    • X(резерв) (биты 0-2) — эти биты должны сбрасываться при передаче и игнорироваться на приеме.
    • I(nitiator) (бит 3 поля Flags) — этот бит должен устанавливаться в сообщениях, передаваемых исходным инициатором IKE_SA, и должен сбрасываться в сообщениях, передаваемых исходным ответчиком. Этот бит позволяет получателю определить, какие восемь октетов SPI были созданы получателем.
    • V(ersion) (бит 4 поля Flags) — этот флаг показывает, что передающий узел способен поддерживать большее значение старшей части номера версии, нежели указано в поле Major Version. Реализации IKEv2 должны сбрасывать этот бит при передаче и игнорировать его во входящих сообщениях.
    • R(esponse) (бит 5 поля Flags) — этот бит показывает, что данное сообщение является откликом на сообщение с таким же идентификатором. Этот бит должен сбрасываться во всех запросах и устанавливаться во всех откликах. Для конечной точки IKE недопустима генерация откликов на сообщения, помеченные, как отклик.
    • X(резерв) (биты 6-7) — эти биты должны сбрасываться при передаче и игнорироваться на приеме.
  • Message ID (4 октета) — идентификатор сообщения служит для управления повторной передачей потерянных пакетов и связывания запросов с откликами. Это поле важно для безопасности протокола, поскольку оно используется для предотвращения атак с повторным использованием перехваченных пакетов (replay-атаки). См. также параграфы 2.1 и 2.2.
  • Length (4 октета) — размер всего сообщения (заголовок и элементы данных) в октетах.

Страница 33 из 62

2007 - 2022 © Русские переводы RFC, IETF, ISOC.