RFC 5996 Internet Key Exchange Protocol Version 2 (IKEv2)

Please enter banners and links.

Internet Engineering Task Force (IETF)                        C. Kaufman
Request for Comments: 5996                                     Microsoft
Obsoletes: 4306, 4718                                         P. Hoffman
Category: Standards Track                                 VPN Consortium
ISSN: 2070-1721                                                   Y. Nir
                                                             Check Point
                                                               P. Eronen
                                                             Independent
                                                          September 2010

Протокол обмена ключами в Internet версии 2 (IKEv2)

Internet Key Exchange Protocol Version 2 (IKEv2)

PDF

Тезисы

В этом документе описана версия 2 протокола IKE¹. Протокол IKE является компонентой IPsec, используемой для взаимной аутентификации, а также организации и поддержки защищенных связей (SA²). Этот документ служит обновлением и заменой RFC 4306, а также включает все разъяснения из RFC 4718.

Статус документа

Этот документ является проектом стандарта Internet (Internet Standards Track).

Документ подготовлен IETF³ и содержит согласованный взгляд сообщества IETF. Документ обсуждался публично и одобрен для публикации IESG⁴. Дополнительная информация о стандартах Internet приведена в разделе 2 RFC 5741.

Информацию о текущем состоянии данного документа, обнаруженных ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc5996.

Авторские права

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

Исключено в версии HTML.

1. Введение

IPsec⁵ обеспечивает конфиденциальность, целостность данных, контроль доступа и проверку подлинности источника данных для дейтаграмм IP. Эти услуги обеспечиваются за счет поддержки состояния, разделяемого источником и потребителем дейтаграмм IP. Это состояние определяет, наряду с прочим, специфические услуги, обеспечиваемые для дейтаграмм, криптографические алгоритмы, которые будут использоваться для предоставления услуг, а также ключи, применяемые криптоалгоритмами.

Организация такого общего состояния вручную не обеспечивает должного уровня масштабирования. Следовательно, нужен протокол динамической организации таких состояний. В данном документе описывается такой протокол – IKE. Первая версия IKE была определена в RFC 2407 [DOI], 2408 [ISAKMP] и 2409 [IKEV1]. Протокол IKEv2 служит заменой всем этим RFC. Протокол IKEv2 был определен в [IKEV2] (RFC 4306) и дополнительно разъяснен в [Clarif] (RFC 4718). Данный документ служит обновлением и заменой RFC 4306 и RFC 4718. Протокол IKEv2 был заменой протокола IKE, не обеспечивающей совместимости со старой версией. В отличие от этого, данный документ не только обеспечивает разъяснение IKEv2, но и минимизирует изменения, вносимые в протокол IKE. Список существенных различий между RFC 4306 и данным документом приведен в параграфе 1.7.

IKE обеспечивает взаимную аутентификацию сторон и организует защищенную связь IKE (SA), включающую общую секретную информацию, которая может использоваться для эффективной организации защищенных связей для ESP⁶ [ESP] или AH⁷ [AH], а также задает набор криптоалгоритмов, который будет использоваться защищенными связями для передачи трафика между сторонами. В этом документе термин шифронабор (suite или cryptographic suite) служит для обозначения полного множества криптографических алгоритмов, служащих для защиты SA. Инициатор предлагает один или множество шифронаборов, перечисляя поддерживаемые алгоритмы, которые могут комбинироваться в шифронаборы. IKE может также согласовывать использование сжатия IPComp⁸ [IP-COMP] для соединений с ESP или AH. Связи SA для ESP или AH, организуемые с использованием IKE SA, будут называться дочерними SA (Child SA).

Все коммуникации IKE осуществляются в формате пар сообщений «запрос-отклик», которые далее будут называться «обменом» (exchange) или «парой запрос-отклик» (request/response pair). Первый обмен сообщениями, организующий IKE SA, называется обменами IKE_SA_INIT и IKE_AUTH, последующие обмены IKE называются CREATE_CHILD_SA или INFORMATIONAL. В общем случае происходит один обмен IKE_SA_INIT и один обмен IKE_AUTH (в сумме четыре сообщения) для организации IKE SA и первой дочерней SA. В исключительных случаях каждый из этих обменов может осуществляться неоднократно. В любом случае все обмены IKE_SA_INIT должны завершаться до выполнения каких-либо других обменов, после этого должны завершаться все обмены IKE_AUTH, а далее может выполняться любое число обменов CREATE_CHILD_SA и INFORMATIONAL в произвольном порядке. В некоторых сценариях требуется только одна дочерняя SA между конечными точками IPsec и, следовательно, дополнительных обменов не происходит. Последующие обмены могут использоваться для организации дополнительных Child SA между теми же аутентифицированными парами конечных точек для выполнения функций поддержки (housekeeping).

Поток сообщений IKE всегда состоит из запросов, за которыми следуют отклики. Ответственность за обеспечение надежной доставки лежит на запрашивающей стороне (requester). Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или разорвать соединение).

Первый обмен в сессии IKE (IKE_SA_INIT) согласует параметры защиты IKE SA, передает nonce и значения Diffie-Hellman.

Второй обмен (IKE_AUTH) передает отождествления, обеспечивает соответствующие им секреты и организует SA для первой (зачастую, единственной) дочерней SA AH или ESP (если не возникает отказа при организации AH или ESP Child SA, когда IKE SA организуется без дочерней SA).

Типами последующих обменов являются CREATE_CHILD_SA (создание дочерней SA) и INFORMATIONAL (удаление SA, информация об ошибках и прочие функции housekeeping). На каждый запрос требуется давать отклик. Запрос INFORMATIONAL без данных (кроме пустого поля Encrypted, требуемого синтаксисом) в общем случае используется для проверки жизнеспособности. Такие обмены не могут происходить до завершения начального обмена.

В приведенных далее описаниях предполагается отсутствие ошибок. Изменение потока сообщений для случаев возникновения ошибок рассмотрено в параграфе 2.21.

1.1. Сценарии использования

IKE используется для согласования защищенных связей ESP или AH в разных сценариях, каждый из которых имеет свои требования.

1.1.1. Взаимодействие между защитными шлюзами в туннельном режиме

             +-+-+-+-+-+            +-+-+-+-+-+
             | Конечная| Туннель    | Конечная|
Защищенная   | точка   | Ipsec      | точка   |     Защищенная
подсеть  <-->| туннеля |<---------->| туннеля |<--> подсеть
             |         |            |         |
             +-+-+-+-+-+            +-+-+-+-+-+

Рисунок 1. Туннель между защитными шлюзами

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

1.1.2. Взаимодействие между конечными точками в транспортном режиме

+-+-+-+-+-+-+                             +-+-+-+-+-+-+
|           |   SA в транспортном или     |           |
|Защищенная |   туннельном режиме IPsec   |Защищенная |
|точка      |<--------------------------->|точка      |
|           |                             |           |
+-+-+-+-+-+-+                             +-+-+-+-+-+-+

Рисунок 2. Взаимодействие между парой конечных точек

В этом сценарии обе конечных точки соединения IP реализуют IPsec в соответствии с требованиями к хостам [IPSECARCH]. Транспортный режим в общем случае не использует внутреннего заголовка IP. Для пакетов, защищаемых данной SA, согласуется одна пара адресов. Конечные точки могут реализовать на прикладном уровне контроль доступа на базе аутентифицированных IPsec отождествлений участников. Этот сценарий обеспечивает сквозную защиту, являющуюся одним из базовых принципов Internet в соответствии с [ARCHPRINC] и [TRANSPARENCY], а также метод снижения унаследованных проблем, связанных со сложностью сетей, как отмечено в [ARCHGUIDEPHIL]. Хотя этот сценарий не полностью применим для IPv4 в Internet, об был успешно развернут в intranet-сетях, использующих IKEv1. Этот метод получит более широкое распространение по мере перехода на IPv6 и адаптации IKEv2.

В этом сценарии возможно размещение одной или обеих защищенных конечных точек за узлом трансляции адресов (NAT⁹). В этом случае туннелируемые пакеты могут инкапсулироваться в UDP так, чтобы номера портов в заголовках UDP могли служить для идентификации конечных точек, расположенных за NAT (см. параграф 2.23).

1.1.3. Туннель между конечной точкой и защитным шлюзом

+-+-+-+-+-+-+                         +-+-+-+-+-+-+
|           |         Туннель         |           |     Защищенная
|Защищенная |         IPsec           |Оконечная  |     подсеть
|точка      |<----------------------->|точка      |<--- и/или
|           |                         |туннеля    |     Internet
+-+-+-+-+-+-+                         +-+-+-+-+-+-+

Рисунок 3. Туннель между конечной точкой и защитным шлюзом

В этом сценарии защищенная конечная точка (обычно перемещаемый портативный компьютер) подключается к корпоративной сети через защищенный с помощью IPsec туннель. Этот туннель может использоваться для доступа к ресурсам корпоративной сети или служить для передачи всего трафика через корпоративную сеть с целью использования обеспечиваемых корпоративным межсетевым экраном услуг защиты от атак из сети Internet. В любом случае защищенной конечной точке требуется адрес IP, связанный с защитным шлюзом, чтобы возвращаемые этой точкой пакеты попадали на защитный шлюз и туннелировались назад. Этот адрес IP может задаваться статически или динамически выделяться защитным шлюзом. Для поддержки второго варианта в IKEv2 обеспечивается механизм (а именно, конфигурационные данные – configuration payload), позволяющий инициатору запросить адрес IP, принадлежащий защитному шлюзу для использования в рамках данной SA.

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

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

1.1.4. Другие сценарии

Возможны и другие сценарии, являющиеся вложенными комбинациями описанных выше вариантов. Одним из значимых примеров является комбинация аспектов, описанных в параграфах 1.1.1 и 1.1.3. Подсеть может осуществлять все внешние взаимодействия через удаленный защитный шлюз, используя туннель IPsec, когда адреса подсети маршрутизируются защитному шлюзу через сеть Internet. Примером может служить домашняя сеть, виртуально являющаяся частью Internet со статическими адресами IP, хотя подключение осуществляется через ISP, выделившего один динамический адрес IP для пользовательского защитного шлюза (статические адреса IP и трансляция IPsec обеспечиваются третьей стороной, расположенной в другом месте).

1.2. Начальный обмен

Коммуникации с использованием IKE всегда начинаются с обменов IKE_SA_INIT и IKE_AUTH (в IKEv1 называются фазой 1 – Phase 1). Эти начальные обмены обычно включают 4 сообщения, хотя в некоторых сценариях число этих сообщений может быть больше. Все коммуникации с использованием IKE состоят из пар запрос-отклик. Сначала будет описан базовый обмен, а потом — возможные варианты. Первая пара сообщений (IKE_SA_INIT) согласует криптографические алгоритмы, осуществляет обмен nonce и обмен Diffie-Hellman [DH].

Вторая пара сообщений (IKE_AUTH) аутентифицирует предыдущие сообщения, обменивается отождествлениями и сертификатами, а также организует первую Child SA. Отдельные части этих сообщений шифруются и целостность их защищается с использованием ключей, организованных при обмене IKE_SA_INIT, что позволяет скрыть отождествление от просмотра и аутентифицировать все поля сообщений (в MITM-атаке¹⁰ нарушитель, который не может завершить обмен IKE_AUTH, тем не менее, способен увидеть отождествление инициатора). Информация о генерировании ключей шифрования приведена в параграфе 2.14.

Обозначение	Тип данных
AUTH	Аутентификация
CERT	Сертификат
CERTREQ	Запрос сертификата
CP	Конфигурация
D	Удаление
EAP	Расширяемая аутентификация
HDR	Заголовок IKE (не данные)
IDi	Идентификация – инициатор
IDr	Идентификация – ответчик
KE	Обмен ключами
Ni, Nr	Nonce
N	Уведомление
SA	Защищенная связь
SK	Зашифровано и аутентифицировано
TSi	Селектор трафика – инициатор
TSr	Селектор трафика – ответчик
V	Идентификатор производителя

Все сообщения после начального обмена защищаются криптографически с использованием алгоритмов и ключей, согласованных при обмене IKE_SA_INIT. В этих сообщениях используется синтаксис полей данных Encrypted, описанных в параграфе 3.14, которые шифруются с ключами, полученными, как описано в параграфе 2.14. Все последующие сообщения включают поле Encrypted, даже если эти сообщения указаны в документе, как «пустые». Для обменов CREATE_CHILD_SA, IKE_AUTH и INFORMATIONAL сообщение, следующее после заголовка, шифруется, а целостность сообщения вместе с заголовком защищается с помощью криптоалгоритмов, согласованных для IKE SA.

Каждое сообщение IKE содержит идентификатор Message ID, как часть фиксированного заголовка. Значения Message ID служат для сопоставления запросов и откликов, а также для идентификации повторов передачи сообщений.

В последующих описаниях поля данных (payload), содержащиеся в сообщениях, идентифицируются по именам, приведенным в таблице справа.

Подробные описания всех типов данных (payload) приведены в разделе 3. Данные, являющиеся необязательными, указываются в квадратных скобках – например, [CERTREQ] показывает, что данные запроса сертификата могут включаться опционально.

Изначальный обмен выполняется следующим образом

   Инициатор                         Ответчик
   ---------------------------------------------------
   HDR, SAi1, KEi, Ni  -->

HDR содержит индексы параметров защиты (SPI¹¹), номера версий и флаги разных типов. Поле SAi1 указывает криптографические алгоритмы, которые инициатор поддерживает для IKE SA. Поле KE содержит значение Diffie-Hellman для инициатора, а Ni – nonce инициатора.

                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]

Отвечающая сторона выбирает шифронабор из предложенных инициатором вариантов и указывает свой выбор в поле SAr1, завершает обмен Diffie-Hellman своим значением в поле KEr и передает свое значение nonce в поле Nr.

На этом этапе согласования каждая из сторон может генерировать значение SKEYSEED, из которого создаются все ключи для данной IKE SA. Последующие сообщения шифруются и целостность их защищается (за исключением заголовка). Ключи, используемые для шифрования и защиты целостности, создаются из SKEYSEED и называются SK_e (шифрование) и SK_a (аутентификация, иначе защита целостности). Подробное описание создания ключей приведено в параграфах 2.13 и 2.14. Ключи SK_e и SK_a создаются отдельно для каждого направления. В дополнение к ключам SK_e и SK_a, получаемым из значения Diffie-Hellman для защиты IKE SA, создается значение SK_d, используемое при создании ключевого материала для дочерних SA. Нотация SK { … } показывает, что поля зашифрованы и целостность их защищена с использованием ключей SK_e и SK_a для соответствующего направления.

   HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, Sai2, TSi, TSr}  -->

Инициатор представляет свое отождествление в поле IDi, подтверждает знание секрета, соответствующего IDi, и защищает целостность содержимого первого сообщения с использованием поля AUTH (см. параграф 2.15). Он может также передать сертификат(ы) в поле(ях) CERT и список доверенных привязок в поле(ях) CERTREQ. При включении какого-либо поля CERT первый представленный сертификат должен содержать открытый ключ, используемый для верификации поля AUTH.

Необязательное поле IDr дает инициатору возможность задать отождествления ответчика, которые он желает получить. Это полезно в тех случаях, когда на отвечающей машине имеется множество отождествлений для одного адреса IP. Если предложенное инициатором отождествление IDr неприемлемо для ответчика, тот может использовать иное значение IDr для завершения обмена. Если инициатор не воспримет от отвечающей стороны значение IDr, отличающееся от запрошенного, он может закрыть SA после фиксации этого факта.

Селекторы трафика (TSi и TSr) рассматриваются в параграфе 2.9.

Инициатор начинает согласование Child SA, используя поле SAi2. Заключительные поля (начиная с SAi2) рассмотрены в описании обмена CREATE_CHILD_SA.

                                <--  HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Ответчик представляет свое отождествление в поле IDr и может также передать один или множество сертификатов (сертификат, содержащий открытый ключ для верификации AUTH, снова должен указываться первым), аутентифицирует свое отождествление и защищает целостность второго сообщения с помощью поля AUTH и завершает согласование Child SA дополнительными полями, рассмотренными ниже при описании обмена CREATE_CHILD_SA.

Обе стороны обмена IKE_AUTH должны удостовериться, что все сигнатуры и коды MAC¹² рассчитаны корректно. Если любая из сторон использует для аутентификации общий секрет, имена в полях ID должны соответствовать ключам, используемым для генерации полей AUTH.

Поскольку инициатор передает свое значение Diffie-Hellman в IKE_SA_INIT, он должен предсказать группу Diffie-Hellman, которую ответчик выберет из предложенного им списка поддерживаемых групп. Если предсказание инициатора окажется ошибочным, ответчик передаст поле Notify типа INVALID_KE_PAYLOAD, показывающее выбранную группу. В этом случае инициатор должен повторить IKE_SA_INIT с корректной группой Diffie-Hellman. Инициатор должен снова предложить полный список подходящих для него шифронаборов, поскольку сообщение об отказе не было аутентифицировано. Отказ от такой практики позволит организовать активные атаки, в результате которых злоумышленник может вынудить конечные точки к выбору не самого сильного из поддерживаемых обеими сторонами шифронаборов.

