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

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

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

Когда полученный поддерживающей RFC4301 системой IPsec пакет IP соответствует «селектору защиты» в соответствии с SPD, подсистема должна защитить пакет с использованием IPsec. Если SA еще не существует, ее создание является задачей IKE. Поддержка SPD в системе выходит за пределы IKE (см. [PFKEY] в качестве примера протокола), хотя некоторые реализации могут обновлять свои SPD в контакте с работающим IKE (см., для примера, сценарий 1.1.3).

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

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

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

Первый из двух элементов TS называют TSi, а второй — TSr. TSi задает одрес отправителя трафика, пересылаемого от инициатора (или адрес получателя трафика, пересылаемого инициатору) пары CHILD_SA. TSr указывает адрес получателя трафика, пересылаемого ответчика (или адрес отправителя трафика, пересылаемого от ответчика) пары CHILD_SA. Например, если исходный инициатор запрашивает создание пары CHILD_SA и хочет туннелировать весь трафик из подсети 192.0.1.* на своей стороне в подсеть 192.0.2.* на стороне ответчика, инициатор будет включать один селектор трафика в каждый элемент TS. TSi будет задавать диапазон адресов 192.0.1.0 - 92.0.1.255, а TSr — диапазон 192.0.2.0 - 192.0.2.255. Предположим, что предложение будет принято ответчиком — тогда он будет передавать обратно идентичные элементы TS.

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

Политика отвечающей стороны может содержать множество меньших диапазонов, охватываемое предложенным инициатором селектором трафика, причем политика требует передачи трафика для этих диапазонов через разные SA. Продолжим использование приведенных выше для примера адресов. Ответчик может иметь политику, которая позволяет туннелировать эти адреса в направлении инициатора и от него, но может требовать, чтобы для каждой пары адресов независимо согласовывалась CHILD_SA. Если инициатор генерирует свой запрос в ответ на пакет с адреса 192.0.1.43, направленный по адресу 192.0.2.123, у ответчика не будет способа определить, какую пару адресов следует включить в этот туннель и он будет пытаться угадать или отбросить запрос со статусом SINGLE_PAIR_REQUIRED.

Чтобы позволить ответчику выбрать подходящий диапазон в том случае, когда инициатор запрашивает SA в результате получения пакета данных, инициатору следует включить в качестве первого селектора трафика в каждом элементе Tsi и TSr очень специфичный селектор трафика, включающий адреса в пакете, вызвывшем запрос. В нашем примере инициатор будет включать в TSi лва селектора трафика — первый будет содержать диапазон адресов 192.0.1.43 — 192.0.1.43, а также порт отправителя и протокол IP из пакета, а второй — диапазон 192.0.1.0 — 192.0.1.255 со всеми портами и протоколами. Инициатор будет также включать два селектора трафика в TSr.

Если политика отвечающей стороны не позволяет принять весь набор селекторов трафика из запроса инициатора, но позволяет принять первый селектор TSi и TSr, ответчик должен сузить селекторы трафика до подмножества, включающего первый выбор инициатора. В приведенном примере ответчик может возвратить TSi 192.0.1.43 — 192.0.1.43 с поддержкой всех портов и протоколов IP.

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

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

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