Если при создании Child SA в процессе обмена IKE_AUTH возникает тот или иной сбой, связь IKE SA все равно создается, как обычно. Список типов сообщений Notify в обмене IKE_AUTH, которые не препятствуют организации IKE SA, включает, по крайней мере NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE и FAILED_CP_REQUIRED.

Если отказ связан с созданием IKE SA (например, возвращено сообщение об ошибке Notify с типом AUTHENTICATION_FAILED), связь IKE SA не организуется. Отметим, что, несмотря на шифрование и защиту целостности сообщений IKE_AUTH, если получивший такое сообщение Notify об ошибке партнер еще не аутентифицирован другой стороной (или аутентификация по той или иной причине завершилась отказом), эта информация должна восприниматься с осторожностью. Точнее говоря, в предположении, что значение MAC прошло верификацию, будет известно, что отправителем сообщения Notify является отвечающая сторона обмена IKE_SA_INIT, но отождествление отправителя проверить невозможно.

Отметим, что сообщения IKE_AUTH не содержат полей KEi/KEr и Ni/Nr. Таким образом, поля SA в обмене IKE_AUTH не могут включать Transform Type 4 (группа Diffie-Hellman) со значениями, отличными от NONE. Реализациям следует опускать всю субструктуру преобразования вместо передачи значения NONE.

1.3. Обмен CREATE_CHILD_SA

Обмен CREATE_CHILD_SA используется для организации новых Child SA и замены ключей сразу для IKE SA и Child SA. Этот обмен включает одну пару «запрос-отклик»; некоторые из функций этого обмена назывались фазой 2 (Phase 2) в обмене IKEv1. Этот обмен может инициироваться любой из сторон IKE SA после завершения начального обмена.

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

Любая из конечных точек может инициировать обмен CREATE_CHILD_SA, поэтому в данном параграфе инициатором будет называться именно эта точка. Реализация может отвергать все запросы CREATE_CHILD_SA в рамках IKE SA.

Запрос CREATE_CHILD_SA может включать поле KE для дополнительного обмена Diffie-Hellman, чтобы обеспечить более высокий уровень защиты для Child SA. Ключевой материал для Child SA обеспечивает функция SK_d, организованная при создании IKE SA, значения nonce, обмен которыми осуществляется в процессе CREATE_CHILD_SA, и значение Diffie-Hellman (если поля KE включены в обмен CREATE_CHILD_SA).

Если обмен CREATE_CHILD_SA включает поле KEi, по крайней мере одна из SA должна включать группу Diffie-Hellman этого KEi. Группой Diffie-Hellman для KEi должен быть элемент группы, который инициатор предполагает приемлемым для ответчика (могут быть предложены дополнительные группы Diffie-Hellman). Если ответчик выбирает другую группу Diffie-Hellman (отличную от NONE), он должен отвергнуть запрос и указать предпочтительную группу Diffie-Hellman с помощью INVALID_KE_PAYLOAD Notify. С этим уведомлением связаны два октета данных, указывающих номер приемлемой группы Diffie-Hellman (порядок битов big endian). В случае такого отказа обмен CREATE_CHILD_SA завершается неудачей и инициатор может повторить обмен с предложением группы Diffie-Hellman и KEi из группы, которую ответчик указал в поле INVALID_KE_PAYLOAD Notify.

Ответчик передает уведомление NO_ADDITIONAL_SAS для индикации неприемлемости запроса CREATE_CHILD_SA по причине нежелания ответчика организовывать дополнительные дочерние SA в данной IKE SA. Такое уведомление может служить также для отказа от смены ключей IKE SA. Некоторые минимальные реализации могут воспринимать организацию только одной связи Child SA в контексте начального обмена IKE и отвергать все последующие попытки добавления.

1.3.1. Создание дочерних SA с помощью обмена CREATE_CHILD_SA

Дочерняя связь Child SA может быть создана путем передачи запроса CREATE_CHILD_SA, как показано ниже.

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, [Kei], TSi, TSr}  -->

Инициатор отправляет предложение(я) SA в поле SA, значение nonce в поле Ni, опционально указывает значение Diffie-Hellman в поле KEi и предлагаемые селекторы трафика для предлагаемой Child SA в полях TSi и TSr.

Отклик CREATE_CHILD_SA для создания новой Child SA имеет вид

                                <--  HDR, SK {SA, Nr, [KEr], TSi, TSr}

Ответчик передает отклик (с тем же значением Message ID) с воспринятым предложением в поле SA и значением Diffie-Hellman в поле KEr, если в запросе было поле KEi и выбранный шифронабор включает данную группу.

Селекторы для трафика, передаваемого через эту связь SA, задаются в полях TS отклика и могут быть подмножеством предложенных инициатором Child SA.

В запрос может включаться уведомление USE_TRANSPORT_MODE, которое также включает поле SA, запрашивающее Child SA. Оно запрашивает для создаваемой Child SA использование транспортного режима вместо туннельного¹³. Если запрос принимается, отклик также должен включать уведомление типа USE_TRANSPORT_MODE. Если ответчик отвергает запрос, Child SA будет организована с использованием туннельного режима. Если это неприемлемо для инициатора, он должен удалить SA.

Уведомление ESP_TFC_PADDING_NOT_SUPPORTED показывает, что передающая конечная точка не будет воспринимать пакеты с заполнением TFC¹⁴ через согласуемую Child SA. Если ни одна из конечных точек не воспринимает заполнение TFC, это уведомление включается как в запрос, так и в отклик. Если уведомление включено только в одно из сообщений, для противоположного направления заполнение TFC может использоваться.

Для контроля фрагментации используется уведомление NON_FIRST_FRAGMENTS_ALSO. Более подробно описание контроля фрагментации приведено в [IPSECARCH]. Обе стороны должны согласовать между собой передачу отличных от первого фрагментов до того, как любая из них начнет передавать такие фрагменты. Передача возможна лишь в тех случаях, когда уведомление NON_FIRST_FRAGMENTS_ALSO включено как в запрос SA, так и в отклик с согласием на организацию связи. Если ответчик не хочет принимать или передавать отличные от первого фрагменты, он просто не включает уведомление NON_FIRST_FRAGMENTS_ALSO в свой отклик, не отвергая создания Child SA.

В сообщение также можно включать уведомление IPCOMP_SUPPORTED, описанное в параграфе 2.22.

При неудачной попытке создания Child SA не следует разрывать организованную связь IKE SA (нет причин для отказа от выполненной работы по созданию IKE SA). Сообщения об ошибках, которые могут возникать при неудачном создании Child SA, описаны в 2.21.

1.3.2. Смена ключей IKE SA с помощью обмена CREATE_CHILD_SA

Запрос CREATE_CHILD_SA для смены ключей IKE SA имеет вид

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, KEi} -->

Инициатор передает предложение(я) SA в поле SA, значение nonce в поле Ni и значение Diffie-Hellman в поле KEi (должно включаться). Новое значение SPI инициатора представляется в поле SPI элемента SA. После того, как партнер получит запрос на смену ключей для IKE SA или передаст такой запрос, ему не следует начинать обменов CREATE_CHILD_SA для связи IKE SA, в которой будут меняться ключи.

Отклик CREATE_CHILD_SA для замены ключей IKE SA имеет вид

                                <--  HDR, SK {SA, Nr, KEr}

Ответчик передает (с тем же значением Message ID) принятое предложение в поле SA и значение Diffie-Hellman в поле KEr, если выбранный шифронабор включает данную группу. Новое значение SPI ответчика передается в поле SPI элемента SA.

Для новой связи IKE SA значение счетчика сообщений устанавливается в 0, независимо от значения счетчика в предшествующей IKE SA. Первые запросы IKE с обеих сторон новой IKE SA будут иметь Message ID=0. Нумерация старой связи IKE SA сохраняется и любые последующие запросы (например, на удаление IKE SA) будут использовать соответствующие номера. В новой IKE SA также устанавливается размер окна 1, а инициатор смены ключей становится «исходным инициатором» новой связи IKE SA.

В параграфе 2.18 смена ключей IKE SA описана более детально.

1.3.3. Смена ключей Child SA с помощью обмена CREATE_CHILD_SA

Запрос CREATE_CHILD_SA для смены ключей Child SA имеет вид

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {N(REKEY_SA), SA, Ni, 
      [Kei], TSi, TSr}            -->

Инициатор передает предложение(я) SA в поле SA, значение nonce в поле Ni, опциональное значение Diffie-Hellman в поле KEi и предлагаемые селекторы трафика для предложенной Child SA в полях TSi и TSr.

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

Если целью обмена сообщениями является замена существующей защищенной связи (SA) ESP или AH, в обмен CREATE_CHILD_SA должно включаться уведомление REKEY_SA. Связь SA, для которой будут меняться ключи, указывается полем SPI в элементе Notify (это значение SPI, которое инициатор обмена будет ожидать во входящих пакетах ESP или AH). С этим типом сообщений Notify не связано каких-либо данных. Поле Protocol ID в уведомлении REKEY_SA устанавливается в соответствии с протоколом SA, для которой меняются ключи (3 для ESP, 2 для AH).

Отклик CREATE_CHILD_SA для смены ключей Child SA имеет вид

                                <--  HDR, SK {SA, Nr, [KEr], TSi, TSr}

Ответчик передает (с тем же Message ID) принятое предложение в поле SA и значение Diffie-Hellman в поле KEr, если KEi было указано в запросе и выбранный шифронабор включает эту группу.

Селекторы для трафика, который будет передаваться через данную SA, задаются в полях TS отклика и могут быть подмножеством селекторов, предложенных инициатором Child SA.

1.4. Обмен INFORMATIONAL

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

Управляющие сообщения, относящиеся к IKE SA, должны передаваться через данную IKE SA. Управляющие сообщения, которые относятся к Child SA, должны передаваться под защитой IKE SA, в которой создана дочерняя связь (или наследующей IKE SA, если были сменены ключи).

Сообщения в обмене INFORMATIONAL могут содержать поля Notification, Delete и Configuration. Получатель запроса INFORMATIONAL должен передать тот или иной отклик. В противном случае отправитель будет предполагать, что сообщение потерялось в сети и повторно передавать его. Откликом может служить пустое сообщение. Запросное сообщение в обмене INFORMATIONAL может не содержать никакой информации (payload). Таким способом один из участников может проверить жизнеспособность другой стороны.

Обмен INFORMATIONAL определяется следующим образом.

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {[N,] [D,] [CP,] ...}  -->
                                  <--  HDR, SK {[N,] [D,] [CP], ...}

Обработка обмена INFORMATIONAL определяется содержимым его компонент.

1.4.1. Удаление SA с помощью INFORMATIONAL

Защищенные связи (SA) ESP и AH всегда существуют парами, по одной SA в каждом направлении. При разрыве SA оба члена пары должны быть закрыты (т. е., удалены). Каждая из конечных точек должна закрыть свои входящие SA и позволить другой точке закрыть соответствующую SA из каждой пары. Для удаления SA выполняется обмен INFORMATIONAL с одним или множеством полей Delete, указывающих значения SPI (какими они ожидаются во входящих пакетах) удаляемых связей SA. Получатель должен закрыть указанные SA. Отметим, что поля Delete никогда не передаются для двух сторон одной SA в одном сообщении. Если одновременно удаляется множество SA, сообщение в обмене INFORMATIONAL включает поля Delete для входящей половины каждой удаляемой пары SA.

Обычно отклики в обмене INFORMATIONAL содержат поля Delete для парных SA противоположного направления, однако имеется одно исключение. Если обе стороны некоторого множества SA независимо решили разорвать эти связи, каждая из сторон может отправить Delete и два запроса могут «столкнуться» в сети. Если узел получает запрос на удаление SA, для которых он сам уже отправил запрос на удаление, он должен удалить исходящие SA в процессе обработки запроса, а входящие – в процессе обработки отклика. В таких случаях в отклики недопустимо включать поля Delete для удаленных SA, поскольку это приведет к дублированию удаления и может (в теории) привести к удалению не тех SA.

Подобно связям ESP и AH, IKE SA также удаляются с помощью информационного обмена. УдалениеIKE SA неявно закрывает все оставшиеся дочерние SA, согласованные для этой связи. Ответ на запрос, который удаляет IKE SA, является пустым откликом INFORMATIONAL.

Полузакрытые соединения ESP и AH являются аномалией и узлам с поддержкой аудита, вероятно следует проверять наличие таких соединений. Отметим, что данная спецификация не задает период ожидания, так что каждая конечная точка вольна самостоятельно определять его. Узел может отказаться принимать данные через полузакрытые соединения, но недопустимо в одностороннем порядке закрывать их с повторным использованием SPI. Если в состояниях накопилось достаточно путаницы, узел может закрыть IKE SA, как описано выше. Нужные SA можно перестроить, организовав новую связь IKE SA.

1.5. Информационные сообщения за пределами IKE SA

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

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

В первом случае, если принимающий узел имеет активную IKE SA для IP-адреса, с которого был получен пакет, он может передать уведомление INVALID_SPI отправителю пакета через IKE SA с использованием обмена INFORMATIONAL. В поле Notification Data указывается значение SPI неприемлемого пакета. Получатель этого уведомления не сможет определить, относится SPI к AH или ESP, но это не имеет существенного значения, поскольку значения SPI для этих протоколов будут разными. При отсутствии подходящей IKE SA узел может передать информационное сообщение без криптографической защиты по IP-адресу отправителя пакета, используя UDP-порт отправителя в качестве порта назначения, если принятый пакет относился к протоколу UDP (ESP или AH с инкапсуляцией в UDP). В этом случае получателю следует использовать такое сообщение, только как намек на возможное возникновение каких-то неполадок, поскольку такое сообщение очень просто подделать. Это сообщение не является частью обмена INFORMATIONAL и принимающему узлу недопустимо отвечать на него, поскольку такой отклик может приводить к зацикливанию обмена сообщениями. В сообщениях этого типа нет значений IKE SPI, важных для получателя, поэтому возможна установка нулевых или случайных значений (исключением является правило параграфа 3.1, которое запрещает использование нулевых значений IKE Initiator SPI). Флаг Initiator имеет значение 1, флаг Response – 0, а флаг версии устанавливается, как обычно (описания флагов приведены в параграфе 3.1).

Для второго и третьего варианта сообщения всегда передаются без криптографической защиты (за пределами IKE SA) и включают уведомление INVALID_IKE_SPI или INVALID_MAJOR_VERSION (без данных). Сообщение является откликом и, таким образом, передается по адресу IP и в порт, откуда поступил запрос, с теми же значениями IKE SPI, Message ID и Exchange Type, которые были в запросе. Флаг Response имеет значение 1, флаги версии устанавливаются, как обычно.

1.6. Уровни требований

Определения основных терминов (таких, как защищенная связь – SA), используемых в этом документе, можно найти в [IPSECARCH]. Следует отметить, что в некоторых случаях IKEv2 работает на основе правил [IPSECARCH], как указано в соответствующих разделах этого документа.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [MUSTSHOULD].

1.7. Существенные отличия от RFC 4306

Этот документ содержит разъяснения и уточнения для протокола IKEv2 [IKEV2]. Многие из разъяснений основаны на работе [Clarif]. Изменения, перечисленные в этом документе, обсуждались в рабочей группе IPsec, а после ее расформирования – в списке рассылки IPsec. Документ содержит подробные разъяснения областей, которые оставались неясными в спецификации IKEv2 и, таким образом, будет полезен разработчикам решений IKEv2.

Протокол, описанный в этом документе, сохраняет значения старшего (2) и младшего (0) номера версии, которые использовались в RFC 4306. Таким образом, номер версии не отличается от RFC 4306. Предполагается, что небольшое число технических изменений, внесенных здесь, не повлияет на уже развернутые реализации RFC 4306.

Ссылки и рисунки в этом документе более согласованы, нежели в [IKEV2].

Разработчики IKEv2 отметили, что требования уровня следует (SHOULD) в RFC 4306 зачастую неясны и не всегда можно определить соответствие реализации этим требованиям. Отмечено также наличие требования уровня должно (MUST), не связанных с интероперабельностью. В данном документе приведены дополнительные разъяснения некоторых из этих требований. Во всех случаях, когда слова следует или должно не выделены шрифтом, они имеют обычную трактовку и не относятся к требованиям интероперабельности [MUSTSHOULD].

Разработчики IKEv2 (и IKEv1) отметили, что приходится много работать с таблицами кодов параграфа 3.10.1 в RFC 4306. Это приводило к тому, что некоторые разработчики не читали остальные части документа. Значительная часть материала из указанных таблиц была перенесена в соответствующие разделы документа.

Из этого документа удалено обсуждение AH и ESP, включенное в RFC 4306 по ошибке, связанной с задержкой между публикацией RFC 4306 и RFC 4301. IKEv2 базируется в основном на спецификации RFC 4301, которая не включает связки SA (SA bundle), присутствовавшие в RFC 2401. Хотя один пакет может проходить обработку IPsec неоднократно, в каждом из таких проходов используется отдельная связь SA и проходы контролируются таблицами пересылки. В IKEv2 каждая из таких SA создается с использованием отдельного обмена CREATE_CHILD_SA.

Из этого документа удалено обсуждение конфигурационного атрибута INTERNAL_ADDRESS_EXPIRY, поскольку его реализация была весьма проблематичной. Реализации, соответствующие этому документу, должны игнорировать предложения с конфигурационным атрибутом типа 5 (старое значение для INTERNAL_ADDRESS_EXPIRY). Этот документ также удаляет конфигурационный атрибут INTERNAL_IP6_NBNS.

Этот документ отменяет разрешение отвергать сообщения, в котором элементы данных (payload) располагались в «некорректном» порядке; сейчас реализациям недопустимо так поступать. Это обусловлено недостаточной ясностью описания порядка следования элементов.

Списки элементов из RFC 4306 для включения в реестр IANA были усечены с включением лишь тех элементов, которые были действительно определены в RFC 4306. Кроме того, многим таким спискам сейчас предшествуют важные инструкции для разработчиков, в которых указано, что на практике следует обращаться к реестру IANA на момент выполнения разработки, поскольку с момента публикации RFC 4306 были добавлены новые элементы.

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

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

В параграфе 1.3.2 требование «KEi следует включать» заменено требованием «должно включаться». Это привело также к изменениям в параграфе 2.18.

В параграфе 2.1 добавлен материал об использовании значений SPI и/или IP инициатора для того, чтобы отличать «полуоткрытые» IKE SA от новых запросов.

В этом документе разъяснено использование флага критичности (параграф 2.5).

В параграфе 2.8 предложение «Отметим, что при смене ключей новая Child SA может иметь селекторы трафика и алгоритмы, отличные от значений для прежней связи.» заменено на «Отметим, что при смене ключей новой Child SA не следует иметь селекторы трафика и алгоритмы, отличные от значений для прежней связи.».

Новый параграф 2.8.2 посвящен одновременной смене ключей IKE SA.

Новый параграф 2.9.2 посвящен селекторам трафика при смене ключей.¹⁵

В параграфе 2.13 добавлено ограничение, в соответствии с которым все псевдослучайные функции (PRF¹⁶), используемые с IKEv2, должны иметь ключи переменного размера. Это требование не должно повлиять на существующие реализации, поскольку неизвестно ни одной стандартизованной PRF с фиксированным размером ключа.

Параграф 2.18 требует выполнения обмена Diffie-Hellman при смене ключей IKE_SA. Теоретически, RFC 4306 разрешает выполнять обмен Diffie-Hellman опционально, но это не полезно (или не приемлемо) при смене ключей IKE_SA.

Параграф 2.21 существенно расширен в части рассмотрения различных случаев, когда требуются отклики на ошибки.

В параграфе 2.23 разъяснено, что при работе через NAT пакеты IPsec, с инкапсуляцией в UDP и без нее, должны быть понятными при получении.

Добавлен параграф 2.23.1, описывающий работу через NAT при запросе транспортного режима.

Добавлен параграф 2.25, объясняющий действия при возникновении конфликтов синхронизации во время удаления и/или смены ключей SA и определяющий два новых уведомления об ошибках (TEMPORARY_FAILURE и CHILD_SA_NOT_FOUND).

В параграф 3.6 добавлен текст: «Реализации должны поддерживать метод HTTP для поиска hash-and-URL. Поведение других URL-методов в настоящее время не задается и такие методы не следует применять при отсутствии спецификаций для них.».

В параграф 3.15.3 добавлена ссылка на новый документ, относящийся к настройке адресов IPv6.

Приложение C расширено и сделано более понятным.

2. Детали и варианты протокола IKE

IKE обычно принимает (слушает) и передает пакеты через порт UDP 500, хотя сообщения IKE могут приниматься и на порту UDP 4500 с использованием слегка отличающегося формата (см. параграф 2.23). Поскольку протокол UDP работает на основе дейтаграмм (без гарантий доставки), IKE включает восстановление при ошибках передачи, включая потерю и повтор пакетов, а также поддельные пакеты. IKE рассчитан на работу при выполнении двух минимальных требований – (1) по крайней мере один из серии повторных пакетов достигнет адресата до тайм-аута и (2) канал не заполнен поддельными и повторно используемыми пакетами до такой степени, что недостаточно пропускной способности сети или ресурсов CPU какой-либо из конечных точек. Даже при невыполнении этих минимальных требований IKE рассчитан на корректное прерывание работы (как при «обрыве» сети).

Хотя сообщения IKEv2 предполагаются короткими, они содержат структуры, для которых не установлен жестко верхний предел размера (в частности, цифровые сертификаты), а IKEv2, сам по себе, не включает механизма фрагментации больших сообщений. Протокол IP определяет механизм для фрагментации сообщений UDP избыточного размера, но реализации существенно различаются по значениям максимального поддерживаемого размера. Кроме того, фрагментация IP открывает реализации для DoS-атак [DOSUDPPROT]. Более того, некоторые трансляторы NAT и/или межсетевые экраны могут блокировать фрагменты IP.

Все реализации IKEv2 должны обеспечивать возможность передачи, приема и обработки сообщений IKE размером до 1280 октетов, а также следует обеспечивать возможность передачи, приема и обработки пакетов размером до 3000 октетов. Реализации IKEv2 должны быть осведомлены о максимальном поддерживаемом размере сообщений UDP и могут укорачивать сообщения, исключая некоторые сертификаты или шифронаборы, если это позволит сохранить размер сообщения в допустимых пределах. Использование формата «Hash and URL¹⁷» вместо включения сертификатов позволяет избавиться от большинства проблем. При реализации и настройке следует принимать во внимание, что в условиях, когда поиск URL становится возможным только после организации Child SA, этот метод может не сработать.

Данные UDP во всех пакетах, содержащих сообщения IKE, переданные в порт 4500, должны начинаться с префикса из четырех нулей (в противном случае получатель не будет знать, как их обрабатывать).

2.1. Использование таймеров повтора передачи

Все сообщения IKE существуют попарно – запрос и отклик. Организация IKE SA обычно включает два обмена. После организации IKE SA любая из сторон защищенной связи SA может в любой момент инициировать запросы, в каждый момент «на лету» может находиться множество запросов и откликов. Каждое сообщение маркируется, как запрос или отклик, и для каждого обмена одна сторона SA является инициатором (initiator), а вторая – ответчиком (responder).

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

IKE является протоколом с гарантией доставки – инициатор должен повторять запрос, пока на него не будет получен соответствующий отклик или не будет принято решение о возникновении сбоя в IKE SA. В последнем случае инициатор отбрасывает все состояния, связанные с IKE SA и всеми Child SA, согласованными в данной IKE SA. Повторные запросы от инициатора должны быть идентичны исходному запросу (с точностью до бита). Т. е., все биты, начиная с заголовка IKE (перед SPI инициатора IKE SA) должны совпадать; элементы до заголовка IKE (например, заголовки IP и UDP) могут отличаться в повторах.

Повторная передача запроса IKE_SA_INIT требует специальной обработки. Когда ответчик получает запрос IKE_SA_INIT, он проверяет, является пакет повторным, относящимся к имеющимся «полуоткрытым IKE SA (в этом случае повторяет передачу созданного ранее отклика), или новым (в этом случае ответчик создает новую IKE SA и передает соответствующий отклик) запросом или относится к существующей IKE SA, в которой запрос IKE_AUTH уже был получен (в этом случае ответчик игнорирует запрос).

Для дифференциации трех описанных выше случаев недостаточно значений SPI и/или IP-адреса инициатора, поскольку два разных партнера за одним устройством NAT могут выбрать одинаковые значения SPI для инициатора. Отказоустойчивый ответчик будет выполнять поиск IKE SA, используя весь пакет, его хэш или данные Ni.

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

2.2. Использование порядковых номеров для Message ID

Каждое сообщение IKE содержит идентификатор Message ID в своем фиксированном заголовке. Значение Message ID служит для сопоставления откликов с запросами и обнаружения повторной передачи сообщений. При повторе сообщения должно использоваться такое же значение Message ID, как в исходном сообщении.

Message ID представляет собой 32-битовое число, которое имеет нулевое значение для сообщений IKE_SA_INIT (включая повторы по причине откликов типа COOKIE и INVALID_KE_PAYLOAD) и инкрементируется для каждого последующего обмена. Таким образом, первая пара сообщений IKE_AUTH имеет Message ID = 1, вторая пара (при использовании EAP) будет иметь идентификатор 2 и т. д. Значение Message ID сбрасывается в 0 для новой IKE SA после смены ключей IKE SA.

Каждая конечная точка IKE SA поддерживает два «текущих» значения Message ID – следующее значение, которое будет использоваться для инициируемого этой точкой запроса и следующее значение, которое она ожидает увидеть в запросе с другой стороны. Эти счетчики инкрементируются по факту генерации или получения запроса. Отклики всегда содержат значения Message ID из соответствующего запроса. Это значит, что после начального обмена каждое целочисленное значение n может появляться в качестве Message ID четырех разных сообщений – n-го запроса от исходного инициатора IKE, соответствующего отклика, n-го запроса от исходного ответчика IKE и соответствующего отклика. Если две стороны передают существенно различающиеся количества запросов, значения Message ID для каждого из направления будут сильно отличаться. Здесь не возникает какой-либо неоднозначности, поскольку флаги Initiator и Response в заголовках сообщений позволяют идентифицировать каждое из четырех сообщений с совпадающими идентификаторами.

В этом документе термин «инициатор» указывает сторону, которая начинает описываемый обмен сообщениями. Исходным инициатором называется сторона, начавшая обмен, который привел к организации текущей IKE SA. Иными словами, если исходный инициатор начинает смену ключей IKE SA, он остается исходным инициатором и для новой IKE SA.

Отметим, что значения ID защищаются криптографически, что позволяет предотвратить повторное использование сообщений. В маловероятной ситуации, когда значения Message ID перестают помещаться в 32 бита, IKE SA должна быть закрыта или ключи сменены.

2.3. Размер окна для перекрывающихся запросов

Уведомление SET_WINDOW_SIZE говорит о том, что передавшая его точка способна сохранять состояния для множества продолжающихся обменов, что позволяет получателю уведомления передавать множество запросов до получения отклика на первый запрос. Данные, связанные с уведомлением SET_WINDOW_SIZE, должны иметь размер 4 октета и указывать число (порядок битов big endian) сообщений, которые отправитель уведомления обещает сохранять. Размер окна всегда равен 1 до завершения начального обмена.

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

После организации IKE SA для повышения производительности IKE конечная точка IKE может вводить множество запросов до получения ответа на какой-либо из них – число незавершенных запросов ограничено установленным партнером значением SET_WINDOW_SIZE. Эти запросы могут передаваться через сеть один за другим. Конечная точка IKE должна быть готова к восприятию и обработке запроса при наличии у нее запроса, обработка которого еще не завершена, для того, чтобы в таких ситуациях не возникало блокировки. Конечная точка IKE может также воспринимать и обрабатывать множество запросов при наличии у нее запросов с незавершенной обработкой.

Для конечных точек IKE недопустимо превышение заданного партнером размера окна при передаче запросов IKE. Иными словами, если ответчик указал размер окна N, а инициатору нужно отправить запрос X, он должен дождаться, пока будут получены отклики на все запросы вплоть до X-N. Конечная точка IKE должна сохранять копию (или обеспечивать возможность точного восстановления) каждого переданного запроса, пока не будет получен соответствующий отклик. Конечная точка IKE должна сохранять копию (или обеспечивать возможность точного восстановления) для ранее отправленных откликов в количестве не менее заявленного ею размера окна на случай потери отправленных откликов и получения от инициатора повторного запроса.

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

Размер окна является обычным (возможно, настраиваемым) параметром конкретной реализации и не связан с контролем насыщения (как размер окна TCP). В частности, поведение ответчика при получении уведомления SET_WINDOW_SIZE с размером окна меньше текущего значения не определено. Т. е., в настоящее время не существует способа снижения размера окна для существующих IKE SA, окно можно лишь увеличивать. При смене ключей IKE SA новая IKE SA работает с размером окна, равным 1, пока окно явно не будет увеличено новым уведомлением SET_WINDOW_SIZE.

Уведомление INVALID_MESSAGE_ID передается в случае получения сообщения со значением IKE Message ID, выходящим за пределы поддерживаемого окна. Такие уведомления недопустимо передавать в откликах и недопустимо подтверждать некорректный запрос. Вместо этого следует информировать другую сторону с помощью обмена INFORMATIONAL, в котором данные Notification содержат 4 октета некорректного значения Message ID. Передача такого уведомления является необязательной и скорость отправки таких уведомлений должна быть ограничена.

2.4. Синхронизация состояний и тайм-ауты соединений

Конечным точкам IKE можно в любой момент забывать все данные о состоянии IKE SA и соответствующих Child SA. Такое поведение является ожидаемым в случаях аварий или перезагрузки конечной станции. При отказе или повторной инициализации конечной точки важно, чтобы другая сторона могла детектировать это и не расходовать пропускную способность сети на передачу пакетов через разорванные связи SA (отправку в «черную дыру»).

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

Поскольку протокол IKE разработан с учетом возможности DoS-атак из сети, конечным точкам недопустимо принимать решение об отказе другой стороны соединения на основании какой-либо маршрутной информации (например, сообщений ICMP) или сообщений IKE, приходящих без криптографической защиты (например, сообщений Notify, говорящих о неизвестных SPI). Конечная точка должна принимать решение об отказе другой стороны только после того, как продолжающиеся попытки контакта оставались безответными в течение заданного времени или после получения криптографически защищенного уведомления INITIAL_CONTACT, полученного через другую IKE SA от того же аутентифицированного узла. Конечной точке следует предполагать возможность аварии на другой стороне на основании маршрутной информации и в таких случаях инициировать запрос с целью проверки жизнеспособности другой стороны. Для такой проверки в IKE служат пустые сообщения INFORMATIONAL, на которые (как и на все прочие сообщения IKE) требуется ответ (отметим, что в контексте IKE SA «пустое» сообщение включает заголовок IKE, за которым следует поле Encrypted, не содержащее данных). Если криптографически защищенное (свежее, а не повторное) сообщение было недавно получено от другой стороны, незащищенные сообщения Notify можно игнорировать. Реализации должны ограничивать скорость, с которой могут предприниматься действия в ответ на получение незащищенных сообщений.

Число попыток и продолжительность ожидания не задаются этой спецификацией, поскольку они не оказывают влияния на интероперабельность. Предлагается повторять попытки не менее нескольких десятков раз в течение периода в несколько минут, но требования разных сред могут отличаться. В соответствии с сетевым этикетом интервалы повтора должны увеличиваться экспоненциально, чтобы избежать лавинной загрузки сети и усугубления имеющихся перегрузок. Если во всех SA, связанных с IKE SA, был только исходящий трафик, важно подтвердить жизнеспособность другой стороны во избежание передачи пакетов в «черную дыру». Если через IKE SA или какую-либо из дочерних SA в последнее время не было получено ни одного криптографически защищенного сообщения, следует проверить жизнеспособность другой стороны, чтобы предотвратить отправку сообщений «мертвому» партнеру¹⁸. Получение свежего криптографически защищенного сообщения в IKE SA или любой из дочерних SA подтверждает жизненность IKE SA и всех дочерних SA. Отметим, что это вносит требования к режимам отказов конечных точек IKE. Реализация должна прекратить передачу через все SA, если тот или иной отказ не позволяет прием через все связанные SA. Если система создает Child SA, которые с точки зрения отказов не зависят от других дочерних связей без возможности связанной IKE SA передавать сообщение Delete, система должна согласовывать такие Child SA с использованием разных IKE SA.

Существуют DoS-атаки на инициатора IKE SA, которые можно предотвратить за счет применения на стороне инициатора соответствующих мер. Поскольку два первых сообщения в процессе организации SA не защищены криптографически, атакующий может ответить на сообщение инициатора раньше настоящего ответчика и нарушить процесс организации соединения. Для предотвращения этого инициатор может воспринимать множественные ответы на свое первое сообщение, трактуя каждый из них, как потенциально легитимный, отвечать на них и затем отбрасывать некорректные полуоткрытые соединения после получения корректного криптографически защищенного отклика для одного из своих запросов. Когда получен корректный криптографически защищенный отклик, все последующие отклики следует игнорировать, независимо от корректности их криптозащиты.

Отметим, что при выполнении этих правил не возникает необходимости согласования времени жизни SA. Если IKE предполагает, что партнер умер на основе повторяющегося отсутствия откликов на сообщение IKE, удаляется IKE SA и все организованные в ней Child SA.

Конечная точка IKE может в любой момент удалить неактивные Child SA для освобождения связанных с ними ресурсов. Если конечная точка IKE выбирает удаление Child SA, она должна передать данные Delete на другую сторону для уведомления об удалении. Это действует подобно тайм-ауту для IKE SA. Закрытие IKE SA неявно закрывает все связанные Child SA. В этом случае конечной точке IKE следует передать данные Delete, указывающие на закрытие IKE SA, если другая сторона больше не отвечает.

2.5. Номера версий и совместимость с новыми версиями

В этом документе описана версия 2.0 протокола IKE – значение старшего номера равно 2, младшего – 0. Данный документ является заменой [IKEV2]. Очевидно, что некоторые реализации захотят поддерживать протоколы версии 1.0 и 2.0, а в будущем и других версий.

Значение старшего номера версии следует увеличивать лишь в тех случаях, когда формат пакетов или требуемые действия меняются столь существенно, что старая версия уже не сможет работать с новой, если будет просто игнорировать непонятные ей поля и выполнять действия заданные старой спецификацией. Младший номер версии показывает новые возможности и должен игнорироваться узлами с меньшим значением младшего номера и использоваться с информационными целями узлами с большим значением младшего номера версии. Например, младший номер может показывать возможность обработки недавно определенного типа сообщений Notify. Узел с большим значением младшего номера просто отметит для себя, что его корреспондент с меньшим значением младшего номера не поймет таких уведомлений и, следовательно, их не нужно направлять ему.

Если конечная точка получает сообщение с более высоким, чем у ней, старшим номером версии, она должна отбросить сообщение, ей следует также передать неаутентифицированное сообщение Notify типа INVALID_MAJOR_VERSION, содержащее максимальный (ближайший) поддерживаемый номер версии. Если конечная точка поддерживает старший номер n, а в уведомлении указана версия m, эта точка должна поддерживать все версии от n до m. Если точка получает сообщение с поддерживаемым ею старшим номером версии, она должна отвечать с этим же номером. Чтобы предотвратить согласование парой узлов значения старшего номера меньше максимально поддерживаемого обоими узлами, в IKE имеется флаг, показывающий, что узел способен понимать более высокое значение старшего номера версии.

Таким образом, старший номер версии в заголовке IKE показывает версию, использованную для сообщения, а не максимальную поддерживаемую отправителем версию. Если инициатор способен поддерживать версии n, n+1 и n+2, а ответчик – n и n+1, они согласуют между собой версию n+1 и инициатор будет устанавливать флаг поддержки более высокой версии. Если узлы по ошибке (возможно, в результате атаки) согласуют версию n, тогда оба узла будут видеть, что партнер может поддерживать больший номер версии и должны разорвать соединение, а потом организовать новое с версией n+1.

Отметим, что это правило не выполняется в IKEv1, поскольку для узлов этого протокола не имеет смысла говорить о возможности поддержки большего номера версии. Поэтому активный атакующий способен вынудить два узла, поддерживающих v2, к согласованию v1. Когда поддерживающий v2 узел переходит в режим v1, ему следует отмечать это в системном журнале.

Для совместимости с будущими версиями значения всех резервных полей (RESERVED) должны устанавливаться в 0 реализациями версии 2.0, а на приеме такие реализации должны игнорировать содержимое этих полей («будьте консервативны при передаче и либеральны на приеме» [IP]). В этом случае будущие версии протокола смогут использовать резервные поля, заведомо зная, что их содержимое будет игнорироваться не понимающими данное поле версиями. Аналогично, типы данных (payload type), которые не определены, являются резервом на будущее, реализации версии, где эти типы еще не определены, должны пропускать такие данные, игнорируя их содержимое.

IKEv2 добавляет флаг критичности (critical) в каждый заголовок данных (payload) для совместимости с будущими версиями. Если для нераспознанных данных установлен флаг критичности, сообщение должно быть отвергнуто, а отклик на запрос IKE с такими данными должен включать поле Notify типа UNSUPPORTED_CRITICAL_PAYLOAD, указывающее на наличие неподдерживаемого типа данных. Если флаг критичности отсутствует для неподдерживаемого типа данных, эти данные должны игнорироваться. В элементах данных, передаваемых в откликах IKE, устанавливать флаг критичности недопустимо. Отметим, что флаг критичности применим только к типу поля данных, но не к его содержимому. Если тип данных распознан, но поле содержит что-либо непонятное (например, неизвестное преобразование в элементах данных SA или неизвестный тип уведомления в поле Notify), флаг критичности игнорируется.

Хотя новые типы полей, которые могут быть добавлены в новых версиях, могут чередоваться с полями определенных здесь типов, реализациям следует передавать определенные в этой спецификации данные в порядке, показанном на рисунках разделов 1 и 2. Реализациям недопустимо отвергать, как некорректные, сообщения с иным порядком полей.

2.6. IKE SA SPI и уведомления Cookie

Два первых 8-октетных поля в заголовке пакетов IKE, называемые IKE SPI, служат в качестве идентификаторов соединения в начале пакетов IKE. Каждая конечная точка выбирает одно из двух значений SPI и должна выбрать то, которое будет уникальным идентификатором IKE SA. Нулевое значение SPI имеет специальный смысл – оно показывает, что значение SPI удаленной стороны еще не известно отправителю.

Входящие пакеты IKE отображаются на IKE SA только по значениям SPI, а не по значениям (например) IP-адресов отправителей.

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

Для первого сообщения начального обмена IKE инициатор еще не знает SPI отвечающей стороны и будет, следовательно, устанавливать для поля значение 0. Когда обмен IKE_SA_INIT не завершается созданием IKE SA по причине INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN или COOKIE (см. параграф 2.6), значение SPI ответчика будет нулевым даже в отклике. Однако, если ответчик передает отличное от нуля значение SPI, инициатору не следует отвергать сообщение только по этой причине.

Возможны атаки на IKE путем исчерпания ресурсов состояний и CPU, когда цель атаки забрасывается лавиной запросов инициирования сессий с подставных адресов IP. Эффективность таких атак может быть существенно снижена, если ответчик использует ресурсы CPU по минимуму и не выделяет ресурсов для состояний SA, пока он не знает, что инициатор может получать пакеты, направленные по адресу, с которого был получен запрос.

Когда отвечающая сторона детектирует многочисленные полуоткрытые IKE SA, ей следует отвечать на запросы IKE_SA_INIT откликами с уведомлением COOKIE. Размер данных, связанных с таким уведомлением, должен составлять от 1 до 64 октетов (включительно), а генерация значения описана ниже. Если отклик IKE_SA_INIT включает уведомление COOKIE, инициатор должен повторить запрос IKE_SA_INIT, включив в него уведомление COOKIE, содержащее полученные данные в качестве первого элемента данных и сохранив все прочие элементы неизменными. Начальный обмен в таком случае будет иметь вид

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR(A,0), SAi1, KEi, Ni      -->
                                <--  HDR(A,0), N(COOKIE)
   HDR(A,0), N(COOKIE), 
     Sai1, KEi, Ni              -->
                                <--  HDR(A,B), SAr1, Ker, Nr, [CERTREQ]
   HDR(A,B), SK {IDi, [CERT,] 
     [CERTREQ,] [IDr,] AUTH, 
     SAi2, TSi, TSr}            -->
                                <--  HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Два первых сообщения не оказывают никакого влияния на состояние инициатора и ответчика, за исключением того, что осуществляется обмен cookie. В частности, порядковые номера 4 первых сообщений будут иметь нулевые значения, а порядковые номера в двух последних сообщениях будут иметь значение 1. В приведенной схеме обмена сообщениями A – значение SPI, выделенное инициатором, а B – значение SPI, выделенное ответчиком.

Реализация IKE может организовать генерацию значений cookie ответчиком таким образом, что это не будет требовать каких-либо сохраненных состояний для проверки приемлемости cookie при получении второго сообщения IKE_SA_INIT. Алгоритмы и синтаксис генерации cookie не оказывают влияния на интероперабельность реализаций и поэтому не рассматриваются здесь. Ниже приводится пример организации конечной точкой частичной защиты от DoS-атак на основе применения cookie.

Хорошим способом является установка ответчиком значения cookie по следующему алгоритму:

   Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

где <secret> – случайным образом сгенерированное секретное значение, известное только ответчику и периодически сменяемое, | указывает на конкатенацию. Значение <VersionIDofSecret> следует менять при каждой смене значения <secret>. Значение cookie может быть рассчитано заново при получении повторного запроса IKE_SA_INIT для сравнения полученного значения с расчетным. Если значения соответствуют, ответчик знает, что значение cookie было сгенерировано после смены значения <secret>, а значение IPi должно совпадать с адресом отправителя в первом запросе. Включение SPIi в создание cookie позволяет организовать множество разных значений для множества параллельных IKE SA (предполагается, что инициатор выбирает уникальные SPIi’). Включение Ni в хэш гарантирует, что атакующий, который видел только сообщение 2, не сможет создать корректное сообщение 3. Встраивание в хэш значения SPIi не позволяет атакующему взять значение cookie от другой стороны и инициировать множество обменов IKE_SA_INIT с разными значениями SPI инициатора (и, возможно, разными номерами портов), которые ответчик мог бы принять за множество узлов, расположенных за одним устройством NAT.

Если в процессе организации соединения значение <secret> было изменено, запрос IKE_SA_INIT может быть возвращен с отличным от текущего значением <VersionIDofSecret>. Ответчик в таком случае может отвергнуть сообщение, отправив новый отклик с другим значением cookie или может сохранять старое значение <secret> в течение некоторого времени после замены и воспринимать значения cookie, созданные с использованием старого секрета. Ответчику не следует воспринимать значения cookie в течение неопределенно долгого периода после замены значения <secret>, поскольку это может ослабить защиту от DoS-атак. Ответчику следует достаточно часто менять значение <secret>, особенно во время атак.

Когда одна сторона получает запрос IKE_SA_INIT со значением cookie, не соответствующим ожидаемому, она должна игнорировать это значение и обрабатывать сообщение, как при отсутствии cookie (обычно это заключается в передаче отклика с новым значением cookie). Инициаторам следует ограничивать число обменов cookie, которые они предпринимают (возможно, путем экспоненциального роста интервала). Атакующий может подделать множество откликов с cookie на сообщение инициатора IKE_SA_INIT и каждое такое сообщение с поддельным cookie будет вызывать передачу двух откликов – один от инициатора к ответчику (который будет отвергать cookie), а второй от ответчика к инициатору с корректным значением cookie.

Следует отметить, что термин cookie появился в документе Karn и Simpson [PHOTURIS] при описании управления ключами в IPsec и получил признание. Фиксированные заголовки протокола ISAKMP¹⁹ [ISAKMP] включают два 8-октетных поля cookie и этот синтаксис используется в протоколах IKEv1 и IKEv2, хотя в IKEv2 эти поля названы IKE SPI, а для cookie выделено отдельное поле в элементе данных Notify.

2.6.1. Взаимодействие COOKIE и INVALID_KE_PAYLOAD

Существуют две основных причины повтора инициатором обмена IKE_SA_INIT – запрос ответчиком cookie и желание ответчика использовать не ту группу Diffie-Hellman, которая была включена в данные KEi. Если инициатор получает от ответчика cookie, он должен принять решение о включении значения cookie только в ближайший повтор IKE_SA_INIT или во все последующие повторы.

Инициатор                         Ответчик
-----------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni -->
                        <-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), 
   SAi1, KEi, Ni        -->
                        <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), 
   SAi1, KEi', Ni       -->
                        <-- HDR(A,B), SAr1, KEr, Nr

Если инициатор включает cookie только в один повтор, в некоторых случаях может потребоваться один дополнительный круговой обход. Это требуется также в тех случаях, когда инициатор включает cookie во все повторы, но ответчик этого не поддерживает. Например, если ответчик включает данные KEi в расчет cookie, он будет отвергать запрос, передавая новое значение cookie.

Если оба партнера включают cookie во все повторы, обмен слегка сокращается, как показано на рисунке.

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

2.7. Согласование криптоалгоритма

Элемент данных типа SA показывают предложение для набора вариантов протоколов IPsec (IKE, ESP, AH) в SA, а также криптоалгоритмов, связанных с каждым протоколом.

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

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

Каждое предложение содержит один протокол. Если предложение принимается, поле SA в отклике должно содержать этот же протокол. Ответчик должен принять одно предложение или отвергнуть все, возвратив сообщение об ошибке. Ошибка указывается типом уведомления NO_PROPOSAL_CHOSEN.

Каждое предложение протокола IPsec содержит не менее одного преобразования, а каждое преобразование содержит тип – Transform Type. Принятый шифронабор должен содержать единственное преобразование каждого типа, включенного в предложение. Например, если предложение ESP включает преобразования ENCR_3DES, ENCR_AES с размером ключа 128, ENCR_AES с размером ключа 256, AUTH_HMAC_MD5 и AUTH_HMAC_SHA, принятый набор должен содержать одно из преобразований ENCR_ и одно из AUTH_. Таким образом, возможны 6 комбинаций.

Если инициатор предлагает обычные шифры с защитой целостности и комбинированные шифры, требуются два предложения. Одно предложение будет включать все обычные шифры с алгоритмами защиты целостности для них, а второе – комбинированные шифры без контроля целостности (комбинированным шрифтам не разрешается включать какие-либо алгоритмы защиты целостности, кроме none).

2.8. Смена ключей

Защищенные связи (SA) IKE, ESP и AH используют секретные ключи, которые следует применять только в течение ограниченного срока для защиты ограниченного объема данных. Это ограничивает время жизни связей SA. Когда срок существования защищенной связи заканчивается, дальнейшее использование SA недопустимо. При наличии потребности может быть организована новая связь SA. Организация SA заново при завершении времени жизни называется сменой ключей (rekeying).

В интересах минимальных реализаций IPsec возможность смены ключей SA без перезапуска всей IKE SA не является обязательной. Реализация может отвергать все запросы CREATE_CHILD_SA в рамках IKE SA. Если срок жизни SA завершился или близок к завершению и попытка смены ключей с помощью описанных здесь механизмов не удается, реализация должна закрыть IKE SA и все дочерние связи (Child SA), а после этого может организовать новые защищенные связи. Реализации могут пожелать замены ключей SA в процессе работы, поскольку это повышает производительность и вероятно снижает число пакетов, теряемых во время смены ключей.

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

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

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

Различие между IKEv1 и IKEv2 заключается в том, что время жизни SA в IKEv1 согласовывалось. В IKEv2 каждая сторона SA отвечает за реализацию своей политики ограничения времени жизни SA и смену ключей SA при необходимости. Если стороны имеют разные правила для времени жизни, смена ключей всегда будет инициироваться стороной с более коротким сроком существования защищенных связей. Если SA была неактивна достаточно долго и если конечная точка не инициировала SA при отсутствии трафика, эта конечная точка может предпочесть закрытие SA (вместо смены ключей) при завершении срока жизни. Это может происходить также в тех случаях, когда после предшествующей смены ключей трафика через SA не было совсем.

Отметим, что в IKEv2 осознанно разрешена организация параллельных SA с общими селекторами трафика между парой конечных точек. Одна из целей этого заключается в поддержке дифференциации качества обслуживания (QoS²⁰) между SA (см. [DIFFSERVFIELD], [DIFFSERVARCH] и параграф 4.1 в [DIFFTUNNEL]). Следовательно, в отличие от IKEv1, комбинация конечных точек и селекторов трафика может не обеспечивать уникальной идентификации SA, организованных между этими точками, поэтому здесь не следует применять удаление SA при смене ключей на основании совпадения селекторов трафика, как это принято в IKEv1.

Возможны интервалы времени (в частности, при наличии потерь пакетов), когда стороны не могут договориться о состоянии SA. Ответчик на CREATE_CHILD_SA должен быть готов к восприятию сообщений в SA до передачи своего отклика на запрос создания – здесь не возникает двусмысленностей для инициатора. Инициатор может начать передачу в SA, как только он обработает отклик. Однако инициатор не может принимать что-либо в новой SA, пока он не получит и не обработает отклик на свой запрос CREATE_CHILD_SA. В таком случая, как ответчик узнает о возможности передачи через созданную SA?

С точки зрения технической корректности и интероперабельности ответчик может начать передачу в SA сразу же после отправки отклика на запрос CREATE_CHILD_SA. В некоторых случаях, однако, это может приводить к ненужному отбрасыванию пакетов, поэтому реализация может задержать такую передачу.

Ответчик может быть уверен в том, что инициатор готов к приему сообщений через SA, если (1) если он получил криптографически защищенное сообщение на другой половине пары SA или (2) новая SA организована в результате смены ключей существующей SA и был получен запрос IKE на закрытие заменяемой SA. При смене ключей SA ответчик продолжает передавать трафик в старую SA, пока не произойдет одно из указанных выше событий. При создании новой SA ответчик может отложить передачу сообщений через нее, пока не получит сообщение через нее или не истечет время ожидания. Если инициатор получает сообщение из SA, для которой он еще не принял отклика на свой запрос CREATE_CHILD_SA, он интерпретирует это, как результат потери пакета и повторяет запрос CREATE_CHILD_SA. Инициатор может передать «холостое» (dummy) сообщение ESP в новую ESP SA, если в его очереди нет сообщений для передачи – это позволит ответчику убедиться в том, что инициатор готов к приему сообщений.

2.8.1. Одновременная смена ключей дочерних SA

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

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

Ниже показано влияние описанного на реализации. Предположим, что хосты A и B имеют пару Child SA с SPI (SPIa1,SPIb1) и обе стороны одновременно начинают смену ключей.

   Хост A                            Хост B
   -------------------------------------------------------------------
   передача req1: N(REKEY_SA,SPIa1),
       SA(..,SPIa2,..),Ni1,..   -->
                                <--  передача req2: N(REKEY_SA,SPIb1), SA(..,SPIb2,..),Ni2
   прием req2                   <--

В этот момент A узнает о начавшейся одновременной смене ключей. Однако он еще не знает, который из обменов будет иметь наименьшее значение nonce, поэтому хост просто зафиксирует этот факт и будет отвечать, как обычно.

   передача resp2: SA(..,SPIa3,..), 
                        Nr1,..  -->
                                -->  прием req1

В этот момент B также узнает об одновременной смене ключей и отвечает, как обычно.

                               <--  передача resp1: SA(..,SPIb3,..), Nr2,..
   прием resp1                 <--
                               -->  прием resp2

В этот момент между хостами будет три Child SA (одна старая и две новых). A и B могут сейчас сравнить значения nonce. Предположим, что меньшим оказалось значение Nr1 из сообщения resp2 – в этом случае B (отправитель req2) удаляет избыточную новую SA, а хост A (инициатор организации SA, для которой менялись ключи) удаляет старую дочернюю связь.

   передача req3: D(SPIa1)  -->
                            <--  передача req4: D(SPIb2)
                            -->  прием req3
                            <--  передача resp3: D(SPIb1)
   прием req4               <--
   передача resp4: D(SPIa3) -->

Смена ключей на этом завершается.

Однако возможна иная последовательность событий, если возникнет потеря пакетов в сети, приводящая к повторам передачи. Смена ключей начинается, как обычно, но первый пакет от хоста A (req1) теряется.

   Хост A                            Хост B
   -------------------------------------------------------------------
   передача req1: N(REKEY_SA,SPIa1), SA(..,SPIa2,..),
       Ni1,..                   -->  (потеряно)
                                <--  передача req2: N(REKEY_SA,SPIb1), SA(..,SPIb2,..),Ni2
   прием req2                   <--
   передача resp2: SA(..,SPIa3,..), 
       Nr1,..                   -->
                                -->  прием resp2
                                <--  передача req3: D(SPIb1)
   прием req3                   <--
   передача resp3: D(SPIa1)     -->
                                -->  recv resp3

С точки зрения хоста B смена ключей завершена, но, поскольку этот хост еще не получил пакет req1 от хоста A, он еще не знает об одновременной смене ключей. Однако A будет повторять передачу сообщения и оно придет хосту B.

   повтор req1                  -->
                                -->  прием req1

Для B это выглядит, как попытка A сменить ключи для SA, которой уже не существует, поэтому B будет отвечать на запрос сообщением о некритической ошибке (например, CHILD_SA_NOT_FOUND).

                                <--  передача resp1: N(CHILD_SA_NOT_FOUND)
   прием resp1                  <--

Когда A получит это сообщение, он уже будет знать об одновременной смене ключей и может просто игнорировать его.

2.8.2. Одновременная смена ключей IKE SA

Возможно, наиболее сложная ситуация возникает при попытке одновременной смены ключей IKE_SA. Текст параграфа 2.8 применим и к таким ситуациям, однако важно обеспечить дочерним связям SA наследование от корректной IKE_SA.

Ситуация, когда обе стороны видят одновременную замену ключей, обрабатывается так же, как для Child SA. После обмена CREATE_CHILD_SA между хостами A и B будет существовать три IKE SA – старая IKE SA и две новых IKE SA. Новую IKE SA с меньшим значением nonce следует удалить создавшему ее узлу, а оставшаяся новая IKE SA должна стать родителем всех Child SA.

Хост A                        Хост B
-------------------------------------------------------------------
передача req1:
   SA(..,SPIa1,..),Ni1,.. -->
                          <-- передача req2: SA(..,SPIb1,..),Ni2,..
                          --> прием req1
                          <-- передача resp1: SA(..,SPIb2,..),Nr2,..
прием resp1               <--
передача req3: D()        -->
                          --> прием req3

В дополнение к обычной ситуации одновременной замены ключей существует специальный случай, когда один из партнеров заканчивает процесс смены ключей до того, как узнает о смене ключей другой стороной. Если одновременная смена ключей замечена только одним из партнеров, избыточные SA не создаются. В этом случае, когда не заметивший одновременной смены ключей партнер получает запрос на смену ключей IKE SA, для которой он уже сменил ключи, ему следует возвращать сообщение TEMPORARY_FAILURE, поскольку это IKE SA, которую он в настоящее время пытается закрыть (независимо от того, успел ли он передать уведомление о закрытии SA). Если партнер, заметивший одновременную смену ключей, получает от другой стороны запрос на удаление старой IKE SA, он понимает, что партнер не обнаружил одновременной смены и может забыть о своей попытке смены ключей.

В этот момент хост B видит запрос на закрытие IKE_SA. Тут не требуется ничего, сверх обычного отклика. Однако в этот момент хосту B следует прекратить повтор передачи req2, поскольку с момента получения хостом A отклика resp3 он будет удалять все состояния, связанные со старой IKE_SA и не сможет отвечать на эти запросы.

                                                     <-- передача resp3: ()

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

2.8.3. Замена ключей IKE SA по сравнению с повторной аутентификацией

Смена ключей IKE SA и повторная аутентификация концептуально различаются в IKEv2. При смене ключей IKE SA организуются новые ключи для IKE SA и сбрасываются счетчики Message ID, но не выполняется повторной аутентификации сторон (элементы AUTH и EAP не используются).

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

IKEv2 не осуществляет какой-либо специальной поддержки для повторной аутентификации, которая выполняется новой IKE SA с нуля (с использованием обменов IKE_SA_INIT/IKE_AUTH без каких-либо элементов REKEY_SA Notify), создания новых Child SA в созданной IKE SA (без элементов REKEY_SA Notify) и удаления имеющейся IKE SA (при этом удаляются и старые дочерние связи – Child SA).

Это означает, что при повторной аутентификации также создаются новые ключи для IKE SA и Child SA. Следовательно, если менять ключи чаще, чем проводить повторную аутентификацию, ситуации, когда «срок аутентификации» короче времени жизни ключей, не возникают.

Хотя создание новой IKE SA может быть инициировано любой из сторон (инициатором или ответчиком исходной IKE SA), использование элементов EAP и/или Configuration на практике означает, что повторная аутентификация будет инициирована той же стороной, что и для исходной IKE SA. IKEv2 в настоящее время не позволяет ответчику в данном случае запросить повторную аутентификацию, однако существуют расширения, добавляющие такую функциональность [REAUTH].

2.9. Согласование селекторов трафика

Когда соответствующая RFC 4301 подсистема IPsec получает пакет IP, который соответствует селектору protect в базе данных SPD²¹, подсистема защищает такой пакет с помощью IPsec. Если SA еще не существует, организация такой связи является задачей IKE. Поддержка SPD системы выходит за пределы IKE, хотя некоторые реализации могут обновлять SPD при работающем IKE (пример сценария приведен в параграфе 1.1.3).

Элементы данных TS²² позволяют конечным точкам обмениваться с партнерами некоторой информацией из своей SPD. Эти данные должны передаваться в IKE из SPD (например, PF_KEY API [PFKEY] использует сообщения SADB_ACQUIRE). Элементы TS задают критерии отбора для пакетов, которые будут пересылаться через вновь созданную SA. В некоторых сценариях это может служить проверкой согласованности SPD, а в других случаях приводить к динамическому обновлению SPD.

В каждом сообщении обмена, создающего пару Child SA, присутствуют два элемента TS и каждый из них содержит один или множество селекторов трафика. Каждый селектор включает диапазон адресов (IPv4 или IPv6), диапазон портов и идентификатор протокола IP.

Первую пару селекторов трафика обозначают TSi²³, а вторую – TSr²⁴. TSi задает адрес отправителя трафика, пересылаемого от инициатора пары Child SA (или получателя трафика, пересылаемого ему). TSr указывает адрес получателя трафика, пересылаемого ответчику пары Child SA (или адрес отправителя трафика, пересылаемого от него). Например, если исходный инициатор запрашивает создание пары Child SA и хочет туннелировать весь трафик из подсети 198.51.100.* на стороне инициатора в подсеть 192.0.2.* на стороне ответчика, инициатор будет включать один селектор трафика в каждое поле TS. TSi будет задавать диапазон адресов (198.51.100.0 — 198.51.100.255), а TSr – диапазон (192.0.2.0 – 192.0.2.255). В предположении, что это предложение приемлемо для ответчика, он будет передавать обратно идентичные элементы TS.

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

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

Чтобы обеспечить ответчику возможность выбора подходящего диапазона в том случае, когда инициатор запрашивает создание SA по причине наличия пакета данных, инициатору следует включить в качестве первого селектора трафика в каждое поле TSi и TSr очень специфичный селектор трафика, включающий адреса из вызвавшего запрос пакета. В нашем примере инициатор будет включать в TSi два селектора трафика – первый с диапазоном адресов (198.51.100.43 – 198.51.100.43) , номером порта и протоколом IP из пакета, а второй с диапазоном (198.51.100.0 – 198.51.100.255) для всех портов и протоколов IP. Инициатор будет просто включать в TSr два селектора трафика. Если инициатор создает пару Child SA не в результате получения пакета, а, например, при старте, здесь может не оказаться специфичных адресов, которые инициатор предпочтет для туннеля. В таком случае первые значения в TSi и TSr могут быть диапазонами, а не конкретными значениями.

Ответчик сужает диапазон следующим образом:

если политика ответчика не позволяет ему принимать никакую часть предложенных селекторов, он отвечает сообщением TS_UNACCEPTABLE Notify;
если политика ответчика позволяет принимать весь трафик, покрываемый селекторами TSi и TSr, сужения диапазона не требуется и ответчик может вернуть те же значения TSi и TSr;
если политика ответчика позволяет принимать первый селектор TSi и TSr, ответчик должен сузить диапазон предложенных селекторов до подмножества, включающего первый выбор инициатора; в приведенном выше примере ответчик может возвратить TSi с адресами (198.51.100.43 – 198.51.100.43) для всех портов и протоколов IP;
если политика ответчика не позволяет принимать первый селектор TSi и TSr, ответчик сужает диапазон до приемлемого подмножества TSi и TSr.

После сужения диапазона может возникнуть несколько приемлемых подмножеств, объединение которых не приемлемо. В таких случаях ответчик выбирает одно из приемлемых подмножеств и может включить в отклик уведомление ADDITIONAL_TS_POSSIBLE, которое информирует о том, что ответчик сузил диапазон полученных селекторов, но приемлемы и другие селекторы в отдельных SA. С этим типом сообщений Notify не связано каких-либо данных. Такие ситуации могут возникать при разной конфигурации инициатора и ответчика. Если обе стороны согласны с гранулярностью туннелей, инициатор никогда не будет запрашивать более широкий туннель, нежели ответчик готов воспринимать.

Вполне возможно, что политика ответчика будет включать множество небольших диапазонов, охватываемых селектором трафика инициатора, но в соответствии с политикой для каждого из этих диапазонов трафик следует передавать через разные SA. В использованном выше примере политика ответчика может требовать организации для каждой пары адресов отдельно согласованной связи Child SA. Если инициатор генерирует запрос не на основе имеющегося для передачи пакета, а (например) при старте, у него не будет достаточно специфичных первых селекторов трафика, помогающих ответчику выбрать корректный диапазон. В этом случае у ответчика не будет возможности определить, какую пару адресов следует включить в этот туннель и он должен будет делать предположение или отвергнет запрос с сообщением SINGLE_PAIR_REQUIRED Notify.

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

Отдельные реализации имеют правила, требующие организации отдельных SA для каждой пары адресов. В результате этого, если для ответчика приемлема только часть TSi и TSr, предложенных инициатором, ему следует сузить диапазон селекторов до приемлемого подмножества, а не использовать SINGLE_PAIR_REQUIRED.

2.9.1. Селекторы трафика, нарушающие свою политику

При создании новой SA инициатор должен избегать предложения селекторов трафика, нарушающих его собственную политику. При нарушении этого правила может отбрасываться допустимый трафик. Если используются декоррелированные правила из [IPSECARCH], таких нарушений не может возникать.

Это лучше всего проиллюстрировать на примере. Предположим, что хост A имеет политику, в соответствии с которой трафик по адресу 198.51.100.66 передается через хост B с использованием шифрования AES, а трафик для остальных адресов сети 198.51.100.0/24 также передается через хост B, но с шифрованием 3DES. Предположим также, что B воспринимает любые комбинации AES и 3DES.

Если хост A предлагает SA, которая использует 3DES и включает TSr с блоком адресов (198.51.100.0-198.51.100.255), это будет приемлемо для хоста B. Хост B может также использовать эту SA для передачи трафика с адреса 198.51.100.66, но такие пакеты будут отбрасываться хостом A, поскольку он требует использования для них шифрования AES. Даже если хост A создаст новую SA только для 198.51.100.66 (использующего AES), хост B может свободно продолжать использование первой SA для этого трафика. В такой ситуации, предлагая SA хосту A, следует соблюдать свою политику и предлагать TSr, содержащий ((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) вместо единого блока.

В общем случае, если (1) инициатор делает предложение «для трафика X (TSi/TSr), создать SA», (2) для некоторого подмножества X’ инициатор на деле не будет принимать X’ через SA и (3) инициатор желает принимать трафик X’ через другую связь SA’ (!=SA), корректный трафик может необоснованно отбрасываться, поскольку ответчик может использовать для трафика X’ как SA, так и SA’ .

2.10. Nonce

Каждое сообщение IKE_SA_INIT содержит значение nonce, которое используется в качестве аргумента криптографической функции. Запросы CREATE_CHILD_SA и отклики CREATE_CHILD_SA также содержат nonce, которые служат для добавления «свежести» методам создания ключей, используемым при генерации ключей для Child SA, а также для обеспечения создания действительно псевдослучайных битов из ключа Diffie-Hellman. Значения nonce, используемые в IKEv2, должны выбираться случайным образом, должны быть размером не менее 128 битов, а также должны быть по размеру не менее половины размера результата согласованной псевдослучайной функции (PRF). Однако инициатор выбирает nonce до того, как узнает результат согласования. По этой причине размер nonce должен быть достаточно велик для всех предлагаемых функция PRF. Если для ключей и nonce используется общий источник случайных чисел, следует принимать меры против компрометации ключей при использовании nonce.

2.11. Адреса и номера портов

IKE работает по протоколу UDP через порты 500 и 4500, неявно устанавливая связь ESP и AH с теми же адресами IP, которые используются IKE. Однако адреса и номера портов во внешних заголовках не защищаются криптографически, а протокол IKE рассчитан также на работу через системы трансляции адресов (NAT²⁵). Реализации должны воспринимать входящие запросы, если номер порта источника отличается от 500 и 4500, а также должны отвечать по адресам и номерам портов, с которых были получены запросы. Реализации должны указывать адрес и номер порта, по которым были получены запросы, в полях адреса и номера порта отправителя передаваемых откликов. Функции IKE идентичны для протоколов IPv4 и IPv6.

2.12. Многократное использование показателей Diffie-Hellman

IKE генерирует ключевой материал, используя эфемерный обмен Diffie-Hellman для достижения преимуществ «совершенной защиты²⁶». Это означает, что после разрыва соединения и забывания соответствующих ключей даже тот, кто сумел записать все данные из соединения и получить доступ ко всем долгосрочным ключам обеих конечных точек, не сможет восстановить ключи, использованные для защиты соединения без перебора всех ключей в пространстве ключей сеанса (brute force search).

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

Поскольку расчет значений Diffie-Hellman требует значительных вычислительных ресурсов, конечная точка может принять решение о неоднократном использовании этих значений DH при организации последующих соединений. Для таких действий имеется несколько разумных стратегий. Конечная точка может менять значения DH периодически, хотя это приведет к некоторому снижению уровня защиты, если срок жизни соединения окажется меньше периода смены значений DH. Можно также отслеживать использование значений DH в каждом соединении и удалять информацию, связанную со значением DH, только после закрытия соответствующего соединения. Это позволит многократно использовать значения DH без снижения уровня защиты но с некоторым ростом издержек на поддержку большего числа состояний.

Решение о многократном использовании значений Diffie-Hellman и режиме такого использования является частным в том смысле, что оно не оказывает влияния на интероперабельность. Реализация, использующая значения DH неоднократно, может запоминать значения DH, использованные другой точкой в прошлых обменах, и при повторном их появлении избежать второй половины расчета. Анализ защиты для этого случая и дополнительное рассмотрение вопросов безопасности при многократном использовании эфемерных ключей Diffie-Hellman приведены в работе [REUSE].

2.13. Генерация ключевого материала

В контексте IKE SA согласуются четыре криптографических алгоритма – алгоритмы шифрования и защиты целостности, группа Diffie-Hellman и псевдослучайная функция (PRF). Функция PRF служит для подготовки ключевого материала, используемого всеми криптоалгоритмами IKE SA и Child SA.

Предполагается, что алгоритмы шифрования и защиты целостности используют ключи фиксированного размера и в качестве ключа может служить произвольное случайно выбранное значение этого размера. Для алгоритмов, способных работать с ключами разного размера, должен задаваться фиксированный размер ключа при согласовании криптографических преобразований (см. определение атрибута преобразования Key Length в параграфе 3.3.5). Для алгоритмов, которые принимают не все значения ключей (таких, как DES или 3DES с четностью ключей), алгоритм выбора ключей из набора произвольных значений должен задаваться криптографическим преобразованием. Для функций защиты целостности на базе хэшированных кодов аутентификации сообщений (HMAC²⁷) фиксированным размером ключа является размер вывода используемой хэш-функции.

Предполагается, что функции PRF воспринимают ключи любого размера, но имеют предпочтительный размер ключей. Этот размер должен использоваться в качестве размера SK_d, SK_pi и SK_pr (см. параграф 2.14). Для функций PRF на базе конструкций HMAC предпочтительный размер ключей равен размеру результата используемой хэш-функции. Остальные типы PRF должны задавать предпочтительный размер ключей.

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

В приведенных ниже примерах | обозначает конкатенацию. Функция prf+ определяется, как

   prf+ (K,S) = T1 | T2 | T3 | T4 | ...

где:

   T1 = prf (K, S | 0x01)
   T2 = prf (K, T1 | S | 0x02)
   T3 = prf (K, T2 | S | 0x03)
   T4 = prf (K, T3 | S | 0x04)
   ...

Этот процесс продолжается, пока на выходе функции prf+ не будет получен полный объем ключевого материала, требуемого для расчета всех нужных ключей. Ключи берутся из результата функции без учета границ (т. е, если требуется 256-битовый ключ AES²⁸ и 160-битовый ключ HMAC, а функция prf генерирует на выход 160 битов, ключ AES будет состоять из T1 и начала T2, а ключ HMAC из остатка T2 и начала T3).

Константа, добавляемая после каждого результата prf, представляет собой один октет. Функцию prf+ не используют для увеличения размера вывода prf более, чем в 255 раз.

2.14. Генерация ключевого материала для IKE SA

Общие (разделяемые) ключи генерируются, как описано ниже. Значение SKEYSEED рассчитывается из значений nonce, передаваемых в процессе обмена IKE_SA_INIT и общего секрета Diffie-Hellman, организованного в процессе этого обмена. Число SKEYSEED используется для расчета семи других секретов – SK_d применяется при генерации новых ключей для Child SA, организуемых в рамках IKE SA, SK_ai и SK_ar служат в качестве ключей алгоритма защиты целостности для аутентификации сообщений при последующих обменах, SK_ei и SK_er применяются для шифрования (и расшифровки) при всех последующих обменах, SK_pi и SK_pr используются при генерации данных AUTH. Размеры SK_d, SK_pi и SK_pr должны совпадать с предпочтительным размером ключей согласованной ранее функции PRF.

SKEYSEED и производные от него значения рассчитываются следующим образом

SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)

(левая часть второго уравнения показывает, что значения SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi и SK_pr берутся в том порядке, в котором создается выход prf+). g^ir является общим секретом из эфемерного обмена Diffie-Hellman. Значение g^ir представляется, как строка октетов в порядке big endian и дополняется при необходимости нулями до требуемого размера. Ni и Nr are представляют собой одноразовые значения nonce, вырезаемые из любых заголовков. В силу исторических причин (для совместимости со старыми версиями) имеется две функции PRF, которые в таком расчете имеют специфическую трактовку. Если согласованной PRF является AES-XCBC-PRF-128 [AESXCBCPRF128] или AES-CMAC-PRF-128 [AESCMACPRF128], только первые 64 бита Ni и первые 64 бита Nr используются при расчете SKEYSEED, а все остальные биты служат для ввода в prf+.

Разные направления потока трафика используют различные ключи. Ключами, служащими для защиты трафика от исходного инициатора являются SK_ai и SK_ei, а ключами для другого направления – SK_ar и SK_er.

2.15. Аутентификация IKE SA

Когда расширяемая аутентификация (см. параграф 2.16) не используется, партнеры аутентифицируются с помощью цифровых подписей (или MAC с использованием дополненного общего секрета, как описано ниже в этом параграфе) для блоков данных. В этих расчетах IDi’ и IDr’ – все данные ID за исключением фиксированного заголовка. Для ответчика подписываемые октеты начинаются с первого октета первого значения SPI в заголовке второго сообщения (отклик IKE_SA_INIT) и заканчивается последним октетом последнего элемента данных во втором сообщении. К этому в конце добавляется (для расчета цифровой подписи) значение nonce инициатора Ni (просто значение, а не содержащий его элемент данных) и prf(SK_pr, IDr’). Отметим, что ни nonce Ni, ни значение prf(SK_pr, Idr’), сами по себе, не передаются. Подобно этому, инициатор подписывает первое сообщение (запрос IKE_SA_INIT), начиная с первого октета первого SPI в заголовке и заканчивая последним октетом последнего элемента данных. В конце этого добавляется (для расчета цифровой подписи) значение nonce ответчика Nr и значение prf(SK_pi, IDi’). Для защиты крайне важно использование в подписи каждой стороны значения nonce другой стороны.

Подписанные инициатором октеты можно описать следующим образом:

   InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
   GenIKEHDR = [ 4 октета со значением 0, если применяется порт 4500 ] | RealIKEHDR
   RealIKEHDR =  SPIi | SPIr |  . . . | Length
   RealMessage1 = RealIKEHDR | RestOfMessage1
   NonceRPayload = PayloadHeader | NonceRData
   InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
   RestOfInitIDPayload = IDType | RESERVED | InitIDData
   MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

Подписанные ответчиком октеты можно описать, как:

   ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
   GenIKEHDR = [ 4 октета со значением 0, если применяется порт 4500 ] | RealIKEHDR
   RealIKEHDR =  SPIi | SPIr |  . . . | Length
   RealMessage2 = RealIKEHDR | RestOfMessage2
   NonceIPayload = PayloadHeader | NonceIData
   ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
   RestOfRespIDPayload = IDType | RESERVED | RespIDData
   MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

Отметим, что в расчет подписи включаются все элементы данных (payload), в том числе и те, которые не определены в данном документе. Если первое сообщение в обмене (например, cookie ответчика и/или другая группа Diffie-Hellman) повторяется несколько раз, подписывается последняя версия сообщения.

Опционально сообщения 3 и 4 могут включать сертификат или цепочку сертификатов, подтверждающих, что ключ, использованный для создания цифровой подписи, относится к имени, указанному в элементе данных ID. Подпись или код MAC будут рассчитываться с использованием алгоритма, диктуемого типом ключа, применяемого подписавшим и указанного в поле Auth Method элемента данных Authentication. Инициатор и ответчик не обязаны использовать для подписи один криптографический алгоритм. Выбор алгоритма зависит от типа имеющихся ключей. В частности, инициатор может использовать общий ключ, а ответчик иметь открытый ключ подписи и сертификат. На практике зачастую (но не обязательно) при использовании общего секрета для аутентификации в обоих направлениях применяется один ключ.

Отметим, что обычной, но зачастую небезопасной практикой является использование общего ключа, полученного из выбранного пользователем пароля без включения иных источников случайных данных. Недостаточная безопасность такого подхода обусловлена тем, что выбираемые пользователями пароли не обеспечивают непредсказуемости, достаточной для предотвращения атак по словарю (приложениям, использующим парольную аутентификацию для загрузки и IKE SA, следует выбирать метод аутентификации из параграфа 2.16, который предотвращает атаки по словарю в режиме off-line). Заранее созданные общие ключи должны обеспечивать уровень непредсказуемости, достаточный для самого сильного из согласуемых ключей. В случае заранее созданного общего ключа (pre-shared key), значение AUTH рассчитывается, как показано ниже.

Для инициатора

      AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <InitiatorSignedOctets>)

Для ответчика

      AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <ResponderSignedOctets>)

где строка «Key Pad for IKEv2²⁹» представляет собой 17 символов ASCII без завершающего null-символа. Общий секрет может иметь переменный размер. Строка заполнения добавляется так, чтобы при создании общего секрета из пароля реализации IKE не требовалось сохранять пароля в открытом виде, а можно было бы сохранить значение prf(Shared Secret,”Key Pad for IKEv2″), которое не может использоваться в качестве эквивалента пароля за пределами IKEv2. Как было отмечено выше, создание общего секрета из пароля не вполне безопасно. Такая конструкция используется в предположении, что люди все равно будут делать это. Интерфейс управления, посредством которого обеспечивается общий секрет, должен воспринимать строки ASCII размером, по крайней мере 64 октета, добавление null-символа завершения перед использованием разделяемого секрета недопустимо. Интерфейс управления может воспринимать другие кодировки символов, если задан алгоритм для представления символов в форме двоичной строки.

Имеется два типа аутентификации EAP³⁰ (см. параграф 2.16), каждый из которых использует разные значения в описанных выше расчетах AUTH. Если метод EAP служит для генерации ключей, главный сеансовый ключ (MSK³¹) при расчете меняется на общий секрет. Для методов, не используемых для генерации ключей, SK_pi и SK_pr заменяются общим секретом в обоих расчетах AUTH.

2.16. Методы EAP

В дополнение к аутентификации с использованием подписей на основе открытых ключей и общих секретов, IKE поддерживает аутентификацию на основе методов, определенных в RFC 3748 [EAP]. Обычно эти методы являются асимметричными (предназначены для аутентификации пользователей на сервере) и могут не быть взаимными. По этой причине такие протоколы обычно используются инициатором для аутентификации самого себя перед ответчиком и должны применяться совместно с аутентификацией на основе подписи с открытым ключом для представления ответчика инициатору. Эти методы часто связывают с механизмами, которые называют «унаследованной аутентификацией³²».

Хотя в этом документе [EAP] упоминается с учетом добавления в будущем новых методов без обновления данной спецификации, некоторые простые вариации здесь рассматриваются. [EAP] определяет протокол аутентификации, требующий переменного числа сообщений. Расширяемая аутентификация реализуется в IKE в форме дополнительных обменов IKE_AUTH, которые должны быть завершены для инициализации IKE SA.

Инициатор                         Ответчик
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni           -->
                             <--  HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] 
   [IDr,] Sai2, TSi, TSr}    -->
                             <--  HDR, SK {IDr, [CERT,] AUTH, EAP }
HDR, SK {EAP}                -->
                             <--  HDR, SK {EAP (успех)}
HDR, SK {AUTH}               -->
                             <--  HDR, SK {AUTH, SAr2, TSi, TSr }

Инициатор показывает желание использовать EAP, опуская поле AUTH в первом сообщении обмена IKE_AUTH (отметим, что это поле требуется для других вариантов аутентификации, поэтому в данном документе не отмечено, как опциональное). Путем включения элемента IDi и исключения AUTH инициатор заявляет свою подлинность, но не подтверждает ее. Если ответчик согласен использовать метод EAP, он помещает элемент EAP в отклик обмена IKE_AUTH и откладывает передачу SAr2, TSi и TSr, пока аутентификация инициатора не будет завершена в следующем обмене IKE_AUTH. Для случая минимального метода EAP организация начальной SA показана на рисунке.

Как указано в параграфе 2.2, при использовании EAP каждая пара изначальных сообщений при организации IKE SA будет использовать увеличивающиеся порядковые номера – сообщения IKE_AUTH первой пары будут иметь номер 1, второй – 2 и т. д.

Для методов EAP, создающих общий ключ в качестве побочного эффекта аутентификации, этот ключ должен использоваться как инициатором, так и ответчиком для генерации данных AUTH в сообщениях 7 и 8 с использованием синтаксиса общих секретов, описанного в параграфе 2.15. Общий ключ от EAP представляет собой поле, которое в спецификации EAP названо MSK. Этот общий ключ генерируется в процессе обмена IKE и его недопустимо использовать для каких-либо целей.

Методы EAP, которые не организуют общего ключа, не следует применять, поскольку они могут быть подвержены MITM-атакам [EAPMITM], если эти методы EAP используются в других протоколах, не использующих аутентифицируемого сервером туннеля. Более подробное обсуждение этой ситуации приводится в разделе «Вопросы безопасности». При использовании методов EAP, не генерирующих общего ключа, элементы AUTH в сообщениях 7 и 8 должны генерироваться с использованием SK_pi и SK_pr, соответственно.

От инициатора IKE SA, использующего EAP, требуется возможность расширения начального протокольного обмена по крайней мере до 10 обменов IKE_AUTH в тех случаях, когда ответчик передает уведомления и/или отклики на приглашение аутентификации. После успешного завершения протокольного обмена, определенного выбранным методом аутентификации EAP, ответчик должен передать элемент EAP, содержащий сообщение Success. При отказе ответчик должен передать элемент EAP, содержащий сообщение Failure. Ответчик может в любой момент прервать обмен IKE, передав элемент EAP с сообщением Failure.

После расширенного обмена данные EAP AUTH должны быть включены в два сообщения после сообщение с EAP Success.

При использовании инициатором аутентификации EAP возможны ситуации, когда содержимое IDi используется только для целей AAA³³ при маршрутизации и выбора используемого метода EAP. Это значение может отличаться от отождествлений, аутентифицированных методом EAP. Важно, чтобы при просмотре правил и принятии решения о предоставлении доступа использовались актуальные аутентифицированные отождествления. Зачастую сервер EAP реализуется на отдельном сервере AAA, который обменивается данными с ответчиком IKEv2. В таких случаях, аутентифицированное отождествление (если оно отличается от данных Idi) будет передаваться от сервера AAA ответчику IKEv2.

2.17. Генерация ключевого материала для Child SA

Одна дочерняя связь Child SA создается обменом IKE_AUTH, а дополнительные Child SA могут создаваться в обменах CREATE_CHILD_SA. Ключевой материал для них генерируется следующим образом

   KEYMAT = prf+(SK_d, Ni | Nr)

Здесь Ni и Nr – значения nonce из обмена IKE_SA_INIT, если это запрос на создание первой Child SA или свежие значения Ni и Nr из обмена CREATE_CHILD_SA для последующих дочерних связей.

Для CREATE_CHILD_SA, включающих обмен Diffie-Hellman, ключевой материал генерируется по формуле

   KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )

где g^ir (new) – общий секрет из эфемерного обмена Diffie-Hellman в данном CREATE_CHILD_SA (представляется, как строка октетов с порядком big endian, дополненная при необходимости нулями в старших битах для получения размера модуля).

Одно согласование CHILD_SA может приводить к организации множества защищенных связей. Связи ESP и AH существуют попарно (по одной для каждого направления), поэтому для этих протоколов создается две SA в одном согласовании Child SA. Кроме того, согласование Child SA может включать некоторые будущие протоколы IPsec в дополнение (или взамен) к ESP или AH (например, ROHC_INTEG [ROHCV2]). В любом случае ключевой материал для каждой Child SA должен браться из расширенного KEYMAT с использованием приведенных ниже правил.

Все ключи для SA, передающих данные от инициатора к ответчику, берутся до ключей для SA обратного направления.
Если согласовано множество протоколов IPsec, ключевой материал для каждой Child SA берется в порядке следования протокольных заголовков в инкапсулированном пакете.
Если протокол IPsec требует множества ключей, порядок их извлечения из ключевого материала SA требуется описать в спецификации протокола. Для ESP и AH в [IPSECARCH] определен следующий порядок – ключ шифрования (если он есть) должен браться из первых битов, а ключ защиты целостности (если он есть) – из оставшихся.

Каждый криптографический алгоритм берет фиксированное число битов ключевого материала, заданное в спецификации или согласованное в данных SA (см описание размеров ключей в параграфе 2.13 и определение алгоритма преобразования Key Length в параграфе 3.3.5).

2.18. Смена ключей IKE SA с помощью обмена CREATE_CHILD_SA

Обмен CREATE_CHILD_SA можно использовать для смены ключей существующей IKE SA (см. параграфы 1.3.2 и 2.8). Новые значения SPI инициатора и ответчика поставляются в полях SPI субструктур Proposal внутри элементов SA (не поля SPI в заголовке IKE). Элементы TS опускаются при смене ключей IKE SA. Значение SKEYSEED для новой IKE SA рассчитывается с использованием SK_d из существующей IKE SA следующим образом:

   SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)

Старая и новая IKE SA могут иметь разные функции PRF. Поскольку обмен, связанный со сменой ключей, происходит в старой IKE SA, для генерации SKEYSEED используется функция PRF из старой IKE SA.

Основной причиной смены ключей IKE SA является предотвращение возможности использования скомпрометированного старого ключевого материала для получения информации о текущих ключах и наоборот. Следовательно, реализации должны выполнять новый обмен Diffie-Hellman при смене ключей IKE SA. Иными словами, для инициатора недопустимо предлагать значение NONE в качестве преобразования Diffie-Hellman, а для ответчика недопустимо принимать такие предложения. Это означает, что для успешного обмена с заменой ключей IKE SA всегда используются элементы данных KEi/KEr.

В новой IKE SA значения счетчиков сообщений должны сбрасываться в 0.

SK_d, SK_ai, SK_ar, SK_ei и SK_er рассчитываются из SKEYSEED, как описано в параграфе 2.14, с использованием SPIi, SPIr, Ni и Nr из нового обмена и функции PRF из новой IKE SA.

2.19. Запрос внутреннего адреса из удаленной сети

Наиболее часто встречающимся сценарием взаимодействия между конечной точкой и защитным шлюзом является необходимость получения конечной точкой IP-адреса из сети, защищенной шлюзом (возможно, динамического). Запрос на получение такого адреса может быть включен в любой запрос на создание Child SA (включая неявный запрос в сообщении 3) с использованием элемента CP. Отметим, однако, что обычно выделяется только один адрес IP в процессе обмена IKE_AUTH. Этот адрес сохраняется по крайней мере до удаления IKE SA.

Инициатор                         Ответчик
-------------------------------------------------------------------
 HDR, SK {IDi, [CERT,]
    [CERTREQ,] [IDr,] AUTH,
    CP(CFG_REQUEST), SAi2,
    TSi, TSr}                -->
                             <--  HDR, SK {IDr, [CERT,] AUTH,
                                     CP(CFG_REPLY), Sar2, TSi, TSr}

Эта функция обеспечивает выделение адреса для удаленного клиента IPsec (IRAC³⁴), пытающегося организовать туннель в сеть, защищенную сервером удаленного доступа IPsec (IRAS³⁵). Поскольку обмен IKE_AUTH создает IKE SA и Child SA, IRAC должен запросить контролируемый сервером IRAS адрес (и, возможно, другую информацию, относящуюся к защищенной сети) в обмене IKE_AUTH. Сервер IRAS может получать адрес для IRAC из любого числа источников типа серверов DHCP/BOOTP³⁶ (протокол загрузки) или выделять его из своего пула.

Во всех случаях данные CP должны помещаться до данных SA. В вариантах протокола с множественными обменами IKE_AUTH данные CP должны помещаться в сообщения, содержащие данные SA.

Вызов CP(CFG_REQUEST) должен включать по крайней мере один атрибут INTERNAL_ADDRESS (IPv4 или Ipv6), но может содержать любое число дополнительных атрибутов, которые инициатор хочет вернуть в отклике.

Пример сообщения от инициатора к ответчику может иметь вид:

   CP(CFG_REQUEST) = INTERNAL_ADDRESS()
   TSi³⁷ = (0, 0-65535,0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535,0.0.0.0-255.255.255.255)

Сообщение от ответчика инициатору:

   CP(CFG_REPLY) = INTERNAL_ADDRESS(192.0.2.202)
     INTERNAL_NETMASK(255.255.255.0)
     INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
   TSr = (0, 0-65535,192.0.2.0-192.0.2.255)

Все возвращаемые значения зависят от реализации. Как можно видеть в приведенных примерах, сервер IRAS может также передать другие атрибуты, которые не были включены в CP(CFG_REQUEST) и может игнорировать любые необязательные атрибуты, которые он не поддерживает.

Ответчику недопустимо передавать CFG_REPLY без получения сначала запроса CP(CFG_REQUEST) от инициатора, поскольку мы не хотим, чтобы сервер IRAS выполнял ненужные просмотры конфигурации в случаях, когда IRAC не может обработать REPLY.

В случаях, когда конфигурация IRAS требует, чтобы элемент CP использовался для данного отождествления IDi, но IRAC не смог передать CP(CFG_REQUEST), сервер IRAS должен отказаться от выполнения запроса и прервать создание Child SA с помощью сообщения об ошибке FAILED_CP_REQUIRED. Это сообщение не относится к критическим для IKE SA и просто приводит к отказу при создании Child SA. Инициатор может исправить ситуацию с помощью нового запроса с элементом Configuration. С сообщением FAILED_CP_REQUIRED не связано каких-либо данных.

2.20. Запрос версии партнера

Узел IKE, желающий узнать версию IKE своего партнера, может использовать описанный ниже метод. Это пример конфигурационного запроса в обмене INFORMATIONAL после организации IKE SA и первой Child SA.

Инициатор                         Ответчик
-------------------------------------------------------------------
HDR, SK{CP(CFG_REQUEST)}     -->
                             <--  HDR, SK{CP(CFG_REPLY)}

CP(CFG_REQUEST)= APPLICATION_VERSION("")

CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")

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

2.21. Обработка ошибок

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

Если ошибка возникает при разборе или обработке отклика, в соответствии с общим правилом не следует передавать в ответ сообщение об ошибке, поскольку отклики не должны вызывать генерации новых запросов (а новый запрос является единственным способом передать ответчику сообщение об ошибке). В случае ошибки при разборе или обработке отклика его получателю следует сбросить состояние IKE (например, передать Delete для SA).

Только отказы при аутентификации (AUTHENTICATION_FAILED и отказ EAP) и сообщения с некорректным форматом (INVALID_SYNTAX) ведут к удалению IKE SA без необходимости использования явного обмена INFORMATIONAL с данными Delete. Другие ошибки могут требовать такого обмена в соответствии с политикой. Если обмен прерывается отказом EAP Failure, уведомление AUTHENTICATION_FAILED не передается.

2.21.1. Обработка ошибок в IKE_SA_INIT

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

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

2.21.2. Обработка ошибок в IKE_AUTH

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

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

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

Если проверка подлинности успешно завершилась в обмене IKE_AUTH, это означает, что связь IKE SA организована, однако при организации Child SA или запросе конфигурационной информации может возникнуть отказ. Такие отказы не ведут к автоматическому удалению IKE SA. В частности, ответчик может включить все элементы, связанные с аутентификацией (IDr, CERT, AUTH) при отправке уведомления об ошибке для дополняемых обменов (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN и т. п.), а инициатору недопустимо на основании этого отказываться от аутентификации. Инициатор может, конечно, по соображениям политики позднее удалить эту IKE SA.

В обмене IKE_AUTH или непосредственно следующим за ним обмене INFORMATIONAL (в случае ошибок при обработке отклика на IKE_AUTH) только уведомления UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX и AUTHENTICATION_FAILED вызывают удаление или отказ от создания IKE SA без использования элемента Delete. Документы расширений могут определять дополнительные уведомления об ошибках, использующие такую семантику, но недопустимо использовать их, пока партнер не указал, что способен их понимать (например, используя данные Vendor ID).

2.21.3. Обработка ошибок после аутентификации IKE SA

После аутентификации IKE SA все запросы с ошибками должны вызывать передачу откликов с уведомлениями об ошибках.

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

Если разбирающий запрос партнер видит, что запрос имеет некорректный формат (после проверки кода аутентификации сообщения и окна), и возвращает уведомление INVALID_SYNTAX, такое уведомление рассматривается обеими сторонами, как критическое и требующее удаления IKE SA без необходимости явного включения элемента Delete.

2.21.4. Обработка ошибок за пределами IKE SA

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

Если узел получает сообщение в порт UDP с номером 500 или 4500 за пределами известного ему контекста IKE SA (и это сообщение не является запросом на организацию новой IKE SA), это может быть результатом недавней аварии на узле. Если сообщение помечено, как отклик, узел может проверить подозрительное событие, но отвечать на сообщение недопустимо. Если сообщение помечено, как запрос, узел может проверить подозрительное событие и может передать отклик на сообщение. Если отклик передается, он должен направляться по адресу IP и с номером порта, которые были указаны в полях отправителя полученного пакета с сохранением значений IKE SPI и Message ID из принятого пакета. Отклик недопустимо защищать криптографически и он должен содержать элемент Notify из INVALID_IKE_SPI. Уведомление INVALID_IKE_SPI показывает, что сообщение IKE было получено для нераспознанного SPI (это обычно говорит о перезагрузке получателя с потерей существовавших IKE SA).

Партнеру, получившему такой незащищенный элемент Notify, недопустимо отвечать на сообщение и недопустимо менять состояние для любой из существующих SA. Сообщение может быть обманным или являться корректным откликом на переданный отвечающему узлу обманный запрос. Узлу следует трактовать такие сообщения (а также сетевые сообщения типа ICMP destination unreachable), как намек на возможное наличие проблем с SA для этого адреса IP и целесообразность проверки жизнеспособности IKE SA. Реализациям следует ограничивать частоту таких проверок, чтобы не оказаться вовлеченным в организацию DoS-атак.

Если ошибка происходит вне контекста запроса IKE (например, узел получает сообщения ESP для несуществующего SPI), узлу следует инициировать обмен INFORMATIONAL с элементом Notify, описывающим проблему.

Узлу, получившему подозрительное сообщение с адреса IP (и номера порта, если используется NAT), с которым он имеет IKE SA, следует передать элемент IKE Notify в обмене IKE INFORMATIONAL через эту связь SA. Получателю недопустимо менять состояние какой-либо SA в результате приема подозрительных сообщений, но можно проверить подозрительные события.

2.22. Компрессия IPComp

Использование компрессии IP [IP-COMP] может быть согласовано в процессе организации Child SA. Хотя сжатие IP включает дополнительный заголовок в каждом пакете и индекс параметров сжатия (CPI³⁸), виртуальная «ассоциация сжатия» не выходит на пределы содержащей ее связи ESP или AH. Эти ассоциации исчезают при завершении соответствующей связи ESP или AH. Они явно не указываются в элементах Delete.

Согласование сжатия IP отделено от согласования криптографических параметров, связанных с Child SA. Узел, запрашивающий Child SA, может анонсировать поддержку одного или множества алгоритмов компрессии а одном или множестве элементов Notify типа IPCOMP_SUPPORTED. Эти сообщения Notify могут включаться только в сообщение, содержащее элемент SA, согласующий Child SA, и показывает желание отправителя использовать IPComp для этой SA. Отклик может показывать приемлемость одного механизма сжатия с помощью элемента Notify типа IPCOMP_SUPPORTED. Такие элементы недопустимо помещать в сообщения, не содержащие полей элементов SA.

Данные, связанные с этим сообщением Notify, включают два октета IPComp CPI, за которыми следует один октет Transform ID, после которого могут включаться атрибуты, размер и формат которых определяется значением Transform ID. Сообщение, предлагающее SA, может содержать множество уведомлений IPCOMP_SUPPORTED для указания разных поддерживаемых алгоритмов. В сообщении, принимающем SA, может указываться не более одного алгоритма.

Имя	Номер	Документ
IPCOMP_OUI	1
IPCOMP_DEFLATE	2	RFC 2394
IPCOMP_LZS	3	RFC 2395
IPCOMP_LZJH	4	RFC 3051

Значения Transform ID приведены в таблице (по состоянию на момент публикации RFC 4306). С тех пор могли появиться новые преобразования, возможно их добавление и после публикации данного документа. Для получения актуальной информации следует обратиться к [IKEV2IANA].

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

Побочным эффектом раздельного согласования IPComp и криптографических параметров является невозможность предложить заданные комбинации шифронаборов и IP Compression.

В некоторых случаях компрессия заголовков ROHC³⁹ может оказаться более подходящей, нежели IP Compression. Документ [ROHCV2] определяет использование компрессии ROHC с IKEv2 и IPsec.

2.23. Работа через NAT

Шлюзы с трансляцией адресов (NAT⁴⁰) являются спорным вопросом. В этом параграфе кратко описано, что и как такие шлюзы делают с трафиком IKE. Многие считают NAT злом и полагают, что не следует разрабатывать протоколы так, чтобы трансляторы работали лучше. IKEv2 задает некоторые не вполне очевидные правила обработки для того, чтобы улучшить работу через NAT.

Существование NAT обусловлено в основном нехваткой адресов IPv4, хотя есть и другие причины. Узлы IP, находящиеся за NAT, могут не иметь уникальных в глобальном масштабе адресов IP, а использовать адреса из неких блоков, обеспечивающих уникальность лишь в пределах расположенной за NAT сети, которые могут одновременно применяться в других сетях, расположенных за другими устройствами NAT. В общем случае узлы, расположенные за NAT, могут взаимодействовать с узлами, расположенными за тем же NAT, и с узлами, имеющими уникальные в глобальном масштабе адреса, но не с узлами, расположенными за другими трансляторами NAT. Из этого правила существуют исключения. Когда расположенные за NAT узлы соединяются с другими узлами в сети Internet, шлюз NAT транслирует IP-адреса отправителей, преобразуя их в некий адрес (адреса), которые будут маршрутизироваться обратно на этот шлюз. Приходящие на шлюз пакеты из сети Internet будут снова транслироваться с заменой адреса получателя на внутренний адрес, чтобы пакет был доставлен нужному узлу за шлюзом.

Системы NAT устроены так, чтобы они оставались «прозрачными» для конечных узлов. Ни программы на узлах за NAT, ни узлы Internet не требуется как-то изменять для работы через NAT. Обеспечение такой прозрачности для некоторых протоколов сложнее, чем для других. Протоколы, включающие в поля данных пакетов IP-адреса конечных точек, не будут работать, пока шлюзы NAT не станут понимать эти протоколы и изменять внутренние поля пакетов, как это делается при трансляции полей заголовков. Однако такое решение по своей природе ненадежно, нарушает требования сетевого уровня и зачастую приводит к возникновению серьезных проблем.

Организация соединений IPsec через NAT вносит свои проблемы. Если соединение организуется в транспортном режиме, замена адресов IP в пакетах будет приводить к отказам при проверке контрольной суммы, а NAT не может ее исправить, поскольку значение контрольной суммы защищено криптографически. Даже в туннельном режиме возникают проблемы с маршрутизацией, поскольку прозрачная трансляция адресов в пакетах AH и ESP требует реализации в NAT специальной логики, которая эвристична и ненадежна по своей природе. По этим причинам в IKEv2 используется инкапсуляция пакетов IKE и ESP в UDP. Такое кодирование менее эффективно, но существенно упрощает обработку в NAT. В дополнение к этому, межсетевые экраны могут быть настроены на пропускание инкапсулированного в UDP трафика IPsec, но не трафика ESP/AH без инкапсуляции (или наоборот).

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

Порт 4500 зарезервирован для инкапсулированных в UDP пакетов ESP и IKE. Конечная точка IPsec, обнаружившая NAT между собой и корреспондентом (как описано ниже), должна передавать весь последующий трафик из порта 4500, для которого устройствам NAT не следует требуется специальной обработки (как и для порта 500).

Инициатор может использовать порт 4500 для IKE и ESP, независимо от информации о наличии NAT в момент организации соединения IKE. Когда любая из сторон использует порт 4500, инкапсуляция ESP в UDP не требуется, но необходимо понимание инкапсулированных в UDP пакетов ESP на стороне приема. Инкапсуляцию UDP недопустимо использовать для порта 500. Если поддерживается NAT-T⁴¹ (т. е., произошел обмен элементами NAT_DETECTION_*_IP в процессе обмена IKE_SA_INIT), все устройства должны быть способны принимать и обрабатывать в любой момент пакеты ESP как с инкапсуляцией в UDP, так и без нее. Каждая сторона может принять решение об использовании инкапсуляции трафика ESP в UDP, независимо от выбора другой стороны. Однако при обнаружении NAT оба устройства должны использовать для пакетов ESP инкапсуляцию в UDP.

Ниже приведены конкретные требования для поддержки работы через NAT [NATREQ] (такая поддержка не является обязательной). В этом параграфе требования с уровнем должны относятся лишь к устройствам с поддержкой работы через NAT.

Инициатор и ответчик IKE должны включить в свои пакеты IKE_SA_INIT элементы Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти элементы могут использоваться для детектирования присутствия NAT между хостами и определения стороны, расположенной за NAT. Элементы размещаются в пакетах IKE_SA_INIT после Ni и Nr (перед необязательным элементом CERTREQ).
Данными, связанными с уведомлением NAT_DETECTION_SOURCE_IP, является сигнатура SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, откуда был передан пакет. Элементов NAT_DETECTION_SOURCE_IP может быть более одного, если отправитель не знает, которая из подключенных сетей будет использоваться для передачи пакетов.
Данными, связанными с уведомлением NAT_DETECTION_DESTINATION_IP, является сигнатура SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда был передан пакет.
Получатель уведомления NAT_DETECTION_SOURCE_IP или NAT_DETECTION_DESTINATION_IP может сравнить полученные значения с сигнатурой SHA-1 для SPI, адресом IP и номером порта отправителя или получателя (соответственно). При несоответствии получателю пакета следует включить работу через NAT. В случаях, когда хэш NAT_DETECTION_SOURCE_IP не совпадает для всех полученных данных NAT_DETECTION_SOURCE_IP, получатель может отвергнуть попытку организации соединения, если работа через NAT не поддерживается. Несоответствие хэша NAT_DETECTION_DESTINATION_IP означает, что система, получившая данные NAT_DETECTION_DESTINATION_IP, расположена за NAT и этой системе следует начать передачу пакетов keepalive, как определено в [UDPENCAPS], система может также отвергнуть попытку организации соединения, если работа через NAT не поддерживается.
Если ни один из полученных элементов NAT_DETECTION_SOURCE_IP не соответствует ожидаемому IP-адресу и порту отправителя из заголовка IP содержащего данные пакета, это означает, что отправившая данные система расположена за транслятором NAT (т. е., кто-то на пути меняет адрес отправителя в исходном пакете на адрес устройства NAT). В таких случаях получившей данные системе следует разрешить динамическое обновление IP-адресов других систем, как описано ниже.
Инициатор IKE должен проверить элементы NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP, если они имеются и, при несоответствии адресам во внешнем пакете, должен туннелировать все будущие пакеты IKE и ESP, связанные с данной IKE SA через порт UDP 4500.
При туннелировании пакетов IKE через порт UDP 4500 4 октета с нулевыми значениями в начале заголовка IKE размещаются сразу после заголовка UDP. При туннелировании пакетов ESP через порт UDP 4500 заголовок ESP следует сразу после заголовка UDP. Поскольку первые 4 октета заголовка ESP содержат SPI и корректное значение SPI не может быть равно 0, это позволяет во всех случаях различать сообщения ESP и IKE.
Реализации должны обрабатывать инкапсулированные в UDP принятые пакеты ESP даже в тех случаях, когда наличие NAT не обнаружено.
Исходные IP-адреса отправителя и получателя, которые нужны в транспортном режиме для расчета контрольной суммы пакетов TCP и UDP (см. [UDPENCAPS]), извлекаются из селекторов трафика, связанных с этим обменом. При работе через NAT селекторы трафика должны содержать в точности один адрес IP, который используется в качестве исходного адреса. Этот вопрос более подробно рассмотрен в параграфе 2.23.1.
В некоторых случаях устройство NAT может удалить отображения, которые продолжают использоваться (например, интервал keepalive слишком велик или транслятор NAT перезагружен). Хост будет видеть это, как будто он получил пакет, прошедший проверку защиты целостности, но имеющий адрес и/или порт, отличающийся от связанного с SA в проверенном пакете. Когда обнаруживается такой прошедший проверку пакет, а хост не поддерживает других методов восстановления типа IKEv2 MOBIKE⁴² [MOBIKE] и не находится за NAT, следует передавать все пакеты (включая повторы) в IP-адрес и порт из проверенного пакета, а также следует сохранить этот адрес и порт, как новую комбинацию для SA (т. е., следует динамически обновить адрес). Находящемуся за NAT хосту не следует выполнять такое динамическое обновление адреса, если проверенный пакет имеет другой адрес/порт, поскольку это может открывать возможность организации DoS-атаки (позволяя атакующему разорвать соединение, отправив единственный пакет). Динамическое обновление адреса следует проводить только в ответе на новый пакет, поскольку в противном случае атакующий сможет вернуться к адресам из старых, повторно использованных пакетов. По этой причине динамическое обновление адресов может выполняться безопасно лишь при включенной защите от повторного использования пакетов. При использовании IKEv2 с MOBIKE описанное выше динамическое обновление будет конфликтовать с используемым MOBIKE способом восстановления для таких ситуаций (см. параграф 3.8 в [MOBIKE]).

2.23.1. Работа через NAT в транспортном режиме

+------+        +------+            +------+         +------+
|Узел- | IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Сервер|
|клиент|<------>|  A   |<---------->|  B   |<------->|      |
+------+        +------+            +------+         +------+

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

В этом сценарии используется два транслятора адресов – NAT A и NAT B. NAT A является динамическим транслятором, который отображает клиентские адреса отправителя IP1 в IPN1. NAT B – статический транслятор, настроенный так, что входящие соединения для адреса IPN2 отображаются на адрес шлюза IP2 (т. е. адрес получателя IPN2 отображается на IP2). Это позволяет клиентам подключаться к серверу, обращаясь по адресу IPN2. Транслятору NAT B не обязательно быть статическим, но клиент должен знать, по какому адресу он может обращаться к серверу и он может добиться этого, лишь обращаясь по внешнему адресу NAT B (т. е., IPN2). Если NAT B является статическим транслятором, его адрес можно будет просто указать в конфигурации клиента. Другим вариантом может служить поиск адреса с использованием того или иного протокола (типа DNS), но это выходит за рамки IKEv2.

В этом сценарии клиент и сервер настраиваются на работу в транспортном режим для трафика, исходящего от клиента и адресованного серверу.

Когда клиент начинает создание IKEv2 SA и Child SA для передачи трафика серверу, он может иметь инициирующий (триггерный) пакет с адресом отправителя IP1 и адресом получателя IPN2. В его базе полномочий партнеров (PAD⁴³) и SPD должно быть конфигурационное соответствие между этими адресами (или соответствующими шаблонами).

В транспортном режиме используются в точности те же адреса, что в селекторах трафика и внешних заголовках IP пакетов IKE. Для транспортного режима должен применяться в точности один адрес IP в элементах данных TSi и TSr. Может применяться множество селекторов трафика, если имеется, например, множество диапазонов портов, которые хочется согласовать, но все элементы TSi должны использовать диапазон IP1-IP1 в качестве адресов IP и все элементы TSr должны иметь адреса из диапазона IPN2-IPN2. Первому селектору трафика TSi и TSr следует иметь конкретные значения Traffic Selector, включая протокол и номера портов (как значения из пакета, инициировавшего запрос).

NAT A будет менять адрес отправителя в пакете IKE с IP1 на IPN1, а NAT B будет менять адрес получателя пакета IKE с IPN2 на IP2, поэтому по прибытии пакета на сервер он будет иметь точно такие селекторы трафика, какие были переданы клиентом, но адреса IP в пакете IKE будут заменены на IPN1 и IP2.

Когда сервер получает этот пакет, он обычно просматривает базу данных PAD, описанную в RFC 4301 [IPSECARCH], по значению ID и ищет SPD по значениям Traffic Selector. Поскольку IP1 реально ничего не говорит серверу (это адрес клиента за NAT), бесполезно заниматься поиском по этому адресу в транспортном режиме. С другой стороны, сервер не может знать, разрешает ли его политика транспортный режим, пока не будет найдена соответствующая запись SPD.

В этом случае серверу следует сначала проверить, запрашивал ли транспортный режим инициатор, а после этого провести замену адреса в селекторах трафика. Сначала нужно сохранить старый адрес IP из селектора трафика, который позднее будет применяться для корректировки контрольной суммы (IP-адрес в TSi может сохраняться, как исходный адрес отправителя, а IP-адрес в TSr – как исходный адрес получателя). После этого, если другая сторона была определена, как расположенная за устройством NAT, сервер меняет адрес IP в элементе данных Tsi на IP-адрес из поля отправителя принятого пакета IKE (т. е., меняет в TSi адрес IP1 на IPN1). Если определено нахождение серверной стороны за устройством NAT, сервер меняет адрес IP в элементе данных TSr на IP-адрес из поля получателя в принятом пакете IKE (т. е., IPN2 в TSr меняется на IP2).

После замены адреса в селекторах трафика и заголовке IKE UDP будут совпадать и сервер может выполнить поиск в SPD по новым значениям Traffic Selector. Если запись найдена и разрешает транспортный режим, эта запись используется. Если же найденная запись не позволяет использовать транспортный режим, сервер может вернуться к прежним адресам и повторить поиск в базе SPD по исходным селекторам трафика. Если такой поиск даст положительный результат, сервер будет создавать SA в туннельном режиме, используя реальные значения Traffic Selector, переданные другой стороной.

Такая подстановка адресов в транспортном режиме нужна потому, что поиск SPD выполняется с использованием адресов, которые видны локальному хосту. Это также позволяет добавлять записи в базу данных SAD⁴⁴ для проверки точек выхода из туннеля и возврата пакетов с использованием адресов, которые видны стеку локальной операционной системы.

В наиболее общем случае SPD сервера будет включать шаблонные записи, соответствующие адресам, но возможно и включение разных записей SPD (например, для разных известных внешних адресов NAT).

После просмотра SPD сервер будет сужать Traffic Selector на основе найденной в SPD записи. Он будет снова использовать селекторы трафика, в которых уже выполнена подстановка адресов, и возвращать селекторы, имеющие IPN1 и IP2 в качестве адресов IP. Сервер может дополнительно сузить диапазоны номеров протоколов и портов, используемые в селекторах трафика. Запись в базе SAD, создаваемая для Child SA, будет иметь адреса, которые видны серверу (IPN1 и IP2).

При получении клиентом отклика от сервера для Child SA он будет выполнять аналогичную обработку. Если создана SA транспортного режима, клиент может сохранить исходные возвращенные селекторы трафика в качестве исходных адресов отправителя и получателя. Он будет заменять адреса IP в селекторах трафика адресами из заголовка IP в пакете IKE, меняя IPN1 на IP1 и IP2 на IPN2. После этого клиент будет использовать селекторы трафика при сравнении SA с переданными селекторами трафика и организации записи SAD.

Правила для прохождения через трансляторы NAT перечислены ниже.

Для клиентов, предлагающих транспортный режим:

записи TSi должны иметь в точности 1 адрес IP, который должен соответствовать адресу отправителя IKE SA;
записи TSr должны иметь в точности 1 адрес IP, который должен соответствовать адресу получателя IKE SA;
первым селекторам трафика TSi и TSr следует иметь наиболее специфичные Traffic Selector, включая номера протоколов и портов (такие, зак из вызвавшего запрос пакета);
может присутствовать множество элементов TSi и Tsr;
если для SA выбран транспортный режим (т. е., сервер включил в свой отклик уведомление USE_TRANSPORT_MODE):

исходные селекторы трафика сохраняются, как принятые адреса отправителя и получателя;
если сервер расположен за транслятором NAT, адрес IP в TSr заменяется удаленным адресом IKE SA;
если клиент расположен за транслятором NAT, адрес IP в TSi заменяется локальным адресом IKE SA;
выполняется замена адресов до использования этих селекторов трафика до использования в каких-либо целях, за исключением сохранения их исходного содержимого; сюда включается проверка корректности сужения селекторов трафика другой стороной, создание записи SAD и т. п.

Для отвечающих в случае предложения клиентом транспортного режима:

сохраняются адреса IP исходного селектора трафика, как полученные адреса отправителя и получателя на случай необходимости их восстановления с целью использования, как «реальных адресов отправителя и получателя», описанного в [UDPENCAPS], и расчета контрольных сумм TCP/UDP;
если клиент расположен за транслятором NAT, адрес IP в TSi заменяется удаленным адресом IKE SA;
если сервер расположен за транслятором NAT, адрес IP в TSr заменяется локальным адресом IKE SA;
выполняется поиск в базах PAD и SPD с использованием ID и селекторов трафика с замененными адресами;
если в SPD не найдено записи или найденная запись не разрешает транспортный режим, восстанавливаются селекторы трафика с обратной подстановкой адресов; выполняется новый поиск в базах PAD и SPD с использованием ID и селекторов трафика с исходными адресами, а также поиск записи SPD для туннельного режима (с целью перехода в этот режим);
если запись SPD найдена, выполняется обычное сужение селекторов трафика на основе Traffic Selector с подстановкой адресов и записи SPD; полученные в результате селекторы трафика применяются для создания записей SAD и передачи селекторов трафика обратно клиенту.

2.24. Явное уведомление о перегрузке (ECN)

При развертывании туннелей IPsec в соответствии с исходной спецификацией [IPSECARCH-OLD], использование ECN⁴⁵ во внешних заголовках IP было, по сути, невозможно, поскольку при декапсуляции туннеля индикаторы перегрузки ECN, появившиеся в сети, отбрасывались. Поддержка ECN для туннелей IPsec на базе IKEv1 требует множества режимов работы и согласований (см. [ECN]). IKEv2 упрощает ситуацию, вводя требование возможности использования ECN во внешних заголовках IP для всех IPsec SA в туннельном режиме, создаваемых IKEv2. В частности, точки инкапсуляции и декапсуляции туннельных SA, создаваемых IKEv2, должны поддерживать опцию полной функциональности ECN для туннелей, заданную в [ECN], а также должны реализовать инкапсуляцию и декапсуляцию в соответствии с [IPSECARCH] для предотвращения отбрасывания индикации перегрузки ECN.

2.25. Конфликты при обменах

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

Обычно использование размера окна больше 1 ведет к возникновению более сложных ситуаций, особенно при обработке запросов с нарушением порядка. В этом разделе рассматриваются проблемы, которые могут возникнуть даже при размере окна 1, и рекомендуемые решения.

Следует передавать уведомление TEMPORARY_FAILURE в тех случаях, когда принятый запрос временно не может быть выполнен (например, по причине смены ключей). При получении партнером уведомления TEMPORARY_FAILURE ему недопустимо сразу же повторять запрос, он должен дать отправителю время на завершение операции вызвавшей временный отказ. Получатель уведомления может повторить запрос один или множество раз в течение нескольких минут. Если продолжают поступать уведомления TEMPORARY_FAILURE для той же IKE SA по истечении нескольких минут, следует принять решение о наличии рассинхронизации данных о состоянии и закрыть IKE SA.

Следует передавать уведомление CHILD_SA_NOT_FOUND при получении запроса на смену ключей для несуществующей связи Child SA. Связь SA, для которой инициатор пытается сменить ключ, указывается полем SPI в элементе Notify, которое копируется из поля SPI в уведомлении REKEY_SA. При получении уведомления CHILD_SA_NOT_FOUND следует удалить Child SA (если она еще существует) и отправить запрос на создание новой Child SA с нуля (если Child SA еще не существует).

2.25.1. Конфликты во время смены ключей или закрытия дочерних SA

Если пратнер получает запрос на смену ключей Child SA, для которой в данный момент выполняется попытка завершения, ему слудет ответить сообщением TEMPORARY_FAILURE. Если такой запро поступает во время происходящей уже замены ключей, на него следует ответить обычным способом, а также следует подготовиться к последующему закрытию избыточных SA на базе значений nonce (см. параграф 2.8.1). Если приходит запрос смены ключей для отсутствующей Child SA, на него следует ответить сообщением CHILD_SA_NOT_FOUND.

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

При получении запроса на смену ключей IKE SA, в которой происходит создание, смена ключей или закрытие Child SA в данной IKE SA следует отвечать на него сообщением TEMPORARY_FAILURE.

2.25.2. Конфликты во время замены ключей или закрытия IKE SA

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

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

При получении запроса на создание или смену ключей Child SA во время смены ключей IKE SA на него следует отвечать сообщением TEMPORARY_FAILURE. При получении запроса на удаление Child SA во время смены ключей IKE SA следует отвечать обычным способом с элементом Delete.

1Internet Key Exchange – обмен ключами в Internet.

2Security Association.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5IP Security – защита IP.

6Encapsulating Security Payload.

7Authentication Header.

8IP Compression.

9Network address translation.

10Man-in-the-middle – перехват с участием человека.

11Security Parameter Index.

12Message Authentication Code – код аутентификации сообщения.

13По умолчанию для всех Child SA используется туннельный режим.

14Traffic Flow Confidentiality – конфиденциальность потока трафика.

15В оригинале этого параграфа нет и он появился лишь в RFC 7296, отменившем данный документ. Прим. перев.

16Pseudorandom function.

17Хэш и ссылка на оригинал.

18Такую процедуру иногда называют «детектированием мертвого партнера» (dead peer detection или DPD), хотя в реальности происходит детектирование живого партнера.

19Internet Security Association and Key Management Protocol – протокол защищенных связей и управления ключами в Internet.

20Quality of service.

21Security Policy Database – база данных о правилах безопасности.

22Traffic Selector – селектор трафика.

23Traffic Selector-initiator – селекторы трафика инициатора.

24Traffic Selector-responder – селекторы трафика ответчика.

25Network Address Translation.

26Perfect forward secrecy.

27Hashed Message Authentication Code.

28Advanced Encryption Standard.

29Key Pad for IKEv2 – заполнение ключа для IKEv2.

30Extensible Authentication Protocol – расширяемый протокол аутентификации.

31Master session key.

32Legacy Authentication.

33Authentication, Authorization, and Accounting — аутентификация, проверка полномочий и учет.

34IPsec Remote Access Client.

35IPsec Remote Access Server.

36Bootstrap Protocol.

37Селекторы трафика содержат протокол, а также диапазоны портов и адресов.

38Compression parameter index.

39Robust Header Compression – отказоустойчивое сжатие заголовков.

40Network Address Translation.

41Network Address Translation Traversal – прохождение через NAT.

42Mobility and Multihoming — мобильность и многодомность.

43Peer Authorization Database – база данных об уполномоченных партнерах.

44Security Association Database – база данных о защищенных связях.

45Explicit Congestion Notification — явное уведомление о насыщении.

Часть 2